Hallo, bekomme seit heute folgende Meldung.
18.12.2020, 13:37:59 | Register Variable | <br />
<b>Warning</b>: Use of undefined constant Value - assumed 'Value' (this will throw an Error in a future version of PHP) in <b>/var/lib/symcon/scripts/36481.ips.php</b> on line <b>1332</b><br />
Gruß Micha
Danke für den Hinweis, sollte jetzt wieder funktionieren
Danke, läuft wieder…
Micha
Der Filter scheint noch ein Schlupfloch zu haben, wenn mehrere Meldungen gleichzeitig kommen:
Ich habe das Thema gerade mit einem Freund beredet und der hatte eine gute Idee. Anstatt die Werte mit SetValue abzuspeichern könnte ich natürlich auch AC_AddLoggedValues (integer $InstanzID, integer $VariableID, array $Datensaetze)
nehmen.
Wenn ich dann den Zeit Stempel mit dem Wert nutze dürfte das Problem elegant gelöst sein.
Was haltet Ihr von dem Vorschlag ?
Stimmt da habe mal wieder zu kurz gedacht 
Ich hatte den Tempest support in Bezug auf die Sendung alter bzw. doppelter Nachrichten angesprochen.
Hier ist die Antwort :
Hi Artur,
Our IT team said what you’re noticing is data backfilling. The Hub retransmits any observation that wasn’t flagged as received. Sometimes our system did get it but for some reason the Hub didn’t get the notification and a few minutes later it tires to retransmit it. We get quite a lot of duplicate transmissions and we just deal with it - better to get duplicates than to miss a bunch of observations!
Das heißt es sind zwei Probleme zu lösen :
1.) Die Nachricht kommt mit einem alten Zeitstempel wurde aber noch nicht empfangen und muss in die Zeitreihe eingefügt werden
2.) Die Nachricht wurde bereits früher empfangen und sollte verworfen werden
Das Problem bei beiden ist der Zeitstempel. Die Einträge in IPS nutzen die lokale Zeit wogegen der Tempest Zeitstempel mit einer Latenz behaftet ist (bis zu 15 sek.) Für jede Variable müsste ich also den Zeitstempel separat abspeichern um doppelte bzw. verpasste Sendungen herauszufinden.
Alternativ könnte ich jeden Wert nicht über SetValue abspeichern und die Funktion AC_AddLoggedValues mit dem Tempest Zeitstempel nutzen.
Das Problem hier ist das dann immer eine Aggregation durchgeführt werden muss (Das macht keinen Sinn)
Ich neige daher zu der Lösung doppelte Sendungen zu akzeptieren und alte Werte mit korrigiertem Zeitstempel (ich addiere die aktuelle Latenz hinzu ) in die Zeitreihe einzufügen. Falls das zu Ausreißern führt kann man den alten Wert eigentlich nur wegwerfen
Eure Meinung ?
da ich - zumindest bei mir - noch nicht festgestellt habe, dass was verloren ging, würde ich sagen, die wiederholten Sendungen zu verwerfen. Auch macht es keinen Sinn, wegen maximal ~10 sek. hier einen größeren Aufwand zu betreiben, die Daten separat ins Archiv einzutragen. Da es eh Minutenwerte sind, sehe ich das nicht als so kritisch. Bei vielen anderen Sensoren gibt es auch keinen Zeitstempel. Und die senden meist auch nur alle 3 bis 5 Minuten. - meine Meinnung -
Mir ist aber aufgefallen, dass seit heute Nacht 3:23 Uhr die Fehler aufgehört haben, als das Sendeintervall für rapid_Wind auf 60 sek. geändert wurde:
warum sollten ab da die Sendungen besser empfangen wurden sein? 
allerdings gibt es bei dieser Umschaltung ein weiteres Problem, dass bei jeder Umstellung auf 60 sek. Intervall bisher auftrat.
Bei der nächsten Sendung nach der Umstellung werden die Temperatur, Feuchtigkeit und wohl auch andere Werte mit „0“ übertragen.
Das bringt natürlich nachfolgende Berechnungen und auch die Grafik durcheinander.
habe das in meiner internen Übertragung noch gefiltert, wenn Temperatur und Feuchtigkeit = 0 sind. Das kam bei mir nun schon dreimal vor, da die aktuelle Wetterlage nicht genug Sonne hergibt
Das sieht aber nach einem Bug aus, den man mit dem Support mal klären sollte.
Gruß
Rainer
Werte mit Null wegzufiltern macht nicht viel Sinn denke ich (Temperatur kann 0 sein)
Ich könnte Werte die außerhalb von 3 X Standartabweichung vom Mittelwert liegen wegwerfen ?
Das mit den Ausreißern müssen wir nicht so genau nehmen. Am Besten verwerfen. Für meine Anwendung kommen kommen sowieso zu viele Daten.
Wobei ich Ausreißer gegen Null nur selten hatte. 2x Luftdruck, 1x Temperatur. Jedes mal hatte ich dann auch unter sensor_status pressure failed oder temperature failed
PS: Für das Script: obs_st/Wind Avg hat noch ein ° als Prefix.
:o
Ok. Bin um eine Zeile verrutscht. Ist Wind Direktion mit °. Grundsätzlich nicht falsch aber SO° sieht komisch aus.
Da wir gerade bei Wind sind.
Was ist eigentlich der unterschied bei den Werten unter rapid_wind / Wind Direction und obs_st / Wind Direktion?
Auch rapid_wind / Windspeed und obs_st / Wind Avg (average over report interval) stehen die gleichen Werte, nur etwas zeitversetzt.
Ich glaube das mit dem Wind hat sich erledigt. Gestern bei wenig Wind waren die Werte immer gleich. Heute ist es etwas windiger und die Werte sind doch unterschiedlich.
deshalb verwerfe ich auch nur Datensätze bei denen Temperatur und Luftfeuchtigkeit = 0 sind.
Luftfeuchtigkeit = 0 sollte hierzulande auch nur ganz selten auftreten 
Ich habe mittlerweile eine neue Routine zum ausfiltern von Doppeleinträgen sowie zum Einfügen von alten Daten geschrieben. Im Moment teste ich das ganze noch.
Mir ist klargeworden das der Vergleich des Zeitstempels von der Wetterstation mit der aktuellen Systemzeit nichts bringt. Der Zeitunterschied zwischen den beiden Daten beschreibt nur die Latenz.
Eigentlich müsste ich zum abspeichern für jedes Datum explizit den Zeitstempel der Wetterstation und nicht die lokale Systemzeit nehmen (Default Symcon). Die Auslastung des System wäre dann allerdings zu groß da ich dann die variablen ständig alle neu aggregieren müsste.
Der Zeitstempel der Wetterstation ist so etwas ähnliches wie eine Unique ID. Kommt dieser Zeitstempel doppelt vor dann müssen alle Nachrichten des betreffenden Typs verworfen werden.
Ist der Zeitstempel der Wetterstation kleiner als der letzte Eintrag in der Variable des Wetterstation Zeitstempels und kommt dieser Stempel nicht doppelt vor, dann handelt es sich um eine alte Nachricht und alle Daten des Typs müssen in die Zeitreihen der jeweiligen Variablen eingefügt und dann neu aggregiert werden.
Irgendwelche Kommentare ?
Ich lese gespannt mit.
Selbst nutze ich Tempest nur zum Ablesen der täglichen Daten ohne Analyseambitionen.
Gesendet von iPad mit Tapatalk
Konntest du mit der neuen Routine feststellen, dass da alte Daten kamen, die noch nicht enthalten sind? Wie hoch ist denn deren Anteil?
Tempest liefert die Daten jede Minute. Das ist im Vergleich zu meinen bisherigen Wetterdaten (alle 3-5 Minuten) schon ordentlich.
Auch ist die Wiederholung alter Daten nicht durchgängig. Es gibt Stunden, da wiederholt sich gar nichts und dann kommen ständig Wiederholungen - auch schon mehrere Minuten alte, die soweit ich erkennen kann, alle schon empfangen wurden.
ich finde Aufwand und Systembelastung, um die alten Daten zu verarbeiten, steht in keinen Verhältnis zum eigentlichen Nutzen.
Mir ist auch nicht klar, wie Tempest bestimmt, dass da Daten nicht empfangen wurden? Der Hub sendet die doch einfach so ins Netz. Wenn da keine APP oder ein anderes Programm aktiv ist, müssten sich die Daten ständig wiederholen.
Übrigens werden Daten mit gleichem Zeitstempel auch mehrfach wiederholt, obwohl sie schon in Symcon geloggt wurden.
Willst du das noch bei rapid_wind alle drei Sekunden testen? Der Hub_status kommt auch alle 10s!
Für mich ist es völlig ausreichend, wenn Doppelsendungen (die wo Zeitstempeldifferenz > maximale Zeitabweichung ist) und die, bei denen alle Werte = 0 (die kommen bei der Umschaltung des Intervalls auf 60s) sind ausgefiltert werden.
Und wenn mal ein Minutenwert nicht vorhanden ist, kann/muss ich wohl damit leben ;). Wenn ich Symcon oder den Rechner neu starte, wird mir Tempest auch nicht die „verlorenen“ Daten nachliefern, oder?
Mache dir bitte nicht mehr Arbeit, als hier wirklich notwendig ist. Du hast das bisher schon wirklich gut umgesetzt. Danke
Gruß
Rainer
Tja ich habe das Skript getestet und manuell Daten mit alten Zeitstempeln erzeugt und das Einfügen hat funktioniert
In den letzten 12 Stunden habe ich im Echt Betrieb keine alten Daten erhalten !
Doppelte Daten hatte ich schon ein paar und die wurden dann auch nicht gespeichert. Um den Aufwand niedrig zu halten wird nur der Datentyp obs_st auf doppelte und alte Zeitstempel überwacht
Ich vermute das die Kommunikation zwischen der Wetterstation und dem Hub einen Handshake hat.
Stimmt UDP ist ohne Handshake
Für mich ist das weniger Arbeit als eine Denksport Aufgabe 
Der Weg ist das Ziel sozusagen.
Ich habe übrigens Deinen Vorschlag (T=0 + H=0) => Daten wegwerfen umgesetzt
Ich lass das ganze noch etwas laufen und sobald ich sehe das ein alter Datensatz im Echtbetrieb eingefügt wurde stelle ich das Skript ins Netz
Das Skript lief jetzt 24 Stunden und scheint seine Aufgabe zu erledigen :
Wie zuvor beschrieben messe ich nunmehr ob der aktuelle Tempest Zeitstempel älter ist als der zuletzt gespeicherte. In der Regel sind seit dem zuletzt gespeicherten Tempest Zeitstempel (bei meinem derzeitigen Akkustand) 60 sekunden vergangen.
Der Chart zeit das heute stand 16:00 vier mal Zeitstempel von der Wetterstation geschickt wurden von denen zwei in der Vergangenheit lagen und weitere zwei quasi zweimal zeitgleich empfangen wurden.
Das Log zeigt das in allen Fällen der Zeitstempel bereits zu einem früheren Zeitpunkt bereits gespeichert wurde. Alle Messdaten wurden daher verworfen
Das letzte Diagramm zeigt in Rot die Zeit zwischen dem letzten und aktuellen Tempest Zeitstempel und in Blau die Differenz zwischen der IPS Systemzeit und dem aktuellen Zeitstempel der Wetterstation
Das einfügen alter Zeitstempel habe ich noch nicht beobachten können, der manuelle Test verlief allerdings erfolgreich.
Ich werde das aktualisierte Skript demnächst posten
26.12.2020
Vers. 1.6.2
Das Skript verfügt jetzt über die Fähigkeit doppelte Nachrichten zu erkennen sowie alte Nachrichten in die Zeitlinie einzufügen
Jeder Message Typ hat eine Nachricht mit einem Zeitstempel (Nicht zu verwechseln mit dem Zeitstempel im Archiv der die Zeit der speicherung festhält)
Alle Zeitstempel von Tempest werden in einer Variablen gespeichert (‚Time Epoch‘,‚timestamp‘,‚Rain Start Event‘)
Beim Empfang einer neuen Nachricht schaut das Skript nach ob der übermittelte Zeitstempel bereits vorhanden ist. Falls das der Fall ist werden
die Nachrichten des betreffenden Typs alle verworfen.
Das Skript anylysiert auch ob der Zeitstempel des Typs älter ist als der zuletzt abgespeicherte Zeitstempel des Message Typs. Ist das der Fall werden alle Nachrichten des Typs in die Zeitlinien der variablen integriert und anschließend werden die Variablen reaggregiert.
Diese Funktion wird „check_time_stamp_for_message_type“ genannt und nur für den Nachrichten Typ „obs_st“ angewandt.
Bei den Variablen im array „$NO_Check_Variable_Names“ werden keine alten Werte eingefügt
Das Skript wird auch beendet ohne die Daten abzuspeichern für den Fall das die Temparatur und die Luftfeuchtigkeit 0 sind.
Das Skript ist hier zu finden : https://www.symcon.de/forum/threads/42554-Tempest?p=442072#post442072
