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 die Qualität des Z-WAVE Netzes. Und zwar nicht nur für das jeweilige Device selbst, sondern auch für dessen Nachbarn. Auf dieser Grundlage kann eine schrittweise Optimierung der Signallaufzeit und der Robustheit des Z-WAVE Netzes aufsetzen.

Eigenschaften von wichtigen Z-WAVE Nodes

Jedes Z-Wave Device stellt einen node im Z-Wave Netz dar. Je Typ sind unterschiedliche Einstellungen erforderlich. Entsprechend sind auch die Kenndaten (s.u.) unterschiedlich.

• Always-on Routing Slave
  • Node ist ständig am Netz, deshalb keine WakeupInterval.
  • Node verfügt über Verzeichnis von Neighbors.
  • Polling ist möglich und sinnvoll.
• Sleeping Routing Slave
  • Dieser node befindet sich normalerweise in einem Tiefschlaf-Modus, um Batterie zu sparen. In diesem Modus ist er nicht von außen erreichbar. Nach Anlauf des WakeupInterval erfolgt Meldung an Controller mit Anfrage, ob eine Nachricht anliegt. Typisches WakeupInterval: 10 min bis einige Std.
  • Node verfügt über Verzeichnis von neighbors.
  • Polling ist möglich und u.U. sinnvoll, aber Netzlast und Batterie beachten.
• Frequently Listening Routing Slave (FLiRS)
  • Alternative Bezeichnungen: Reachable Sleeping Slave, Listening Sleeping Slave
  • Dieser node befindet sich normalerweise in einem Tiefschlaf-Modus, um Batterie zu sparen. In diesem Modus ist er nicht von außen erreichbar. Geht periodisch (1/4 bis 1 sek) in einen Halbwach-Zustand. In diesem Zustand erfährt er, ob ein WakeupBeam eines anderen node anliegt und wacht bei Bedarf auf. Dann kann normal kommuniziert werden.
    Eine WakeupInterval Verwaltung findet nicht statt.
  • Node verfügt über Verzeichnis von neighbors, wird jedoch nicht zum Routen von Nachrichten eines anderen node benutzt (Batterielebensdauer).
  • Polling ist möglich und u.U. sinnvoll, aber Netzlast und Batterie beachten.
  • In VERA erkennt man diesen Device Typ daran, dass keine Einstellung des WakeupInterval angeboten wird (anders als bei sonstigen Batterie-Devices).
• Portable Controller (Remote Control Unit)
  • Dieser node befindet sich normalerweise in einem Tiefschlaf-Modus, um Batterie zu sparen. In diesem Modus ist er nicht von außen erreichbar. Das Aufwecken erfolgt manuell (meist per Tastendruck).
  • Parallel ist meist ein Aufwecken per WakeupIntervall möglich.
  • Node verfügt nicht über Verzeichnis von neighbors (zumindest bei VERA). Vermutlich versucht er zunächst die letzte funktionierende Route und/oder alle direkt erreichbaren nodes. Bei Misserfolg baut er sich über Explorer Frame Prozess eine temporäre Route.
  • Polling ist möglich und u.U. sinnvoll, aber Netzlast und Batterie beachten.

Z-Wave Monitoring

Wichtige Beobachtungsfelder sind Wakeup, Polling, Z-Wave Routing, Kommunikationsfehler und Batterie-Monitoring. VERA bietet je Device einige Kenndaten an.

Wakeup

• ConfiguredWakeupInterval (anDevice gemeldetes WakeupIntervall in s)
• WakeupRate (Anzahl ok aus den letzten 50 erwarteten Wakeups)
  5.00 bedeutet 50 Wakeups waren korrekt, 0.00 bedeutet 0 Wakeups waren korrekt. In meinem stabilisierten Netz bei wenig 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)

Anhand der Wakeup Kenndaten kann man erkennen, ob die WakeupIntervalle angemessen sind hinsichtlich Batterieverbrauch, Aktualität, Abstimmung mit PollInterval. Aus WakeupRate und LastWakeup läßt sich auch leicht erkennen, ob die Kommunikation zuverlässig funktioniert.
Mehr dazu siehe Z-Wave Wakeup.

Polling

• PollSettings (PollIntervall in s)
• 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 ist 5.00 normal.
• PollOk (Anzahl erfolgreicher Polls)
• PollNoReply (Anzahl erfolgloser Polls)
• ConsecutivePollFails (Anzahl aufeinaderfolgender erfolgloser Polls)
• LastPollSuccess (Timestamp der letzten erfolgreichen Poll-Antwort)

Aus den Polling Kenndaten kann man erkennen, ob die Intervalle angemessen gesetzt sind hinsichtlich Netzwerklast, Aktualität, Abstimmung mit WakeupInterval.
PollRatings zeigt auf einen Blick, ob das Device gut kommuniziert. Falls die Kennzahl schlecht ist, kann man mit PollNoReply, ConsecutivePollFails und LastPollSuccess in die Analyse einsteigen.
Mehr dazu siehe Z-Wave Polling.

Z-Wave Routing

• Neighbors (Z-WAVE-Neighbors)
  NodNummer=AltID, nicht DeviceNummer
• LastRouteUpdate (Timestamp)

Aus den neighbors kann man Rückschlüsse auf die verfügbaren Z-WAVE-Routen für das Device und für dessen Nachbar-Devices ziehen. Diese Daten stabilisieren sich erst einige Tage nach Installation des Devices (im Zuge der automatischen Netzwerk-Reorgs). Neuinstallationen oder Platzänderungen von benachbarten Devices können zu erneuten Änderungen führen.
Mehr dazu siehe Z-Wave Routing und Fehler.

Kommunikations-Fehler

• CommFailure (aktueller Fehler-Zustand 0 oder 1)
  Der Fehlerzustand wird gesetzt aus:
  
  • Polling: wenn ConsecutivePollFails größer 2 oder 3
  • Wakeup: 6 h nach dem letzten erwarteten wakeup
  • Z-Wave Chip: FailedNodeList wird alle 5 min die übernommen; für diese Nodes ist CommFailure=1
  • Kommunikationsfehler bei der Ausführung eines Vera-Kommandos
• CommFailureTime (Timestamp des letzten CommFailure)

Mehr dazu siehe Z-Wave Routing und Fehler.

Batterie-Monitoring

• BatteryLevel (%)
• BatteryDate (Timestamp der letzten Batterie Meldung)

Diese Felder betreffen nur Batterie-Devices und sind nur korrekt und aktuell gefüllt, wenn Polling aktiviert ist und funktioniert.
In VERA kann man ” battery level goes below” Notifications einrichten. Vermutlich basiert das Verfahren auf o.g. BatteryLevel. Einige Devices können zwar aktive Reports senden: Beispiel “Battery Auto Report” bei Philio 4 in 1. Vermutlich werden solche Nachrichten von VERA nicht ausgewertet.

Es ist nicht leicht, gute Schwellwerte für Batteristand Warnungen zu finden. Manche Devices funktionieren bis 40% BatteryLevel, andere bis 20%. Viele Devices arbeiten sogar noch einige Tage, obwohl der BatteryLevel auf 1% abgestürzt ist.
Dabei spielt auch der Batterietyp eine wesentliche Rolle. Lithium Batterien zeigen lange 100% an und fallen dann rasch ab. Die Spannung von Alkali-Battterien fällt kontinuierlich und schneller ab. Alkali Batterien sollten auf geringen Stromverbrauch und langsamen Spannungsabfall optimiert sein. Sie sind deutlich länger nutzbar als High Energy Versionen.

Z-WAVE Optimierung

Aus den Daten des Monitoring kann man Rückschlüsse ziehen, ob die Vermaschung oder die Funkverbindung mit dem Device gut sind. Liegen beispielsweise das Rating für Polling und für Wakeup nach einigen Tagen jeweils bei 5.00, dann funktioniert die Kommunikation zumindest im Normalfall gut. Ist das Rating schlecht, so kann man aus den Daten Anhaltspunkte zur Ursache des Problems herausfinden.

Das Monitoring bildet die Basis für die Optimierung des Z-WAVE Netzes. Durch Veränderungen an einzelnen Devices sollen Signal-Laufzeiten und Ausweichrouten bei Störungen verbessert werden. Und somit die Qualität der Z-WAVE Vermaschung insgesamt.
Bereits kleine Veränderungen von Standort oder Antennenlage der Devices können sich auf die Qualität Funkstrecken auswirken. Unter Umständen sind jedoch zusätzliche Devices zur Verbesserung der Netz-Topologie erforderlich. Aber auch die Einstellungen von Wakeup und Polling können stark auf die Netzqualität einwirken.

Die Optimierung ist nur als iterativer Prozess möglich. Nach jeder Änderung an einem Device muss man die Stabilisierung des Netzwerks abwarten und dann das neue Verhalten analysieren. Man muss alle Devices regelmäßig monitoren, auch wenn nur ein Device verändert wurde. Erst über einen längeren Zeitraum erhält man zuverlässige Ergebnisse.

Es ist praktisch unmöglich die Informationen für ein derartiges Monitoring mit vielen Daten aller Z-WAVE-Devices aus dem VERA-UI zusammenzusuchen. Stattdessen benötigt man eine übersichtliche, tabellarische, automatisierte Fortschreibung der relevanten Daten.
Ich habe mir dafür ein Hilfsmittel entwickelt, siehe “LUA+PHP: Tabelle zum Z-WAVE Monitoring”

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 Polling
  Was ist Polling? Beim Polling schickt der Controller einem Device die Aufforderung seinen Status zu melden und geht in den WAIT ...
• 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 ...