Das Wetterstationen Forum

Hi!

Ich fange mal ganz unten an, weil ich mich darueber (inhaltlich wie auch meldungstechnisch) freue:

Beta 0.8 funktioniert soweit ohne Probleme. WsWin Datei Erstellung klappt und wird auch fleißig eingelesen.

Das ist eine neue Funktion von FOSHKplugin und ich freue mich immer sehr, wenn explizit eine Mitteilung erfolgt, das eine neue Funktion wie erwartet/gewuenscht funktioniert. Danke!
Ich teste den Kram hier natuerlich vorab auch. Aber es ist ja bekannt, dass die Technik beim Nutzer dann manchmal anders funktioniert oder genutzt wird.

Die Sache mit den Rechten verfolgt mich seit Beginn der FOSHKplugin-Entwicklung. Wenn man mal etwas als root installiert ist es spaeter nicht ohne Rechte-Aenderung moeglich, komplett darauf zuzugreifen. Daher moeglichst immer mit sudo arbeiten oder eben grundsaetzlich als root.

Wieso fragt es danach? Sollte er doch normalerweise von alleine wissen/machen?

Das ist ein feature!
Die Idee dahinter ist, das manch einer mehrere Instanzen von FOSHKplugin parallel betreiben will. Das sind dann natuerlich auch unterschiedliche Dienste.

Warum bei Dir die Config-Datei zerstoert wurde, erschliesst sich mir nicht. Ich habe hier hunderte Male irgendwelche Updates eingespielt, ohne das auch nur einmal die Config nicht uebernommen wurde.

Dann hoffen wir mal, das beim naechsten Update die su-Probleme (und die Config-Zerstoerung) Geschichte sind.

Danke fuers Testen!

Oliver

Danke für deine Rückmeldung.
Ja, das mit den Rechten war komisch. Ich habe Floshk nun ganz normal mit den PI Account per Sudo installiert und dann nochmal (damit ich per WinSCP einfacher damit arbeiten kann) per chmod den Foshk Order auf 777 gesetzt.

Noch eine Frage:
Du hast in einen Beta Log geschrieben, dass nun die Wettersektor API supportet wird.
Es fehlt noch ein Beispiel, wie man sich das nun zunutze machen kann. Ich will das gern einsetzen.

Das Wetter.com Plugin habe ich nun auch in Betrieb genommen.
Weather365 wird zZ noch von WsWin übernommen. Stelle ich um wenn das mit Wettersektor klar ist.

Awekas, Windy & PWSDashboard funktionieren wie bisher einwandfrei.

Die InfluxDB Übertragung läuft nun auch und die Daten kommen an
Jetzt fehlt mir noch noch eine Grafana Vorlage. Du hast da eins zusammengebastelt, aber es scheint statisch zu sein, eine Übernahme ist so direkt nicht möglich. Theoretisch könntest du deine Vorlage auf der Grafana Webseite zur Verfügung stellen oder die passende ID teilen.
Ich würds zwar auch selber versuchen, aber ich bin da noch zu Noobig

Hi!

Du hast in einen Beta Log geschrieben, dass nun die Wettersektor API supportet wird.
Es fehlt noch ein Beispiel, wie man sich das nun zunutze machen kann. Ich will das gern einsetzen.

Wer ohnehin WSWin einsetz, sollte besser WSWin zum Upload zu Wettersektor nutzen. FOSHKplugin kann etliche Felder, die Wettersektor erfordert, leider nicht liefern. Ich sehe auch keine Dringlichkeit, dies zu aendern: es waere ziemlich aufwendig und eigentlich auch voellig sinnfrei, weil die Daten besser bei Wettersektor errechnet/bereitgestellt werden sollten. Ausserdem scheint der Dienst aktuell nicht wirklich supported zu sein - ich habe jedenfalls keine Reaktion auf meine Anfragen erhalten.

Ich habe aber ein Beispiel fuer den Versand ueber FOSHKplugin auf der generic-Seite eingefuegt.
So sieht es bei mir aus:

Jetzt fehlt mir noch noch eine Grafana Vorlage. Du hast da eins zusammengebastelt, aber es scheint statisch zu sein, eine Übernahme ist so direkt nicht möglich. Theoretisch könntest du deine Vorlage auf der Grafana Webseite zur Verfügung stellen oder die passende ID teilen.

Ja, die Demo-Seite ist tatsaechlich statisch.
Ich kann mal schauen, ob ich meine Vorlage extrahieren kann. Da bei Dir die Datenbank aber vermutlich anders heisst als bei mir, koennte es da durchaus knifflig werden.

Nachtrag: JSON anbei.
Gib mal bitte Bescheid, ob Du das Dashboard so importieren kannst. Ah, JSON geht nicht - ich habs jetzt in ein ZIP gepackt.

Oliver

Wunderbar.

Also das Wettersektor Teil funktioniert mit deiner Version.
Weather365 ist jetzt auch in Betrieb. Ich beobachte das morgen mal wie es läuft.

Danke auch für die Json.
Dort hast du "directInfluxDB" als Source, bei mir war es "InfluxDB". Das musste ich nur anpassen, danach läuft das ganze.

Du hast da auch son Clock Panel drin. Das musste ich bei mir nachinstallieren. Für die, die es auch benötigen: und danach den Grafana Dienst neustarten Edit:
Was direkt bei 365 auffällt:
Von WSWIN wurde noch "Humidex" und "Kondensationsniveau" mit übertragen.
Das fehlt anscheint mit den Pluging.
Die Berechnung von "Empfunden Temperatur" scheint auch eine andere zu sein.

Morgen mal schauen wie es sich bei Tageslicht verhält.

Moin!

Schoen, das der Austausch der Grafana-Oberflaeche so einfach funktioniert. Vielleicht findet sich hier in der Community dann ja noch Verbesserungspotential. Ich nutze Grafana jetzt seit vielleicht 2-3 Wochen und stecke da auch noch nicht so drin.

Von WSWIN wurde noch "Humidex" und "Kondensationsniveau" mit übertragen.
Das fehlt anscheint mit den Pluging.

Das ist korrekt. Humidex und ET werden von FOSHKplugin nicht gemeldet.
Bei beiden fehlt mir die Berechnungsgrundlage - bei Humidex konnte ich noch nicht in Erfahrung bringen, nach welcher Formel das berechnet werden will - ich habe da mehrere Moeglichkeiten gefunden.
ET ist noch deutlich komplizierter - da habe ich mich einfach noch nicht herangetraut. Der Vorteil von WSWin ist dabei ganz klar, dass es fuer irgendwelche Berechnungen auf alle Daten zurueckgreifen kann.
FOSHKplugin ist eigentlich eher als Echtzeit-Konvertierung konzipiert - fuer Berechnungen mit aelteren als den aktuellen Daten muss ich mir die irgendwie (und irgendwo) merken. Das ist recht aufwendig.

Aber auch andere Werte sind gewissen Einschraenkungen unterworfen, die vorallem darin begruendet sind, dass die Grundlage fuer Weather365 eben eine Davis-Station ist und kein Ecowitt-System. Ecowitt kennt einige Werte nicht oder liefert diese anders aus.
Als Beispiel:
Die Bodenfeuchte ist bei Weather365 nach Bodentiefen eingeteilt. Bei Ecowitt sind das einfach verschiedene Bodenfeuchte-Sensoren - es gibt schlicht keine Sensoren fuer die verschiedenen Tiefen.
Hinzu kommt hier, dass Weather365 einen cb-Wert erwartet, fuer den es keine sinnvolle Umrechnung vom prozentualen Bodenfeuchte-Wert bei Ecowitt gibt.
Bei der Bodentemperatur sieht das aehnlich aus (wobei da immerhin die gleiche Einheit genutzt wird).

Die Berechnung von "Empfunden Temperatur" scheint auch eine andere zu sein.

Bei der gefuehlten Temperatur gibt es zwei Problemmoeglichkeiten:
1. Es gibt verschiedene Berechnungsverfahren fuer die gefuehlte Temperatur. Fuer das in Weather365 erwartete appTemp nutze ich bei FOSHKplugin die amerikanische Feelslike-Berechnung. Das muss so aber nicht richtig sein.
2. Es koennte sich aber auch um einen Berechnungsfehler des an sich korrekten Fellslike-Ansatzes handeln.
Da muss ich mal die Werte von WSWin und FOSHKplugin vergleichen.

Gruss, Oliver

Moin!

Schoen, das der Austausch der Grafana-Oberflaeche so einfach funktioniert. Vielleicht findet sich hier in der Community dann ja noch Verbesserungspotential. Ich nutze Grafana jetzt seit vielleicht 2-3 Wochen und stecke da auch noch nicht so drin.

Von WSWIN wurde noch "Humidex" und "Kondensationsniveau" mit übertragen.
Das fehlt anscheint mit den Pluging.

Das ist korrekt. Humidex und ET werden von FOSHKplugin nicht gemeldet.
Bei beiden fehlt mir die Berechnungsgrundlage - bei Humidex konnte ich noch nicht in Erfahrung bringen, nach welcher Formel das berechnet werden will - ich habe da mehrere Moeglichkeiten gefunden.
ET ist noch deutlich komplizierter - da habe ich mich einfach noch nicht herangetraut. Der Vorteil von WSWin ist dabei ganz klar, dass es fuer irgendwelche Berechnungen auf alle Daten zurueckgreifen kann. FOSHKplugin ist eigentlich eher als Echtzeit-Konvertierung konzipiert - fuer Berechnungen mit aelteren als den aktuellen Daten muss ich mir die irgendwie (und irgendwo) merken. Das ist recht aufwendig.

Aber auch andere Werte sind gewissen Einschraenkungen unterworfen, die vorallem darin begruendet sind, dass die Grundlage fuer Weather365 eben eine Davis-Station ist und kein Ecowitt-System. Ecowitt kennt einige Werte nicht oder liefert diese anders aus.
Als Beispiel:
Die Bodenfeuchte ist bei Weather365 nach Bodentiefen eingeteilt. Bei Ecowitt sind das einfach verschiedene Bodenfeuchte-Sensoren - es gibt schlicht keine Sensoren fuer die verschiedenen Tiefen.
Hinzu kommt hier, dass Weather365 einen cb-Wert erwartet, fuer den es keine sinnvolle Umrechnung vom prozentualen Bodenfeuchte-Wert bei Ecowitt gibt.
Bei der Bodentemperatur sieht das aehnlich aus (wobei da immerhin die gleiche Einheit genutzt wird).

Die Berechnung von "Empfunden Temperatur" scheint auch eine andere zu sein.

Bei der gefuehlten Temperatur gibt es zwei Problemmoeglichkeiten:
1. Es gibt verschiedene Berechnungsverfahren fuer die gefuehlte Temperatur. Fuer das in Weather365 erwartete appTemp nutze ich bei FOSHKplugin die amerikanische Feelslike-Berechnung. Das muss so aber nicht richtig sein.
2. Es koennte sich aber auch um einen Berechnungsfehler des an sich korrekten Feelslike-Ansatzes handeln.
Da muss ich mal die Werte von WSWin und FOSHKplugin vergleichen.

Und, um das nochmal ganz klar zu sagen:
Der Anspruch von FOSHKplugin ist nicht, WSWin oder weewx zu ersetzen oder deren Leistungsumfang nachzubilden.
Das kann (und will) ich nicht.
Es ist eher ein Angebot an die Nutzer, die mit den anderen Programmen nicht arbeiten wollen/koennen oder die FOSHKplugin wegen "Nischenfunktionen" (etwa dem UDP-Versand an Loxone oder als Ecowitt-Relay oder als Zulieferer fuer Ambient Weather) ohnehin nutzen.
Ansonsten sehe ich (persoenlich) FOSHKplugin eher als (An)Treiber fuer die anderen, deren Programme zu verbessern.
Das hat ja zumindest bei WSWin und der Unterstuetzung von Weather365 ganz gut geklappt ..


Gruss, Oliver

Weiteres Feedback:

Bei WSWIN ist mir aufgefallen, dass du auf deiner Seite folgendes Config Beispiel gebracht hast: Daraus ergab sich ein Problem und zwar, wenn man eingestellt hat, dass der WS_INTERVAL auf unter 60sec steht.
Dadurch entstehen doppelte Zeileneinträge in der wswin.csv. Da aber WSWIN nur minütlich abrechnet, wird es womöglich eine der doppelten Einträge verwerfen.

Durch das Regenwetter merkt man bei länger anhaltenden Schauern das die übermittelten Regenmengen irgendwann zu den tatsächlichen Werten auf Ecowitt & Grafana abweicht.

Ich habe nun zu den oberen Teil hinzugefügt und ich hoffe, dass es damit wieder passt.

Zu den Post mit den "Anspruch":
Ich stimme dir Grundsätzlich zu, dennoch bin ich ein Fan von wenn man sich am "Prismus" Programmen wie WSWIN so gut wie möglich annähert, einfach um vor allem mehr Plattform Unabhängigkeit zu ermöglichen. Zwar haben beide OS Welten ihre eigenen Alternativen, allerdings ist (für mich) Foshkplugin auch dank der Ecowitt Station eine Einstiegsfreundliche Alternative geworden, ohne das man sich mit komplex gestaltete Anleitungen herumschlagen muss. Da biste auf jeden Fall einigen voraus, denke ich.

Hi!

Danke fuer den Hinweis zum Intervall. Ich habe das jetzt mal nachgetragen.

allerdings ist (für mich) Foshkplugin auch dank der Ecowitt Station eine Einstiegsfreundliche Alternative geworden, ohne das man sich mit komplex gestaltete Anleitungen herumschlagen muss.

Das liegt aber primaer daran, dass FOSHKplugin tatsaechlich auch weniger komplex ist. Aber auch ich merke am FOSHKplugin, wie es mit zunehmender Anzahl von Features mehr nach besserer Dokumentation schreit und inhaltlich komplexer wird - ein grundsaetzliches Problem "gewachsener" Software.

Wenn ich fuer Humidex eine passende Formel finde und dafuer und fuer ET keine grosse Datenhaltung extra implementieren muss, werde ich das sicher noch hinzufuegen.

Gruss, Oliver

Hi,
ich will mal eine Zwischenmeldung geben. Das FOSHKplugin läuft nun schon einige Tage und liefert die Daten zuverlässig für den Import in WSWIN. Ich rufe am PC die Daten vom Raspberry per wget ab und WSWIN holt sie per Dateiüberwachung ab. Alles ganz prima. Ich habe jetzt auch noch auf einem Tablet und einem Smartphone die App Personal Weather Tablet laufen und im Plugin die entsprechenden Forwards eingerichtet - und siehe da - auch das funktioniert.
Jetzt aber auch noch eine Frage: Wenn ich mit dem Smartphone außerhalb meines WLANs bin bekomme ich ja eine andere IP zugewiesen und dann kann ja das entsprechende Forward nicht mehr senden. Gäbe es auch ein Forward, um über eine VPN-Verbindung die Wetterdaten abzuholen bzw. zu empfangen?

Viele Grüße und nochmals vielen Dank an Oliver für die tolle Arbeit und auch den Support

Hartmut

Hi!

Wenn ich mit dem Smartphone außerhalb meines WLANs bin bekomme ich ja eine andere IP zugewiesen und dann kann ja das entsprechende Forward nicht mehr senden. Gäbe es auch ein Forward, um über eine VPN-Verbindung die Wetterdaten abzuholen bzw. zu empfangen?

Wenn die IP-Adresse des VPN-Clients bekannt ist, kannst Du natuerlich auch einen zusaetzlichen Forward zu dieser IP anlegen.
Das Problem ist einfach, das PWT darauf angelegt ist, Daten zu empfangen. Dazu muss die Empfaengeradresse am Sendeursprung natuerlich bekannt sein.
Der Autor von PWT wollte aber zukuenftig zusaetzlich die GW1000-API integrieren. Damit koennte PWT dann die Daten eines GW1000/DP1500 abrufen - unabhaengig von der eigenen IP-Adresse. Fuer eine HP2551C hilft das natuerlich nicht.

Gruss, Oliver