Kategorie: Smarthouse Systeme und Entwicklung

SMARTHOUSE entsteht in einem interaktiven und iterativen Prozess. Die Phasen Installation, Entwicklung, Stabilisierung und Betrieb wiederholen sich immer wieder. Einerseits will man die Leistung und Stabilität der Systeme verbessern. Andererseits geht es um die Entwicklung von Funktionslogik und deren Einsatz in automatisierten Prozessen.

D.h. mit dem Kauf der Hardware Komponenten ist noch lange kein SMARTHOUSE System geschaffen. Zuerst sind die einzelnen Sensoren, Actoren und Controller zu einem funktionierenden Gesamtsystem zusammenzufügen. Darauf setzt die Optimierung des Netzes auf, um den Systembetrieb zu stabilisieren.
Parallel läuft der Entwicklungs-Prozess der SMARTHOUSE Anwendung. Es beginnt mit individuellen Einstellungen in der Benutzeroberfläche. Mit zunehmender Automatisierung kommt immer mehr Customizing, Scenes, Apps, Programmierung etc. hinzu. Dabei wächst die Komplexität der Entwicklung und der Anwendung. Logiken und Prozesse verändern sich zyklisch: entwickeln, testen, verwerfen und verbessern. Meist kommen auch Schnittstellen zu Dritt-Systemen und Services hinzu.
Schritt für Schritt entsteht so ein ziemlich komplexes SMARTHOUSE Gebilde. Auch die Performance des Netz- und Systembetriebs muss im Auge behalten und ggf. immer wieder optimiert werden. Es bedarf einiger Anstrengungen und Methodik, um bei der Weiterentwicklung den Überblick zu behalten.

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 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.

Smart RainSensor

Mein Smart Rainsensor ist über den Cloudservice WeatherUnderground (WUnderground) mit meiner eigenen Wetterstation (PWS) verbunden. Er steuert mithilfe des Smarthouse Controllers VERA meine Bewässerungsanlage anstatt eines einfachen (Trocknungszeit-)Regensensors. Der Smart Rainsensor betrachtet nicht einfach einen Zeitpunkt, sondern einen Zeitraum über mehrere Tage in der Vergangenheit und Zukunft. Der Smart Rainsensor benutzt dabei Ist-Wetterdaten aus meiner eigenen PS-Wetterstation und Prognosen von WUnderground. Er berechnet aus Standort, Jahreszeit, Temperatur, Wind und Luftfeuchtigkeit den Wasserverbrauch der Pflanzen. Das wird dann mit der Regenmenge verglichen, die in dem Betrachtungszeitraum angefallen ist und die erwartet wird.

Smart RainSensor = VERA Sitesensor, PHP, WUnderground, …

Smart RainSensor verkettete mehrere Komponenten von Smart House. Auf dem VERA Controller startet die App SiteSensor periodisch die Verarbeitung, wertet die Resultate aus und triggert eine Scene zur Steuerung des Regenschalters an der Bewässerungsanlage. Eine weitere Komponente ist ein PHP Skript auf meinem Webserver, das periodisch durch SiteSensor aufgerufen wird. Dieses Skript holt die Basisdaten vom Cloud Service WeatherUnderground (WUnderground) per API im JSON Format, bereitet die Variablenreihen für Vergangenheit und Zukunft auf und führt die Wasserbedarfsrechnung durch: Die Ergebnisse gehen per JSON Response zurück an SiteSensor. WUnderground übernimmt ca. 10-minütig Messdaten von meiner PWS-Wetterstation, bereitet die Datenreihen auf und ergänzt Wetterprognose-Daten. Falls man einen VERA Controller betreibt, kann man das System recht einfach übernehmen. Siehe auch den Gesamtüberblick über Smart Rainsensor.

VERA Werkzeuge

VERA bietet viele kostenlose Werkzeuge zur Unterstützung von Administration und Entwicklung. Davon führe ich hier nur die VERA Werkzeuge auf, die ich regelmäßig benutze. Dabei beschränke ich mich auf die Administration von VERA und auf die Entwicklung von LUA Code. Ich gehe hier nicht ein auf Logic-Device-Apps, auf konfigurierbare Logic Apps oder auf Makrosprachen-Apps.

Event-Logs auf meiner Webseite

Mir ist es wichtig, bestimmte Events langfristig über viele Tage und Wochen als separate Event-Logs auf meiner Webseite zu protokollieren. Diese Event-Logs entstehen beim Ablauf von Scenes auf VERA. Ein Event-Log auf meiner Webseite zeigt beispielsweise die stündliche Entwicklung von Temperatur und Feuchte eines bestimmten Raumes. Ein anderes Log listet z.B. für einen bestimmten Gebäudebereich die Events DoorOpen, DoorClose oder Motion.
Ich möchte eine Vielzahl solcher spezieller Event-Logs auf meiner Webseite. Sie sollen übersichtlich und sehr lange verfügbar sind. Auf meiner Webseite sollen sie deshalb liegen, damit sie einfach und von überall abfragbar sind.
In solche Logs sammle ich auch Zustandswerte zum Austesten von Devices, von scenes oder von scene Prozesseketten. Das hat sich im Tagesbetrieb, bei Fehlersuche und zur Optimierung vielfach bewährt.

Z-WAVE Wakeup

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).

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.

VERA im Intranet: Aktion starten

SMART HOME Controller wie VERA verfügen über ein User-Interface, um das System komplett zu verwalten. Leider sind solche spezifischen Oberflächen nicht für alle Benutzertypen gut geeignet. Denn Gelegenheits-Benutzer müssen das UI immer wieder neu finden/starten und sich in dessen Bedienungslogik einfinden.
Existiert jedoch ein Intranet, so sind die Benutzer mit den Intranet-Webseiten vertraut. Warum also SMARTHOUSE nicht direkt aus den relevanten Intranetseiten heraus steuern? Beispielsweise mit einem Action Button (oder mit mehr Schick). Zudem lassen sich dort auch die relevanten SMARTHOUSE Informationen anzeigen. Beispielsweise mit Ampeln zur Signalisierung des Zustands von Ein-Aus Sensoren oder Actoren. Natürlich sind auch Zahlen-Felder darstellbar, z.B. mit Temperaturangaben (vgl. VERA im Intranet: Ampeln + Zahlenwerte). Auch weitere Geräte lassen sich so direkt einbinden. Zum Beispiel Cam-Aufzeichnungen oder Cam-Livestreams.

VERA im Intranet: Ampeln + Zahlenwerte

SMART HOME Controller wie VERA verfügen über ein User-Interface mit dem man das System komplett verwalten kann. Solche spezifischen Oberflächen sind nicht für alle Benutzertypen gut geeignet. Gelegenheitsnutzer müssen nämlich das UI immer neu finden/starten und sich in dessen Bedienungslogik einfinden.
Hat man ein Intranet, so werden diese Webseiten regelmäßig benutzt. Warum nicht direkt auf den relevanten Intranetseiten auch SMARTHOUSE Informationen anbieten? Beispielsweise Ampeln zur Signalisierung des Zustands von Ein-Aus Sensoren oder Actoren. Oder Zahlen-Felder z.B. mit Temperaturangaben. Bei Bedarf kann auf solchen Seiten auch eine Fernsteuerung erfolgen (vgl. VERA im Intranet: Aktion starten). Man könnte dort auch zusätzliche Geräte direkt einbinden. Zum Beispiel Cam-Aufzeichnungen oder Cam-Livestreams.

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.