RS RainRadar Forecast (RRFC) 3.x
Neue Version (V 3.1) vom 22.07.2016
!!! Seite noch im Aufbau !!! Download für eingeloggte User am Ende dieser Seite verfügbar
Der kleine Haus-Automatisierer hat heute eine eigene Wetterstation an sein IP-Symcon angebunden. So weiß nicht nur er, ob es grad regnet, sondern auch seine Wohnung. Und die kann entsprechend darauf reagieren. Was ist aber, wenn die Automation oder die Hausbewohner einen gewissen Vorlauf für Entscheidungen brauchen? Anders formuliert: es gibt Fälle, in denen eine Ausführung von Aktionen vor Eintreffen eines Ereignisses notwendig ist. Mein Lieblings-Beispiel: Die Markise soll gefälligst eingefahren werden, bevor es regnet. Wir wollen ja keine Biotop-Bildung fördern (jedenfalls nicht in der feucht gewordenen Markise).
Anwendungsfälle, die ich noch so von meinen Usern aufgeschnappt habe:
- Mähroboter via IP-Symcon rechtzeitig vom Rasen holen und in die Garage einsperren
- Einstellen der Gartenbewässerung bei drohendem Niederschlag
- Steuerung der Video-Aufnahmen via SAT (bei Starkregen/Gewitter kein Empfang) bzw. Warnung vor evtl. gestörten SAT-Aufzeichnungen bei Starkregen
- Alarm-Messaging für Open-Air Party’s (vor Niederschlag natürlich)
Cool ist es schon, via RainRadar Forecast (=> ff. RRFC) bis zu 1,5 Stunden vor eintreffendem Regen bescheid zu wissen, automatisch Markisen einfahren zu lassen, automatisch Fenster zu schließen, Grillparty nach innen verlegen…. soweit die Intention.
Für Alle, die es noch nicht kennen: das Konzept
Lassen wir es mal langsam angehen: zunächst geht es „nur“ um das Primärziel, verwertbare Daten für IP-Symcon aus den Radar-Forecast Bildern von wetteronline.de zu gewinnen. Zum Beispiel
- wann setzt der Regen ein?
- mit welcher Intensität?
- wann hört es wieder auf?
Der RRFC ist somit wie ein Treiber zu verstehen, der die Kopplung von Hardware (=Niederschlag) und Betriebssystem (=IP-Symcon) ermöglicht. Der RRFC übersetzt quasi die (grafischen) Forecast-Informationen in (für IP-Symcon) auswertbare Variablen-Werte. Was mit den gewonnenen Daten dann passiert (ob Alarm-Mails versandt, Automationsaufgaben ausgelöst werden etc. etc.) ist nicht Bestandteil dieses Projektes. Dieses Projekt liefert bestenfalls noch eine rudimentäre Visualisierung für das Webfront mit.
Konkret holt der RRFC alle 5 Minuten die Regenradar-Forecastbilder von Wetteronline ab, analysiert jedes Einzelbild auf Niederschlags-Intensität im (frei konfigurierbaren) Radius um den eigenen Standort und wandelt die Ergebnisse in Variablenwerte um. Klingt einfach, ist es aber nicht.
Für den User werden die Analyse-Ergebnisse leicht verdaulich aufbereitet: keine abstrakten Summenwerte, sondern ein Index, der mit der Wetteronline Intensitäts-Skala korrespondiert und nur für die eigene HomeBase (= Niederschlags-Überwachungszone des selbst gewählten Standorts) gilt. Der vom RRFC ermittelte Niederschlags-Index ist ein Durchschnittswert aller registrierten Intensittätswerte innerhalb der HomeBase. Ein Niederschlags-Index zwischen 0,0 -1,0 entsptricht also der ersten Intensitäts-Stufe auf der Wetteronline Intensitäts-Skala (hellblau, erster Farbbalken von Links). Ein Niederschlags-Index von 1.0 – 2.0 entspricht dann dem 2. Farbbalken usw.usw.
Was neu in der Version 3.0?
Für den erfahrenen RRFC 2.0-Nutzer hat sich auf den ersten Blick nicht viel geändert – außer: die Version 3.0 funktioniert! Nachdem ich im Februar 2016 die Version 2.0 fertig gestellt hatte, hat Wetteronline seine Webseite umgestellt und der RRFC 2.0 funktionierte plötzlich nicht mehr. Hauptgrund war, dass Wetteronline die Auslieferung des Radarbild-Forecasts nun nicht mehr über ein animiertes .gif vornahm, sondern über Einzelbilder. Das bedeutete, dass das gesamte Konzept des RRFC 3.0 umgestellt bzw. neu erarbeitet werden musste (für den interessierten Leser: das hat – nur für die V 3.0 – ca. 100 Stunden Aufwand gekostet ;-).
Weiterhin wurde auf Betriebssicherheit und -Stabilität des RRFC sehr viel Wert gelegt: neu sind umfangreiche und aufwändige Kontroll- und Plausibilitäts-Routinen, die den Download der Radarbilder und deren Ergebnisse überwachen und auswerten. Die Testphase mit einigen Testusern zeigte hier, dass eine schlechte WAN-Leitung das Projekt durchaus zur Verzweiflung treiben konnte (der RRFC hat sich nicht selten durch Time-Outs bei Downloads aufgehängt). Hier war die Testphase mit den Testusern sehr, sehr hilf- und erkenntnisreich. Besten Dank nochmal an alle Tester!
Daraus resultierend wurde unter anderem ein Watchdog-Script eingebaut, was den Zustand des RRFC ständig überwacht und bei Problemen automatisch den System-Administrator via eMail informiert. Ebenso stehen nun Variablen breit, die Auskunft über den Systemzustand des RRFC geben (‚Störung‚ und ‚Notbetrieb‚) und im IP-Symcon für andere Anwendungen ausgewertet werden können.
Was mich persönlich aber richtig gefreut hat und ein riesen Mehrwert für den RRFC ist: Wetteronline stellt jetzt 5-Minuten-Intervalle für den Niederschlags-Forecast zur Verfügung. Die bisherigen Erfahrungen aus der Vergangenheit (mit 15-Minuten Intervallen) bestätigten immer wieder: das Zeitintervall von 15-Minuten ist für Homeautomatisierungs-Aufgaben einfach zu groß. Da kann ein kleiner, aber schneller Regenschauer schnell mal unerkannt durch den zu überwachenden Home-Radius sausen! Ich hatte mir schon immer ein 5-Minuten-Intervall gewünscht, nun isses da!
Bedienung (WFE)
Nach der Installation präsentiert sich der RRFC im WFE und beinhaltet 4 Bereiche:
1. Zeitstrahl
Dient zur Visualisierung der aus der Radarbild-Analyse gewonnen Informationen. Intervalle mit Intensitätswerten unterhalb des eingestellten Schwellwerts werden minimiert dargestellt, Intervalle mit Intensitätswerten >= dem eingestellten Schwellwert werden mit Zeitstempel, farblicher Codierung (die dem Intensitätswert entspricht) und Tooltip-Informationen bereitgestellt. Unterhalb des Zeitstrahls befinden sich 3 zusätzliche Variablen, die Beginn, Niederschlagsintensität und Ende zum Zeitpunkt des Downloads ersten bevorstehenden Niederschlagsintervalls beinhalten.
2. Intensitätsvariablen der ersten 8 Zeitintervalle
Hier wird für die ersten 8 5-Minuten Intervalle der durchschnittliche Niederschlagsintensitätswert für die zu überwachende Homebase hinterlegt. Der Durchschnittswert ergibt sich wie folgt: Summe Intensitätswerte aller Netto-Pixel innerhalb der Homebase / Anzahl Netto-Pixel. Hierbei berechnet sich die Fläche der Homebase (in Pixel): 2* Analyse-Radius + 1. Die Nettopixel sind alle Pixel innerhalb der Homebase abzüglich evtl. Karten-Objekte (Ortsnamen, Gewässer, Orts-Symbole). Beide Angaben (Fläche Homebase und Netto-Pixel) befinden sich auch in den Objektbezeichnungen über dem Zeitstrahl und den Intervall-Variablen.
3. Anzeige der Radarbilder
Hier werden alle vom RRFC geladenen Radarbilder (Standard: 1 Radarbild ‚IST‘ + 20 Radarbilder Forecast) über den WFE Inhaltswechsler bereitgestellt (der Wechselintervall beträgt 1 Sekunde). Der Inhaltswechsler kann vom User nach eigenen Wünschen konfiguriert werden.
4. Konfig-Bereich (standardmäßig eingeklappt)
Direkt nach der Installation und Initialisierung, Betriebsstörung oder Notbetrieb des Projekts ist der Konfig-Bereich ausgeklappt (Schwellwert-Variable rot hinterlegt), um dem User die Konfiguration bzw. die Erkennung von Problemen zu erleichtern. Sind die Konfig-Elemente sichtbar, können hier alle Einstellungen für das Projekt vorgenommen werden (Konfigurationen via Konsole/User Config sind nicht notwendig). Die Schwellwert-Variable ist mit einer Toggle-Funktion zum ein- und ausklappen des Konfig-Bereiches ausgestattet: einmaliges Klicken auf den aktiven Schwellwert klappt den Konfigbereich ein/aus.
Jede der Konfigurations-Variablen ist mit einer Verzögerung zur Übernahme der daten ausgestattet: das Projekt übernimmt die Daten erst, nachdem mindestens für 5 Sekunden keine Eingaben mehr erfolgt sind. Die Übernahme erfolgt durch einen erneuten Download (und Analyse) aller Radarbilder (Ausnahme: wird die Region geändert, erfolgt eine Projekt-Reinitialisierung).
Der Konfig-Bereich wird vom Projekt selbständig ca. 35 Minuten nach der letzten manuellen Bedienung eingeklappt (sofern keine Betriebsstörung oder Notbetrieb vorliegt).
Weiterhin erzeugt der RRFC aus allen geladenen Radarbildern zusätzlich ein animiertes GIF, welches als Media-Objekt im IPS-Objektbaum angelegt und aktualisiert wird, aber standardmässig nicht im WFE sichtbar ist. Das animierte GIF ist z.B. für die schnelle und schlanke Darstellung auf mobilen Devices (IPSView oder IPS mobile) gedacht. Hinweis: nach jeder Projekt-Initialisierung (und damit auch nach dem Wechsel einer Region) wird das Media-Objekt gelöscht und neu erzeugt => die Objekt-ID ändert sich damit!
Schnittstellen + Bedeutung
Betriebssicherheit
In der aktuellen Version des RRFC wurde nochmals verstärkt auf die Betriebssicherheit und -Stabilität Wert gelegt. Death Threads (wie in der Testphase bei schlechter WAN-Anbindung öfter aufgetreten) dürften nun nahezu ausgeschlossen sein. Der RRFC erkennt nun Time-Outs und Verbindungsprobleme selbstständig und kann vor allem auch darauf reagieren (mit entsprechender Fehlerbehandlung, bis hin zum Script-Abbruch). In dem Zusammenhang ist auch die frühere (optionale) WAN-Überwachungs-Variable aus dem System des Anwenders nicht mehr notwendig.
Dennoch wurde ein eigenes Watchdog-Script eingebaut, was alle 3 Minuten den Zustand des Projekts überwacht und ggf. Alarm schlägt. Der Wachhund kennt 2 Problemfälle (die auch direkt im Konfig-Bereich des WFE in der Variable „Betriebsstörung“ angezeigt werden):
1. Scriptfehler (Betriebsstörung): das Script wurde von IP-Symcon als fehlerhaft eingestuft – ist aber theoretisch noch lauffähig. Gründe dafür sind z.B.:
a) Der Downloadmanager benötigt zur Abarbeitung mehr als die zulässige Maximal-Laufzeit
b) Variablen nicht definiert
c) Syntaxfehler etc.
Die Bereitstelllung der aktuellen Analyse-Ergebnisse erfolgt mit hoher Wahrscheinlichkeit nicht mehr. Es besteht aber durchaus die Chance, dass das Script zum nächsten Lauf wieder normal läuft und die Betriebsstörung aufgehoben wird. Der Wachhund versendet jedoch vorsichtshalber eine eMail an den System-Administrator und wiederholt diese Mail jede Stunde, sofern die Betriebsstörung noch besteht. Weiterhin wird -um die System-Ressourcen zu schonen, die Anzahl der Download-Intervalle auf max. 3x pro Stunde begrenzt sowie der Konfig-Bereich ausgeklappt, um die Störung auch zu singalisieren.
2. Death Thread: der Downloadmanager hat die max. zulässige Scriptlaufzeit überschritten und kann von PHP nicht mehr beendet werden. Dies bedeutet, dass der RRFC definitiv nicht mehr betriebsfähig ist bzw. diese Betriebsfähigkeit mit dem nächsten Durchlauf wieder herstellen kann. Darüber hinaus wird es beim nächsten Versuch, IPS runter zu fahren, zwangsläufig dazu kommen, dass der IPS-Task ‚abgeschossen‘ werden muss, da es sich nicht mehr regulär beenden läst. Datenverlust (Variablen-Daten und ggf. Änderungen im Objektbaum) kann die Folge sein. Enstprechende Vorsichtsmaßnahmen sind dazu passend in der Watchdog-Mail enthalten. Hier wird ebenfalls zusätzlich der Konfigbereich zur optischen Signalisierung ausgeklappt.
Merke: eine Mail vom Wachtdog sollte auf jeden Fall zur manuellen Kontrolle durch den Amin führen. Und das besser gleich als später!
Notbetrieb:
Und dann gibt es noch die Probleme auf dem Weg von der LAN-Schnittstelle des IPS-Hosts bis zum Wetteronline-Server, zusammengefasst unter ‚Download-Problemen‘. Ja, ich mach es mir hier einfach und schiebe alles auf die Anderen ;-) Stellt der Download-Manager fest, dass ein Download-Zyklus nicht erfolgreich war (und er versucht es mehrfach, bevor er das behauptet), setzt er den Download-Zähler hoch. Um einen fehlerhaften Download handelt es sich, wenn das PIC 0 (= Radarbild vom aktuellen 5 Minuten Intervall) nicht vollständig geladen werden kann. Wird die max. zulässige Anzahl fehlerhafter Downloads (Defaultwert = 20) überschritten, geht der Download-Manager in den Notbetrieb. Notbetrieb heißt: nur noch 1 Download-Versuch pro Stunde. Der Konfigbereich im WFE wird zur Signalisierung eingeblendet – mehr nicht (keine Watchdog-Mail!).
Zusammengefasst heißt das: der RRFC stellt dem IP-Symcon fast alle möglichen Problem-Zustände zur Verfügung – sie müssen nur genutzt werden. Koppelt der IPS-Anwender die Steuerung kritischer Themen mit dem RRFC, sollte er unbedingt die beiden Variablen ‚Störung‚ und Notbetrieb‚ überwachen und mit den eigenen Steuerungen entsprechend darauf reagieren!
Beispiel: der Nutzer koppelt den RRFC mit seiner Dachfenster-Steuerung. Aufgabe: bei drohendem Niederschlag spätestens 15 Minuten vor Eintreffen Desselben sollen die Dachfenster geschlossen werden (weil: der Pool ist ja im Keller). Empfohlenes Vorgehen: verlässt eine der beiden Variablen (‚Störung‚ oder ‚Notbetrieb‚ ) den Normalzustand, sollte die eigene Steuerung unbedingt vorsorglich die Dachfenster schließen. Völlig unabhängig von irgendwelchen Intensitäts-Werten, die der RRFC bereit stellt.
Showcase
Und wer gleich bis hier runter gescrollt hat, spart sich den ganzen Text und geht direkt über LOS direkt zum Live-Projekt: RS RRFC in meiner Area51
Kompatibilität
Der RRFC ist unter IPS 3.4 entwickelt worden. Er ist auch unter IPS 4.0 (sowohl Windows als auch Linux) installierbar und betriebsfähig (erfolgreich getestet).
Hinweis für Linux-User: Wenn das Betriebssystem nicht auf Systemsprache ‚englisch‘ gesetzt ist, wird der Zeitrahl im WFE nicht korrekt dargestellt. Voraussetzung für eine korrekte Darstellung ist die Systemsprache ‚englisch‘. Hintergrund: steht die Systemsprache z.B. auf ‚deutsch‘, so werden die Dezimal-Trenner von Floatwerten ein ein Komma umgewandelt (z.B.: 3,1415 statt 3.1415). Das führt dazu, dass der Browser rgba-Farbwerte (hier insbesondere den Wert für den Alpha-Kanal) nicht mehr korrekt interpretieren kann.
(Erst-)Installation
Das Projekt wird -wie immer – als Project Exporter Paket geliefert. Das heißt: alle benötigten Objekte befinden sich in einem einzigen Installationsscript. Einfach das Script aus dem Download ins eigene IPS einbauen (egal wo), die ID des WFC-Konfigurators angeben und Script starten.
Zur Aktivierung des Projekts sind mindestens folgende Aktionen nötig:
- Angabe des Projekt-Namen (bei Parallel-Installation des Projekts unbedingt unterschiedliche Projektnamen vergeben!)
- einmaliges, manuelles Starten des Scripts „User-Config“ aktiviert das Projekt – fertig
Das Projekt holt nun initial und dann alle 5 Minuten die Radarbilder ab und analysiert dieses vollautomatisch.
Im WFE können im Konfig-Bereich nun jederzeit Region, Intensitäts-Schwellwert, Analyse-Radius und Standort-Koordinaten geändert werden.
Update
1. Installation
Ein Update setzt eine bestehende Installation und mindestens ein Installationsprotokoll der letzten Installation voraus. Das Script aus dem Download wird in das bestehende Installer-Script einkopiert (Angabe der WFE-ID nicht vergessen) und ausgeführt. Die Projektinstallation ist nun abgeschlossen. Es wird eine neue User-Config (‚User Config V3.1 20160720‚) angelegt. Die alte User-Config wird nicht mehr benötigt und kann gelöscht werden (vorher ggf. die Konfigurationsparameter aus der alten User-Config übernehmen)
2. Projekt-Initialisierung
- Config-Script öffnen und Minimal-Konfiguration vornehmen: Projektnamen vergeben
- Config Script ausführen
- Ins WFE wechseln und Projekt nach eigenen Wünschen im Konfig-Bereich konfigurieren (Konfig-Bereich ist nach Initialisierung automatisch ausgeklappt)
Versions-Hinweise
RS RRFC 3.0: Initial-Version vom 26.06.2016
RS RRFC 3.1: Version 3.1 vom 22.07.2016
Nutzungsrechte
- das Script darf für private, nicht kommerzielle Zwecke frei verwendet werden
- eine Weitergabe oder Änderung sowie auszugsweise Verwendung des Codes nur nach schriftl. Genehmigung des Autors
- für evtl. entstehende Schäden durch die Verwendung dieses Scripts wird vom Autor keinerlei Haftung übernommen
- gewerbliche Nutzung nur in vorheriger Abstimmung mit dem Projektautor (MICH)
Quellen:
Live-Daten
Eine Gegenüberstellung der Forecast-Ergebnisse und tatsächlicher Niederschlags-Intensität kann man sich hier live anschauen.
Download:
Der Download erscheint für eingeloggte User unter diesem Beitrag.