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.
WUnderground API
IBM hat WUnderground / WheatherUnderground 2017 übernommen. Das neue Geschäftsmodell sieht vor, dass man Daten seiner PWS-Wetterstation zu Verfügung stellt. Dafür erhält man u.a. in gewissem Umfang API-Zugriff auf historische Zeitreihen und auf Prognosedaten. Den erforderlichen API Key habe ich auf der WUnderground Webseite generiert. Er bleibt nur gültig, solange die PWS Daten liefert. Unter https://api.weather.com/v2/pws/dailysummary/7day… lassen sich historische Daten für 6 Tage plus heute abrufen. Unter https://api.weather.com/v3/wx/forecast/daily/5day… sind 5 Tage Zukunft plus heute verfügbar. Die recht umfangreichen Datenreihen werden als JSON History und JSON Forecast zurückgegeben.
PHP Konverter Skript auf Webserver
Das PHP Skript wird mit dem gewünschten Namen (z.B. raincalc.php) im gewünschten Pfad des Webservers zu installiert. Das File benötigt entsprechende Rechte (auf Unix 700). Das PHP Skript wird dann durch SiteSensor z.B. mit https://<myServer/raincalc.php aufgerufen. Es sollte eigentlich praktisch unverändert auf jedem Webserver laufen, nachdem eine Handvoll Parameter angepasst sind (Wetterstationsdaten, WundergroundID,…).
Im ersten Block des Skripts müssen einige Parameter angepasst werden. Beispielsweise StationID der PWS, apiKey von WUnderground, Höhe/ Länge/Breite der PWS. Das Skript ist auf metrische Daten (mm/qm, km/h, °C) eingestellt. Man kann zwar einen Parameter setzen, um andere Einheiten aus der API abzurufen. Dann sind jedoch auch entsprechende Konvertierungen in der Funktion zur Wasserbedarfsrechnung einzufügen.
Der Betrachtungszeitraum ist wählbar. Per default arbeitet das Skript mit 4 Tagen Vergangenheit und 2 Tagen Zukunft. Ein langer Betrachtungszeitraum ist z.B. günstig bei wasserhaltigem Grund oder bei mehrtägigen Bewässerungsintervallen.
Die Wasserbedarfsrechnung (Evapotranspiration) erfolgt mithilfe der Penman-Monteith-Methode. In der Rechenfunktion werden viele Variablen berücksichtigt: Standort, Jahreszeit, Temperatur, Luftfeuchtigkeit und Windgeschwindigkeit.
Man kann die meteorologische Windprognose(für 10m Höhe und freies Feld) per Faktor auf den eigenen Standort anpassen (durch Vergleich mit den eigenen Messdaten). Denn Wind ist ein wesentlicher Verbrauchsfaktor.
Hinzu kommt ein LandscapeKoeffizient zur Beeinflussung der Verdunstungsmenge entsprechend dem Pflanzentyp im Garten (Erläuterungen im Skript).
Man kann diese Parameter direkt im ersten Block des Skripts ändern oder per CGI-Parameter im Skript-Aufruf überschreiben, z.B. : https://<myServer/raincalc.php?daypast=3&dayfuture=3
Die prognostizierte Regenmenge wird mit der Regenwahrscheinlichkeit gewichtet. Die Funktion calcPrcMeanForecast berücksichtigt Regen mit einer Wahrscheinlichkeit <40% nicht.
Das Skript führt die Aufrufe der WUnderground API unmittelbar durch. Der Zugriff erfolgt per cCurl, file_get_contents oder fopen (automatische Wahl, falls eine Methode bei Web Provider nicht verfügbar ist). Da die API sehr performant ist, benötigt man keinen Puffer für die JSON Daten. Die Gesamtantwortzeit des PHP Skripts liegt bei mir unter 1 s.
Der PHP Code ist in folgende Abschnitte gegliedert: Parameter, globale Variablen, Funktionen (common, calculate forecast, calculate Evapotranspiration). Dann folgt der Hauptteil mit
- Aufbereitung der Resultate für SiteSensor und Ausgabe JSON.
- Verarbeitung der Historien Daten für alle verfügbaren Tage,
- Verarbeitung der Prognosedaten für alle verfügbaren Tage
mit Zusammenfassung der Tag-Nacht-Daten;
mit Korrektur der Windprognosen mit Faktor 0,75 (für Konversion von 10m MeteoStandardhöhe auf 2m) und mit Faktor 0,5 (da WUnderground offenbar MaxDurchschnittswerte liefert) - Aufbereitung des Ergebnis Array für Betrachtungszeitraum
mit Kalkulation der Evapotranspiration (Wasserbedarf der Pflanzen);
mit Bewässerungsbedarfsrechnung; - Aufbereitung der Ergebnisvariablenm als JSON
Die Variablen sind aussagefähig benannt und teilweise kommentiert. Das Skript ist also weitgehend selbsterklärend. Zu Testzwecken kann man den Parameter displayLog=1 setzen. Dann wird nicht nur das JSON Resultat zurückgegeben, sondern man sieht zusätzlich einige Ablaufdaten und einige Zwischenergebnisse.
VERA App “SiteSensor”
Die URL zum PHP Skript wird in SiteSensor als “Request URL” vorgegeben. Der Aufruf von http oder https Seiten ist möglich. Also beispielsweise https://<myDomain>/raincalc.php oder https://<myDomain>raincalc.php?daypast=4&dayfuture=2&lcoeff=60
In SiteSensor sind folgende Einstellungen erforderlich:
Im Abschnitt “Value Expressions” werden die JSON Variablen definiert, die das PHP Skript als Resultat zurückgibt. Die definierte “Trip Expression” bestimmt, dass SiteSensor durch” disarm” abgestellt werden kann und dann auch keine Abfragen bei WUnderground mehr vornimmt.
Der Status des SiteSensors und die Ergebnisse der Berechnung findet man in der Control Ansicht.
- Feld 1: Status des Regensensors. Ist der Gesamt-Bewässerungsbedarf (=Wasserverdunstung minus Regen, siehe Feld 4) negativ, dann geht der Status auf StopWater. Die Bewässerungsanlage wird abgeschaltet. Dies kann auch dann der Fall sein, wenn es einige Tage nicht geregnet hat. Oder umgekehrt: Die Bewässerung kann u.U. laufen, während es leicht regnet.
- Feld 5: Betrachtungszeitraum. Er ist wählbar,
hier sind die Tage |-4|-3|-2|gestern|heute|morgen|+2| ausgewählt. Das Feld ist als Spaltenüberschrift für die Felder 6 bis 8 zu verstehen. Für die zukünftigen Tage und z.T. für heute werden Prognosedaten benutzt.
Ein langer Betrachtungszeitraum ist z.B. günstig bei wasserhaltigem Grund oder bei mehrtägigen Bewässerungsintervallen. - Feld 2: Gesamtsumme Regen im Betrachtungszeitraum in mm (Ist & Prognose)
- Feld 6: Tagessummen Regen mm (Tage vgl. Feld 5)
- Feld 3: Gesamtsumme Wasserverdunstung der Pflanzen im Betrachtungszeitraum in mm (Ist & Prognose)
- Feld 7: Tagessummen Wasserverdunstung in mm (Tage vgl. Feld 5)
- Feld 4: Gesamt-Bewässerungsbedarf (=Wasserverdunstung minus Regen) im Betrachtungszeitraum in mm (Ist & Prognose)
- Feld 8: Tages-Bewässerungsbedarf in mm (Tage vgl. Feld 5)
- Schalter “Armed”: Damit kann man Smart Rainsensor abschalten. Es erfolgen keine Abfragen bei WUnderground mehr. Der Status bleibt unabhängig von der Wetterlage auf RunWater.
Der Regenschalter der Bewässerungsanlage wird mithilfe einer Scene angesteuert. Als ScneneTrigger dient Sitesensor mit folgender Auswahl:
- Regensensor inaktiv bzw. Bewässerung freigegeben =>
“Whenever restores from tripped whether it is armed or disarmed” - Regensonsor aktiv bzw. Bewässerung gestoppt =>
“Whenever is armed and tripped ”
Dieser Beitrag gehört zur Themengruppe
Smarthouse Programmierung, Smarthouse Schnittstellen und Integration
VERA erlaubt individuelle SMART HOUSE Programmierung mit LUA und LUUP. Dabei ist LUUP die Kommandosprache von VERA. LUUP Kommandos können nicht nur aus LUA heraus ausgeführt werden. Der Aufruf von LUUP ist auch von außen über CGI (http-GET) möglich. Dieser Weg ermöglicht vielfältige Zugriffe auf VERA aus Drittsystemen. Bei der LUA Programmierung für SMART HOUSE sind einige Apps und Werkzeuge hilfreich. Zusätzlich ist Entwicklungsdisziplin gefordert. Ein SMART HOUSE Controller wie VERA ist nämlich ein limitiertes Kleinsystem. Deshalb ist eine performante Strukturierung des LUA Programm Codes besonders wichtig. Dabei sollten die Schreib-Aktionen minimiert werden. Es empfiehlt sich, Datenfehler sorgfältig abzufangen. Denn ein nachträgliches Debugging ist bei VERA nicht einfach. Versteckte Programmfehler können viel Ärger machen. Also am besten jede einzelne Programmentwicklung oder -änderung gut austesten, bevor man weitergeht.
- Event-Logs auf meiner WebseiteMir ist es wichtig, bestimmte Events langfristig über viele Tage und Wochen als separate Event-Logs auf meiner Webseite zu protokollieren. ...
- 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 ...
- Nützliche globale VariablenEin LUA Programm benutzt überwiegend lokale Variablen. Manchmal sind stattdessen globale Variablen vorteilhaft. Beispiele für nützliche globale Variablen bei VERA: ...