Hallo allerseits,
ich habe hier ein seltsames Problem.
Bei einem trivialen notify wird die Aktion nicht ausgeführt:
Heizung:Heizgeraet_1_TOB_CGB2_MGK2.6.O.Ruecklauftemperatur.C:.30.0 set Heizung Direkter_Heizkreis_direktes_Warmwasser.57.Programmwahl_Heizkreis 0
Der Trigger wird gestartet - ist im Logfile zu sehen (und die Ausführungszeit ist auch im Webfrontend zu sehen). Ebenso, dass die Aktion ausgeführt wird. Aber: de facto wird sie nicht ausgeführt - auch kein Fehler wird gebracht.
Ich habe absichtlich mal Mist reingeschrieben in den set-Befehl. Dann kamen bei der Ausführung auch die entsprechenden Fehlerhinweise. Dies belegt ebenso, dass grundsätzlich versucht wird, etwas zu machen.
Hier der Auszug aus dem Verbose 5:
2024.03.25 23:16:43 5: Cmd: >trigger Heizung Heizgeraet_1_TOB_CGB2_MGK2.6.O.Ruecklauftemperatur.C: 30.0<
2024.03.25 23:16:43 5: Starting notify loop for Heizung, 1 event(s), first is Heizgeraet_1_TOB_CGB2_MGK2.6.O.Ruecklauftemperatur.C: 30.0
2024.03.25 23:16:43 5: Triggering HeizungWaitVL30
2024.03.25 23:16:43 4: HeizungWaitVL30 exec set Heizung Direkter_Heizkreis_direktes_Warmwasser.57.Programmwahl_Heizkreis 0
2024.03.25 23:16:43 5: Cmd: >set Heizung Direkter_Heizkreis_direktes_Warmwasser.57.Programmwahl_Heizkreis 0<
2024.03.25 23:16:43 4: DbLog logdb - check Device: Heizung , Event: Heizgeraet_1_TOB_CGB2_MGK2.6.O.Ruecklauftemperatur.C: 30.0
2024.03.25 23:16:43 5: DbLog logdb - parsed Event: Heizung , Event: Heizgeraet_1_TOB_CGB2_MGK2.6.O.Ruecklauftemperatur.C: 30.0
2024.03.25 23:16:43 4: DbLog logdb - added event - Timestamp: 2024-03-25 23:16:43, Device: Heizung, Type: WOLF_ISM8I, Event: Heizgeraet_1_TOB_CGB2_MGK2.6.O.Ruecklauftemperatur.C: 30.0, Reading: Heizgeraet_1_TOB_CGB2_MGK2.6.O.Ruecklauftemperatur.C, Value: 30.0, Unit:
2024.03.25 23:16:43 5: End notify loop for Heizung
Die gleiche Aktion in einem at funktioniert astrein. Was ist da los? Warum geht es auf der einen Seite - auf der anderen aber nicht!?
Mir ist das ein Rätsel. Wäre für hilfreiche Tipps dankbar!
Das Problem ist weder "seltsam" noch "ein Rätsel".
Und es ist eigentlich nichtmal ein Problem.
Du versuchst in Deinem notify, ein reading im gleichen device zu setzen, mit dem das notify getriggert wurde. Das ist keine gute Idee.
Hmm, das Event kommt vom gleichen Device, auf das hinterher auch die Aktion ausgeführt wird. Was ist daran böse? Es gibt kein anderes Device, welches hier aktiv sein könnte - das ist so gesehen eine Selbststeuerung.
Oder habe ich da jetzt was missverstanden - kann durchaus sein.
Du hast offenbar noch nicht verstanden, dass man damit u.U. Eine Endlosschleife produzieren kann.
Entkopple die Verarbeitung von der notify-loop, dann wird es funktionieren.
Im einfachsten Fall fügst Du dazu einfach ein "sleep 0.1;" vor dem set-Befehl ein.
Das ist mir durchaus klar, dass man sich da ins Knie schießen kann - nicht nur wegen Endlosschleifen, sondern auch rein funktional. Daher habe ich ja auch bei jedem notify gleich ein disable integriert, sobald es tatsächlich irgend etwas getan hat. Das disable wurde ja auch immer schön ausgeführt - nur die eigentliche Aktion nicht.
Ich habe jetzt mal zusätzlich noch den sleep integriert. Mal sehen, ob es dann wie gewünscht funktioniert.
Danke!
Update:
Das Verhalten hat sich auch mit dem sleep nicht geändert. Jedoch ist mir mittlerweile aufgefallen, dass der Call
set Heizung Direkter_Heizkreis_direktes_Warmwasser.57.Programmwahl_Heizkreis 0
durchaus ausgeführt wird - jedoch unterbleibt der state-Eintrag in der history-Tabelle. Mir ist das gestern nicht aufgefallen, da das Wolf / ISM8 / ebus - System zuweilen sehr träge ist, bis es reagiert geschweige denn eine Rückmeldung gibt. Das macht die Steuerung auch ziemlich aufwändig, zumal es auch mal vorkommt, dass ein gesendeter Befehl (warum auch immer) gar nicht umgesetzt wird. Da muss ich auch mal noch genauer tracen, was da Sache ist.
Gerade deshalb, weil die Schnittstelle, sagen wir mal so, etwas wackelig ist, sind die Logeinträge natürlich noch wichtiger als sie eh schon sind.
Aber ich habe in der Menge der Doku meine ich irgendwo gelesen, dass beim notify state-Einträge unterdrückt werden (zur Loopverhinderung?). Habe ich das noch richtig in Erinnerung? Oder habe ich da was in den falschen Hals bekommen? Zumindest würde das das beobachtete Verhalten erklären.
Danke für die tolle Unterstützung und viele Grüße!
ZitatAber ich habe in der Menge der Doku meine ich irgendwo gelesen, dass beim notify state-Einträge unterdrückt werden (zur Loopverhinderung?).
Sowas gibts nicht, nur die vom betateilchen beschriebene Endlosschleifen-Vermeidung.
Genauer: falls wegen einem Event vom Geraet X ein notify/DOIF/etc ausgefuehrt wird, wo wieder ein Event fuer das gleiche Geraet X erzeugt wird (z.Bsp. durch set/setreading/etc), dann werden fuer dieses zweite Event keine notifies/DOIFs/FileLogs/DbLogs/etc mehr ausgefuehrt.
Damit sehe ich auch keine Notwendigkeit fuer das sleep in dem obigen Beispiel, es sei denn man moechte das durch set erzeugte Event verwenden, z.Bsp. um den Befehl per FileLog/DbLog zu protokollieren.