Neueste Beiträge

Seiten1 2 3 ... 10
#1
Server - Linux / Aw: [Docker / Container] echod...
Letzter Beitrag von FlatTV - 13 Mai 2026, 21:32:28
Oder man legt das Volumen ./alexa-cookie-data:/data gleich nach .fhem/alexa-cookie-data:/data
#2
fronthem / smartVISU / Aw: Neue fronthem-Version v1.2
Letzter Beitrag von wvhn - 13 Mai 2026, 20:45:10
Danke Michael für die Auflösung.

Mir ist hier wichtig für alle Mitleser klarzustellen, dass die Version im master branch weiterhin so funktioniert, wie eh und je.

Wer die weniger getestete, aber für Neuanlagen komfortablere develop-Version verwendet, muss Anpassungen vornehmen, die dann aber nicht zur Master-Version kompatibel sind. Das meinte ich oben mit ,,breaking change".


Gruß
Wolfram
#3
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 13 Mai 2026, 20:24:07
Ich habe die Aussage:

ZitatLeider zeigt mir pv-forecast den ganzen Tag über Verbrauch an, aber nur im Balkendiagramm. In der Flussgrafik stimmen die Werte wenn ich kontrolliere. 

nicht verstanden. Kannst du es nochmal anders beschreiben was du meinst?
Welche Daten zeigen die grauen und blauen Balken im Diagramm?
#4
FHEMWEB / Aw: FW_okDialog wird durch Nav...
Letzter Beitrag von rudolfkoenig - 13 Mai 2026, 20:11:41
Ich kann das Problem mit einem einfachen fhem.cfg (dummy Test) nicht nachstellen.
#5
Sonstiges / Aw: Brauche Hilfe beim Bau ein...
Letzter Beitrag von betateilchen - 13 Mai 2026, 19:49:31
Das Wichtigste funktioniert schon: Die SIP Kommunikation in beide Richtungen und die Auswertung der gewählten Eingabe (*123#)

Du darfst diesen Dateianhang nicht ansehen.

Die ausgehende Fehlermeldung 500 ist die einfachste Variante, das anrufende Telefon zum Auflegen zu bewegen 8)

Code Auswählen
026.05.13 19:46:04 4: minisip: _process.154 Message in:
REGISTER sip:fhem.h5u.de SIP/2.0
Via: SIP/2.0/UDP 192.168.123.20:5060;branch=z9hG4bK-rmdqj26earfz;rport
From: "minisip" <sip:snomd892m@fhem.h5u.de>;tag=pqaprqtvwg
To: "minisip" <sip:snomd892m@fhem.h5u.de>
Call-ID: 28b6046a5d61-24dncbeulwxn
CSeq: 3 REGISTER
Max-Forwards: 70
User-Agent: snomD892/10.1.215.13
Contact: <sip:snomd892m@192.168.123.20:5060>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:9f2ea6dd-3881-4616-8a6b-000413C404BB>";audio;mobility="fixed";duplex="full";description="snomD892";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
Allow-Events: dialog, talk, hold, check-sync
X-Real-IP: 192.168.123.20
Supported: path, gruu
Expires: 3600
Content-Length: 0

2026.05.13 19:46:04 4: minisip: _send_msg.128 Message out:
SIP/2.0 200 OK

2026.05.13 19:47:11 4: minisip: _process.154 Message in:
INVITE sip:*123%23@fhem.h5u.de;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.123.20:5060;branch=z9hG4bK-1o0bnne388bw;rport
From: "minisip" <sip:snomd892m@fhem.h5u.de>;tag=98dch5ijde
To: <sip:*123%23@fhem.h5u.de;user=phone>
Call-ID: 1bb9046ad66d-8wys93m4uced
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: snomD892/10.1.215.13
Contact: "minisip" <sip:snomd892m@192.168.123.20:5060>;reg-id=1
X-Serialnumber: 000413C404BB
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 3600
Min-SE: 90
Content-Type: application/sdp
Content-Length: 489

v=0
o=root 983923464 983923464 IN IP4 192.168.123.20
s=call
c=IN IP4 192.168.123.20
t=0 0
m=audio 56472 RTP/AVP 9 0 8 3 99 111 18 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:IaFzQVRpvef4ageCSg/2mqdhfmSIsREuZUen3wvM
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:99 G726-32/8000
a=rtpmap:111 AAL2-G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

2026.05.13 19:47:11 4: minisip: _send_msg.128 Message out:
SIP/2.0 500 Error

2026.05.13 19:47:11 4: minisip: _process.154 Message in:
ACK sip:*123%23@fhem.h5u.de;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.123.20:5060;branch=z9hG4bK-1o0bnne388bw;rport
From: "minisip" <sip:snomd892m@fhem.h5u.de>;tag=98dch5ijde
To: <sip:*123%23@fhem.h5u.de;user=phone>
Call-ID: 1bb9046ad66d-8wys93m4uced
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: snomD892/10.1.215.13
Contact: "minisip" <sip:snomd892m@192.168.123.20:5060>;reg-id=1
Content-Length: 0

#6
FHEMWEB / FW_okDialog wird durch Navigat...
Letzter Beitrag von phys1 - 13 Mai 2026, 19:45:22
Hallo,

wenn ich aus einem DOIF (Perl-Modus, DeviceName: Test) in einem Block folgendes aufrufe:
Code Auswählen
::FW_directNotify("#FHEMWEB:WEB","FW_okDialog('Meine Nachricht')","");
erscheint der modale FW_okDialog nur Sekundenbruchteile und danach wieder die DeviceOverview Seite.
In der DevTools Console sieht man:

Code Auswählen
19:21:13.117 Rcvd:
fhemweb.js:613 19:21:16.177 Rcvd: ["#FHEMWEB:WEB","FW_okDialog('Meine Nachricht')",""]
Navigated to http://192.168.178.11:8083/fhem?detail=Test&fw_id=
fhemweb.js:613 19:21:16.465 FW_queryValue:{ReadingsVal("Test","action","")}
fhemweb.js:613 19:21:16.466 FW_queryValue:{AttrVal("Test","room","")}
fhemweb.js:613 19:21:16.473 f18.js resize W:853 S:1920
fhemweb.js:613 19:21:16.475 f18.js resize W:853 S:1920
contentScript.js:2 i18next: languageChanged de-DE
contentScript.js:2 i18next: initialized {debug: true, initImmediate: true, ns: Array(1), defaultNS: Array(1), fallbackLng: Array(1), ...}
content-script.js-a8PnzBQ-.js:1 [Smart Unit Converter] Content script loaded
content-script.js-a8PnzBQ-.js:1 [Smart Unit Converter] Smart Unit Converter initialized with state: false
content-script.js-a8PnzBQ-.js:1 [Smart Unit Converter] State changed: false
fhemweb.js:613 19:21:16.565 Inform-channel opened (websocket) with filter Test
fhemweb.js:613 19:21:16.621 Rcvd:
D.h. sofort nach dem Ausführen von FW_okDialog kommt:
Navigated to http://192.168.178.11:8083/fhem?detail=Test&fw_id=
und damit verschwindet der modale Dialog.
Frage: wer löst das Navigated to... aus? fhemweb.js? Und warum wird das ausgelöst?
Kann man das Verhalten eventuell im FHEMWEB Device über ein Attribut ändern?
Das Verhalten ist identisch bei Browsern unter Windows 11 oder Ubuntu.

Andere modale Dialoge von fhem funktionieren ohne Probleme. fhem selbst (aktuelle Version) läuft auf einem RasPi unter Debian Trixie.

Viele Grüße
#7
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Shadow3561 - 13 Mai 2026, 19:45:18
Ich habe mal eine Frage. Ich messe den Verbrauch mit einem Shelly Pro 3EM.
Folgend ist es als Meter definiert
Code Auswählen
ShellyPro_3EM gcon=Active_Power_S:W gfeedin=-gcon contotal=Purchased_Energy_S:Wh feedtotal=Returned_Energy_S:Wh asynchron=1
Leider zeigt mir pv-forecast den ganzen Tag über Verbrauch an, aber nur im Balkendiagramm. In der Flussgrafik stimmen die Werte wenn ich kontrolliere.  Bilder sind angehängt. Was läuft hier falsch? Hat evtl. jemand einen Shelly 3EM eingebunden und kann mir die genaue definition in pv-forecast geben?

Edit:
Wird bei mir der Eigenverbrauch von der PV mitgezählt?
Bild vom Solaredge-Zähler anbei.
Gruss,
Daniel
#8
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 13 Mai 2026, 19:39:37
@Markus, @300P,

Zitatconsumer01 Heizstab 3kW (swprio=100).
consumer02-05 heater je 1000W (swprio=50).
Im Winter wenn morgens die Sonne aufgeht erwartetes Verhalten:
surplus 1000W -> consumer02 schaltet ein.
Anschließend zusätzlich surplus 1000W -> consumer 03 schaltet ein (Gesamtüberschuss (surplus + eingeschaltetete consumer) 2000W).
Weitere 1000W surplus-> consumer 04 schaltet ein (Gesamtüberschuss 3000W). usw.
Dann würde den ganzen Tag consumer02-05 mit niedriger prio an sein, und consumer01 mit höchster prio gar nicht zum Zug kommen ?
Erwartung wäre dass bei einem Gesamtüberschuss von 3000W, dann auf consumer01 mit höchster Prio umgeschaltet wird und die consumer mit niedriger prio dafür ausgeschaltet werden.
Wie 300P schon gefolgert hat, müßte man diese Logik über ctrlUserExitFn unterstützen. Für eine Logik wäre das Setup etwa so.

Definiert sind die Consumer ohne exclgroup, aber mit swprio (02-05 könnte gleich sein, aber ich würde die Reihenfolge mal vorsehen):

consumer01 Heizstab 3000W -> swprio=100, locktime=300
consumer02 heater 1000W -> swprio=50, locktime=300
consumer03 heater 1000W -> swprio=40, locktime=300
consumer04 heater 1000W -> swprio=30, locktime=300
consumer05 heater 1000W -> swprio=20, locktime=300

Wenn zum Start des Tages der Überschuß ansteigt, schalten die consumer 02 bis 05 nacheinander an, da der Überschuß langsam steigt. Sollte er schnell auf über 3000W steigen und noch nicht alle 02-05 an sein, schaltet consumer01 an wegen der höheren prio! Muß man sehen ob das realistisch ist.

Wenn also insgesamt 4000W Überschuß vorhanden ist, sind die consumer 02-05 on und verbrauchen den Überschuß obwohl der Überschuß jetzt reichen würde um consumer01 und ggf. noch einen anderen consumer zu betreiben.

Eine Lösung wäre in ctrlUserExitFn eine kleine Logik zu bauen:

1. prüfe ob alle consumer 02-05 (evtl. 02-04) "on" sind
2. wenn ja, ist eigentlich genügend Überschuß vorhanden um consumer01 zu bereiben -> dann
3. schalte über die entsprechenden Befehle die consumer 02-05 (02-04) aus!

Dh. in diesem Fall werden durch die Logik ctrlUserExitFn alle consumer 02-05 (02-04) am Ende des SF-Zyklus ausgeschaltet sein, der PV-Überschuß wird frei.
Im nächsten Zyklus wird consumer01 aktiviert da genügend PV Überschuß vorhanden ist und er die höchste Prio hat. Damit nicht gleicht einer der consumer 02-05 dazu kommt, haben alle locktime von 5 Minuten nach dem Ausschalten gesetzt.

Sollte die PV nach unten gehen, wird consumer01 unterbrochen und die anderen 02-05 werden beim Hochlauf der PV wieder aktiviert bis die Logik in ctrlUserExitFn wieder greift, die C 02-05 abschaltet und dann consumer01 wieder fortsetzt da ja genug PV vorhanden.

Wenn das Verfahren gefällt, muß man es nur noch in Perl kodieren und testen.

LG,
Heiko
#9
Sonstiges / Aw: Brauche Hilfe beim Bau ein...
Letzter Beitrag von betateilchen - 13 Mai 2026, 19:30:24
Hallo Rudi,

danke, der Schubs in Richtung IO::Socket hilft mir schonmal viel weiter.
#10
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 13 Mai 2026, 19:05:01
@Gisbert,

Zitatbei Sonne/Wolken-Wechsel und den damit sich stark ändernden Einspeisungen kommt es immer zu scheinbar hohen Haus-Verbäuchen im Flussdiagramm, die aber i.d.R. nur einige 100 W betragen.
Was kann man dagegen tun? Vom meinem Deye-Wechselrichter bekomme ich sowohl den Gesamt- als auch den Tagesverbrauch sowie die Leistung zur Verfügung gestellt. Gibt es dafür Eingabemöglichkeiten bei deinem Modul?
Das ist ein typisches Race-Condition Problem. Es wird bei fast allen mehr oder weniger auftreten.
HIer geht es um die Intime-Messungen, d.h. was gerade _jetzt_ erzeugt/verbraucht/gespeichert/eingespeist/bezogen/usw. wird.
Diese Werte werden durch unterschiedlichste Geräte in FHEM geliefertund durch SF ausgelesen.
Das Problem - diese Geräte sind nicht synchronisiert, sie liefern nicht zur gleichen Zeit die gerade aktuellen Daten. SF liest also von allen Geräte Daten deren Erfassungszeit u.U. z.B. 15 Minuten auseinanderliegen, je nachdem wie oft die beteiligten Geräte Daten aktualisieren.
Die Lösung wäre, dass man versucht die Geräte z.B. über ein zentrales notify/at zu synchronisieren falls das überhaupt im jeweiligen Gerätemodul möglich ist und unterstützt wird.
Andere Möglichkeit wäre SF würde alle Geräte nativ abfragen. Das ist schlicht nicht möglich, dann müßte ich ja alle möglichen FHEM Module in SF nachbauen.  ;)

LG,
Heiko 
Seiten1 2 3 ... 10