Nachdem sich unsere Ab-ins-Bett-Szene nach dem Hinzufügen einiger neuer Leuchten etwas verändert/erweitert hat und in der Folge ein sehr seltsames Verhalten zeigte, schaute ich mir die Abarbeitung der Aktions-Pipeline mal etwas genauer an. Dabei bin ich auf ein Kuriosum gestoßen, zu dem ich mich über ein Feedback seitens homee/Developer freuen würde.
Das erwähnte Homeegramm kümmert sich ohne Verzögerung um ein paar andere HG, die gestoppt, aktiviert oder deaktiviert werden. Dann wird im Sekundentakt eine Handvoll weiterer HG gestartet, die die Z-Wave-Beleuchtung für den Weg übers Bad ins Schlafzimmer in den gewünschten Zustand bringt (diese HG schalten nur die Lampen ein/aus, prüfen den Status und wiederholen gegebenenfalls den Befehl – quasi die Kombination aus selbst-implementiertem Watchdog und dem gerne praktizierten Auslagern von Schaltbefehlen in HG zwecks einfacherem Ersetzen von Geräten). Das ist all die Jahre recht gut gegangen und es wird auch heute wieder gut gehen… ach nein: ich habe jetzt ja noch zwei Zigbee-Leuchten hinzugefügt.
Da diese ja auf Funkprotokollebene nicht mit den Z-Wave-Schaltbefehlen kollidieren, kann ich sie parallel abarbeiten und habe daher die entsprechenden Schaltbefehle zu den bestehenden ganz an den Anfang des HG gesetzt. Und da geht das interessante Verhalten los:
- Der Schaltbefehl, der ohne Verzögerung gleich zu Beginn erfolgen soll (Setzen einer Gruppe mit zwei Zigbee-Leuchtmitteln auf Dimmwert 50 %), erfolgt erst nach mehreren Sekunden.
- Der zweite Schaltbefehl, der eigentlich mit einer Sekunde Verzögerung erfolgen soll (Setzen der Leuchtengruppe auf eine bestimmte Farbtemperatur – geht bei den Hue-Leuchtmitteln erst, wenn sie schon eingeschaltet sind), erfolgt auch exakt wie gewünscht eine Sekunde nach Auslösen des HG – was dazu führt, dass er nicht von Hue-Lightstrips angenommen wird und diese so bunt bleiben wie sie zuletzt waren.
- Diese Schaltreihenfolge ist im Tagebuch ganz klar ersichtlich. Es geht also nicht um Verzögerungen auf Funk-Cube-Ebene, sondern die Gruppen- wie auch die Geräteschaltungen werden vom Brain tatsächlich mit unerwarteten Verzögerungen und damit in der falschen Reihenfolge ausgelöst.
Die Reihenfolge wird also umgekehrt, und das sogar mit mehreren Sekunden Abstand.
Ich habe dann einen Test gestartet und herausbekommen, dass sich die ohne Verzögerung anstehende Schaltung (und zwar völlig gleich, ob es um Zigbee, Z-Wave oder eine Gruppe geht) immer weiter nach hinten schiebt, je mehr HB-Stopp/Aktivier/Deaktivier-Kommandos zum gleichen Zeitpunkt erfolgen sollen. Man sieht auch im Tagebuch, dass diese HB-bezogenen Befehle sich über mehrere Sekunden hinziehen und nicht etwa mehr oder weniger zeitgleich erfolgen – da hapert’s wohl etwas mit der Performance. Und erst wenn die alle absolviert sind, wird das Gerät oder die Gruppe geschaltet.
Seltsamerweise betrifft dies jedoch nur die zeitgleich zum Zeitpunkt 0 auszuführenden Kommandos. Der erste Befehl, der mit einer Verzögerung von einer Sekunde erfolgen soll, wird auch genau dann ausgeführt – weitere ebenfalls zu diesem Zeitpunkt zu absolvierenden Befehle reihen sich dann wiederum in diese Schlange ein und werden gegebenenfalls wieder von einem eigentlich um zwei Sekunden verzögerten Befehl überholt.
Bei diesem beobachteten Verhalten kann es also sinnvoll sein, schnell auszuführende Schaltbefehle lieber bei T+1 anzusiedeln, wenn bei T+0 ein paar HG behandelt werden müssen, da sie dann früher ausgelöst werden als wenn man sie ebenfalls bei T+0 programmieren würde.
tl;dr
Offenbar gibt es für jeden Zeitpunkt T+x eine Pipeline, in die alle zu diesem Zeitpunkt zu absolvierenden Kommandos eingereiht werden. Die Abarbeitung dieser Befehle braucht selbst bei simplen Dingen wie „anderes HG aktivieren/deaktivieren/stoppen“ recht lange, so dass sich das bei einer größeren Zahl von Befehlen über einige Sekunden hinziehen kann. Dabei werden HG-bezogene Kommandos offenbar vor Geräte- oder Gruppenschaltbefehlen ausgeführt. Diese verzögerungs-spezifischen Pipelines laufen jedoch unabhängig voneinander parallel ab, so dass beispielsweise ein Befehl bei T+5 Sekunden früher ausgeführt werden kann als einer, der eigentlich schon bei T+2 Sekunden anstand und durch andere, zeitgleich programmierte Kommandos um etliche Sekunden verzögert wird.
Soweit der Befund. Jetzt die Fragen:
- Ist jemand aus der Community schon über dieses Phänomen gestolpert und kann es bestätigen?
- Kann diese Art der Abarbeitung von Kommandos in Hommegrammen seitens homee bestätigt werden? Das wäre für das Erstellen von zuverlässigen Homeegrammen, bei denen es aufs Timing ankommt, nämlich nicht ganz unwichtig.