Das VERA-Userinterface zeigt für die Z-Wave Devices einige wichtige Informationen zum Kommunikationsverhalten. Allerdings sind diese Daten in vielen Sub-Tabs der einzelnen Devices versteckt. Die Informationen für alle Devices regelmäßig zusammenzusuchen wäre äußerst zeitaufwändig. Deshalb ist ein tabellarischer Überblick wichtig, der alle relevanten Informationen aller Z-Wave Devices nebeneinander zeigt. Und man muss die Veränderung im Zeitablauf gut verfolgen können.
Zu diesem Zweck habe ich ein Verfahren zur automatisierten Erzeugung einer Log-Tabelle entwickelt. Die Tabelle enthält für alle Z-WAVE Devices die wichtigsten Netz-Kenndaten, z.B.: Neighbors, WakeupRatings, PollRatings, LastWakeup. Der Inhalt und die Anwendung der Kenndaten sind im Beitrag “Z-WAVE Netz: Monitoring + Optimierung” skizziert.
Das Verfahren war und ist die Grundlage für die Optimierung meines Z-WAVE Netzes. Es läuft periodisch auf VERA und ich beobachte das Netz auf dieser Grundlage regelmäßig.
Eine Scene startet periodisch ein LUA Programm. Das Programm ermittelt für alle Z-WAVE Devices die relevanten Z-WAVE Kenndaten. Dann ruft es per luup.inet.wget ein PHP Programm auf meinem Webserver auf und übergibt ihm die Daten. Die Datenübergabe erfolgt per CGI-String. Das PHP Programm schreibt eine CSV Datei fort. Diese Datei lässt sich in einem Tabellenprogramm (Excel etc.) öffnen. Sie zeigt dann für jeden Übergabezeitpunkt eine Device-Kenndaten-Matrix.
Hier zeige ich eine einfache Beispielversion der Programme. Ich habe sie aus meinem Programmverbund heraus gekürzt – hoffentlich fehlerlos. Vielleicht inspiriert die Methodik den Einen oder Anderen bei der Entwicklung seiner eigenen Werkzeuge.
Das LUA Programm für VERA
Das LUA Programm besteht aus dem Hauptprogramm und der Log-Funktion csvLog(arg).
csvLog ruft tabvera.php auf dem Webserver auf und übergibt die Logdaten per CGI Get-String. Dabei lassen sich einfach verschiedene Log-Dateien vorgeben. Ich benutze diese Funktion nämlich auch für andere Zwecke. (vgl. LUA+PHP: Event-Logs auf eigener Webseite) Die Log-Funktion greift auf meine universelle Hilfsfunktion mySplit(inStr,sep) zurück. Sie splittet den ursprünglichen Datenstring anhand eines Trennzeichens (hier !) in ein array, das zurückgegeben wird. Feld 1 (also der String vor dem Trennzeichen) enthält den Namen der Zieldatei. Feld 2 enthält den Log-Datenstring. Dort werden noch Leerzeichen durch + ersetzt, um einen gültigen CGI-String sicherzustellen.
Das Hauptprogramm generiert zunächst ein Array idx mit allen DeviceNummern. Dann wird zunächst eine Timestamp-Zeile und dann eine Überschriftzeile in das Logfile log_zwave_vera.csv geschrieben.
Nun werden die DeviceNummern abgearbeitet: Zunächst werden per luup.devices[dev] einige Daten des Devices (z.B. Bezeichnung) in ein Array übernommen. Die Z-WAVE Kenndaten des Devices kommen per luup.variable_get hinzu. Anschließend werden einige Werte aufbereitet. Insbesondere der Unix Timestamp ist in lesbare Form zu konvertieren. Nun folgt die Aufbereitung des CGI-String. Als csv Trennzeichen dient nach europäischer Sitte “;”. Anschließen wird nur für die Z-Wave Haupt-Devices eine Daten-Zeile in log_zwave_vera.csv geschrieben.
Das PHP Skript auf dem Webserver
tabvera.php ist im gewünschten Pfad des Webservers zu installieren. Auf Unixsystemen ist die Berechtigung 700 erforderlich. Das Skript schreibt die Logdatei in den gleichen Pfad. Das erfordert im Pfad die Schreibberechtigung 755. Bei Bedarf lässt sich das Skript leicht ändern, um z.B. das Log in einen Unterpfad zu legen.
Das Skript übernimmt zuerst die Daten aus dem CGI-String. Dann werden die Datenfelder zur Kontrolle in das Array logMain geschrieben. Diese Daten lassen sich am Bildschirm anzeigen, wenn man tabvera.php zu Testzwecken mit einem geeigneten CGI-String aufruft. Der Aufbau ist im Skript beschrieben. Dann wird die Logzeile logLine nach Aufbereitung in das File log_zwave_vera geschrieben.
Hier ein Datei-Beispiel von log_zwave_vera.csv. (Trennzeichen ist Semikolon, um in deutschem Excel gut öffnen zu können. Im LUA-Code wäre das einfach auf Komma umstellbar.)
Und dieses Datei-Beispiel angezeigt in Excel (Screenshot)
Dieser Beitrag gehört zur Themengruppe
Optimierung des Z-WAVE Netzes, Smarthouse Programmierung
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.
- 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 ...
- Z-WAVE WakeupEin Batterie Device (Sensor oder Actor) muss Strom sparen. Deshalb befindet es sich normalerweise im “deep sleep“. Ein typisches Batterie ...