18

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

by boomx12. April 2016

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.

siio-App
About The Author
boomx
18 Comments
  • 13. April 2016 at 9:50

    Sehr gute Erklärung. Vielen Dank dafür!

  • Ernst
    13. April 2016 at 18:40

    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ß.

    • Ernst
      13. April 2016 at 19:05

      Nachtrag: es waren alle Module betroffen, auch Rollläden, Licht, etc.

      • 13. April 2016 at 22:12

        Kann sein, dass das HC das Netzwerk neu meshed. Wenn du überall das globale Polling bei den einzelnen Geräten deaktiviert hast, sollte es jetzt laufen.

        Gruß

  • Ernst
    14. April 2016 at 20:12

    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ß

    • 14. April 2016 at 22:30

      Die Module sollten nicht als deadnode markiert werden. Auch bei der Aufwachzeit nicht. Klingt eher nach anderen Problemen in deinem Netzwerk.

      Gruß

  • turpit
    15. April 2016 at 7:51

    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.

    • 15. April 2016 at 11:27

      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ß

  • Mr.Coffee
    19. Mai 2016 at 12:04

    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

    • 19. Mai 2016 at 13:34

      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ß

  • nomennescio
    6. November 2016 at 11:45

    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!

  • Oliver
    6. Januar 2017 at 15:07

    Ich finde leider nirgends in meinen Geräten die Funktion Polling. Nur in den Netzwerkeinstellungen habe ich es auf 900 gesetzt

  • Maverick
    1. April 2017 at 0:49

    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

    • 1. April 2017 at 0:53

      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ß

  • Maverick2805
    4. April 2017 at 18:50

    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

Leave a Response