[gelöst] Zigbee2mqtt liefert doppelte Events / Refraktärzeit von Systemvariablen

Es gibt eine starke Verzögerung bei Verwendung von Systemvariablen innerhalb von node-Blue. Ich benutze die Systemvariablen um eine Abstraktionsschicht für MQTT aufzubauen, da ich Systemvariablen von openHAB und von Node-Blue verwenden kann und ich mich mit den Besonderheiten der MQTT Nachrichten nur einmal herumschlagen muss, und nicht bei jeder Verwendung

Leider funktioniert das aktuell nicht mehr zufriedenstellend, da eine starke Verzögerung von mehreren Minuten auftritt. Testweise habe ich das mal wieder auf direkt angebundene MQTT-Nodes umgestellt und sofort ist alles wieder direkt.

Dieser Flow erzeugt und schreibt die Systemvariablen:
image

In der php-Node funktioniert Folgendes:

$path = explode("/", $message['topic']);

$var=$path[1] . "_OCCUPANCY";
switch(strtoupper($message['payload'])) 
{
    case "TRUE": $val=true; break;
    case "FALSE": $val=false; break;
    default: $val=null; break;
}

if (!is_null($val)) 
{
    $hg->setSystemVariable($var, $val);
}
return NULL;

Verwendet wird das nun folgendermassen:

Wird die MQTT-Node verwendet, wird direkt geschaltet, wird die Systemvariable verwendet, passiert erst Minuten später etwas.

Was läuft hier schief?

Was mir noch einfällt, dieses Konzept könnte das Problem auch lösen:

Hey Job,

auf welcher Version bist du gerade unterwegs?
Du schreibst, dass es aktuell nicht mehr zufriedenstellend schnell geht. Lese ich da richtig raus, dass du ein Update auf ein aktuelles nightly gemacht hast und es seither nicht mehr geht?
Mir fällt dazu nur ein, dass Sathya auf PHP8 aktualisiert hat. Geht es mit einer Version vor dem 30.11.?

viele Grüße, Simon

1 Like

Von mir fuer die “MQTT”-Familie ein +1 :wink:

– Micha

1 Like

Hi Sim,

nunja, als ich das gebaut habe, lief das zufriedenstellend. Das ist aber lange her. Mir ist das nur in den letzten Wochen/Monaten aufgefallen, dass die ganzen Zigbee-Bewegungselder nicht mehr so wirklich zeitnah schalten.

Ich hatte das immer auf schlechte Verbindung und übervolles Zigbee-Netzwerk zurückgeführt. Ich habe aber letzte Woche eine neue Instanz mit dem CC2538 Modul von @pmayer aufgesetzt, und dort exakt die gelichen Probleme. Daher habe ich das in den letzten Tagen verfolgt und die wirkliche Ursache herausgefunden.

Also nein, ich kann das nicht auf eine spezielle nightly zurückführen.

Ich habe eher das Gefühl, dass hier ein anderer Mechanismus zu tragen kommt. Z.B., dass die Funktion setSystemVariable nicht direkt einen (node-Blue-)Event triggered, sondern dass die Systemvariablen zyklisch auf Änderungen geprüft werden, und dadurch die Verzögerung auftritt.

2 Likes

Das ist dann was für @sathya . Vielen Dank für dein debugging und die Zeit, die du dafür investiert hast!

Von mit auch ein +1 für eine MQTT Family!

Aber unbedingt mit integriertem JSON-Parseing. Perfekt wäre es mit einer Art DeviceType, dann könnte man für gleiche Geräte einmal die Definition anlegen und dann einfach darauf basierend die Devices.

Beispielsweise habe ich recht viele H801-LED-Stripe-Controller mit Tasmota, da die super-stabil laufen und RGB-CCT können. Bei anderen Usern werden es vermutlich andere Devices sein, aber das Prinzip ist das gleiche!

Apropos Families und weil ich gerade dran denke: Gibt es für Homegear eigentlich irgendwas zum steuern von E1.31 (ArtNet/DMX)? Meine WLED-Controller möchten gern über Homegear gesteuert werden…

Gruß Andreas

1 Like

Hmm,

ich muss mich glaube endlich mal mit ArtNet auseinandersetzen… einen node-red node gibt es, könnte man sicher in node-blue auch machen.

Für WLED könntest du aber auch einfach HTTP API per UDP nehmen. node-blue hat einen UDP-Out-Node seit Längerem.


Und wir haben vor ein paar Monaten die HTTP-API auch auf dem offenen UDP-Port geöffnet:

Aktuell nutze ich für allgemeine Beleuchtungsaufgaben der WLEDs die HTTP-JSON-API und für die Steuerung im Einzel-Pixelbetrieb (z.B. unter dem Bett jede 10.-15. LED auf 1% Weiß als bewegungsabhängiges Nachtlicht) das DMX-Binding von OpenHAB. Letzteres gefällt mir aber nicht richtig, da ich die meisten Grundfunktionen in NodeBlue realisiert habe, da die alte DSL-Rules von OH ziemlich anfällig sind und die neue Skript Engine damals noch sehr jung war.

Die UDP-API muss ich mir mal anschauen, mit der habe ich mich bisher noch nicht beschäftigt.

Im Wohnzimmer soll WLED allerdings in Verbindung mit Hyperion zukünftig auch als Vollraum-Ambilight zum Einsatz kommen, da komme ich glaube ich um E1.31 nicht drum herum und beides parallel soll man soweit ich weiß nicht einsetzen.

1 Like

Aktuell habe ich mein Logging erweitert und es bilden sich Fragezeichen in meinem Hirn.

Der Event kommt zeitnah bei Systemvariablen, trotzdem schalten die Lichter nicht. Es ist als ob die Variable-In-Nodes irgendetwas anders machen als die Mqtt-Nodes, was zu der Verzögerung führt.

Ich muss das definitiv weiter analysieren, im Moment verstehe ich gar nichts mehr… :scream:

1 Like

Verdammt! Refraktärzeit!

Es wird kurz vor dem Event noch der alte Wert erhalten. Dadurch wurde mit einer Refraktärzeit von 200ms der richtige Wert immer verworfen und natürlich funktioniert es dann erst bei dem nächsten Ereignis.

12/18/20 13:18:55.713 Script log (node id: 80f262a1.93923): mqtt received T1MD_OCCUPANCY = false
12/18/20 13:18:55.717 Script log (node id: 80f262a1.93923): var set T1MD_OCCUPANCY = 0
12/18/20 13:18:55.725 Script log (node id: 80f262a1.93923): mqtt received T1MD_OCCUPANCY = true
12/18/20 13:18:55.731 Script log (node id: 80f262a1.93923): var set T1MD_OCCUPANCY = 1
12/18/20 13:18:55.774 Script log (node id: 4834b4f2.3c334c:76f6cc0d.696774): 0: .
12/18/20 13:18:55.831 Script log (node id: 4834b4f2.3c334c:af82a2fc.9ee9d): event received (expire) T1MD_OCCUPANCY = .
12/18/20 13:18:55.836 Script log (node id: 4834b4f2.3c334c:76f6cc0d.696774): 0: 1.
12/18/20 13:18:55.841 Script log (node id: 4834b4f2.3c334c:af82a2fc.9ee9d): event received (expire) T1MD_OCCUPANCY = 1.

Zigbee2mqtt liefert vor dem Ereignis anscheinend noch mal den alten Wert als Ereignis, dadurch scheint der Fehler an zigbee2mqtt zu liegen.

3 Likes