Gelöst: Doppelter Status der Keymatic

Deutsche Foren Geräte
#1

Hallo,

mir ist aufgefallen, dass beim setzen des Status auf False (abschließen) andere Variable-Nodes sofort feuern und den neuen Status verbreiten, obwohl dieser noch gar nicht erreicht ist (abgeschlossen). Sofort danach feuern die Variable-Nodes dann wieder mit true (also nicht verschlossen). Und beim erreichen des Endzustandes (verschlossen) wird dann erneut false gefeuert.
Wenn ich mich recht erinnere, hat @sathya mal geschrieben, dass die Kommunikation von Homegear mit den Homematic-Geräten asynchron läuft. Aber gerade bei der Keymatic sollte ich den Status doch sicher kennen und nicht nur den internen Homegear-Status.

Gibt es irgendeine Möglichkeit herauszufinden, ob eine Statusänderung von der internen Homegear-State-Machine kommt, oder direkt vom Gerät empfangen wurde?

In meinem Anwendungsfall möchte ich über blinken informieren, wenn die Tür erfolgreich abgeschlossen wurde. Aber eben auch nur in dem Fall und nicht schon, wenn probiert wird, abzuschließen.

Grüße
Sven

#2

Hallo,

ich habe versucht, dieses generelle Architekturproblem in Software zu lösen. Dabei schien die Node Off-Delay eine ganz brauchbare Lösung: Kommt False (abgeschlossen), warte eine Sekunde ob nicht doch noch ein True (Keymatic noch nicht verschlossen) kommt. Das klappt ganz gut. Jedoch habe ich das gleiche Problem auch in die andere Richtung.

Dabei kam mir der Gedanke, dass ich eigentlich nur den Eingang entprellen will. Hat jemand sowas schon mal erstellt?

Grüße
Sven

#3

Da kann sicher @sathya was zu sagen.

Ich habe die Keymatic nur über node-red/mqtt angebunden und erinnere mich da nicht, irgend ein Problem in der Richtung gehabt zu haben.

#4

Danke für den Tipp. Aber über MQTT werden die Nachrichten auch gesendet. In folgendem Test habe ich die Tür abgeschlossen (STATE=false). Geloggt habe ich hier die Ausgabe der Variable-Node und der MQTT-Node:

11/25/2019, 8:11:29
$message : Object { payload: false, peerId: 13, channel: 1, variable: "STATE", ... }

11/25/2019, 8:11:29
$message : Object { payload: "[false]", topic: "homegear/1234-5678-9abc/json/13/1/STATE" }

11/25/2019, 8:11:29
$message : Object { payload: true, peerId: 13, channel: 1, variable: "STATE", ... }

11/25/2019, 8:11:29
$message : Object { payload: "[true]", topic: "homegear/1234-5678-9abc/json/13/1/STATE", ... }

11/25/2019, 8:11:35
$message : Object { payload: false, peerId: 13, channel: 1, variable: "STATE", ...}

11/25/2019, 8:11:35
$message : Object { payload: "[false]", topic: "homegear/1234-5678-9abc/json/13/1/STATE" }

Hier sieht man gut, dass es kein Unterschied macht, ob die Daten per Variable-Node oder per MQTT reinkommt. Bei beiden wird kurzzeitig False gesendet dann wieder auf True korrigiert und anschließend nach 6 Sekunden korrekt gesetzt…

1 Like
#5

Hallo @avanc,

ja, du kannst erkennen, woher ein Ereignis kommt. Über MQTT geht das im jsonobj-Topic über eventSource. In Node-BLUE über $message['eventSource'] eines variable-in-Knotens.

Viele Grüße

Sathya

1 Like
#6

Hallo @sathya,

das ist echt ein super Hinweis. Das hatte ich bisher noch nicht auf dem Schirm.
Interessanter Weise tritt das Problem mit 0.7.40 auch nicht mehr auf. Ich hatte noch eine alte 0.7.3 9. Ich gelobe Besserung und werde häufiger aktualisieren :slight_smile:
Grüße
Sven

1 Like
#7