RS RainRadar Forecast V 0.x (alt)

Alle Projekte auf Raketenschnecke.net sind ab 2013 mit einem Update-Info Modul ausgestattet. Ist eine neuere Version des Projekts verfügbar, wird eine Info über das WFE eingeblendet. Ausnahme: der Project Exporter hat keine WFE-Visualisierung, daher werden hier die Update-Informationen im Script-Meldungsfenster ausgegeben. Diese Info verschwindet nach einem erfolgreichen Update.

Versions- und Update-Infos werden immer über einen Blog-Artikel veröffentlicht, der mit der Projekt-Homepage verlinkt ist.

Der DB-Analyzer ist defaultmäßig so konfiguriert, dass er innerhalb der ersten 10 Minuten nach Mitternacht läuft. Hierbei werden nicht nur die Logging-Zeiträume der Variablen aufgeräumt (sofern in den variablen Vorhaltezeiträume definiert wurden), es werden auch Statistik-Daten erhoben, die ohne den täglichen Lauf nicht ermittelbar sind. Das sind im Wesentlichen die Zuwächse der Datenbestände pro Variable. 

Da auch der Datenzuwachs pro Tag ermittelt wird, ist es wichtig, dass der DB-Analyzer möglichst exakt zum selben Zeitpunkt läuft, da anderenfalls nicht korrekte Zuwachsraten pro Tag gemessen werden.

Lässt man den DB-Analyzer nun in unregelmäßigen/größeren Zeitabständen laufen,  ist eine Analyse der Datenbestände und Zuwächse kaum möglich bzw. wird es hier zu falschen Schlussfolgerungen kommen. Soweit man das in Kauf nehmen kann/will, kann der DB-Analyzer auch in unregelmäßigen/größeren Zeitabständen laufen (was aber ausdrücklich nicht empfohlen wird und auch nicht im Sinne des Projekts ist).

Keine Angst, Du bist nicht blind! Die Downloads sind (seit 16.11.2014) nur registrierten Usern zugänglich ;-)

F: Bei mir läuft der DB-Analyzer sehr lange (Script „read DB“),  IPS ist während dieser Zeit wie blockiert, DeathThreads tauchen auf. Woran liegt das, was kann ich tun?

A: Die Abfrage der Datensatz-Informationen aus der IPS-DB ist ziemlich Ressourcenhungrig. Bei einer intakten DB sollte das aber dennoch kein Problem sein.
Bei mir dauert eine Abfrage (Script „read DB“) ziemlich stabil zwischen 10-12 Sekunden. Ich habe ca 240 geloggte Variablen, die DB ist genau 2 Jahre als und beinhaltet aktuell 9,7 Mio Datensätze. Der Server ist ein i5 mit SSD’s und 8GB RAM.
Es kommt bei mir (selten) mal vor, dass die Abfrage 60 Sekunden läuft. Der Grund ist mir nicht transparent. Aus diesem Grunde habe ich die Laufzeit bei mir sehr großzügig eingestellt, um hier nicht auf einen Fehler zu laufen.
In den Fällen, wo das Script wirklich eine Blockade des IPS und DeathThreads zur Folge hat (bisher sind mir 4 Fälle bekannt, 3 davon wurden gelöst, im 4. Fall ist mir der Status nicht bekannt), war das immer auf eine korrupte DB zurück zu führen. Es empfielt sich hier, einen DB-Scan bzw. einen Repair-Versuch (keine Reaggregation!) zu starten: Anleitung DB-Reparatur auf der IP-Symcon-Seite.

Hinweis: Das Prüfungsergebnis der Db durch die genannten Tools ist leider nicht verlässlich! Auch fehlerfrei gemeldete Datenbanken verursachten Fehler im Betrieb, welche erst nach einem  tatsächlichen Reparaturlauf beseitigt wurden.

F (aus IPS-Forendiskussion):

Wir haben hier ja schon oft diskutiert das dies in einer SQLite ja eigentlich Blödsinn ist, da die Daten nur als gelöscht markiert aber nicht physisch gelöscht werden. Die Filegröße bleibt gleich.
Ist das bei deiner Löschfunktion auch so, oder reorganisierst du die Datenbank hinterher ?
Macht es also Sinn für die Behaltezeiten einzupflegen, oder ist das nur Makulatur – in Bezug auf Filegröße ?

A: Also: Blödsinn ist das m.E. nicht. zwar wird das File nicht kleiner (was durch es reagggregieren übrigens auch nicht wird), dazu müsste man IPS runterfahren und manuell verdichten.

Der Vorteil ist schon gegeben, da der durch gelöschte Daten eingesparte File-Space anschließend mit neuen Datensätzen aufgefüllt wird. d.h. dein File wächst solange nicht, bis die vor dem Löschen erreichte Anzahl von Datensätzen wieder erreicht ist. Und hier spielt der DB-Analyzer einen richtigen Vorteil aus: durch das tägliche Löschen ereicht man, dass das File so klein wie möglich bleibt (und nicht in der Größe oszilliert, wenn man alle paar Monate man. löschen + verdichten würde).

sehr gut zu sehen ist das hier:  RS.SYS-Health (Chart ganz unten)

vielleicht noch ein Nachtrag, um den Vorteil des zyklischen Löschens zu verdeutlichen:
würde man alle Variablen mit einer Vorhaltezeit definieren, dann täglich alle Daten (die nicht in diesem Zeitraum liegen) löschen, würde das DB-File nicht mehr wachsen. Seine Größe bliebe konstant. Natürlich nur unter der -rein theoretischen- Annahme, dass das tägliche Datensatz-Aufkommen absolut konstant ist.

Alle Projekte auf Raketenschnecke.net sind ab 2013 mit einem Update-Info Modul ausgestattet. Ist eine neuere Version des Projekts verfügbar, wird eine Info über das WFE eingeblendet. Ausnahme: der Project Exporter hat keine WFE-Visualisierung, daher werden hier die Update-Informationen im Script-Meldungsfenster ausgegeben. Diese Info verschwindet nach einem erfolgreichen Update.

Versions- und Update-Infos werden immer über einen Blog-Artikel veröffentlicht, der mit der Projekt-Homepage verlinkt ist.

Das ist grundsätzlich dann ok, wenn das Config-Script manuell gestartet wurde (nach Installation oder Update). Das Config-Script legt 0-Byte Files an, um IP-Symcon zu animieren,  zu den Files korrelierende Media-Objekte im Objektbaum anzulegen. Erst nach dem ersten erfolgreichen Download von Wetteronline enthalten diese Files richtige Bilder.

Installieren kann man es zwar beliebig oft, aber die Scripte sind nicht dafür ausgelegt, mehrere Standorte zu unterscheiden. Spätestens bei den Einzel-GIFs würden sich die Projektinstanzen gegenseitig kanibalisieren (Stichwort „Fadenkreuz“).
Allerdings spiele ich schon mit dem Gedanken, dem Projekt eine Standort-Unterscheidung beizubringen. Kann also gut sein, das sowas ab V0.5 möglich ist.

F: ich wohne nicht in Deutschland, kann ich den RS RainRadar Forecast auch (z.B. in Österreich/Schweiz) nutzen?

A: prinzipiell ist des dem Script, egal, welche Wetteronline-Region benutzt wird. Leider stellt aber Wetteronline derzeit nur Regionen innerhalb Deutschlands als Radar-Forecast zur Verfügung. Somit ist der RainRadar Forecast derzeit für Regionen außerhalb Deutschlands nicht nutzbar.

Man kann sich aber statt einer Region auch die Übersicht für Deutschland laden. Statt der im Config-Script angegebenen Regionen einfach „DL“ eintragen. Zumindest für die angrenzenden Regionen der Nachbarländer ist dann der RainRadar Forecast nutzbar (wenn auch mit deutlich geringerer Auflösung)

Falls bei der Installation etwas schief läuft (grrr: das Problem mit der sauberen Installation der Media-Objekte hab ich immer noch nicht im Griff => hier hakt es in einigen Systemen und die Installation läuft nicht sauber durch) oder man aus anderen Gründen den RS RainRadar Forecast vollständig aus seinem System entfernen will, reicht es nicht, nur die Objekte im Objektbaum der Konsole zu löschen.

Darüber hinaus sollte man auch

• die Media-Objekte (GIF-Bilder „latestForecast_0.gif“ – „latestForecast_9.gif“ im Ordner „\media“  entfernen
• den Projekt-Ordner „\webfront\user\RS_RainRadar_Forecast“ löschen
• im Webfront-Konfigurator alle Objekte ab „CpyRegenForecast“ löschen
• alle Variablenprofile beginnend mit „CpyRegenForecast….“ löschen

Für die beiden letztgenannten Aufgaben gibt es auch Tools, nämlich den Variablenprofil-Töter „IPS RS VP Terminator“ und den Webfront-Sanierer „IPS RS WFE Terminator„.

Wer nur eine „verbogene“ Installation durch eine erneute Installation/Update grade biegen will, braucht nur die Mediafiles („latestForecast_0.gif“ etc) zu löschen, Installscript neu starten…. und so weiter und so weiter.

Ansonsten wird ja wohl ein vollständiges Entfernen dieses Projekts nicht in Frage kommen, gelle?!

Keine Angst, Du bist nicht blind! Die Downloads sind (seit 16.11.2014) nur registrierten Usern zugänglich ;-)

Der RS RainRadar Forecast ist auf IPS-Version V2.7 (Build #2732) entwickelt worden, bis auf einige Fehler im Installationsscript (die ignoriert werden können), läuft es dort problemlos. Erste Tests auf der IPS V3.0 (Beta) sehen gut aus, jedoch sind hier neue Funktionen für Webfront-Objekte hinzugekommen, die mit der bisherigen Installationsroutine nicht abgedeckt werden. Funktionsfähig ist die V0.3 unter IPS 3.0 jedoch.

+++++ ab Version V0.4 behoben: das Install-Script wird mit einer neueren Version des Project Exporters erstellt ++++++++++

Primäre Ursache für diese Fehler ist ein Bug im Project Exporter: der kann mit Media-Objekten nicht 100%ig umgehen. Sofern man die IPS-Library/IPS-Logger nicht installiert hat, kann man diese Fehler ignorieren, da das Config-Script eine eigene Installationsroutine für die Media-Files mitbringt. Hat man die IPS-Library/IPS-Logger installiert, ist das Problem etwas größer: hier wird jedes Script abgebrochen, welches eine bestimmte Fehleranzahl überschreitet. Damit wird die Installation abgebrochen,, das Projekt ist nicht vollständig installiert. Hier gibt es 2 Möglichkeiten: 1. auf die nächste Version (V0.4) des RS RainRadar Forecast warten oder die Fehlertoleranz der IPS Library/IPS-Loggers hoch setzen => bitte hierzu den Entwickler der IPS-Library (Brownson) kontaktieren.

Alle Projekte auf Raketenschnecke.net sind ab 2013 mit einem Update-Info Modul ausgestattet. Ist eine neuere Version des Projekts verfügbar, wird eine Info über das WFE eingeblendet. Ausnahme: der Project Exporter hat keine WFE-Visualisierung, daher werden hier die Update-Informationen im Script-Meldungsfenster ausgegeben. Diese Info verschwindet nach einem erfolgreichen Update.

Versions- und Update-Infos werden immer über einen Blog-Artikel veröffentlicht, der mit der Projekt-Homepage verlinkt ist.

Der Energy-Forecast lebt von den Daten aus der Vergangenheit und Gegenwart.

Benötigter Zeitraum
Daher werden Verbrauchsdaten mindestens für die letzten 7 Wochen erwartet. Aus den Daten dieser 7 Wochen und den aktuellen berechnet sich der Tages-Forecast.
Daher ist ab Version 1.0 des Energy-Forecasts auch eine Datenmengenprüfung eingebaut, die die Projekt-Initialisierung abbricht, wenn Daten über weniger als 7 Wochen gefunden werden und der IPS-Logger installiert ist. Unter dieser Konstellation ist ein Abarbeiten der Scripte nicht möglich.

Benötigter Logging-Intervall
Weiterhin werden Loggingdaten in möglichst hoher, zeitlicher Auflösung benötigt. Der Loggingintervall sollte zwischen 1-5 Minuten liegen. Je feiner die zeitliche Auflösung, desto besser und zielgenauer das Forecast-Ergebnis.

IPS-Version

Im Download-Fenster ist die jeweilige IPS-Version angegeben, unter der das Projekt entwickelt wurde. Kleinere IPS-Versionen als angegeben sollten auch funktionieren – was aber nicht  garantiert werden kann.

Nein!

Das Projekt wurde bewusst so entwickelt, dass die im Projekt benutzten HighCharts projektgebunden installiert und konfiguriert werden. Das heißt, das Projekt RS Energy Forecast bringt bei der Installation seine eigene Highchart-Installation mit und legt diese auch in einem für dieses Projekt separat angelegten Ordner an. Somit wird die Highcharts-Versionspflege ausschließlich über die Projektinstallation vorgenommen und ist damit völlig unabhängig von evtl. weiteren, durch den Anwender vorgenommenen Installationen.

Der Anwender kann während dessen völlig unbekümmert seine eigene, parallel existierende HighChart-Installation updaten, neu installieren, löschen etc. etc – die HighCharts im RS Energy Forecast bleiben davon unberührt.

Eine Konfiguration ist ebenfalls nicht notwendig, dies wird alles aus dem Projekt heraus erledigt und gesteuert.

Keine Angst, Du bist nicht blind! Die Downloads sind (seit 16.11.2014) nur registrierten Usern zugänglich ;-)

Alle Projekte auf Raketenschnecke.net sind ab 2013 mit einem Update-Info Modul ausgestattet. Ist eine neuere Version des Projekts verfügbar, wird eine Info über das WFE eingeblendet. Ausnahme: der Project Exporter hat keine WFE-Visualisierung, daher werden hier die Update-Informationen im Script-Meldungsfenster ausgegeben. Diese Info verschwindet nach einem erfolgreichen Update.

Versions- und Update-Infos werden immer über einen Blog-Artikel veröffentlicht, der mit der Projekt-Homepage verlinkt ist.

Keine Angst, Du bist nicht blind! Die Downloads sind (seit 16.11.2014) nur registrierten Usern zugänglich ;-)

Alle Projekte auf Raketenschnecke.net sind ab 2013 mit einem Update-Info Modul ausgestattet. Ist eine neuere Version des Projekts verfügbar, wird eine Info über das WFE eingeblendet. Ausnahme: der Project Exporter hat keine WFE-Visualisierung, daher werden hier die Update-Informationen im Script-Meldungsfenster ausgegeben. Diese Info verschwindet nach einem erfolgreichen Update.

Versions- und Update-Infos werden immer über einen Blog-Artikel veröffentlicht, der mit der Projekt-Homepage verlinkt ist.

Keine Angst, Du bist nicht blind! Die Downloads sind (seit 16.11.2014) nur registrierten Usern zugänglich ;-)

F: Ich habe die Installation abgeschlossen, es gibt eine Reihe von Kategorien, Dummy-Instanzen, Scripte usw. Aber kaum Variablen (weder im WFE noch im Objektbaum) mit denen sich mein DENON nun steuern lässt. Was ist schief gelaufen?

A: Alles OK, keine Panik! Das Projekt legt von sich aus die Steuerungs-Variablen für den DENON an, und zwar während des Betriebs – nicht bei der Installation. Wird eine Funktion am DENON abgerufen (z. B. über die Fernbedienung), so teilt der DENON dies über seine Schnittstelle mit. Der DENON AVR Connector nimmt das auf und prüft im Hintergrund, ob für diese Steuerfunktion schon eine Variable existiert. Ist das nicht der Fall, so wird die Variable vom DENON AVR Connector angelegt.

Grund für das Verhalten ist folgende Überlegung: IPS-Einsteiger beginnen oft mit der IPS-Basic Version. Diese ist auf 100 Variablen limitiert. Würde nun der DENON AVR Connector bei Installation alle am DENON vorhandenen Funktionen installieren, so wäre die IPS-Basic Version schnell am Limit. So kann man sich auf die Variablen beschränken, die tatsächlich benutzt werden (und das ist meist nur ein Bruchteil der verfügbaren Funktionen).

Keine Angst, Du bist nicht blind! Die Downloads sind (seit 16.11.2014) nur registrierten Usern zugänglich ;-)