Z-WAVE Polling

Was ist Polling?

Beim Polling schickt der Controller einem Device die Aufforderung seinen Status zu melden und geht in den WAIT Status. Durch dieses spezielle Z-Wave Frame wird bei dem Device die “Z-Wave state machine” in den BEGIN Status gesetzt. Erhält der Controller eine korrekte Antwort, ist der END Status erreicht und die weitere Kommunikation beginnt. Ansonsten setzt der Controller einen ERR Status und wiederholt den Polling Versuch maximal dreimal. Ohne Erfolg wäre dann Polling einmal gescheitert.

Der Controller pollt beim Hochfahren alle ihm bekannten Devices. Er kann Polling periodisch wiederholen. Bei welchen Devices und mit welchem PollIntervall das geschieht, ist abhängig von den Einstellungen im Controller. Siehe dazu auch Z-WAVE Monitoring und Optimierung.

Polling war in frühen Z-Wave Generationen üblich, um den Device Status abzufragen. Ein Grund dafür war ein Patent, das bis 2015 lief. Inzwischen werden alle Events eines Devices sofort per Nachricht an den Controller geschickt. Deshalb ist Polling nicht mehr unbedingt erforderlich.

Vorsicht Netzlast

Polling verursacht erhebliche Netzlast. Eventuell kann diese Belastung Signal-Verzögerungen oder sogar Instabilität zur Folge haben. Besser also Polling nur bei solchen Devices benutzen, wo es wirklich notwendig ist. Und das PollIntervall darf nicht unnötig klein gewählt sein. Die Netzlast wächst:

• mit der Anzahl Devices
• je kleiner das PollIntervall eingestellt wird.
• je mehr Devices eine indirekte Verbindung zum Controller haben
• wenn mehrere Übertragungsversuche nötig sind (Funkqualität, veraltete Routing Tabelle)
• je öfter Controller durchgestartet wird

Warum Polling bei modernen Devices?

Regelmäßiges Polling erzeugt Netzlast, die erheblich sein kann. Ein weiterer Nachteil bei Batterie Devices: Der Stromverbrauch. Warum also niciht einfach auf Polling verzichten?

• Device Status
  Im Normalfall ist es nicht erforderlich, den Device Status per Polling abzufragen. Geht allerdings eine Nachricht über eine Statusänderung verloren, sieht es anders aus. Dann korrigiert Polling den Status-Unterschied zwischen Device und Controller. Beispielsweise bei kritischen Alarm-Devices kann das hilfreich sein.
• Kommunikationsstörungen
  Liegt eine Kommunikationsstörung vor, so wird Polling nicht erfolgreich sein. Man führt also damit regelmäßig eine Prüfung durch. Dies kann bei kritischen Alarm-Devices oder bei selten aktiven Devices hilfreich sein. 
• Device Eigenschaften (z.B. Batteriestand)
  Ohne Polling werden manche Eigenschaften nicht an den Controller übermittelt (zumindest bei VERA). Einige moderne Devices können zwar aktiv eine Warnung zum Batteriestand schicken, sobald eine Schwelle erreicht ist. Aber zwischenzeitlich ist man nicht informiert.

Polling bei verschiedenen Device Typen:

• Always-on Routing Slave
  Polling ist möglich und u.U. sinnvoll, aber Netzlast beachten.
  Device ist immer erreichbar. Meine Einstellung: 3600 sek.
• Sleeping Routing Slave
  Device ist nur wach erreichbar, deshalb: pollInterval <= wakeupInterval
  Meine Einstellungen: 3600-10800 sek.
  Polling ist möglich und u.U. sinnvoll, aber Netzlast und Batterie beachten.
  Das Device ist meist in Tiefschlaf. Polling Anforderungen entstehen alos meiar während der Tiefschlafphase. Sie werden dann beim Controller in die Nachrichten-Warteschlange eingereiht, um sie beim nächsten Wakeup des Devices abzuarbeiten.
  Angeblich soll ein Device beim Wakeup unaufgefordert die Status an den Controller senden. Ohne Polling (pollInterval=0)  geschah dies in meinen Tests nicht (oder wurde nicht von Vera verarbeitet).
• Frequently Listening Routing Slave (FLiRS)
  Polling ist möglich und u.U. sinnvoll, aber Netzlast und Batterie beachten.
  Polling erfolgt gemäß pollIntervall des Controllers. Das FLiRS Device wird dabei aufgeweckt. Zusätzlich erfolgt Polling (mit Aufwecken des Devices) bei jedem Neustart des Controllers. Also z.B. auch bei Änderung von scenes, rooms usw.
  Meine Einstellung: 0 sek = kein Polling.
  Alternative um z.B. den Batteriestand abzufragen: Pollling abstellen und wöchentlich 1 PollAufruf per Scene.
• Portable Controller (Remote Control Unit)
  Polling ist möglich und u.U. sinnvoll, aber Netzlast und Batterie beachten.
  Dieser Devicetyp speichert keine neighbors. Deshalb können bei entfernten Standorten zusätzliche Nachrichten zur Einleitung der Kommunikation erforderlich sein.

Polling Verwaltung bei VERA

VERA verfügt über einige generelle Einstellungen zum Polling. Standardmäßig beginnt ein Polling Loop nach 20s und die nodes folgen frühestens  im Abstand von 30s aufeinander, wenn das Netzwerk mindesten 10s idle war. Derselbe node darf frühestens nach 60s erneut gepollt werden. Bei einem großen Netz kann sich daraus je Device ein recht langes tatsächliches PollIntervall ergeben.
Je Device kann das generelle PollIntervall durch einen anderen Wert überschrieben werden. Mit PollIntervall = 0 kann das Polling je Device abgestellt werden.

Ein schlafendes Device wird für den nächsten Wakeup Zeitpunkt zum Polling vorgemerkt.
VERA führt folgende Kenndaten zum Polling:

• PollSettings (PollIntervall in s)
• PollOk (Anzahl erfolgreicher Polls)
• PollNoReply (Anzahl erfolgloser Polls)
• PollRatings (Anzahl ok aus den letzten 50 Polls)
  5.00 bedeutet 50 Polls waren korrekt, 0.00 bedeutet 0 Polls 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.
• ConsecutivePollFails (Anzahl aufeinaderfolgender erfolgloser Polls)
• LastPollSuccess (Timestamp der letzten erfolgreichen Poll-Antwort)
• CommFailure (aktueller Kommunikations-Zustand 0 oder 1)
  Fehler = wenn ConsecutivePollFails größer 2 oder 3.
  Ein CommFailure kann auch aus anderen Gründen entstehen (siehe Z-WAVE: Monitoring + Optimierung).

Besonderheiten

Einige Devices haben Probleme mit Polling (z.B. Qubino Switch). Sie zeigen immer oder sporadisch Pollfehler.  Eine Erklärung wäre, dass Poll Nachrichten und andere Nachrichten in der verfügbaren Zeitscheibe nicht gemeinsam “durchkommen”. In einem  Fall (Popp Thermostat) hat Polling bei mir sogar den Wakeup-Zyklus durcheinander gebracht.

In solchen Fällen muss man Polling abschalten und die Nachteile in kauf nehmen. Oder man kann eine Teil-Funktion des Polling durch andere Maßnahmen ersetzen. Beispielsweise durch Statusabfragen per scene.
Wenn möglich lasse ich zunächst, in der ersten Optimierungsphase eines Devices relativ häufiges Polling zu. Nach ausreichender Beobachtung reduzierte ich dann das PollInverval oder schalte Polling ganz ab.

Dieser Beitrag gehört zur Themengruppe
Optimierung des Z-WAVE Netzes, Smarthouse Technologie

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 Monitoring
  Das 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 Optimierung
  Im 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 Routing und Fehler
  Es nicht leicht, die Themen Z-Wave Routing und Fehler sowie Update Neighbours, Network Heal richtig zu verstehen. Man findet widersprüchliche ...
• Z-WAVE Wakeup
  Ein Batterie Device (Sensor oder Actor) muss Strom sparen. Deshalb befindet es sich normalerweise im “deep sleep“. Ein typisches Batterie ...