Es nicht leicht, die Themen Z-Wave Routing und Fehler sowie Update Neighbours, Network Heal richtig zu verstehen. Man findet widersprüchliche Aussagen dazu. Das hat historische Ursachen. Das ursprüngliche Routing von Z-Wave war nicht immer ausreichend. Deshalb bot VERA damals zusätzlich ein eigenes Routing Verfahren an. Das wurde später obsolet. Dann hat sich der Prozess der Netzwerk-Aktualisierung in den Z-Wave Chips grundsätzlich geändert. Und dazu kommt: In einem Netzwerk können Devices aus diesen verschiedenen Z-Wave Generation (mit unterschiedlichem Netzwerkverhalten) koexistieren.
Beim Betrieb, beim Umbau und bei Erweiterung seines Z-Wave Netzes wurde mir klar, dass es sehr vorteilhaft ist, wenn man die Zusammenhänge bis zu einer gewissen Tiefe versteht. Nachfolgend eine Kurzfassung meines Verständnisses und meiner Erfahrungen (Fehler bitte ich zu entschuldigen, ich bin kein Experte auf diesem Gebiet).
1. Neighbor Discovery
Z-Wave ist ein vermaschtes Netzwerk. Seine Nodes können Nachrichten anderer Nodes weiterleiten. Der Prozess “Neighbor Discovery” schafft eine Grundlage dazu. Ein Node fordert alle direkt erreichbaren Nachbar-Nodes auf, sich zu melden. Diese Information schickt er an den Controller. Man kann die Daten beim VERA Controller im Feld neighbors nachschauen.
Der Neighbor Discovery Prozess wird automatisch nach der Inclusion eines Routing Slaves gestartet. Der Controller verdichtet diese Informationen aus allen Devices zu einer Routing Tabelle. Ein Routing Slave erhält daraus den für ihn relevanten Teil.
Auch ein manueller Start des Neighbor Discovery Prozesses aus dem Device-Tab des Controllers ist möglich (Update Neighbor Nodes). Das kann bei einer partiellen Netzwerkveränderung zweckmäßig sein. Insbesondere wenn es sich um ein Device handelt, das als Router agiert.
2. Netz-Update alt: network heal
Z-Wave ist in gewissem Maß fehlertolerant. Zunächst wird die letzte funktionierende Route gewählt und max. 3-mal ausprobiert. Dann werden max. 2 weitere Routen aus der Tabelle gewählt und je max. 3-mal ausprobiert.
Vor Z-Wave+ wurden danach die Kommunikation abgebrochen. Denn Neighbor Discovery war der einzige Weg um Routen im Netz zu ermitteln. Allerdings erkennt man, dass erfolglose Verbindungsversuche erhebliche Netzwerklast erzeugen. Außerdem ist der Sender-Knoten während der gesamten Zeit bis zum Abbruch der Kommunikation blockiert. Als Konsequenz können fehlerhaften Routing-Tabellen in einem großen Netzwerk mit mehrstufigen Routen zum Zusammenbruch führen.
Deshalb waren vor Z-Wave+ korrekt, aktuelle Routing Informationen unverzichtbar. Der Controller startete regelmäßig nachts einen Prozess health oder heal, der alle neighbors im Netzwerk neu ermittelte. Dieser Prozess erzeugte viel Netzwerklast, sodass die normale Kommunikation behindert oder blockiert wird. Außerdem kostet er Batteriekapazität. Insbesondere FLIRS Devices werden von jedem Nachbarn mindestens einmal aufgeweckt.
Seit Z-Wave+ ist das nicht mehr erforderlich. Es gibt nun einen besseren Prozess. Bei VERA könnte man den network heal trotzdem manuell anstoßen (generelle Z-Wave setting: Update Neighbor Nodes). Aufgrund der vielen Nachteile sollte man das vermeiden. Wenn überhaupt, dann wäre ein gezielter “Update Neighbor Nodes” für ein spezielles Device (in Device Options) vorzuziehen.
3. Netz-Update neu: Explorer Frames
Wenn ein node mit seinen gespeicherten Routing Daten keine Verbindung herstellen kann, sendet er ein explorer SearchRequest frame an alle nodes. Jeder Z-Wave+ node leitet die Anforderung weiter. Sobald der Ziel node erreicht ist, sendet er ein SearchResult an den ursprünglichen Anforderer. Gleichzeitig geht das SearchResult mit einem Stop flag (aus dem SearchRequest ) an die Nachbar nodes, damit sie keine explorer frame copies mehr abschicke.
Normalerweise findet diese Methode die schnellste Route zuerst. Der Controller erhält auf diese Weise aktualisierte Routen Informationen und kann diese an die Devices verteilen.
Allerdings verursacht auch dieses Verfahren beträchtliche Netzwerklast, wenn die Routing Tabelle nicht aktuell ist. Nachdem die 3 x 3 regulären Verbindungsversuche je Device erfolglos geblieben sind, sendet das Device das explorer SearchRequest frame an alle nodes. Diese fluten mit ihren Weiterleitungen das Netzwerk. Und dann folgen noch die Bestätigungen.
Diese Methode der Netzwerkaktualisierung setzt kein polling voraus. Sie setzt auf jeder Art Kommunikation auf. Findet allerdings weder polling, noch eine sonstige Kommunikation statt, so werden fehlerhafte Routen nicht erkannt. In solchen Fällen könnte man auch durch eine scene periodisch eine gezielte Kommunikation (auch Einmal-Polling) aufrufen.
4. Fehler im Netzwerk
Netzwerk-Umbauten
Bei umfangreiche Netzwerk Erweiterungen oder Umbauten ändern sich Routen. Als Folge gibt es Kommunikationsfehler und damit eine erhöhte Netzlast bis hin zum Kolllaps. Man mildert diese Probleme, wenn man die Maßnahmen schrittweise umsetzen. Vorteilhaft ist, wenn man dem Z-Wave Prozess dazwischen ausreichend Zeit gibt (1 Tag oder länger) um die Vermaschung zu aktualisieren.
Generell empfiehlt es sich, netzbetriebene alway-on routing slaves immer möglichst früh inkludieren. Sie agieren nämlich aktiv als weiterleitende nodes im Netz agieren. Batteriebetriebene sleeping routing slaves tun das nicht. Sie können also erst später hinzukommen.
Bei einem räumlich ausgedehnten Netz kann man grob abschätzen, welche Netzsegmente von Erweiterungen oder Umbauten betroffen sind. So lassen sich die Installationsschritte entsprechend ordnen.
Dead Nodes
Manchmal sind Devices aus irgendeinem Grund nicht betriebsbereit (Batterie fehlt,…). Es gibt jedoch keine Möglichkeit, ein Z-Wave Device als inaktiv zu kennzeichnen. Selbst wenn der Controller es als fehlerhaft erkennt, wird doch immer wieder eine Verbindung versucht. Beispielsweise beim Start des Controllers. Man kann auch nicht sicher sein, dass das Device wirklich aus allen Routing Tabellen verschwindet. Auch der Z-Wave Prozess wird immer wieder versuchen, eine Verbindung herzustellen.
Das kosten unnötig Netzwerk Bandbreite und Batterieleistung. Also besser solche Devices rasch excludieren.
Mixed Network:
Übertragungsgewschwindigkeit
Z-Wave Devices basieren auf verschiedenen Chipsets. Deren Leistung hat sich im Laufe der Jahre deutlich verbessert. Dabei hat sich auch die Übertragungsgeschwindigkeit deutlich erhöht. Es gibt Devices mit 9.6Kbps, 40Kbps, 100Kbps. Bei höherer Übertragungsgeschwindigkeit ergibt sich natürlich eine kürzere Übertragungszeit (bei gleicher Nachrichtenlänge). Also können mehr Übertragungen (und Weiterleitungen, Fehlversuche, Rückbestätigungen) abgewickelt werden. Ein entscheidender Vorteil für Performance und Stabilität des Netzes.
Bei Mehrstufen-Verbindungen ist die Übertragungsgeschwindigkeit der Router besonders wichtig. Langsame Router Devices (netzbetriebene Slaves)auf einer Strecke können die effektive Geschwindigkeit des gesamten Netzes herabsetzen.
Bei einigen alten Devices scheint es auch Fehler im Routing mit schnellen Devices zu geben. Zumindest an den Routing Positionen sollte man also ausschließlich moderne, schnelle Devices einsetzen. Ein weiterer Vorteil: Es handelt sich dabei normalerweise um Z-Wave+ Devices, was auch andere Probleme (s.u.) vermeidet.
Mixed Network: Z-Wave+
Die neue Art der Netzwerk Aktualisierung auf Basis von ExplorerFrames funktioniert nur sicher, wenn ausschließlich Z-Wave+ Devices im Netz sind. Die neighbors älterer Devices ohne ExplorerFrames werden nicht oder zumindest nicht sicher aktualisiert. Insbesondere wenn ein solches Device als Router arbeitet, kann das zu Fehlern führen.
Man könnte manuell oder periodisch einen globale NetworkHeals anstoßen. Das würde die neighbors der alten Devices aktualisieren und somit zu einem aktuellen Routing Table führen. Dieses alte Verfahren der Netzwerkaktualisierung hat jedoch viele Nachteile (s.o.).
Wenn möglich sollte man besser gezielt und manuell bei den alten Devices einen “Update Neighbor Nodes” starten.
Optimal wäre es, die alten Devices zu ersetzen. Zumindest bei Devices mit Routing Funktion ist das sehr empfehlenswert. Das vermeidet auch das Geschwindigkeits-Problem (s.o.).
Controller erreicht device nicht (can’t detct device)
Wenn bestimmte Fehler auftreten, kennzeichnet der Controller ein device als nicht erreichbar “can’t detect device“. Wahrscheinlich behandelt er dann das Gerät auch in irgendeiner Weise besonders. Der Fehlerstatus wird wie folgt gesetzt:
- aus Polling: wenn ConsecutivePollFails größer 2 oder 3
- aus Wakeup: 6 h nach dem letzten erwarteten wakeup
- aus Z-Wave Chip: Die FailedNodeList wird alle 5 min die übernommen
- nach Verbindungsfehler bei der Ausführung eines Vera-Kommandos
Die Fehlermeldung verschwindet normalerweise kurze Zeit, nachdem Ursache beseitigt ist automatisch. Falls das nicht geschieht, können (je nach Fehlertyp) nachfolgende Maßnahmen helfen. Manchmal hilft eine mehrfache Wiederholung. Erst wenn man damit nicht weiterkommt, muss man zu Exclusion + factory reset + Inclusion greifen.
- Device lokal aufwecken, ggf. Batterie tauschen
- Manuelles Polling für das Device aufrufen und sofort danach ein manuelles Wakeup des Devices (per Schalter an Device, per Strom aus/an)
- “update neighbor nodes” bei Nachbar-Devices
- Schaltkommando an das fehlerhafte Device schicken
Falls das Device erreicht wird und nur die Antwort nicht ankommt, löst das eine Z-Wave Selbstheilung per ExplorerFrame aus. Wiederholung kann bei Zeitüberschreitung helfen. - Restart VERA
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 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 WakeupEin Batterie Device (Sensor oder Actor) muss Strom sparen. Deshalb befindet es sich normalerweise im “deep sleep“. Ein typisches Batterie ...