So funktioniert Z-Wave: Polling & Wake-Up Intervall

Geschrieben von boomx

Mit diesem kleinen Artikel möchten wir euch ein wenig über die Funktionsweise eures Z-Wave-Netzwerk aufklären und erläutern, was es mit den oben genannten Begriffen auf sich hat.

Um die Begriffe zu erklären, muss bei der Betrachtung grundsätzlich zwischen batterie- & strombetriebenen Geräten unterschieden werden. Beginnen werden wir mit den batteriebetriebenen Geräte, da diese das sogenannte „Aufwach-Intervall“ (engl. Wake-Up Intervall) besitzen.

Wake-Up Intervall

Alle batteriebetriebenen Geräte im Z-Wave-Netzwerk befinden sich grundsätzlich in einem „deep sleep“-Zustand, um die Batterie zu schonen. Dieser Zustand wird auch beim zum Beispiel Öffnen/Schließen einer Tür nicht verlassen, sondern weiterhin beibehalten. Der neue Wert (auf/zu) wird dem Gateway in diesem Fall aktiv mitgeteilt. Nun gibt es aber das sogenannte „Aufwach-Intervall“. Doch was genau hat es damit auf sich?

Das Gerät wacht nach dem definierten Zeit-Intervall auf und meldet sich bei dem Gateway mit einer sogenannten WAKEUP-NOTIFICATION. Damit signalisiert das Gerät, dass es jetzt bereit ist, neue Konfigurationsdaten (Parameter, Assoziationen, Werte) zu empfangen. Das Gerät verweilt kurz in dem Wach-Zustand und sofern keine neuen Konfigurationen übertragen werden, fällt es kurze Zeit später wieder in den oben beschriebenen „deep sleep“-Zustand. Beim Versenden der WAKEUP-NOTIFICATION werden KEINE Werte vom batteriebetriebenen Gerät an das Gateway übermittelt. Die Werte werden aktiv vom Sensor an das Gateway übermittelt; dies kann in den meisten Fällen in den Parametern des Gerätes eingestellt werden. (Zum Beispiel beim MotionSensor die Übermittlung von Temperatur & LUX, Bewegungserkennung wird beim Auslösen gemeldet)

wakeUp_ms

WakeUp-Intervall eines Rauchmelders (21600 Sekunden = 6 Stunden)

Jedes batteriebetriebene Gerät kann zusätzlich auch manuell aufgeweckt werden. Beim MotionSensor von Fibaro passiert dies zum Beispiel über das dreimalige Betätigen des B-Buttons in der Innenseite des Sensors.

Das WakeUP Intervall dient also ausschließlich dazu neue Werte an batteriebetriebene Geräte zu übermitteln. Deshalb kann die Zeit bei Bewegungsmeldern, Türkontakten, usw. relativ hoch (> 6 Stunden) eingestellt werden, wodurch man zum einen Batterieleistung sparen kann und zum anderen den Traffic im Z-Wave-Netzwerk reduziert. Bei Thermostaten sieht dies ein wenig anders aus, hier muss ein Mittelweg zwischen Sparen der Batterieleistung und der Delay-Zeit bei der Übermittlung von neuen Werten eingeschlagen werden. Als guter Wert hat sich hier ein Aufwach-Intervall von 15 Minuten etabliert.

Polling

Die strombetriebenen Geräte in einem Z-Wave-Netzwerk besitzen keinen „deep sleep“-Zustand. Diese sind also dauerhaft „wach“ und warten auf Befehle von dem Gateway. Dadurch werden Konfigurationsänderungen auch direkt an die Geräte übertragen und müssen nicht wie die batteriebetriebenen Geräte aufgeweckt werden (Batteriebetriebene Geräte, welche FLIRS unterstützen, müssen nicht aufgeweckt werden, hier werden die Parameter ebenfalls just-in-time übermittelt). Dies ist auch der Grund, warum nur strombetriebene Geräte als Repeater fungieren können.

polling device

Polling-Einstellungen eines Gerätes auf dem Fibaro HomeCenter 2

Beim Polling werden die Geräte nach einem bestimmten Intervall  (Bei vielen Gateways kann nur ein globales Polling eingestellt werden, bei anderen Gateways kann das Polling individuell für jedes Gerät separat gesetzt werden) abgefragt und strombetriebene Geräte schicken daraufhin auch eine Antwort an das Gateway zurück. Dies führt allerdings zu einer hohen Netzwerkbelastung, sofern dieses Intervall zu gering eingestellt wurde oder sich viele Geräte im Netzwerk befinden.  Das Polling sollte also sehr vorsichtig und selektiv eingesetzt werden, beziehungsweise ist das Polling eigentlich nicht notwendig und bei den meisten Geräten kann auf ein Polling verzichtet werden, da diese selbstständig Zustandsänderungen dem Gateway mitteilen (Gerät muss dazu mit dem Gateway assoziiert sein).

Z-Wave.de hat dazu folgende Tipps zusammengefasst:

  1. Wählen Sie ein sinnvolles Poll-Intervall. Es ist nicht zu empfehlen, öfters als einmal pro Minute zu pollen, Ein 5 Minuten Intervall ist ein sinnvoller Kompromiss.
  2. FLIRS-Geräte sollen nicht gepollt werden!
  3. Wenn verfügbar sollten Geräte so konfiguriert werden, dass sie selbständig und ohne Anforderungen durch den Controller Messwertaktualisierungen senden.
  4. Sensorwerte ändern sich öfters und weniger vorhersagbar wie Zählerwerte. Zählerwerte, die einen Verbrauch wie Gas, Elektroenergie oder Wasser aufsummieren sollten maximal einmal pro Stunde oder noch seltener gepollt werden.
  5. Wenn bereits durch eine Kommandoklasse der Status eines Gerätes ermittelt wird – zum Beispiel durch die Switch Binary Klasse – dann muss eine andere Kommandoklasse – zum Beispiel Basic – gar nicht mehr gepollt werden. Sie würde nur den gleichen Wert zurückliefern.
titel_polling

Globale Polling-Einstellung

Warum erklären wir euch das?

In der letzten Zeit häuften sich Fragen zu auftretenden Delays im Z-Wave-Netzwerk. Hier häufig bei der aktuellsten Version des Fibaro HomeCenter 2. Bei einem Update auf 4.070, beziehungsweise einer späteren Version, kommt es wohl zu Problemen mit Antworten auf eine Polling-Abfrage von strombetriebenen Geräten, wodurch sich diese Delays extrem vergrößern. Dies kann mit den oben erläuterten Maßnahmen häufig behoben werden und mit dem Artikel liefern wir euch auch gleich eine kleine Erklärung dazu ab. Wir hoffen euch hat der etwas tiefere Einblick in die Z-Wave-Welt gefallen. Ihr könnt gerne einen Kommentar hier lassen.

Diesen Blogpost hat geschrieben ...

boomx

18 Kommentare

  • Hi,
    vielen Dank für den Artikel. Ich gehöre auch zu den Geplagten und habe die WakeIp-Intervalle vorhin auf 6 Stunden eingestellt und das Polling bei den strombetriebenen Geräte ganz deaktiviert. Vorhin hatte ich die Situation, dass mein Z-Wave-Netzwerk scheinbar gänzlich "tot" war: es wurden die Statusänderungen aller Fenster- und Türkontakte plötzlich nicht mehr erkannt und dadurch die von diesen Kontakten getriggerten Szenen nicht mehr ausgeführt. Seit dem Neustart des HC2 funktioniert es jetzt erst mal wieder. Kann es hier einen Zusammenhang geben?
    Danke und Gruß.

  • Ja, habe jedes einzelne Modul gerade noch einmal gecheckt. Bei allen strombetriebenen ist das Polling deaktiviert. Die batteriebetriebenen werden alle 18000 Sekunden geweckt, da bei 21600 einige als inaktiv markiert wurden.
    Gruß

  • Danke für die kurzen und gut verständlichen Artikel.

    In einer Fortsetzung wäre es vielleicht gut FLIRS zu erklären. Das sucht nur als Randbemerkung bei strombetriebenen Geräten auf.

    • Hi,

      danke für das Lob.

      Ein Artikel über FLIRS würde wahrscheinlich noch nicht mal 50 Wörter ergeben, deshalb beantworte ich die Frage mal hier:

      Batteriebetriebenen Geräten müssen nach Änderung der Parameter manuell aufgeweckt werden, damit diese Werte aktiv werden. Bei batteriebetriebenen Geräten mit FLIRS werden die Parameter sofort nach dem Abspeichern auf dem Gateway übertragen. Das war es eigentlich auch schon.

      Gruß

  • Hi,

    ein wirklich guter Artikel, der sehr gut beim Verstehen hilft. Trotzdem mache ich scheinbar irgendetwas falsch:
    Mein Aeon Labs Multisensor 6 betreibe ich per Batterie. Das Aufwachintervall ist auf 900s (15 Minuten) eingestellt. Die Daten werden an die Group1 alle 180s (3 Minuten) reportet.
    Wenn ich den Artikel richtig verstanden habe, müsste mein HC2 doch alle 3 Minuten die neuen Werte des Sensors anzeigen, oder? Ich bekomme das Update aber erst nach 15 Minuten.
    Bewegungen werden in Echtzeit erkannt und reportet - so wie es sein soll.

    Losgelöst von Reporting- und Aufwachinterwall: Könnte man eine Szene programmieren, in der der Sensor immer dann neue Daten ermittelt & überträgt, wenn er eine Bewegung erkannt hat?

    Besten Dank.

    Gruß
    Mr.Coffee

    • Hi,

      ein WakeUp-Intervall von 900 Sekunden ist bei einem batteriebetriebenen Modul nicht so gut, dadurch wird nur die Batterie schneller leergesaugt ;)

      Vom Grundsatz her gebe ich dir Recht. Hier wird der Sensor aber intern eine Messung nur alle 15 Minuten vornehmen. Beim Fibaro MotionSensor kann man die Zeit einstellen, nach welcher Zeit eine erneute Messung vorgenommen werden soll. Bei MS6 funktioniert dies leider nicht.

      Nein, dies funktioniert leider nicht.

      Gruß

  • Vielen Dank für die hilfreichen Erläuterungen!
    Ein kleiner Zusatz für Anfänger wie mich (ich bin bei HC2 auf 4.100):
    Es gibt ja bei den Devices meist eine Master ID und ein oder mehrere Slave-IDs.
    Im Tab General eines Devices sieht man beide IDs im Zusammenhang (mit graphischer Relationskante).
    Man kann auf beide untere schwarze Hälften klicken und bekommt dann rechts oben bei ID entweder die eine oder die andere angezeigt.
    Die "Wakeup Intervalls" ändern kann zumindest ich aber nur, wenn ich in Advanced bei der Master-ID gehe,
    Ein Änderungsversuch in der Advanced-Sicht der Slave-ID wird ignoriert (trotz dort angebotenem Save mit "!").
    Ein Teil der Attribute bei Advanced ist scheinbar nur auf der Master-Ebene änderbar und werden an die Slave-IDs vererbt, sind dort sichtbar, aber nicht änderbar.
    Ich hoffe, dass das soweit richtig und allgemeingültig ist und nicht nur durch eine Besonderheit bei mir im System so ist.
    Ansonsten bitte ich einen Erfahrenen hier in der Runde um Korrektur, danke!

  • Hallo Zusammen

    Kurze Frage, wenn die Werte nur alle 3 Minuten übertragen werden und ich einen Aktuellen Wert in einem LUA Script benötige, wie kriege ich diesen?
    Beispiel: ich habe einen Philips HUE Lightstrip der nur eingeschaltet werden soll, wenn das normale Licht (nicht über Fibaro) aus ist. Das hätte ich über den LUX Wert vom Motion Sensor geprüft. Nur klappt das natürlich nicht, wenn das Licht 3 Minuten an sein muss um den LUX Wert upzudaten.
    Gibt es da nicht einen call um den aktuellen LUX Wert bei Bewegung zu holen?

    Danke und beste Grüsse
    Mav

    • Hi,

      die Werte können bei einer bestimmten LUX-Grenzüberschreitung vom MS übertragen werden. Dazu musst du dir mal die Parameter vom MS ansehen. Eine andere Möglichkeit gibt es nicht. Über LUA kann kann nur die API vom HC2 abgefragt werden.

      Gruß

  • Super, vielen Dank hat so geklappt, nur ist im Bad die LUX-Veränderung so klein, dass das nichts nützt. Ich lass den Lightstrip lieber immer laufen egal was für LUX es hat, sonst wird die Batterie zu schnell leer. Arbeite dann einfach mit der Tageszeitvariable.

    Danke und Gruss
    Mav

Gib deinen Senf dazu!

Cookie Consent mit Real Cookie Banner