Nachsenden von "verspäteten" Datensätzen

Für Geräte von froggit
Antworten
Benutzeravatar
olicat
Offline
Beiträge: 2003
Registriert: 07 Dez 2020, 20:33
Wohnort: Hohen Neuendorf
Hat sich bedankt: 26 mal
Danksagung erhalten: 411 mal
Kontaktdaten:

Nachsenden von "verspäteten" Datensätzen

#1

Beitrag von olicat »

Hi!

Beim Versand der Wetterdaten von der Station selbst oder über externe Software gibt ja immer wieder mal Probleme mit der Internetleitung, dem WLAN, dem Zielsystem (etwa Serverwartung oder -fehler oder Rechnerneustart oder Programmfehler).
Das ergibt dann immer unschöne Lücken in den aufgezeichneten Daten im Zielsystem.

Wie handhabt ihr das?
Ist das ein akutes Problem, das angegangen werden sollte? Oder passiert das so selten, dass dies nicht wirklich relevant ist?

Nach Rücksprache mit verschiedenen Entwicklern gab es dafür bisher wohl keinen echten Bedarf.
Aber auch wenn ich das hier nicht wissenschaftlich betreibe - mich ärgern diese Lücken!

Zu Testzwecken habe ich hier einen InfluxDB v2-Server auf dem Notebook (unter Windows) zu laufen.
Obwohl - logischerweise - das Notebook sehr häufig nicht vor Ort ist oder nachts ausgeschaltet in der Tasche schlummert, habe ich doch - nach Verbindung mit dem lokalen Netzwerk - eine lückenlose Datensammlung.
Denn ist das Notebook mit dem InfluxDB-Server nicht erreichbar, speichert FOSHKplugin die Daten lokal zwischen.
Wann immer das Gerät im lokalen Netzwerk - und somit der InfluxDB-Server erreichbar ist, sendet FOSHKplugin die aufgelaufenen Daten zum Datenbank-Server und vervollständigt die Datenbank.
Ein Traum wird wahr!
Ich habe hier wirklich eine lückenlose Datenbank über den letzten Monat (seit Erstimplementierung im FOSHKplugin). Und das obwohl das Notebook nur alle paar Tage mal im heimischen Netz angemeldet ist.

Leider funktioniert das bisher nur mit InfluxDB-Servern (v1 und v2).
Ich kenne keinen Dienst, der den Zeitpunkt der Messwerterfassung aus dem Datensatz selbst nutzt. Stattdessen wird immer die Eingangszeit am Server (oder Empfangsprogramm) übernommen.

Awekas bietet den etwas unhandlichen Weg über ein manuell zu generierendes (und hochzuladendes) Import-XLS an - zumindest für die Hauptdaten wie Luftdruck, AT, AF, Regen, Wind, UVI, ....
Immerhin.
Denn die anderen Dienste und Programme (etwa CumulusMX) bieten meist nichtmal eine manuelle Import-Schnittstelle - man hat da oft überhaupt keine Möglichkeit einer wie-auch-immer Nachmeldung. Wobei CMX die Daten in einer ggf. geringeren Auflösung per API automatisch vom Ecowitt-Server ziehen kann (was eine sehr schöne Funktion ist!).

Bei den "üblichen" Diensten wie WU, Weathercloud, WOW, Ecowitt.net oder PWSWeather suche ich noch nach Möglichkeiten. Das Testen und Erfragen ist aber sehr mühsam.
Daher:
Stören Euch diese Lücken in der Datenaufzeichnung?
Nutzt ihr etwaig vorhandene Import-Möglichkeiten (etwa das Import-XLS bei Awekas)?
Kennt ihr Dienste, die den nachträglichen Versand ermöglichen?
Bei welchem Dienst würdet ihr Euch das denn am meisten wünschen? Vielleicht lässt sich da ja etwas bei den Herstellern/Anbietern bewegen? Mit Ecowitt stehe ich dazu zumindest schonmal in Kontakt.

Ich würde mich über eine Diskussion oder Hinweise und Erfahrungswerte dazu sehr freuen.
Vielen Dank!

Oliver
Benutzeravatar
Gyvate
Offline
Beiträge: 2479
Registriert: 10 Aug 2021, 23:41
Wohnort: Saarbrücken
Hat sich bedankt: 12 mal
Danksagung erhalten: 375 mal
Kontaktdaten:

Re: Nachsenden von "verspäteten" Datensätzen

#2

Beitrag von Gyvate »

also meine Stationsdaten (3 Stationen - WS2320E/WH4000SE, HP2553 und GW2001) werden redundant von mehreren Raspberry Pis (mit jeweils weewx und CumulusMX) und zwei Meteobridges (1 x RPi, 1 x MB Pro) gespeichert, auch parallel mit extra GW1000/WH2650. Damit sind die Konsolen redundant abgesichert - nur die Aussensensoren sind nicht gedoppelt.

Die WH4000SE/WS2320E speichert zusätzlich noch bis zu 3500 Datensätze intern und hat Batteriebetrieb, also hochgradig ausfallsicher. Der "Wetterbereich" läuft über eine eigene USV, die bis zu einer Stunde die Wetterinfrastruktur selbst bei lokalen brown-outs überbrücken kann, die bislang (3 Jahre) aber über drei Minuten nicht hinausgingen. Aber, da läuft eben ein kleines "Rechenzentrum" mit. Einschließlich regelmässiger Datensicherungen !!! 8-) .

Wenngleich das auch, wenn auch nicht immer redundant, selbst in der Ausprägung eine (oder zwei) Wetterstation(en), ein (oder zwei) RaspberryPi4 mit externem Datensicherungsmedium und eine USV ziemlich gut absichern lässt. Es muss also nicht immer das "große Besteck" sein.

Meine Webpräsenzen lassen sich so bei Internet-Ausfällen immer "nachrüsten". Diese sind auch auf meinem NAS gespiegelt, so dass ich bei größeren Ausfällen die Links auf mein NAS umleiten könnte, bis die Websites wieder "à-jour" sind. Die Webpräsenzen auf dem NAS laufen ja in einer DMZ.

Bei den beiden CumulusMX-basierten Websites (CMX classic und CUtils) ist das besonders einfach - da muss nur ggf. die CMX-Sendeinstanz aktualisiert werden, da die Daten per FTP aktualisiert werden. Im Regelfall muss ich dort gar nichts machen, da sich das von selbst ausregelt, sobald die Internetverbindung wieder steht, weil lokal ja nichts verloren ging.

Die ansonsten sehr nützliche Nachladefunktion von CMX für Ecowitt-Stationen bringt ja nichts, wenn während des Internetverbindungsausfalls auch keine Daten an ecowitt.net übertragen wurden. Die ist eher hilfreich, wenn der Server, auf dem CMX läuft, ausfällt oder sich das Programm aufhängt oder verabschiedet (was eher selten vorkommt).

Wenn mal eine Konsole funktional streikt, sind so immer die parallelen Daten da, die sich dann dort nachimportieren lassen, wo sie fehlen - selbst anwendungsübergreifend, also z.B. Meteobridge --> weewx, CMX oder jede beliebige Kombination bis hin zum manuellen Export der Daten aus der WS2320E/WH400SE oder HP2550. Das habe ich mittlerweile alles schon mal durchgespielt und die passenden Skripte dazu. :ugeek:

Übrigens kann man man Daten in CumulusMX natürlich sehr wohl - wenn auch halb-automatisch - nachreichen - und auch die Datenbank entsprechend hinsichtlich Summen und Tageswerte aktualisieren. In weewx und Meteobridge auch, wenngleich es dort einfacher zu automatisieren ist, wenn man die Daten im passenden Importformat vorliegen hat.

Die typischen Internet-PWS-Wetterdienste (WU, WeatherCloud, WOW, PWS etc.) lassen ja (meines Wissen), mit Ausnahme von AWEKAS über einen Umweg, keine Nacherfassung zu. Dort bleiben dann eben Lücken. Unschön aber wohl bislang nicht zu ändern.
Ecowitt WS2320E,HP2553,HP3501,GW2001,GW1100, GW1000,WH2650,WN1910,WN1980, Meteobridge RPi4B-2GB/(16)32GB SLC 3165, Weewx 4.5.1/4.10.2, CumulusMX 3.28.4 b3282, Barani MeteoShield Pro, MetSpecRad02, Personal Weather Tablet(PWT) - http://meshka.eu
zinz
Offline
Beiträge: 20
Registriert: 09 Mai 2022, 21:44
Hat sich bedankt: 2 mal
Danksagung erhalten: 5 mal

Re: Nachsenden von "verspäteten" Datensätzen

#3

Beitrag von zinz »

Klar ist das interessant. Das hatte ich mir auch schon überlegt, dass nachzubasteln. (der nicht modulare Ansatz des FOSHKplugin hatte mich aber davon abgeschreckt)

Die docker container (derzeit CumulusMX und influxdb) bei mir werden z. B. Regelmäßig gebackupt oder automatisch geupdatet. Dies führt zu einer Unterbrechung der Daten.

Volkszähler (vzlogger als datenlogger) z.B. Das ich zum auslesen von Stromzähler Ständen benutze speichert für jede Destination einstellbar die Daten im Arbeitsspeicher zwischen und schickt sie dann bei Erreichbarkeit der Destination weiter.

Grundsätzlich ist es natürlich immer eine fragwürdige Entscheidung die Ankunftszeit der Daten zu verwenden im Vergleich zu den in den Daten vorhandenem Zeitstempel. Zumindest trifft dies auf die selbst betriebenen Dienste zu. Die großen Webseiten haben andere Anforderungen. Wie schaut es z.B. Mit dem überschreiben von Datensätzen aus.

@olicat hast du schon mal bei ecowitt angesprochen ob die SD Kartensätze (z.B. HP2551) zum nachträglichen Versand verwendet werden können? Dann müsste nämlich nur die Konsole ne USV bekommen. Kann man natürlich auch super vermarkten.

@gryvat du betreibtst einen ziemlichen technischen und finanziellen Aufwand um die Lückenlose Aufzeichnung sicherzustellen. Nahezu das gleiche könnte erreicht werden, wenn die Gateways asynchron senden könnten. Dann müsste man nur noch eine Powerbank als USV dazwischen hängen und hätte für ein paar Euro und keinen Aufwand sehr ähnliche Funktionalität wie du.

Aus datentechnischer Sicht kann ich nicht nachvollziehen warum das derzeit so schlecht gelöst ist. Jegliche Möglichkeit Wetterdaten lückenlos aufzuzeichnen wenn Netzwerk und Strom Unterbrechungen haben können ist extrem aufwendig. Im PV Bereich ist es zum Beispiel üblich Daten nur einmal am Tag zu übertragen. Das wäre sicherlich für sehr viele abgelegene Standorte interessant. Leider haben wir nur gateways und keine Datenlogger. Ich kann mir das nicht so schwierig und teuer zum umsetzen vorstellen. Am einfachsten nen zusätzlichen SD Slot damit die Kosten niedriger bleiben und nen bisschen Software von ecowitt.
Benutzeravatar
olicat
Offline
Beiträge: 2003
Registriert: 07 Dez 2020, 20:33
Wohnort: Hohen Neuendorf
Hat sich bedankt: 26 mal
Danksagung erhalten: 411 mal
Kontaktdaten:

Re: Nachsenden von "verspäteten" Datensätzen

#4

Beitrag von olicat »

Moin,

es ist leider auch bzgl. Ecowitt.net wie befuerchtet - fire and forget:
> Does ecowitt.net accept the reception of "delayed" datasets or does the
> Ecowitt.net server take the server time on reception instead of the time
> contained in the dataset (dateutc)?

No, what missed is missed. Our server data has time stamp and it will store
in our data base with the correct time only.

So no data amendment can be arranged afterwards. Our system is not capable
of handling the history data that was missed.
Also selbst wenn man die Daten hat - etwa auf SD-Karte oder als Queue via FOSHKplugin - es gibt aktuell leider keine Moeglichkeit, diese Daten nachtraeglich hochzuladen.

Technisch ist es ja wirklich nicht sehr aufwaendig, das zu realisieren. Aber natuerlich erfordert dies Ressourcen und birgt Risiken.
Daher werden die Betreiber/Entwickler das eher nicht freiwillig einbauen, sofern es von den Nutzern/Kunden nicht unmissverstaendliche Wunschaeusserungen diesbezueglich gibt.
Im Moment bin ich mir auch nicht ganz sicher, ob ich das forcieren sollte - bisher scheint dies wohl "nur" ein Wunsch eines einzelnen "Nerds" zu sein. Wenn jedoch VIELE Nutzer danach schreien und dabei mit Argumenten kommen, laesst sich da vielleicht auch was bewegen.

Eine kurze Episode dazu:
Ich stellte am 29.10.22 fest, dass die Ecowitt-Konsolen leider nicht alle Zusatzsensoren per WU-Protokoll uebertragen, obwohl das technisch - lt. WU-Standard und vorhandener Sensortechnik - durchaus moeglich waere. Zwar zeigt WU selbst diese zusaetzlichen Daten nicht an. Aber andere - WU-kompatible - Dienste machen das durchaus - etwa Awekas.
Also fragte ich bei Ecowitt an, ob es da zukuenftig vielleicht Verbesserungen geben koennte und unterlegte dies mit entsprechenden Loesungsansaetzen und Beispielen.

Ecowitt wollte da aber nicht ran - WU unterstuetzt das nicht - wir machen, was WU macht.
Ueber etliche Tage hatte ich dazu regen Email-Verkehr - bis Ecowitt irgendwann recht pampig fragte, was ich denn will - es waere doch alles geklaert.
Sie hatten ja Recht! Sie hatten gesagt, das es so bleiben soll, wie es ist.
Ich akzeptierte dies - immerhin koennte Awekas ja auch das Ecowitt-Format nativ unterstuetzen und das Problem mit den Zusatzsensoren waere vom Tisch. Warum sollte Ecowitt kostbare Entwicklungszeit fuer "Sonderlocken" investieren?
Also pflichtete ich bei und schrieb ihnen, dass ich das verstehe und akzeptiere - bei Nutzer-Anfragen bzgl. Awekas-Nutzung jedoch zukuenftig dann eher CCL/Bresser-Anlagen empfehlen wuerde - weil die diese Zusatzsensoren naemlich gemaess WU-Standard uebertragen.

Sehr kurze Zeit spaeter erhielt ich dann die Mitteilung, das man mich nun verstanden haette und die Entwickler sich das anschauen wollen.
2 (zwei!) Tage spaeter gab es dann fuer GW1100 und GW2000 die Firmware v2.2.0 mit Unterstuetzung der erweiterten Sensoren im WU-Protokoll.
Heute gab es das entsprechende Update fuer die WN19xxC ...

Ich will damit sagen: Aenderungen und Verbesserungen sind moeglich, wenn man es Ecowitt irgendwie als "Wunsch der Massen" vermitteln kann.
Wenn also viele Nutzer einen Wunsch an den Hersteller richten, der machbar und sinnvoll ist, wird zumindest Ecowitt bemueht sein, dem auch nachzukommen.
Wer also die Moeglichkeit eines nachtraeglichen Uploads der Daten wuenscht, sollte dies Ecowitt kundtun ...

Oliver
Benutzeravatar
Gyvate
Offline
Beiträge: 2479
Registriert: 10 Aug 2021, 23:41
Wohnort: Saarbrücken
Hat sich bedankt: 12 mal
Danksagung erhalten: 375 mal
Kontaktdaten:

Re: Nachsenden von "verspäteten" Datensätzen

#5

Beitrag von Gyvate »

zinz hat geschrieben: 01 Dez 2022, 08:41 @gryvat du betreibtst einen ziemlichen technischen und finanziellen Aufwand um die Lückenlose Aufzeichnung sicherzustellen. Nahezu das gleiche könnte erreicht werden, wenn die Gateways asynchron senden könnten. Dann müsste man nur noch eine Powerbank als USV dazwischen hängen und hätte für ein paar Euro und keinen Aufwand sehr ähnliche Funktionalität wie du.
Also es ist bei mir kaum extra Finanz-Aufwand. Das meiste sind Synergieeffekte. Ich betreibe diese Infrastruktur, von den Raspis mal abgesehen, ja nicht primär fürs Wetterhobby. Das NAS und die Netzwerkinfrastruktur sind sowieso da und auch professionell abgesichert (USV). Und für die Datensicherung der Raspis halten alte Laptop-HDDs her. Wiederverwendbarkeit ! Genauso eine alte Fritzbox als WLAN Access Point für die Konsolen.

Natürlich sind integrierte Datenlogger wie bei meiner WS2320E/WH4000SE und der HP2551 wünschenswert, dann ist man im Zweifelsfall WLAN unabhängig und kann die Daten auch bei dessen Ausfall rekonstruieren. Aber das scheint nicht im Trend zu liegen, in einer Zeit, wo das Internet bereits als Bestandteil der Wohnung angesehen wird, so wie die Strom- und Wasserversorgung. (Stationäres ["landline"] Telefon geht ja auch nicht mehr ohne Internet).

Dann sind eigene Webpräsenzen, die man auch nachbeliefern kann (dazu gibt es ja viele Vorlagen und Hilfestellungen), schon mal interessanter als die bislang größtenteils immer noch unflexiblen PWS-Wetterdienste, wenngleich die eben den Vorteil der globalen Vernetzung haben ...
Ecowitt WS2320E,HP2553,HP3501,GW2001,GW1100, GW1000,WH2650,WN1910,WN1980, Meteobridge RPi4B-2GB/(16)32GB SLC 3165, Weewx 4.5.1/4.10.2, CumulusMX 3.28.4 b3282, Barani MeteoShield Pro, MetSpecRad02, Personal Weather Tablet(PWT) - http://meshka.eu
zinz
Offline
Beiträge: 20
Registriert: 09 Mai 2022, 21:44
Hat sich bedankt: 2 mal
Danksagung erhalten: 5 mal

Re: Nachsenden von "verspäteten" Datensätzen

#6

Beitrag von zinz »

Nun nachdem ich mich vor nem Jahr mal mit USVs beschäftigt habe und die ähnliche viel Strom verbrauchen wie mein kompletter unraid server (Grüßen Ordnung 20W) steht das für mich alles in keinem Verhältnis wenn es darum geht Ausfall resistent Daten zu loggen.

Zum einen wäre es natürlich zur automatisierung unendlich praktisch wenn die schon bestehenden Datenlogger ihre historischen Daten zur Verfügung stellen würden. (API oder asynchrones Versenden)
Ja ich sehe auch leider den Trend alles nur noch mit aktiver Internet Verbindung zu betreiben. Nun zum telefonieren war schon immer eine aktive Verbindung notwendig um in Echtzeit Kommunizieren zu können. Das ist aber bei wetterdaten völlig anders. Da können wir die Firmen ja daran erinnern.

Ich glaube wir sind uns alle einig, dass es bei den selbstgehosteten Datensenken wesentlich einfacher ist, die Daten nachzupflegen.
Zumindest verstehe ich es so, dass olicat das nachpflegen der Daten zu automatisieren, da das FOSHKplugin bereits alle Informationen besitzt die für das nachpflegen benötigt werden.
Bis jetzt unterstützt halt als einzige Senke Influxdb asynchrone Daten. Bei weewx und CumulusMX sollte es nicht besonders schwierig sein dies umzustellen.
awekas bietet ja bereits die Möglichkeit Datensätze nachträglich zu ändern. Jetzt ginge es darum diesen Prozess zu automatisieren.
Antworten