Ein Batterie Device (Sensor oder Actor) muss Strom sparen. Deshalb befindet es sich normalerweise im “deep sleep“. Ein typisches Batterie Sensor Device bleibt relativ lange im deep sleep (meist 10 min bis einige Std.). Wenn es diesen Zustand verlässt, nennt man das bei Z-Wave Wakeup. Das Device informiert dann den Controller über sein
Wakeup. Anschließend wartet es kurz, ob der Controller eine Nachricht übermittelt. Lokale Events werden völlig unabhängig von diesem Wachzustand verarbeitet. Löst beispielsweise ein Bewegungsmelder aus, so schickt das Device sofort eine Status-Nachricht an den Controller. Ähnlich ist das bei periodischen vorgesehenen Zustandsnachrichten (z.B. für Temperaturen).
Ein FLIRS Batterie Device spart auf andere Weise Strom. Auch ein solches Device befindet sich normalerweise im deep sleep. Es kennt jedoch kein Wakeup mit einem WakeupIntervall. Stattdessen geht ein FLIRS Device in sehr kurzen Abständen (1/4 bis 1 sek) aus deep sleep in einen Halbwach-Zustand. In diesem Zustand ist es in der Lage, ein spezielles Beam Signal zu empfangen. Ein Beam Signal wird vom Controller gesendet, wenn er eine Nachricht an das FLIRS Device senden möchte. Das Beam Signal veranlasst das FLIRS Device in den Wachzustand zu wechseln. Nun kann normal kommuniziert werden.
Wakeup Verwaltung bei VERA
- Wakeup Einstellung
Das WakeupInterval wird nur bei den entspr. Device Typen zur Eingabe angezeigt. Meine Einstellungen:
In der Optimierungsphase 1800 sek. Danach für Sensoren 3600 bis 10800 sek und für Heizkörper-Thermostaten: 600 sek. - ConfiguredWakeupInterval
an das Device gemeldete WakeupIntervall in s - WakeupRate
VERA errechnet sich aus dem WakeupIntervall den jeweils nächsten Wakeup Zeitpunkt. VERA überwacht, ob zeitgerecht eine Wakeup Information vom Device kommt. Die WakeupRate ist die Anzahl der ok-Meldungen aus den letzten 50 erwarteten Wakeups (5.00 bedeutet 50 Wakeups waren korrekt, 0.00 bedeutet 0 Wakeups waren korrekt). In meinem stabilisierten Netz mit wenige Neuentwicklung ist 5.00 normal, gelegentlich auch mal 4.80. Bei Veränderungen und bei intensiver Neuentwicklung (häufiges Reload von VERA) können einige Devices auch mal stark abfallen. - LastWakeup
Timestamp der letzten Wakeup-Nachricht - CommFailure (0 oder 1)
Eine Wakeup Fehlermeldung wird 6 h nach der letzten erwarteten und nicht eingetroffenen Wakeup Information gesetzt. Ein CommFailure kann auch aus anderen Gründen entstehen (siehe Z-WAVE: Monitoring + Optimierung).
Abhängigkeiten vom WakeupInterval
- Polling und PollIntervall
PollIntervall <= WakeupIntervall, Einzelheiten siehe „Z-WAVE: Polling“ - Netzreorganisation, Update Neighbors
Veränderte Kommunikationsbeziehungen zu einem Device können erst nach dessen nächstem Wakeup ermittelt werden. Deshalb wirkt das WakeupInterval auf die Geschwindigkeit der Netzwerkreorganisation. Und zwar sowohl auf das Device-spezifische UpdateNeighbors Kommando, als auch auf die automatische Z-Wave Netzwerk-Vermaschung. In großen Netzen kann die Aktualisierung der Vermaschung Stunden und Tage lange dauern. Insbesondere unter Beteiligung mehrerer Sleeping Routing Slaves mit langem WakeupInterval. Siehe dazu auch Z-WAVE Routing und Fehler. - Konfigurations-Parameter
Beispielsweise Änderungen der Z-Wave Parameter übernimmt das Device erst nach dessen nächstem Wakeup. - Einstellungen
Beispielsweise Änderungen des Temperatur Setpoint bei Thermostaten übernimmt das Device erst nach dessen nächstem Wakeup.
Dieser Beitrag gehört zur Themengruppe
Optimierung des Z-WAVE Netzes
Das Z-WAVE Netz beginnt mit der Installation des Z-Wave Controller. Darauf folgt die Inklusion der Devices. Die Z-WAVE Knoten erkennen nun ihre Nachbarn im Netz. So passt sich die Netz Topologie automatisch an. Dieses Verfahren gewährleistet zwar ein lauffähiges Netz. Aber schnell und in jedem Lastzustand robust ist die Kommunikation damit noch nicht. Zuerst muß man noch die Platzierung und die relevanten Einstellungen der Geräte optimieren. Ein Feld der Optimierung: Die Einstellungen für Wakeup, Polling und Nachrichten-Frequenz. Ein weiteres Thema: Die Platzierung des Controller und der Z-WAVE Devices ist heikel. An vielen Stellen stören Dämpfungen oder Interferenzen den Funkverkehr. Das Z-WAVE Netz arbeitet dann zwar grundsätzlich. In bestimmten Situationen ergebe sich jedoch lange Schaltzeiten. Dieser Effekt resultiert aus langen Signalwegen über mehrere Knoten. Vielleicht machen sich sogar sporadisch Signalverluste bemerkbar. Ursache sind dann meist die vielfachen Wiederholungen gestörter Nachrichtenübertragungen. Ich habe mit einer iterativen Optimierung des Z-WAVE Netzes gute Erfahrungen gemacht. Basis ist sorgfältiges Monitoring der Devices mit dem Controller. Damit beobachte ich die Wirkung einer schrittweisen Veränderung ungünstiger Standorte. Genauso verfahre ich mit der Veränderung der Einstellungen für Wakeup und Polling.
- LUA+PHP: Tabelle zum Z-WAVE MonitoringDas VERA-Userinterface zeigt für die Z-Wave Devices einige wichtige Informationen zum Kommunikationsverhalten. Allerdings sind diese Daten in vielen Sub-Tabs der ...
- Z-WAVE Monitoring und OptimierungIm UI von VERA findet man je Z-WAVE Device einige Kenndaten zur Kommunikation. Das Monitoring dieser Daten ermöglicht Rückschlüsse auf ...
- Z-WAVE PollingWas ist Polling? Beim Polling schickt der Controller einem Device die Aufforderung seinen Status zu melden und geht in den WAIT ...
- Z-WAVE Routing und FehlerEs nicht leicht, die Themen Z-Wave Routing und Fehler sowie Update Neighbours, Network Heal richtig zu verstehen. Man findet widersprüchliche ...