NEWS
[Linux Shell-Skript] WLAN-Wetterstation
-
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
./wetterstation.sh --data
Ich habe jetzt mal die Wetterstation in Betrieb genommen.
Nochmal zur Info, ich habe die Froggit HP1000SE Pro Single Sensor Edition. D.h. dabei ist:- das Display mit dem Innensensor (Temp, Luftfeuchte, Luftdruck)
- DP300 Anemometer, UV-/Lichtsensor
- DP80 Regensensor
- DP40 Temperatur/Luftfeuchte Sensor für außen
Die Station sendet nun die Daten im Ecowitt Format.
Ich habe dann das Skript runtergeladen und mit ./wetterstation.sh --data ist erst einmal nichts passiert. Habe dann noch --debug angehängt, keine Änderung. Danach habe ich in der config mal IPP auf 127.0.0.1 gesetzt, wo die Simple RESTful API zu erreichen ist. Und dann kam etwas mehr, aber leider nicht genug ;-)
Wenn ich dann ./wetterstation.sh --data --debug ausführe, kommt zwar scheinbar das Paket an, zeigt aber keine Daten:Connection to 127.0.0.1 8087 port [tcp/*] succeeded! Warte maximal 66 Sekunden auf Datenpaket der Wetterstation... Listening on 0.0.0.0 1080 Connection received on 192.168.0.100 26435 POST / HTTP/1.1Es wird nur der Pfad "/" angezeigt
Ich habe jetzt einfach mal nc -lv 1080 ausgeführt und bekomme diesen Content (den PASSKEY habe ich mal abgeändert):PASSKEY=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&stationtype=EasyWeatherV1.5.9&dateutc=2021-10-21+12:03:15&tempinf=71.6&humidityin=60&baromrelin=28.733&baromabsin=28.733&tempf=70.7&humidity=60&winddir=280&winddir_avg10m=299&windspeedmph=11.9&windspdmph_avg10m=8.5&windgustmph=15.9&maxdailygust=22.8&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&dailyrainin=0.000&weeklyrainin=0.000&monthlyrainin=0.000&yearlyrainin=0.000&solarradiation=176.16&uv=1&wh68batt=1.88&wh25batt=0&wh26batt=0&freq=868M&model=HP1000SE-PRO_Pro_V1.7.4Innen- und Außentemperaturensor liegen zur Zeit im gleichen Raum, also nicht wundern, warum die fast das Gleiche anzeigen.
Die Batteriewerte machen nicht so viel Sinn, wobei ich jetzt auch nicht weiß wie die Sensornamen DP zu WH zu übersetzen sind.Reichen die Infos so erst mal aus, um die Sensoren in das Skript einzubauen?
@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Es wird nur der Pfad "/" angezeigt
Das ist "normal" und mir bis dato nicht aufgefallen. Not a feature, that's a bug ;)
--datafunktioniert aktuell nur beim WU-Protokoll --> eben beiläufig gefixt; funktioniert in der nächsten Version dann auch korrekt mit dem Ecowitt-Protokoll
--dataund--debugsind exklusiv, also entweder oder, nicht beide gleichzeitig.
./wetterstation.sh --data(geht aktuell beim Ecowitt nicht) oder./wetterstation.sh --debug(der sollte funktionieren)Eigentlich solltest du Daten bekommen, nur die Batteriestände fehlen.
Allerdings kann ich die Batterien nicht zuordnen. Du müsstest mal nacheinander die Batterien entfernen und dann schauen welcher whxxbatt zu welchem Sensor gehört....und noch einen Fehler gefunden: beim --debug und Ecowitt-Protokoll wird der PASSKEY nicht ausge-x-t (glatt übersehen...)
-
Moin Leute. Etwas OT, aber wo soll ich Fragen, wenn nicht hier? Seit einigen Tagen liefert meine Wetterstation WH3000SE weder die Außentemperatur noch die Außenluftfeuchtigkeit mehr. Alle andere Werte werden weiterhin übermittelt.
Hat jemand ähnliche Ausfälle? Wer kennt den internen Aufbau der Station? Ich gehe davon aus, dass das ein Sensor ist, der die beiden Werte liefern soll und der jetzt tot ist. Kann das einer bestätigen?
Ich habe noch Garantie auf das Gerät und werde morgen den Support kontaktieren. Für Hinweise wäre ich trotzdem dankbar.
PASSKEY=AAAAA&stationtype=GW1000A_V1.6.8&dateutc=2021-10-21+13:46:20&tempinf=69.1&humidityin=62&baromrelin=29.453&baromabsin=29.453&winddir=328&windspeedmph=0.67&windgustmph=1.12&maxdailygust=3.36&solarradiation=88.45&uv=0&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&dailyrainin=0.012&weeklyrainin=0.012&monthlyrainin=0.031&yearlyrainin=16.579&totalrainin=16.579&temp3f=66.56&humidity3=63&wh65batt=1&batt3=1&freq=868M&model=GW1000_ProKein tempf und kein humidity :anguished:
@a200 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
wh65batt=1
Ich mag ja nicht so recht dran glauben, aber "1" ist eigentlich eine leere oder zumindest schwache Batterie.
Da aktuell (wohl) auch wenig Sonne, wird die Solarzelle/GoldCap ev. nicht mehr genügen.
Gerade Temp + Humi brauchen aber Saft, die anderen sind ja mehr oder minder nur Impulsgeber.LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@a200 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
wh65batt=1
Ich mag ja nicht so recht dran glauben, aber "1" ist eigentlich eine leere oder zumindest schwache Batterie.
Da aktuell (wohl) auch wenig Sonne, wird die Solarzelle/GoldCap ev. nicht mehr genügen.
Gerade Temp + Humi brauchen aber Saft, die anderen sind ja mehr oder minder nur Impulsgeber.@sborg Tja, das wollte ich auch nicht glauben, denn früher ist die Übertragung der Daten abgebrochen wenn die Batterien leer waren, aber die Temp. wurde bis zu Ende übermittelt. Aber jetzt! HUT AB! Du hast es wieder mal geschafft. Neue Batterien und plötzlich läuft wieder alles!
Vielen Dank!
IoBroker auf QNAP TS-451, Raspi und NUC
-
@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Es wird nur der Pfad "/" angezeigt
Das ist "normal" und mir bis dato nicht aufgefallen. Not a feature, that's a bug ;)
--datafunktioniert aktuell nur beim WU-Protokoll --> eben beiläufig gefixt; funktioniert in der nächsten Version dann auch korrekt mit dem Ecowitt-Protokoll
--dataund--debugsind exklusiv, also entweder oder, nicht beide gleichzeitig.
./wetterstation.sh --data(geht aktuell beim Ecowitt nicht) oder./wetterstation.sh --debug(der sollte funktionieren)Eigentlich solltest du Daten bekommen, nur die Batteriestände fehlen.
Allerdings kann ich die Batterien nicht zuordnen. Du müsstest mal nacheinander die Batterien entfernen und dann schauen welcher whxxbatt zu welchem Sensor gehört....und noch einen Fehler gefunden: beim --debug und Ecowitt-Protokoll wird der PASSKEY nicht ausge-x-t (glatt übersehen...)
@sborg
Wenn ich auf WU-Protokoll umstelle, dann kommt bei./wetterstation.sh --dataauch was an, ist aber genau das Gleiche wie ein nc -lv.
Im WU-Protokoll sind allerdings auch keine Batteriewerte drin.
Bei den Batteriewerten bin ich mir nicht so sicher, was mir die sagen sollen.
Im Ecowitt-Format waren die 3 Werte enthalten:wh68batt=1.88 wh25batt=0 wh26batt=03 Werte bei 4 Sensoren (Innentemp. mit 2 x 1,5V, Außentemp. mit 2 x 1,5V, Regensensor mit 1 x 1,5V, Windsensor/Lichtsensor mit 1 x 1,5V)
Bei Ecowitt habe ich auf der Webseite gesehen, dass ein WS68 dem DP300 Wind-/Lichtsensor entspricht.
wh68 könnte also dieser sein, aber was soll der Wert 1,88 bedeuten, die Spannung?
Die Batterie ist 1,5V, gestern erst eingelegt. Und dann hat das Teil noch eine Solarzelle als Stromversorgung. Ich habe auch gerade eben nochmal den Wert ausgelesen als es dunkel war, da war er sogar auf 1.90
wh25 und wh26 konnte ich erst mal nirgends finden, was das sein soll. Da es aber 2 aufeinander folgende Nummern sind, hätte ich auf die Innen- und Außentemp.-Sensoren getippt.
Da werde ich wohl mal die Batterien nacheinander heraus nehmen müssen.
Dann wäre aber auch da die Frage, was der Wert 0 bedeudet. Ist das nur ein boolean mit 0 für Batterie Ok und 1 für Batterie schwach?
Und dann fehlt ein Sensor komplett.Wenn ich es richtig verstanden habe, kann ich das Skript verwenden und müsste bis auf die Batteriestände alle Daten bekommen, auch wenn in der conf die Sensortypen nicht existieren, richtig?
UPDATE
Nach etwas googlen bin ich auf das gestoßen: https://github.com/merbanan/rtl_433/blob/master/src/devices/fineoffset.c
Fine Offset Electronics WH25 / WH32B Temperature/Humidity/Pressure sensor protocol.
wh25 ist also der Innen-Temp-Luftfeuchte-Luftdruck Sensor, der auch keine DP-Bezeichnung hat
Und dann habe ich noch folgende interessante Seite gefunden:
https://www.wxforum.net/index.php?topic=40730.0
the predecessor model of the WH32 is the WH26 which is no longer built.
Und WH32 ist wiederum der DP40, also der Temp-Luftfeuchte Sensor für außen.
Wenn man sich bei dem Forum anmeldet, kann man auch noch ein Bild sehen, wo diese ganzen Infos zusammengefasst sind.
Ich hänge es mal hier an.
Damit ist dann auch klar, dass der Regensensor DP80 bei der Batteriemeldung fehlt, warum auch immer.
-
@sborg
Wenn ich auf WU-Protokoll umstelle, dann kommt bei./wetterstation.sh --dataauch was an, ist aber genau das Gleiche wie ein nc -lv.
Im WU-Protokoll sind allerdings auch keine Batteriewerte drin.
Bei den Batteriewerten bin ich mir nicht so sicher, was mir die sagen sollen.
Im Ecowitt-Format waren die 3 Werte enthalten:wh68batt=1.88 wh25batt=0 wh26batt=03 Werte bei 4 Sensoren (Innentemp. mit 2 x 1,5V, Außentemp. mit 2 x 1,5V, Regensensor mit 1 x 1,5V, Windsensor/Lichtsensor mit 1 x 1,5V)
Bei Ecowitt habe ich auf der Webseite gesehen, dass ein WS68 dem DP300 Wind-/Lichtsensor entspricht.
wh68 könnte also dieser sein, aber was soll der Wert 1,88 bedeuten, die Spannung?
Die Batterie ist 1,5V, gestern erst eingelegt. Und dann hat das Teil noch eine Solarzelle als Stromversorgung. Ich habe auch gerade eben nochmal den Wert ausgelesen als es dunkel war, da war er sogar auf 1.90
wh25 und wh26 konnte ich erst mal nirgends finden, was das sein soll. Da es aber 2 aufeinander folgende Nummern sind, hätte ich auf die Innen- und Außentemp.-Sensoren getippt.
Da werde ich wohl mal die Batterien nacheinander heraus nehmen müssen.
Dann wäre aber auch da die Frage, was der Wert 0 bedeudet. Ist das nur ein boolean mit 0 für Batterie Ok und 1 für Batterie schwach?
Und dann fehlt ein Sensor komplett.Wenn ich es richtig verstanden habe, kann ich das Skript verwenden und müsste bis auf die Batteriestände alle Daten bekommen, auch wenn in der conf die Sensortypen nicht existieren, richtig?
UPDATE
Nach etwas googlen bin ich auf das gestoßen: https://github.com/merbanan/rtl_433/blob/master/src/devices/fineoffset.c
Fine Offset Electronics WH25 / WH32B Temperature/Humidity/Pressure sensor protocol.
wh25 ist also der Innen-Temp-Luftfeuchte-Luftdruck Sensor, der auch keine DP-Bezeichnung hat
Und dann habe ich noch folgende interessante Seite gefunden:
https://www.wxforum.net/index.php?topic=40730.0
the predecessor model of the WH32 is the WH26 which is no longer built.
Und WH32 ist wiederum der DP40, also der Temp-Luftfeuchte Sensor für außen.
Wenn man sich bei dem Forum anmeldet, kann man auch noch ein Bild sehen, wo diese ganzen Infos zusammengefasst sind.
Ich hänge es mal hier an.
Damit ist dann auch klar, dass der Regensensor DP80 bei der Batteriemeldung fehlt, warum auch immer.
Ich habe jetzt mal das Skript soweit in Betrieb genommen, dass ich den ersten Aufruf mit
./wetterstation.sh --debugwie in Teil 2 der Anleitung beschrieben, ausgeführt habe.Das sieht soweit ganz gut aus, ich bekomme Werte und die werden auch in den iobroker geschrieben:
Temperatur Innen : 22.22 °C Temperatur Aussen : 10.22 °C Taupunkt : 2.35 °C Gefühlte Temperatur : 9.50 °C Luftfeuchte Innen : 57 % Luftfeuchte Aussen : 58 % Windgeschwindkeit : 6.92 km/h Windböengeschwindkeit : 9.33 km/h max. Windböe : 23.81 km/h Windrichtung : 291 ° Windrichtung : WNW Luftdruck absolut : 981.81 hPa Luftdruck relativ : 1021.84 hPa Regenrate : 0 mm/h Regenstatus : kein Regen Regen seit Regenbeginn : 0 mm Regen Stunde : 0 mm Regen Tag : .1 mm Regen Woche : 1.2 mm Regen Monat : 1.2 mm Regen Jahr : 1.2 mm Regen Gesamt : mm Sonnenstrahlung : 452.64 W/m² UV-Index : 4 Zeitstempel : 22.10.2021 12:40:50 Firmware : EasyWeatherV1.5.9 Batteriestand: : Gateway-Modell : HP1000SE-PRO_Pro_V1.7.4Nur am Anfang kommen folgende Fehlermeldungen:
... Connection to 127.0.0.1 8087 port [tcp/*] succeeded! Listening on 0.0.0.0 1080 Connection received on 192.168.0.100 1662 /opt/wetterstation/wetterstation.sub: Zeile 559: printf: »%d Std, %d Min«: Ist kein gültiger Bezeichner /opt/wetterstation/wetterstation.sub: Zeile 559: printf: »%d Std, %d Min«: Ist kein gültiger Bezeichner /opt/wetterstation/wetterstation.sub: Zeile 559: printf: »%d Std, %d Min«: Ist kein gültiger Bezeichner /opt/wetterstation/wetterstation.sub: Zeile 559: printf: »%d Std, %d Min«: Ist kein gültiger Bezeichner [ { "id": "javascript.0.Wetterstation.Innentemperatur", "val": 22.22 }, ...Kann ich die ignorieren?
Da gehts scheinbar um das Sonnenschein-Textformat.UPDATE
Ich hatte jetzt das Skript etwa 2 Stunden als Dienst laufen und habe jetzt zusätzlich den Zugriff auf die InfluxDB-API in der conf hinterlegt.
Nach einem erneuten./wetterstation.sh --debugkamen die Fehlermeldungen jetzt nicht mehr.
Wahrscheinlich hat nur irgendein Wert gefehlt, wodurch printf in einen Fehler läuft. -
@sborg Tja, das wollte ich auch nicht glauben, denn früher ist die Übertragung der Daten abgebrochen wenn die Batterien leer waren, aber die Temp. wurde bis zu Ende übermittelt. Aber jetzt! HUT AB! Du hast es wieder mal geschafft. Neue Batterien und plötzlich läuft wieder alles!
Vielen Dank!
@a200 Zumindest kann man sich also wohl auf die Batterie-Anzeige verlassen :)
-
@sborg
Wenn ich auf WU-Protokoll umstelle, dann kommt bei./wetterstation.sh --dataauch was an, ist aber genau das Gleiche wie ein nc -lv.
Im WU-Protokoll sind allerdings auch keine Batteriewerte drin.
Bei den Batteriewerten bin ich mir nicht so sicher, was mir die sagen sollen.
Im Ecowitt-Format waren die 3 Werte enthalten:wh68batt=1.88 wh25batt=0 wh26batt=03 Werte bei 4 Sensoren (Innentemp. mit 2 x 1,5V, Außentemp. mit 2 x 1,5V, Regensensor mit 1 x 1,5V, Windsensor/Lichtsensor mit 1 x 1,5V)
Bei Ecowitt habe ich auf der Webseite gesehen, dass ein WS68 dem DP300 Wind-/Lichtsensor entspricht.
wh68 könnte also dieser sein, aber was soll der Wert 1,88 bedeuten, die Spannung?
Die Batterie ist 1,5V, gestern erst eingelegt. Und dann hat das Teil noch eine Solarzelle als Stromversorgung. Ich habe auch gerade eben nochmal den Wert ausgelesen als es dunkel war, da war er sogar auf 1.90
wh25 und wh26 konnte ich erst mal nirgends finden, was das sein soll. Da es aber 2 aufeinander folgende Nummern sind, hätte ich auf die Innen- und Außentemp.-Sensoren getippt.
Da werde ich wohl mal die Batterien nacheinander heraus nehmen müssen.
Dann wäre aber auch da die Frage, was der Wert 0 bedeudet. Ist das nur ein boolean mit 0 für Batterie Ok und 1 für Batterie schwach?
Und dann fehlt ein Sensor komplett.Wenn ich es richtig verstanden habe, kann ich das Skript verwenden und müsste bis auf die Batteriestände alle Daten bekommen, auch wenn in der conf die Sensortypen nicht existieren, richtig?
UPDATE
Nach etwas googlen bin ich auf das gestoßen: https://github.com/merbanan/rtl_433/blob/master/src/devices/fineoffset.c
Fine Offset Electronics WH25 / WH32B Temperature/Humidity/Pressure sensor protocol.
wh25 ist also der Innen-Temp-Luftfeuchte-Luftdruck Sensor, der auch keine DP-Bezeichnung hat
Und dann habe ich noch folgende interessante Seite gefunden:
https://www.wxforum.net/index.php?topic=40730.0
the predecessor model of the WH32 is the WH26 which is no longer built.
Und WH32 ist wiederum der DP40, also der Temp-Luftfeuchte Sensor für außen.
Wenn man sich bei dem Forum anmeldet, kann man auch noch ein Bild sehen, wo diese ganzen Infos zusammengefasst sind.
Ich hänge es mal hier an.
Damit ist dann auch klar, dass der Regensensor DP80 bei der Batteriemeldung fehlt, warum auch immer.
@viper4iob Bei den Batteriewerten gibt es keine einheitliche Linie. Bisher gibt es drei Möglichkeiten:
- digital [quasi true/false] : 0 und 1, wobei 0 = Ok und 1 = schwach ist (bei "leer" kommen auch keine Daten mehr ;) )
- Zählerbereich "0-5": könnte in 20% Schritten sein
- Messwert: hier wird ein ungefährer Wert der Batteriespannung angezeigt
Die Batteriemessung ist mehr eine Schätzung. Zwar ist es nicht sonderlich schwer eine Spannung zu messen, man braucht aber eine Referenzspannung dazu. Beim Multimeter übernimmt dies die Batterie des Messgerätes. Die 1.88/1.9 (Volt) sind dann auch erklärbar, da sie wohl die Gesamtspannung messen, also was das Gerät an kompletter Spannung hat inkl. des GoldCaps und der Batterie. Obwohl es dann im dunklen mehr war, liegt es einfach daran, dass er bei Tageslicht bereits geladen wurde.
So ergäbe sich dann aktuell:
wh68batt = DP300 / WS68, Solar unterstütztes Anemometer mit UV-Licht-Sensor wh25batt = WH25, Innen-Temp-Luftfeuchte-Luftdruck Sensor wh26batt = DP40 / WH32, Temp-Luftfeuchte Sensor Außen@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Wenn ich es richtig verstanden habe, kann ich das Skript verwenden und müsste bis auf die Batteriestände alle Daten bekommen, auch wenn in der conf die Sensortypen nicht existieren, richtig?
Jepp, du kannst damit produktiv arbeiten, nur die drei Batterielevel fehlen dann aktuell.
Wenn der Regensensor allerdings auch nicht im Datenstring beim Ecowitt-Protokoll auftaucht, wird er, warum dann auch immer, vom Sensor nicht übertragen.Die Umsetzung der Batterielevel wird aber nicht so ganz easy wie üblich. Da muss ich mir erst was Neues dazu einfallen lassen. Bisher hatte jeder Sensor immer zusätzliche Werte geliefert, nicht quasi bestehende und einen Batterielevel.
@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich hatte jetzt das Skript etwa 2 Stunden als Dienst laufen und habe jetzt zusätzlich den Zugriff auf die InfluxDB-API in der conf hinterlegt.
Nach einem erneuten ./wetterstation.sh --debug kamen die Fehlermeldungen jetzt nicht mehr.
Wahrscheinlich hat nur irgendein Wert gefehlt, wodurch printf in einen Fehler läuft.Sollte eigentlich nicht, da die Pakete aber extrem in ihrer Datenmenge schwanken, kann es genau eines gewesen sein was mal so gar nicht völlig valide war:
-
@viper4iob Bei den Batteriewerten gibt es keine einheitliche Linie. Bisher gibt es drei Möglichkeiten:
- digital [quasi true/false] : 0 und 1, wobei 0 = Ok und 1 = schwach ist (bei "leer" kommen auch keine Daten mehr ;) )
- Zählerbereich "0-5": könnte in 20% Schritten sein
- Messwert: hier wird ein ungefährer Wert der Batteriespannung angezeigt
Die Batteriemessung ist mehr eine Schätzung. Zwar ist es nicht sonderlich schwer eine Spannung zu messen, man braucht aber eine Referenzspannung dazu. Beim Multimeter übernimmt dies die Batterie des Messgerätes. Die 1.88/1.9 (Volt) sind dann auch erklärbar, da sie wohl die Gesamtspannung messen, also was das Gerät an kompletter Spannung hat inkl. des GoldCaps und der Batterie. Obwohl es dann im dunklen mehr war, liegt es einfach daran, dass er bei Tageslicht bereits geladen wurde.
So ergäbe sich dann aktuell:
wh68batt = DP300 / WS68, Solar unterstütztes Anemometer mit UV-Licht-Sensor wh25batt = WH25, Innen-Temp-Luftfeuchte-Luftdruck Sensor wh26batt = DP40 / WH32, Temp-Luftfeuchte Sensor Außen@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Wenn ich es richtig verstanden habe, kann ich das Skript verwenden und müsste bis auf die Batteriestände alle Daten bekommen, auch wenn in der conf die Sensortypen nicht existieren, richtig?
Jepp, du kannst damit produktiv arbeiten, nur die drei Batterielevel fehlen dann aktuell.
Wenn der Regensensor allerdings auch nicht im Datenstring beim Ecowitt-Protokoll auftaucht, wird er, warum dann auch immer, vom Sensor nicht übertragen.Die Umsetzung der Batterielevel wird aber nicht so ganz easy wie üblich. Da muss ich mir erst was Neues dazu einfallen lassen. Bisher hatte jeder Sensor immer zusätzliche Werte geliefert, nicht quasi bestehende und einen Batterielevel.
@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich hatte jetzt das Skript etwa 2 Stunden als Dienst laufen und habe jetzt zusätzlich den Zugriff auf die InfluxDB-API in der conf hinterlegt.
Nach einem erneuten ./wetterstation.sh --debug kamen die Fehlermeldungen jetzt nicht mehr.
Wahrscheinlich hat nur irgendein Wert gefehlt, wodurch printf in einen Fehler läuft.Sollte eigentlich nicht, da die Pakete aber extrem in ihrer Datenmenge schwanken, kann es genau eines gewesen sein was mal so gar nicht völlig valide war:
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
... Die 1.88/1.9 (Volt) sind dann auch erklärbar, da sie wohl die Gesamtspannung messen, also was das Gerät an kompletter Spannung hat inkl. des GoldCaps und der Batterie. Obwohl es dann im dunklen mehr war, liegt es einfach daran, dass er bei Tageslicht bereits geladen wurde.
In der Theorie wäre das plausibel, allerdings habe ich den Wert gerade nochmal geprüft. Die Sonne ist zwar schon vor einer Stunde aufgegangen, aber es ist komplett bedeckter Himmel und bei der Sonnenstrahlung waren wir jetzt gerade bei 20 W/m².
Und der Batteriewert istwh68batt=1.90
Ich kann mir jetzt nicht vorstellen, dass der Kondensator da schon wieder voll geladen ist.
Ich weiß aber auch nicht wie lange die Ladung reichen würde, da gestern den ganzen Tag die Sonne gescheint hat.
Ich werde das nochmal prüfen, sobald mal länger schlechtes Wetter ist. -
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
... Die 1.88/1.9 (Volt) sind dann auch erklärbar, da sie wohl die Gesamtspannung messen, also was das Gerät an kompletter Spannung hat inkl. des GoldCaps und der Batterie. Obwohl es dann im dunklen mehr war, liegt es einfach daran, dass er bei Tageslicht bereits geladen wurde.
In der Theorie wäre das plausibel, allerdings habe ich den Wert gerade nochmal geprüft. Die Sonne ist zwar schon vor einer Stunde aufgegangen, aber es ist komplett bedeckter Himmel und bei der Sonnenstrahlung waren wir jetzt gerade bei 20 W/m².
Und der Batteriewert istwh68batt=1.90
Ich kann mir jetzt nicht vorstellen, dass der Kondensator da schon wieder voll geladen ist.
Ich weiß aber auch nicht wie lange die Ladung reichen würde, da gestern den ganzen Tag die Sonne gescheint hat.
Ich werde das nochmal prüfen, sobald mal länger schlechtes Wetter ist.@viper4iob Unterschätze da mal nicht die kleine Solarzelle/den Cap ;)
Mein Batteriesatz wird demnächst 2 Jahre alt. Ist halt alle ~30 Sekunden "nur" Funk. -
Da keine offensichtlichen Fehler zu verzeichnen sind:
Neues Release des Wetterstation WLAN-Skriptes auf GitHub V2.9.0
- + Min-/Max-Aussentemperatur des heutigen Tages
- ~ Änderung bei Datenübertragung per Simple-API wg. InfluxDB 2.x
- + Meteorologischer Sommer Durchschnittstemperatur und Regenmenge
- + neuer Shell-Parameter --metsommer (zur manuellen Berechnung der Werte des meteorologischen Sommers)
Wie immer zu finden im GitHub
Update-Routine:
- wetterstation.sh und wetterstation.sub ersetzen
- wetterstation.js muss ebenfalls im JavaScript-Adapter ersetzt und einmalig ausgeführt werden (neue Datenpunkte "Info.Regenmenge_Met_Sommer" und "Info.Temp_Met_Sommer_avg")
- nun mittels
sudo systemctl restart wetterstationden Service neu starten - (ws_updater.sh ist diesmal nicht nötig, da es keine Änderungen in der wetterstation.conf gibt)
Wer bereits die Beta-Version der V2.9.0 nutzt sollte ggf. trotzdem updaten (hier genügt der Tausch der "sub" und den Service neu zu starten). Das Beta-Release ist mit dieser Release-Version nicht identisch. Beim Beta-Release fehlt die "Nullung" der beiden Werte des meteorologischen Sommers zum 01.01.
Neue Beta-Version des Wetterstation WLAN-Skriptes auf GitHub V2.10.0
(Beta-Releases lassen sich nicht! über den ws_updater installieren, nur die *.conf lässt sich damit patchen [s.u.])
- ~ Bugfix Option '--data' bei Ecowitt-Protokoll
- ~ Passkey bei Nutzung des Ecowitt-Protokolls maskieren
- + logging des Datenstrings der Wetterstation in eine Datei
- + Unterstützung für DP40/WH32 (bzw. WH26) Sensor
- + Unterstützung für DP300/WS68 Sensor
- + Unterstützung für WH31 (bzw. WH25) Sensor
Wie immer zu finden im GitHub
Update-Routine:
- wetterstation.sh, wetterstation.sub und ws_updater.sh ersetzen
- wetterstation.js muss ebenfalls im JavaScript-Adapter ersetzt und einmalig ausgeführt werden (neue Datenpunkte der Batteriestände); nicht zwingend nötig wenn man keine der neuen Sensoren einsetzt
./ws_updater.sh --patchim Installationsverzeichnis ausführen- nun mittels
sudo systemctl restart wetterstationden Service neu starten
Hinweis:
In der *.conf kann (temporär) nun das Logging der Datenstrings (raw) der Wetterstation aktiviert werden. Dies legt im Installationsverzeichnis dann eine Datei im Format YYYYMMTT_station.log an und schreibt den Raw-String der Station fortlaufend durch eine Leerzeile separiert.Da Frogitt offenbar bei neueren Sensoren sich von seiner DPxxx-Bezeichnung verabschiedet und zur Ecowitt WHxxx-Bezeichnung umschwenkt, ist der Interne Zusatzsensor sowohl als DP50/WH31, sowie als reiner WH31 zu finden. Eigentlich sollten hier bis zu 8 Sensoren möglich sein, der passende Datenstring liefert dafür aber aktuell keinen Hinweis ( typisch xyz[1-8]; die Nummerierung für die Sensoren fehlt aber aktuell?!? ). Hier hilft nur probieren welcher den beiden Typen korrekte Werte liefert ;)
-
Neue Beta-Version des Wetterstation WLAN-Skriptes auf GitHub V2.10.0
(Beta-Releases lassen sich nicht! über den ws_updater installieren, nur die *.conf lässt sich damit patchen [s.u.])
- ~ Bugfix Option '--data' bei Ecowitt-Protokoll
- ~ Passkey bei Nutzung des Ecowitt-Protokolls maskieren
- + logging des Datenstrings der Wetterstation in eine Datei
- + Unterstützung für DP40/WH32 (bzw. WH26) Sensor
- + Unterstützung für DP300/WS68 Sensor
- + Unterstützung für WH31 (bzw. WH25) Sensor
Wie immer zu finden im GitHub
Update-Routine:
- wetterstation.sh, wetterstation.sub und ws_updater.sh ersetzen
- wetterstation.js muss ebenfalls im JavaScript-Adapter ersetzt und einmalig ausgeführt werden (neue Datenpunkte der Batteriestände); nicht zwingend nötig wenn man keine der neuen Sensoren einsetzt
./ws_updater.sh --patchim Installationsverzeichnis ausführen- nun mittels
sudo systemctl restart wetterstationden Service neu starten
Hinweis:
In der *.conf kann (temporär) nun das Logging der Datenstrings (raw) der Wetterstation aktiviert werden. Dies legt im Installationsverzeichnis dann eine Datei im Format YYYYMMTT_station.log an und schreibt den Raw-String der Station fortlaufend durch eine Leerzeile separiert.Da Frogitt offenbar bei neueren Sensoren sich von seiner DPxxx-Bezeichnung verabschiedet und zur Ecowitt WHxxx-Bezeichnung umschwenkt, ist der Interne Zusatzsensor sowohl als DP50/WH31, sowie als reiner WH31 zu finden. Eigentlich sollten hier bis zu 8 Sensoren möglich sein, der passende Datenstring liefert dafür aber aktuell keinen Hinweis ( typisch xyz[1-8]; die Nummerierung für die Sensoren fehlt aber aktuell?!? ). Hier hilft nur probieren welcher den beiden Typen korrekte Werte liefert ;)
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
Update-Routine:
- wetterstation.sh, wetterstation.sub und ws_updater.sh ersetzen
- wetterstation.js muss ebenfalls im JavaScript-Adapter ersetzt und einmalig ausgeführt werden (neue Datenpunkte der Batteriestände); nicht zwingend nötig wenn man keine der neuen Sensoren einsetzt
./ws_updater.sh --patchim Installationsverzeichnis ausführen- nun mittels
sudo systemctl restart wetterstationden Service neu starten
Erst einmal danke für das Update.
Aber irgendetwas mache ich falsch. Mein erster Anlauf des Updates ging schief. Ich habe dann meine Sicherung zurück gespielt und den ganzen Ordner erst mal kopiert, um dort weiter zu testen. Allerdings immer mit dem gleichen Ergebnis.Ich habe die 3 Dateien wie beschrieben ausgetauscht und dann
./ws_updater.sh --patchausgeführt.
Den bestätige ich mit "J", das Skript läd die patch-Datei, legt eine Sicherung der conf an, fragt dann komischerweise nochmal, wo ich aber nichts mehr eingeben kann und dann kommt Abbruch. Die Datei hat weiterhin den alten Stand. Habe es auch als root probiert, gleiches Ergebnis.
Irgendeine Idee?
Ich könnte jetzt natürlich die conf manuell anpassen, die Infos dazu kann ich aus der patch-Datei ziehen, aber das wäre ja nicht im Sinne des Erfinders ;-)
Das Ganze läuft übrigens unter Ubuntu 20.04 LTS.PS: Bitte nicht über die 2 log Dateien wundern, die man da im Screenshot sieht. Ich lasse das Log über den systemd Service da hin schreiben, damit ich im Syslog nicht alle 30 sek die Meldungen "Connection received" und "Listening" im syslog vom netcat error output bekomme. Das wäre eventuell nochmal ein feature request, den Error Output vom netcat default wegzuschmeißen (
nc -nlvw 1 -p ${WS_PORT} 2>/dev/null) und nur in den syslog schreiben zu lassen, wenn die neue logging Option aktiviert ist oder auch nochmal eine extra Option oder generell in ein anderes Logfile schreiben lassen wie es beispielsweise der Apache oder Samba machen (da müsste man aber auch wieder das logrotate konfigurieren und dann ist man wieder beim Problem, dass das versch. Linux-Distributionen evtl. unterschiedlich handhaben) .UPDATE zum Patcher
Ich glaube ich habe einen Fehler im ws_updater.sh gefunden, das Skript legt die Datei "patch" an und versucht dann "patch.dat" anzuwenden:#Patch Version V2.8.0 auf V2.10.0 PATCH2100() { backup echo -e "\n Patche wetterstation.conf auf V2.10.0 ..." patch_2100 && patch ./wetterstation.conf < patch.dat rm patch.dat echo -e " Fertig...\n" echo -e " ${GE}Eventuelle Zusatzsensoren DP300/WS68, DP40/WH32 oder WH25/WH31 müssen eingetragen werden!\n" } -
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
Update-Routine:
- wetterstation.sh, wetterstation.sub und ws_updater.sh ersetzen
- wetterstation.js muss ebenfalls im JavaScript-Adapter ersetzt und einmalig ausgeführt werden (neue Datenpunkte der Batteriestände); nicht zwingend nötig wenn man keine der neuen Sensoren einsetzt
./ws_updater.sh --patchim Installationsverzeichnis ausführen- nun mittels
sudo systemctl restart wetterstationden Service neu starten
Erst einmal danke für das Update.
Aber irgendetwas mache ich falsch. Mein erster Anlauf des Updates ging schief. Ich habe dann meine Sicherung zurück gespielt und den ganzen Ordner erst mal kopiert, um dort weiter zu testen. Allerdings immer mit dem gleichen Ergebnis.Ich habe die 3 Dateien wie beschrieben ausgetauscht und dann
./ws_updater.sh --patchausgeführt.
Den bestätige ich mit "J", das Skript läd die patch-Datei, legt eine Sicherung der conf an, fragt dann komischerweise nochmal, wo ich aber nichts mehr eingeben kann und dann kommt Abbruch. Die Datei hat weiterhin den alten Stand. Habe es auch als root probiert, gleiches Ergebnis.Irgendeine Idee?
Ich könnte jetzt natürlich die conf manuell anpassen, die Infos dazu kann ich aus der patch-Datei ziehen, aber das wäre ja nicht im Sinne des Erfinders ;-)
Das Ganze läuft übrigens unter Ubuntu 20.04 LTS.PS: Bitte nicht über die 2 log Dateien wundern, die man da im Screenshot sieht. Ich lasse das Log über den systemd Service da hin schreiben, damit ich im Syslog nicht alle 30 sek die Meldungen "Connection received" und "Listening" im syslog vom netcat error output bekomme. Das wäre eventuell nochmal ein feature request, den Error Output vom netcat default wegzuschmeißen (
nc -nlvw 1 -p ${WS_PORT} 2>/dev/null) und nur in den syslog schreiben zu lassen, wenn die neue logging Option aktiviert ist oder auch nochmal eine extra Option oder generell in ein anderes Logfile schreiben lassen wie es beispielsweise der Apache oder Samba machen (da müsste man aber auch wieder das logrotate konfigurieren und dann ist man wieder beim Problem, dass das versch. Linux-Distributionen evtl. unterschiedlich handhaben) .UPDATE zum Patcher
Ich glaube ich habe einen Fehler im ws_updater.sh gefunden, das Skript legt die Datei "patch" an und versucht dann "patch.dat" anzuwenden:#Patch Version V2.8.0 auf V2.10.0 PATCH2100() { backup echo -e "\n Patche wetterstation.conf auf V2.10.0 ..." patch_2100 && patch ./wetterstation.conf < patch.dat rm patch.dat echo -e " Fertig...\n" echo -e " ${GE}Eventuelle Zusatzsensoren DP300/WS68, DP40/WH32 oder WH25/WH31 müssen eingetragen werden!\n" }@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Irgendeine Idee?
Nicht wirklich, bei mir funktioniert(e) es. Dann habe ich die Version von GitHub geladen, selbe wie bei dir ?!?
Sehe aber so keinen Fehler, also habe ich das Patchfile nochmals erstellt und eingefügt, jetzt:
bzgl. patch.dat: das habe ich erst eben geändert ;)
@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
damit ich im Syslog nicht alle 30 sek die Meldungen "Connection received" und "Listening" im syslog vom netcat error output bekomme. Das wäre eventuell nochmal ein feature request, den Error Output
Nehme ich mit auf, bis dato einfach vergessen, wollte ich schon öfters eliminieren :)
-
@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Irgendeine Idee?
Nicht wirklich, bei mir funktioniert(e) es. Dann habe ich die Version von GitHub geladen, selbe wie bei dir ?!?
Sehe aber so keinen Fehler, also habe ich das Patchfile nochmals erstellt und eingefügt, jetzt:
bzgl. patch.dat: das habe ich erst eben geändert ;)
@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
damit ich im Syslog nicht alle 30 sek die Meldungen "Connection received" und "Listening" im syslog vom netcat error output bekomme. Das wäre eventuell nochmal ein feature request, den Error Output
Nehme ich mit auf, bis dato einfach vergessen, wollte ich schon öfters eliminieren :)
-
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
bzgl. patch.dat: das habe ich erst eben geändert ;)
Das habe ich auch gerade gesehen 😉
Muss ich morgen nochmal testen.@SBorg
Bei mir läuft das Patchen schief, habs mal manuell probiert :viper@kubix:/opt/wetterstation_upate$ patch ./wetterstation.conf < patch patching file ./wetterstation.conf Hunk #1 FAILED at 1. Hunk #2 FAILED at 9. 2 out of 2 hunks FAILED -- saving rejects to file. /wetterstation.conf.rejKeine Ahnung woran das liegt.
Vielleicht habe ich beim Setzen der Werte irgendwo ne Leerzeile eingefügt oder gelöscht.
Ich lade morgen nochmal die conf von 2.8.0 runter und mache ein diff zu meiner config. Mal sehen, ob ich was finde.
Es könnte sein, dass ich hinter den Werten, die ich geändert habe, einen Kommentar eingefügt habe. Dann würde das wahrscheinlich für den Patcher nicht mehr zusammen passen. -
@SBorg
Bei mir läuft das Patchen schief, habs mal manuell probiert :viper@kubix:/opt/wetterstation_upate$ patch ./wetterstation.conf < patch patching file ./wetterstation.conf Hunk #1 FAILED at 1. Hunk #2 FAILED at 9. 2 out of 2 hunks FAILED -- saving rejects to file. /wetterstation.conf.rejKeine Ahnung woran das liegt.
Vielleicht habe ich beim Setzen der Werte irgendwo ne Leerzeile eingefügt oder gelöscht.
Ich lade morgen nochmal die conf von 2.8.0 runter und mache ein diff zu meiner config. Mal sehen, ob ich was finde.
Es könnte sein, dass ich hinter den Werten, die ich geändert habe, einen Kommentar eingefügt habe. Dann würde das wahrscheinlich für den Patcher nicht mehr zusammen passen.@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Vielleicht habe ich beim Setzen der Werte irgendwo ne Leerzeile eingefügt oder gelöscht.
...Es könnte sein, dass ich hinter den Werten, die ich geändert habe, einen Kommentar eingefügt habeDas sollte "patch" eigentlich abkönnen. Bei mir kommt bspw. "fuzz xyz" da meine IP nicht 192.168.1.3 wie im Patchfile ist, genauso wie ich nicht das WU-Protokoll lt. Patchfile nutze, sondern Ecowitt.
-
@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Vielleicht habe ich beim Setzen der Werte irgendwo ne Leerzeile eingefügt oder gelöscht.
...Es könnte sein, dass ich hinter den Werten, die ich geändert habe, einen Kommentar eingefügt habeDas sollte "patch" eigentlich abkönnen. Bei mir kommt bspw. "fuzz xyz" da meine IP nicht 192.168.1.3 wie im Patchfile ist, genauso wie ich nicht das WU-Protokoll lt. Patchfile nutze, sondern Ecowitt.
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Vielleicht habe ich beim Setzen der Werte irgendwo ne Leerzeile eingefügt oder gelöscht.
...Es könnte sein, dass ich hinter den Werten, die ich geändert habe, einen Kommentar eingefügt habeDas sollte "patch" eigentlich abkönnen. Bei mir kommt bspw. "fuzz xyz" da meine IP nicht 192.168.1.3 wie im Patchfile ist, genauso wie ich nicht das WU-Protokoll lt. Patchfile nutze, sondern Ecowitt.
Ich habe jetzt nochmal die 2.9.0 release Version (https://github.com/SBorg2014/WLAN-Wetterstation/releases/download/V2.9.0/WLAN-Wetterstation.zip) herunter geladen und habe daran nichts verändert.
Dann habe ich den Stand 2.10.0 von hier herunter geladen: https://github.com/SBorg2014/WLAN-Wetterstation/tree/a3de2459fad54adc427ddb7c17f8eef9f3c5d3a6
Danach dann in der 2.9.0 einfach mal alle Dateien außer der conf durch die von der 2.10.0 ersetzt.
Und dann./ws_updater.sh --patchausgeführt und bekomme den gleichen Fehler.
Dann einpatch --verbose ./wetterstation.conf < patchausgeführt und der sagt:patch --verbose ./wetterstation.conf < patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- wetterstation.conf_org 2021-10-24 11:21:11.969204947 +0200 |+++ wetterstation.conf 2021-10-25 12:40:46.210234324 +0200 -------------------------- patching file ./wetterstation.conf Using Plan A... Hunk #1 FAILED at 1. Hunk #2 succeeded at 9 with fuzz 1. 1 out of 2 hunks FAILED -- saving rejects to file ./wetterstation.conf.rej doneIn der Datei patch steht:
--- wetterstation.conf_org 2021-10-24 11:21:11.969204947 +0200 +++ wetterstation.conf 2021-10-25 12:40:46.210234324 +0200 @@ -1,7 +1,10 @@ -### Settings V2.8.0 ----------------------------------------------------------- +### Settings V2.10.0 ----------------------------------------------------------- #Debuging einschalten [true/false] / default: false / Ausgabe der Messwerte debug=false + #Logging einschalten [true/false] / default: false / schreibt die Datenstrings der Station in eine Datei + logging=false + #ioBroker-IP und Port der Simple-Restful-API [xxx.xxx.xxx.xxx:xxxxx] IPP=192.168.1.3:8087 @@ -9,12 +12,15 @@ WS_PROTOKOLL=2 #Anzahl der vorhandenen Zusatzsensoren / default: 0 + ANZAHL_WH31=0 + ANZAHL_DP40=0 ANZAHL_DP50=0 ANZAHL_DP60=0 ANZAHL_DP70=0 ANZAHL_DP100=0 ANZAHL_DP200=0 ANZAHL_DP250=0 + ANZAHL_DP300=0 #Protokoll (HTTP oder HTTPS) / default: HTTP WEB=HTTPDie Änderungen ab Zeile 9 hat er ausgeführt, das ging bei meiner geänderten config auch nicht und das lag tatsächlich an meinen Kommentaren dahinter.
Aber ab Zeile 1 bekommt er auch mit den originalen config files aus 2.9.0 und 2.10.0 bei mir nicht hin.
Es geht nur, wenn ich den Parameter ignore-whitespace hinzufüge:patch --verbose --ignore-whitespace ./wetterstation.conf < patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- wetterstation.conf_org 2021-10-24 11:21:11.969204947 +0200 |+++ wetterstation.conf 2021-10-25 12:40:46.210234324 +0200 -------------------------- patching file ./wetterstation.conf Using Plan A... Hunk #1 succeeded at 1. Hunk #2 succeeded at 12 with fuzz 1. doneIch glaube ich werde die Änderungen manuell einpflegen, ich weiß hier ehrlich gesagt nicht weiter.
So gut kenne ich mich dann damit auch nicht aus. -
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Vielleicht habe ich beim Setzen der Werte irgendwo ne Leerzeile eingefügt oder gelöscht.
...Es könnte sein, dass ich hinter den Werten, die ich geändert habe, einen Kommentar eingefügt habeDas sollte "patch" eigentlich abkönnen. Bei mir kommt bspw. "fuzz xyz" da meine IP nicht 192.168.1.3 wie im Patchfile ist, genauso wie ich nicht das WU-Protokoll lt. Patchfile nutze, sondern Ecowitt.
Ich habe jetzt nochmal die 2.9.0 release Version (https://github.com/SBorg2014/WLAN-Wetterstation/releases/download/V2.9.0/WLAN-Wetterstation.zip) herunter geladen und habe daran nichts verändert.
Dann habe ich den Stand 2.10.0 von hier herunter geladen: https://github.com/SBorg2014/WLAN-Wetterstation/tree/a3de2459fad54adc427ddb7c17f8eef9f3c5d3a6
Danach dann in der 2.9.0 einfach mal alle Dateien außer der conf durch die von der 2.10.0 ersetzt.
Und dann./ws_updater.sh --patchausgeführt und bekomme den gleichen Fehler.
Dann einpatch --verbose ./wetterstation.conf < patchausgeführt und der sagt:patch --verbose ./wetterstation.conf < patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- wetterstation.conf_org 2021-10-24 11:21:11.969204947 +0200 |+++ wetterstation.conf 2021-10-25 12:40:46.210234324 +0200 -------------------------- patching file ./wetterstation.conf Using Plan A... Hunk #1 FAILED at 1. Hunk #2 succeeded at 9 with fuzz 1. 1 out of 2 hunks FAILED -- saving rejects to file ./wetterstation.conf.rej doneIn der Datei patch steht:
--- wetterstation.conf_org 2021-10-24 11:21:11.969204947 +0200 +++ wetterstation.conf 2021-10-25 12:40:46.210234324 +0200 @@ -1,7 +1,10 @@ -### Settings V2.8.0 ----------------------------------------------------------- +### Settings V2.10.0 ----------------------------------------------------------- #Debuging einschalten [true/false] / default: false / Ausgabe der Messwerte debug=false + #Logging einschalten [true/false] / default: false / schreibt die Datenstrings der Station in eine Datei + logging=false + #ioBroker-IP und Port der Simple-Restful-API [xxx.xxx.xxx.xxx:xxxxx] IPP=192.168.1.3:8087 @@ -9,12 +12,15 @@ WS_PROTOKOLL=2 #Anzahl der vorhandenen Zusatzsensoren / default: 0 + ANZAHL_WH31=0 + ANZAHL_DP40=0 ANZAHL_DP50=0 ANZAHL_DP60=0 ANZAHL_DP70=0 ANZAHL_DP100=0 ANZAHL_DP200=0 ANZAHL_DP250=0 + ANZAHL_DP300=0 #Protokoll (HTTP oder HTTPS) / default: HTTP WEB=HTTPDie Änderungen ab Zeile 9 hat er ausgeführt, das ging bei meiner geänderten config auch nicht und das lag tatsächlich an meinen Kommentaren dahinter.
Aber ab Zeile 1 bekommt er auch mit den originalen config files aus 2.9.0 und 2.10.0 bei mir nicht hin.
Es geht nur, wenn ich den Parameter ignore-whitespace hinzufüge:patch --verbose --ignore-whitespace ./wetterstation.conf < patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- wetterstation.conf_org 2021-10-24 11:21:11.969204947 +0200 |+++ wetterstation.conf 2021-10-25 12:40:46.210234324 +0200 -------------------------- patching file ./wetterstation.conf Using Plan A... Hunk #1 succeeded at 1. Hunk #2 succeeded at 12 with fuzz 1. doneIch glaube ich werde die Änderungen manuell einpflegen, ich weiß hier ehrlich gesagt nicht weiter.
So gut kenne ich mich dann damit auch nicht aus.@viper4iob Ich bin auch nicht gerade der "diff/patch - King" ;)
Ich habe noch weiter getestet, bei mir funktioniert es. Distri kann ich ausschließen, nutze ebenfalls Ubuntu 20.04 LTS
Vielleicht tritt es ja bei einem weiteren Tester noch auf? Andererseits wenn es mittels "whitespace" funktioniert, kann ich das in den Updater auch noch aufnehmen. Die Leerzeilen sind reine Optik.Noch nicht hochgeladen, aber schon umgesetzt (Ruhe im Log):
Für die Kommunikationsüberwachung gibt es ja DPs, andernfalls kann man es dann auch per aktiviertem Logging wieder anhand des Logfiles sehen.
-
@viper4iob Ich bin auch nicht gerade der "diff/patch - King" ;)
Ich habe noch weiter getestet, bei mir funktioniert es. Distri kann ich ausschließen, nutze ebenfalls Ubuntu 20.04 LTS
Vielleicht tritt es ja bei einem weiteren Tester noch auf? Andererseits wenn es mittels "whitespace" funktioniert, kann ich das in den Updater auch noch aufnehmen. Die Leerzeilen sind reine Optik.Noch nicht hochgeladen, aber schon umgesetzt (Ruhe im Log):
Für die Kommunikationsüberwachung gibt es ja DPs, andernfalls kann man es dann auch per aktiviertem Logging wieder anhand des Logfiles sehen.
Ich hatte beide Versionen mit wget runter geladen, entpackt, und auf die unveränderte conf Version 2.8.0 den Patch angewandt und trotzdem ein Fehler. Ich dachte erst es könnte an den line-endings liegen wegen LF und CRLF, aber da war alles identisch, Kodierung ist UTF-8.
Vielleicht noch etwas mit Tabs vs. Leerzeichen, wie die interpretiert werden, keine Ahnung.
Ich habe jetzt mal eindiff -uauf die beiden Dateien gemacht und da kommt das hier raus:--- 2.8.0/wetterstation.conf 2021-08-16 13:24:08.000000000 +0200 +++ 2.10.0/wetterstation.conf 2021-10-27 09:09:01.000000000 +0200 @@ -1,20 +1,26 @@ -### Settings V2.8.0 ----------------------------------------------------------- +### Settings V2.10.0 ----------------------------------------------------------- #Debuging einschalten [true/false] / default: false / Ausgabe der Messwerte debug=false + #Logging einschalten [true/false] / default: false / schreibt die Datenstrings der Station in eine Datei + logging=false + #ioBroker-IP und Port der Simple-Restful-API [xxx.xxx.xxx.xxx:xxxxx] IPP=192.168.1.3:8087 - #Protokoll der Wetterstation [1/2/9] / 1=Wunderground ; 2=Ecowitt ; 9=Sainlogic Profi / default: 1 - WS_PROTOKOLL=1 + #Protokoll der Wetterstation [1/2/9] / 1=Wunderground ; 2=Ecowitt ; 9=Sainlogic Profi / default: 2 + WS_PROTOKOLL=2 #Anzahl der vorhandenen Zusatzsensoren / default: 0 + ANZAHL_WH31=0 + ANZAHL_DP40=0 ANZAHL_DP50=0 ANZAHL_DP60=0 ANZAHL_DP70=0 ANZAHL_DP100=0 ANZAHL_DP200=0 ANZAHL_DP250=0 + ANZAHL_DP300=0 #Protokoll (HTTP oder HTTPS) / default: HTTP WEB=HTTPSieht anders aus als in dem patch file vom Skript, z.B. nur ein Hunk statt 2, hat mir jetzt bei der Fehlersuche also auch nicht wirklich geholfen. Wenn ich das als Patch auf die unveränderte 2.8.0 conf anwende, geht es bei mir.
Die Leerzeichen beim Patchen mit dem Parameter ignore-whitespace zu ignorieren, würde mir zwar jetzt helfen, ich weiß aber nicht, ob das so eine gute Idee ist. Manchmal werden die ja auch absichtlich benutzt. Siehe auch die Diskussion hier: https://unix.stackexchange.com/questions/96486/how-to-create-a-patch-ignoring-indentation-differences-in-the-code
Lass es lieber raus. Ich passe meine conf manuell an.
Kannst du mal schauen, was der Befehllocalebei dir ausspuckt. Bei mir steht da in der ersten ZeileLANG=de_DE.UTF-8Schon mal danke im Voraus für das Anpassen vom netcat Log.
-
@viper4iob Ich bin auch nicht gerade der "diff/patch - King" ;)
Ich habe noch weiter getestet, bei mir funktioniert es. Distri kann ich ausschließen, nutze ebenfalls Ubuntu 20.04 LTS
Vielleicht tritt es ja bei einem weiteren Tester noch auf? Andererseits wenn es mittels "whitespace" funktioniert, kann ich das in den Updater auch noch aufnehmen. Die Leerzeilen sind reine Optik.Noch nicht hochgeladen, aber schon umgesetzt (Ruhe im Log):
Für die Kommunikationsüberwachung gibt es ja DPs, andernfalls kann man es dann auch per aktiviertem Logging wieder anhand des Logfiles sehen.
Jetzt aber mal eine positive Nachricht, die 2.10.0 Beta funktioniert mit den neuen Sensoren, die Batteriewerte werden angezeigt.
Gute Arbeit, danke.Noch eine generelle Frage: Es gibt ja schon die neue Wifi-Firmware EasyWeather 1.6.0.
Meine WS-View-App ist aber immer noch der Meinung 1.5.9 wäre aktuell. Nach dem Kauf der Wetterstation hatte ich da bereits ein Update auf die 1.5.9. D.h. prinzipiell scheint das zu gehen.
Wird die neue Firmware vielleicht für verschiedene WS-Modelle zu verschiedenen Zeiten ausgerollt? Gibt es da Erfahrung? -
@sborg
Ein kleinen Punkt hätte ich doch noch.
Ich habe heute einen zusätzlichen DP50 in Betrieb genommen und bekomme seitdem im iobroker Log von der Simple API ständig folgende Meldung:State value to set for "javascript.0.Wetterstation.DP50.1.Batterie" has to be type "number" but received type "string"Da passt der Datentyp nicht zusammen.
Bei den neuen Sensoren wird 0 oder 1 für den Batteriewert-Datenpunkt geschrieben, beim DP50 steht im Datenpunkt "OK"UPDATE
Ich habe jetzt mal den Datentyp vom Datenpunkt der DP50 Batterie von Zahl auf Zeichenkette geändert, damit nicht alle 30 sek eine Meldung im iobroker generiert wird.
Ist die Frage wie man es einheitlich handhaben will. Es sollte zumindest einheitlich für alle Sensoren sein, die 0 oder 1 als Batteriestatus melden.
Entweder das Skript schreibt "OK"/"Alarm", dann muss das JS-Skript, das die Datenpunkte anlegt, das als String definieren.
Oder eben 0/1, dann bleibts bei number.
Es scheint aktuell nur beim DP50 die Funktion batterie aufgerufen zu werden (https://github.com/SBorg2014/WLAN-Wetterstation/blob/master/wetterstation.sub#L1172)
Support us
827
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge