RS RainRadar Forecast (RRFC) 3.0 ist da!

Betriebszustands-Variablen RRFC 3.0

die Testphase der verg. 2 Wochen hat richtig gute Erkenntnisse gebracht! In Sachen Betriebsstabilität und -Sicherheit hat der RS RainRadar Forecast 3.0 (ff. RRFC) einen Satz nach vorn gemacht. Im Hinterkopf die Überlegung: was ist, wenn der Anwender über die Analyse-Ergebnisse des RRFC kritische Anwendungen in seinem Haus steuert,  und die Analyse-Argebnisse sind falsch, nicht mehr aktuell etc.? Evtl. entstehen materielle Schäden (durch z.B. ein nicht geschlossenes Dachfenster, weil der RRFC ausgefallen ist oder sich das Script aufgehängt hat)? Natürlich übernehme ich dafür keine Haftung, aber Vertrauen in den RRFC ist mir sehr, sehr wichtig.

Im Ergebnis dieser Überlegungen und der Testphase sind ein Watchdog-Script (mit Alarm-Mailfunktion) und 2 Variablen dazu gekommen, die Auskunft über den Betriebszustand des RRFC geben. Diese Variablen dienen nicht nur zur Information des Users, sondern sollten (bei den og. kritischen Anwendungen) auch immer mit in die Steuerung einbezogen und berücksichtigt werden!

Was gibts Neues?

wie schon angedeutet: auf den ersten Blick (ins WFE) nicht viel Neues! Die wirklich einzige und wesentlich signifikante Änderung hat Wetteronline vorgegeben: durch den Wechsel vom animierten Forecast.gif (im 15 Minuten Intervall) auf Einzelbilder (im 5 Minuten Intervall) musste nicht nur der RRFC komplett überarbeitet werden, sondern es stehen nun für die Homeautomation Forecastdaten im 5 Minuten Intervall zur Verfügung. Das erhöht deutlich die Forecast-Präzision und Sicherheit. Während es bei 15 Minuten Intervallen durchaus vorkommen konnte, dass ein kleiner, schneller Regenschauer vom RRFC unbemerkt durch die zu überwachende Homebase rasen konnte, dürfte das nun mit 5 Minuten Intervallen kaum noch möglich sein. Damit ist die Verlässlichkeit deutlich höher geworden – und hat mich riesig gefreut.

Leicht angepasste Darstellung des RRFC 3.0 Zeitstrahls

Das hat zur Folge, dass die 8 Intensitäts-Variablen nun auch Daten im 5-Minuten Intervall enthalten (wer hier Daten für die eigene Steuerung abgreift, sollte diese ggf. nochmal auf Anpassungsbedarf überprüfen) und ’nur‘ die Daten der kommenden halben Stunde enthalten (vorher 90 Minuten), auch der Zeitstrahl sieht nun etwas anders aus: deutlich mehr Intervalle und etwas andere Darstellung (siehe Bild): komprimierte Darstellung von 5 Minuten Intervallen ohne Niederschlag – Intervalle mit Niederschlag werden wie bisher dargestellt (farblich entsprechend der Niederschlagsintensität markiert und mit Zeitstempel).

Kurzübersicht der Änderungen

• Zeitliche Auflösung des Forecasts nun 5 Minuten (vorher 15 Minuten)
• Wachtdog zur Selbstüberwachung und Signalisierung von Betriebsstörungen via WFE und eMail (wenn mind. eine Mailinstanz im System vorhanden ist)
• 2 Variablen mit Angaben zum Betriebszustand („Störung“ + „Notbetrieb“)
• Bereitstelllung eines zusätzlichen animierten RADAR.GIF, welches alle Einzelbilder enthält (zur individuellen Verwendung)
• Durch den User konfigurierbare Anzahl Radarbilder für Vergangenheit und Zukunft (siehe User Config)

Was ist  ‚Notbetrieb‘?

RRFC 3.0: aktivierter Notbetrieb

Der Notbetrieb bezieht sich immer auf Störungen, die außerhalb des Projekts liegen (z.B. WAN-Anbindung unterbrochen, Wetteronline.de nicht erreichbar, PIC 0 [= Radarbild des aktuellen 5 Minuten Intervalls]  nicht vorhanden etc.) Er wird dann aktiviert, wenn der RRFC nach einer bestimmten Anzahl von Download-Versuchen (Default: 20, konfigurierbar via User Config) kein Radarbild (PIC 0) runterladen konnte. Ist der Notbetrieb aktiviert, erfolgen die nächsten Download-Versuche nur noch 1x pro Stunde (in der Hoffnung, dass sich die Ursache für den Notbetrieb irgendwann abstellt. Sie Signalisierung des Notbetriebs erfolgt optisch, in dem der Konfig-Bereich eingeklappt wird (und die Variable ‚Notbetrieb‘ mit rotem Inhalt sichtbar wird). Der Notbetrieb wird mit dem nächsten erfolgreichen Download von PIC 0 deaktiviert. Die Zustände der Variable „Notbetrieb“ sind „true“ für aktivierten Notbetrieb und „false“ für deaktivierten Notbetrieb.

Was ist ‚Störung‘?

Eine Betriebsstörung liegt immer dann vor, wenn Das Problem innerhalb des Projekts liegt. In der Regel ist hier manuelles Eingreifen erforderlich.Die Überwachung des Betriebszustandes erfolgt alle 3 Minuten durch den im RRFC eingebauten Watchdog. Hier wird zwischen 2 Arten der Betriebsstörung unterschieden:

a) Scriptfehler (Betriebsstörung)

Das Script wurde vom System (=IP-Symcon) fehlerhaft markiert (erscheint rot im Objektbaum). Diese Störung muss nicht den Totalausfall bedeuten – wenn die Ursachen für diese Störung beim nächsten Durchlauf nicht mehr existieren. Sicherheitshalber wird hier eine dedizierte eMail versandt (bei Fortbestand der Störung 1 weitere Mail pro Stunde), der Download-Intervall wird auf 3x pro Stunde reduziert. Reanimiert sich das Projekt im nächsten Durchlauf, wird die Störung aufgehoben (kein eMail-Versand).

b) Death Thread (schwere Betriebsstörung)

Tritt ein Death Thread (= aufgehängter PHP-Task, Script lässt sich nicht beenden) auf, ist Hopfen und Malz verloren: hier hilft nur noch ein IPS-Restart (sehr wahrscheinlich nur mit Abschuss des IP-Symcon Tasks). Da ein solcher Restart Datenverlust mit sich bringen kann, wurden besondere Hinweise in die eMail eingebaut, die der Watchdog in diesem Fall verschickt. Folgemails werden 1x pro Stunde versandt, sofern die Störung nicht beseitigt wurde.

Verlässliche Niederschlags-Datensind hier in keinem Fall mehr zu erwarten, da jeder weitere Startversuch des RRFC abgebrochen wird!

Die Zustände der Variable „Störung“ sind: 0 = keine Störung; 1 = Scriptfehler; 2 = Death Thread 

Parallel-Installation von 3 RRFC 3.0 Projekten

Download

… wie immer über die Homepage des Projekt: Projekte/RS RainRadar Forecast 3.x