NEWS
[Linux Shell-Skript] WLAN-Wetterstation
-
@wendy2702 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
das Statistik Script installiert.
Ist es immer noch ausreichend nur das loggen für diese DP's zu aktivieren?Sorry, hab überlesen, dass du das Statistik meinst.
Ja, da reichen diese 3
-
Sodele, neues von der Front.
[JSON] habe ich verworfen, da dass Blödsinn ist. Ich habe dann einen DP (der eine Bezeichnung hat) in dem dann die Bezeichnung und der Wert drin steht... Das habe ich ja schon mit dem "normalen" Datenpunkt.
Dafür kam [TAG] dazu:

Nicht über die Werte wundern, die sind stellenweise getürkt, da es hier bspw. Dauerregen hat, ich aber mal einen "Spezialpatch" für die Tag/Tage-Problematik probieren musste. Der "4. Oktober" beim [TAG]-Test ist ebenfalls falsch, kommt davon wenn man getDay/getDate verwechselt...Das Ganze wird natürlich wie üblich erst mit dem Start der neuen Funktion korrekt laufen und Änderungen am Template werden erst geschrieben wenn sich der Wert des DPs auch wirklich ändert. Deswegen steht bei mir zum Teil "...im Oktober..." und "... am 4. Oktober..."
Dann baue ich noch die beiden "Schnittchen" ( @ilovegym ) voraussichtlich heute ein, dann gübbet es morgen wieder was zu testen :grin: -
Neue Version des Wetterstation-Statistik-Skriptes auf GitHub V0.1.1
- + AutoReset Jahresstatistik
Wie immer zu finden im GitHub (wetterstation-statistik.js)
Zu sehen ist so erst mal nichts, außer es funktioniert dann am 01.01.
In der Simulation lief es zumindest, allerdings sind das keine 19'er Daten, sondern nur die 12 Tage vom Oktober ;)

Neue Beta-Version des Wetterstation-Statistik-Skriptes auf GitHub V0.1.3B_01
- + Rekordwerte
Wie immer zu finden im GitHub (wetterstation-statistik.js)
Beim Einsatz der Beta geht nichts kaputt oder verloren, nur sind die neuen Rekordwerte noch eher "suboptimal" bzw. experimentell. Neue User-Einstellungen beachten!Ich habe mal mit diversen Template-Vorlagen gespielt. Dabei kam noch [MONAT_ZAHL] und [MONAT_KURZ] dazu:

Allerdings wird man später um das ein oder andere Binding per "value-Werte" in der VIS nicht herum kommen.
Beispiel-Template: [WERT] am [TAG].[MONAT_ZAHL].[JAHR]
Ausgabe im DP (zB. Temperatur-Spitzenhöchstwert): 41.34 °C am 14.07.2020
Sähe bei der Trockenperiode aber blöd aus: 31 Tage am 15.05.2020...und gleich wieder ein neues Problemchen mit der Durchschnittstemperatur. Im Grunde ist die nur am 31.12. korrekt zu ermitteln wenn man auch die kpl. Jahreswerte hat. Da es jetzt eher kälter wird, sinkt natürlich die Durchschnittstemperatur überdurchschnittlich ab, da wir keine Werte von Januar - Oktober haben. Damit wird natürlich ein unrealistischer Temperatur-Jahresdurchschnitt-Minimal-Wert generiert (bei mir aktuell 7.9 °C), der natürlich weder die korrekte Durchschnittstemperatur von 2020 wieder spiegelt, noch wird der wohl bis zur nächsten Eiszeit jemals gebrochen werden können ;)
Als Lösung sehe ich aktuell nur, diese Rekordwerte ausschließlich am 01.01. des Jahres zu berechnen und einmalig für das "Startjahr" dann am nächsten Ersten (bei uns also der 01.01.2021) die Werte auf -/+ 99.99 °C zu setzen, damit dann ab 01.01.2022 die Rekordwerte korrekt sind. Muss mal schauen ob ich das irgendwie automatisch hinbekomme. Man, man, man, sind das Planungszeiträume :grinning:btw: "kalte Tage" funktioniert auch, gestern war der Spitzenwert nur 9.88 °C und ich habe einen bekommen...
-
Neue Beta-Version des Wetterstation-Statistik-Skriptes auf GitHub V0.1.3B_01
- + Rekordwerte
Wie immer zu finden im GitHub (wetterstation-statistik.js)
Beim Einsatz der Beta geht nichts kaputt oder verloren, nur sind die neuen Rekordwerte noch eher "suboptimal" bzw. experimentell. Neue User-Einstellungen beachten!Ich habe mal mit diversen Template-Vorlagen gespielt. Dabei kam noch [MONAT_ZAHL] und [MONAT_KURZ] dazu:

Allerdings wird man später um das ein oder andere Binding per "value-Werte" in der VIS nicht herum kommen.
Beispiel-Template: [WERT] am [TAG].[MONAT_ZAHL].[JAHR]
Ausgabe im DP (zB. Temperatur-Spitzenhöchstwert): 41.34 °C am 14.07.2020
Sähe bei der Trockenperiode aber blöd aus: 31 Tage am 15.05.2020...und gleich wieder ein neues Problemchen mit der Durchschnittstemperatur. Im Grunde ist die nur am 31.12. korrekt zu ermitteln wenn man auch die kpl. Jahreswerte hat. Da es jetzt eher kälter wird, sinkt natürlich die Durchschnittstemperatur überdurchschnittlich ab, da wir keine Werte von Januar - Oktober haben. Damit wird natürlich ein unrealistischer Temperatur-Jahresdurchschnitt-Minimal-Wert generiert (bei mir aktuell 7.9 °C), der natürlich weder die korrekte Durchschnittstemperatur von 2020 wieder spiegelt, noch wird der wohl bis zur nächsten Eiszeit jemals gebrochen werden können ;)
Als Lösung sehe ich aktuell nur, diese Rekordwerte ausschließlich am 01.01. des Jahres zu berechnen und einmalig für das "Startjahr" dann am nächsten Ersten (bei uns also der 01.01.2021) die Werte auf -/+ 99.99 °C zu setzen, damit dann ab 01.01.2022 die Rekordwerte korrekt sind. Muss mal schauen ob ich das irgendwie automatisch hinbekomme. Man, man, man, sind das Planungszeiträume :grinning:btw: "kalte Tage" funktioniert auch, gestern war der Spitzenwert nur 9.88 °C und ich habe einen bekommen...
@SBorg Hi, richtig, die kompletten Rekordwerte kann man nur am 1.1. berechnen auf Grund den Vorjahreswerten.
Leider werden wir also noch bis zum 1.1.2022 warten muessen, um zu sehen, ob es wirklich klappt..
Man kann ja das Script mal zum testen starten, um zu sehen, ob Werte ermittelt werden, aber am 1.1. muss das Script dann neu berechnen ...
-
Neue Beta-Version des Wetterstation-Statistik-Skriptes auf GitHub V0.1.3B_01
- + Rekordwerte
Wie immer zu finden im GitHub (wetterstation-statistik.js)
Beim Einsatz der Beta geht nichts kaputt oder verloren, nur sind die neuen Rekordwerte noch eher "suboptimal" bzw. experimentell. Neue User-Einstellungen beachten!Ich habe mal mit diversen Template-Vorlagen gespielt. Dabei kam noch [MONAT_ZAHL] und [MONAT_KURZ] dazu:

Allerdings wird man später um das ein oder andere Binding per "value-Werte" in der VIS nicht herum kommen.
Beispiel-Template: [WERT] am [TAG].[MONAT_ZAHL].[JAHR]
Ausgabe im DP (zB. Temperatur-Spitzenhöchstwert): 41.34 °C am 14.07.2020
Sähe bei der Trockenperiode aber blöd aus: 31 Tage am 15.05.2020...und gleich wieder ein neues Problemchen mit der Durchschnittstemperatur. Im Grunde ist die nur am 31.12. korrekt zu ermitteln wenn man auch die kpl. Jahreswerte hat. Da es jetzt eher kälter wird, sinkt natürlich die Durchschnittstemperatur überdurchschnittlich ab, da wir keine Werte von Januar - Oktober haben. Damit wird natürlich ein unrealistischer Temperatur-Jahresdurchschnitt-Minimal-Wert generiert (bei mir aktuell 7.9 °C), der natürlich weder die korrekte Durchschnittstemperatur von 2020 wieder spiegelt, noch wird der wohl bis zur nächsten Eiszeit jemals gebrochen werden können ;)
Als Lösung sehe ich aktuell nur, diese Rekordwerte ausschließlich am 01.01. des Jahres zu berechnen und einmalig für das "Startjahr" dann am nächsten Ersten (bei uns also der 01.01.2021) die Werte auf -/+ 99.99 °C zu setzen, damit dann ab 01.01.2022 die Rekordwerte korrekt sind. Muss mal schauen ob ich das irgendwie automatisch hinbekomme. Man, man, man, sind das Planungszeiträume :grinning:btw: "kalte Tage" funktioniert auch, gestern war der Spitzenwert nur 9.88 °C und ich habe einen bekommen...
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
btw: "kalte Tage" funktioniert auch, gestern war der Spitzenwert nur 9.88 °C und ich habe einen bekommen...
ist ja fast Badewetter. :grin:
Rekord seit Script sind 4 °C
PS: :money_with_wings: ;)
-
Das ganze entstand aus diesem Thread.
Damit ist es möglich mit einem Linux-Client die Daten einer WLAN-Wetterstation und/oder mit Hilfe eines Gateways und Zusatzsensoren zu empfangen, aufzubereiten und im ioBroker zur Verfügung zu stellen. Optional können die Daten auch bei AWEKAS.at, OpenSenseMap, Windy und wetter.com zur Verfügung gestellt werden.
Mein Dank geht an @Latzi für das testen in der Entwicklungsphase und dessen Unterstützung bei der Verfassung der WiKi-Artikel.
Aktuelle Version auf GitHub:
Neue Versionen im Thread sind ab V2.15.0 (Juli 2022) unterschiedlich farblich gekennzeichnet:- Beta-Releases haben dann eine rote Versionsnummer
- stabile Releases haben dann eine grüne Versionsnummer
Projektseite (inkl. WiKi): https://sborg2014.github.io/WLAN-Wetterstation/
Da es sich um keinen Adapter handelt, ist dies eine "Vorschaltseite" von GitHub. Nicht das wer auf die Idee kommt von der URL im ioBroker installieren zu wollen ;)
Zum Download/WiKi geht es dann weiter per View on GitHubBisher geteste Stationen:
- BRESSER
- WLAN Farb-Wetter Center mit 5-in-1 Profi-Sensor V (1) @pandor
- WLAN Comfort Wetterstation mit 7-in-1 Profi-Sensor (1)
- ChiliTec Funk Wetterstation 12in1 @tege0
- DNT Weatherscreen PRO @Petersilie
- Ecowitt
- GW1000
- GW2000A
- GW3000A @MartyBr
- WS2910 @Nashra
- WS3800A @hoschi2007
- WS3900 @Mike77
- ELV WS980WiFi @sonystar
- Eurochron EFWS2900 @Latzi, @ilovegym, @SBorg (baugleich mit Ambient Weather WS-2902, Chilitec CTW-902, Sainlogic 10 in 1)
- Froggit
- Gateway/USB-Dongle DP1500/DP2000 @Boronsbruder
- HP1000SE Pro @Stormbringer
- WH3000 SE @ToxSox, @crunchip
- WH4000 SE @unltdnetworx, @Glasfaser, @Negalein, @Boronsbruder
- WH6000 Pro @Mugel80
- Renkforce WH2600
- Sainlogic
- Ventus W830 @CiroCool, @Rushmed
(1) Abfrage per DNS-Server wie bspw. PiHole oder dnsmasq
Bisher unterstütze Zusatzsensoren per Station oder mittels DP1500/DP2000/GW1000/GW2000A - Gateway:
- bis zu 8 Stück DP35/WN34 Wassertemperatur-Sensoren
- ein DP40/WH32 (bzw. WH26) Außentemperatur- und Luftfeuchtigkeitssensor
- bis zu 8 Stück DP50/WH31 Temperatur-/Luftfeuchtigkeit-Sensoren
- ein DP60/WH57 Blitzsensor
- bis zu 4 Stück DP70/WH55 Wasserleckage-Sensoren
- bis zu 16 Stück DP100/WH51 Bodenfeuchte-Sensoren
- bis zu 4 Stück DP200/WH43 PM2.5 Feinstaub-Sensoren
- ein DP250/WH45 5-In-1 CO2 / PM2.5 / PM10 / Temperatur / Luftfeuchte Innenraumsensor
- ein DP300/WS68 Solarunterstütztes Anemometer mit UV-Lichtsensor
- ein WH31 (bzw. WH25) Sensor
- ein WH40H Sensor
- ein WS80 Sensor
- ein WS90 "Wittboy" Sensor
- BRESSER (1)
- bis zu 4 Stück(2) BRESSER Thermo-/Hygro-Sensor 7 Kanal #7009999
Für den WFC01 hat @Rand nun hier und folgende ein kleines Javascript gebaut, um diesen auch auslesen zu können.
(1) nicht alle Bresser-Stationen unterstützen Zusatzsensoren! siehe hier
(2) durch das verwendete Wunderground-Protokoll limitiertDie mögliche Anzahl der Zusatzsensoren ist nicht durch das Skript begrenzt, sondern wird vom Display und/oder Gateway bestimmt.
Es besteht ferner auch die Möglichkeit Stationen (wie bspw. Sainlogic Profi Wlan Wetterstation FT0300) einzubinden die nicht per WS View[+] App konfiguriert werden können und nur ein Web-Interface bieten, dass keine Angabe eines eigenen Wetterdienst-Servers zulässt. Hierfür kann man den Umweg eines eigenen DNS-Servers wie dnsmasq oder Pi-hole gehen. Für Pi-hole hat @XxJooO freundlicherweise hier im Forum eine ausführliche Doku erstellt: klick mich
Wäre schön wenn sich weitere User mit entsprechenden Modellen melden bei denen es funktioniert (auch wenn es baugleiche sein sollten, so ist man sich wenigstens sicher ;) )
Update von einer Vorgängerversion (bei Nutzung per systemd):
Im Installationsverzeichnis
./ws_updater.shausführen.
Alternativ (falls die aktuell installierte Version kleiner als V2.12.0 ist): im Installationsverzeichnisbash <(curl -s https://raw.githubusercontent.com/SBorg2014/WLAN-Wetterstation/master/ws_updater.sh)ausführenUpdate von einer Vorgängerversion (bei Nutzung als cronjob):
Am besten das laufende Skript mit
pkill -9 wetterstation.shstoppen, wetterstation.sh und -.sub ersetzen (-.conf und -.js nur nach Aufforderung nötig; conf dann neu konfigurieren / js ersetzen und einmalig ausführen), dann entweder- direkt am Linux-Client
./wetterstation.sh & - oder per Putty oä.
nohup ./wetterstation.sh &(erzeugt dabei eine Datei nohup.out) - oder reboot des Systemes (Skript wird dann per cronjob wieder gestartet)
jeweils im Installationsverzeichnis ausführen. Sonst befindet sich ggf. noch das alte Skript im RAM und läuft munter bis zum nächsten Reboot weiter ;)
Beispiele einer grafischen Umsetzung:
@Glasfaser: View / zum Beitrag

@crunchip: Grafana / zum Beitrag

Wetterstation-Statistik (JS-Addon)
Statistikmodul als Javascript. Liefert diverse Statistiken:

Javascript für eine HTML-Tabelle vorheriger Monatswerte ( @liv-in-sky ) :


zum ThreadNeues Projekt PimpMyStation (14.11.2020)
Kein Support per PM/Chat !
PS: 💸 :blush:
-
Neue Beta-Version des Wetterstation-Statistik-Skriptes auf GitHub V0.1.3B_01
- + Rekordwerte
Wie immer zu finden im GitHub (wetterstation-statistik.js)
Beim Einsatz der Beta geht nichts kaputt oder verloren, nur sind die neuen Rekordwerte noch eher "suboptimal" bzw. experimentell. Neue User-Einstellungen beachten!Ich habe mal mit diversen Template-Vorlagen gespielt. Dabei kam noch [MONAT_ZAHL] und [MONAT_KURZ] dazu:

Allerdings wird man später um das ein oder andere Binding per "value-Werte" in der VIS nicht herum kommen.
Beispiel-Template: [WERT] am [TAG].[MONAT_ZAHL].[JAHR]
Ausgabe im DP (zB. Temperatur-Spitzenhöchstwert): 41.34 °C am 14.07.2020
Sähe bei der Trockenperiode aber blöd aus: 31 Tage am 15.05.2020...und gleich wieder ein neues Problemchen mit der Durchschnittstemperatur. Im Grunde ist die nur am 31.12. korrekt zu ermitteln wenn man auch die kpl. Jahreswerte hat. Da es jetzt eher kälter wird, sinkt natürlich die Durchschnittstemperatur überdurchschnittlich ab, da wir keine Werte von Januar - Oktober haben. Damit wird natürlich ein unrealistischer Temperatur-Jahresdurchschnitt-Minimal-Wert generiert (bei mir aktuell 7.9 °C), der natürlich weder die korrekte Durchschnittstemperatur von 2020 wieder spiegelt, noch wird der wohl bis zur nächsten Eiszeit jemals gebrochen werden können ;)
Als Lösung sehe ich aktuell nur, diese Rekordwerte ausschließlich am 01.01. des Jahres zu berechnen und einmalig für das "Startjahr" dann am nächsten Ersten (bei uns also der 01.01.2021) die Werte auf -/+ 99.99 °C zu setzen, damit dann ab 01.01.2022 die Rekordwerte korrekt sind. Muss mal schauen ob ich das irgendwie automatisch hinbekomme. Man, man, man, sind das Planungszeiträume :grinning:btw: "kalte Tage" funktioniert auch, gestern war der Spitzenwert nur 9.88 °C und ich habe einen bekommen...
-
@SBorg said in [Linux Shell-Skript] WLAN-Wetterstation:
Man, man, man, sind das Planungszeiträume
wenn man dann erst einen 10jahres schnitt haben will... :D
@da_Woody sagte in [Linux Shell-Skript] WLAN-Wetterstation:
wenn man dann erst einen 10jahres schnitt haben will...
Ich werde mir einen DeLorean kaufen und mit Marty und Doc Brown einen Ausflug machen! ;)
-
@da_Woody sagte in [Linux Shell-Skript] WLAN-Wetterstation:
wenn man dann erst einen 10jahres schnitt haben will...
Ich werde mir einen DeLorean kaufen und mit Marty und Doc Brown einen Ausflug machen! ;)
-
@Negalein ey, wo treffen wir uns? ich will mit! soweit ich weis bist du ja auch ausm ösi-land. da is es einfacher sich zu treffen... :D
@da_Woody sagte in [Linux Shell-Skript] WLAN-Wetterstation:
soweit ich weis bist du ja auch ausm ösi-land
Richtig! Bin im Innviertel. Schon fast ein Bayer. Schau da vom Fenster rüber. :)
-
@da_Woody sagte in [Linux Shell-Skript] WLAN-Wetterstation:
soweit ich weis bist du ja auch ausm ösi-land
Richtig! Bin im Innviertel. Schon fast ein Bayer. Schau da vom Fenster rüber. :)
-
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
btw: "kalte Tage" funktioniert auch, gestern war der Spitzenwert nur 9.88 °C und ich habe einen bekommen...
ist ja fast Badewetter. :grin:
Rekord seit Script sind 4 °C
PS: :money_with_wings: ;)
@Negalein, @ilovegym sagte in [Linux Shell-Skript] WLAN-Wetterstation:
PS: :money_with_wings: ;)
Herzlichen Dank euch beiden :sunglasses: :the_horns:
Brauch mal wieder eure Meinung:
Ich kann quasi das Installationsdatum aus dem Ordner-DP ziehen. Bei mir 12.09.2020
Egal wann nun ein User installiert, würde am 01.01. geprüft werden ob "aktuelles Jahr" = "Installationsjahr +1". Wäre bei uns allen am 01.01.2021 jetzt wahr --> dann resette den Durchschnitt (weil ja bei jedem der innerhalb eines Jahres beginnt das erste Jahr quasi "für die Füsse" ist). Am 01.01.2022 und spätere Jahre wäre es immer falsch und die Berechnung, Anzeige etc. würde erfolgen (und stimmen :) ). Soweit, so gut. Problem besteht aber wenn man bspw. 2 oder mehr Jahre schön Daten gesammelt hat und das System bspw. crasht. Backup einspielen und bis hierhin ist alles gut. Da sich jetzt aber quasi das Installationsdatum auf zB. 2022 geändert hat, würde der Durchschnitt wg. obiger Automatik dann aber wieder resettet werden (was aber unnötig wäre, da die Daten kpl. vorliegen).
Muss es der User von Hand machen (und eben auch daran denken) und ich schreibe es in die WiKi, ließt es wieder nur die Hälfte (weil das einfach alles zu lang/zu viel wird [geht mir auch so ;) ]). Von der anderen Hälfte wird dann wieder kaum einer daran denken es am 01.01. per Hand korrekt zu resetten (weil das ja auch nur für Installationsjahr +1 gilt).Was wäre das kleinere Übel? Ich tendiere zur Automatik und im Fall des Backups dann eben Pech gehabt...
-
@Negalein, @ilovegym sagte in [Linux Shell-Skript] WLAN-Wetterstation:
PS: :money_with_wings: ;)
Herzlichen Dank euch beiden :sunglasses: :the_horns:
Brauch mal wieder eure Meinung:
Ich kann quasi das Installationsdatum aus dem Ordner-DP ziehen. Bei mir 12.09.2020
Egal wann nun ein User installiert, würde am 01.01. geprüft werden ob "aktuelles Jahr" = "Installationsjahr +1". Wäre bei uns allen am 01.01.2021 jetzt wahr --> dann resette den Durchschnitt (weil ja bei jedem der innerhalb eines Jahres beginnt das erste Jahr quasi "für die Füsse" ist). Am 01.01.2022 und spätere Jahre wäre es immer falsch und die Berechnung, Anzeige etc. würde erfolgen (und stimmen :) ). Soweit, so gut. Problem besteht aber wenn man bspw. 2 oder mehr Jahre schön Daten gesammelt hat und das System bspw. crasht. Backup einspielen und bis hierhin ist alles gut. Da sich jetzt aber quasi das Installationsdatum auf zB. 2022 geändert hat, würde der Durchschnitt wg. obiger Automatik dann aber wieder resettet werden (was aber unnötig wäre, da die Daten kpl. vorliegen).
Muss es der User von Hand machen (und eben auch daran denken) und ich schreibe es in die WiKi, ließt es wieder nur die Hälfte (weil das einfach alles zu lang/zu viel wird [geht mir auch so ;) ]). Von der anderen Hälfte wird dann wieder kaum einer daran denken es am 01.01. per Hand korrekt zu resetten (weil das ja auch nur für Installationsjahr +1 gilt).Was wäre das kleinere Übel? Ich tendiere zur Automatik und im Fall des Backups dann eben Pech gehabt...
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Was wäre das kleinere Übel? Ich tendiere zur Automatik und im Fall des Backups dann eben Pech gehabt...
Ich auch.
Obwohl ich mich sicher zu denen zähle, die darauf vergessen! :grin: -
@Negalein, @ilovegym sagte in [Linux Shell-Skript] WLAN-Wetterstation:
PS: :money_with_wings: ;)
Herzlichen Dank euch beiden :sunglasses: :the_horns:
Brauch mal wieder eure Meinung:
Ich kann quasi das Installationsdatum aus dem Ordner-DP ziehen. Bei mir 12.09.2020
Egal wann nun ein User installiert, würde am 01.01. geprüft werden ob "aktuelles Jahr" = "Installationsjahr +1". Wäre bei uns allen am 01.01.2021 jetzt wahr --> dann resette den Durchschnitt (weil ja bei jedem der innerhalb eines Jahres beginnt das erste Jahr quasi "für die Füsse" ist). Am 01.01.2022 und spätere Jahre wäre es immer falsch und die Berechnung, Anzeige etc. würde erfolgen (und stimmen :) ). Soweit, so gut. Problem besteht aber wenn man bspw. 2 oder mehr Jahre schön Daten gesammelt hat und das System bspw. crasht. Backup einspielen und bis hierhin ist alles gut. Da sich jetzt aber quasi das Installationsdatum auf zB. 2022 geändert hat, würde der Durchschnitt wg. obiger Automatik dann aber wieder resettet werden (was aber unnötig wäre, da die Daten kpl. vorliegen).
Muss es der User von Hand machen (und eben auch daran denken) und ich schreibe es in die WiKi, ließt es wieder nur die Hälfte (weil das einfach alles zu lang/zu viel wird [geht mir auch so ;) ]). Von der anderen Hälfte wird dann wieder kaum einer daran denken es am 01.01. per Hand korrekt zu resetten (weil das ja auch nur für Installationsjahr +1 gilt).Was wäre das kleinere Übel? Ich tendiere zur Automatik und im Fall des Backups dann eben Pech gehabt...
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@Negalein, @ilovegym sagte in [[Linux Shell-Skript] .
Was wäre das kleinere Übel? Ich tendiere zur Automatik und im Fall des Backups dann eben Pech gehabt...
Automatisch ist immer gut 👍👍😁😁
-
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@Negalein, @ilovegym sagte in [[Linux Shell-Skript] .
Was wäre das kleinere Übel? Ich tendiere zur Automatik und im Fall des Backups dann eben Pech gehabt...
Automatisch ist immer gut 👍👍😁😁
So hab auch ein Problem mit dem Statistik script. Es sollte alles angepasst sein aber es werden keine Werte gesetzt. Angelegt wurde alles es wird aber zur festgelegten Zeit nichts reingeschrieben.
Im Log:javascript.0 2020-10-17 07:05:00.010 warn (460) TypeError: Reduce of empty array with no initial value at Array.reduce (<anonymous>) at Math.sum.temps [as sum] (script.js.common.wetterstation-statistik:152:53) at Object.cb (script javascript.0 2020-10-17 07:05:00.009 warn (460) States system pmessage messagebox.system.adapter.javascript.0 {"command":"query","message":{"result":[[],[],[]],"ts":1602911100007,"error":null},"from":"system.adapter.influxdb.0","callback":{"mEdit: sehe gerade ich muss MANUELL die Influx Loggings erstellen ? ? Welche Werte den alle ? Vielleicht kann man das im Wiki ein klein wenig erweitern ? Gibt ja auch Werte von Das Wetter ..
-
So hab auch ein Problem mit dem Statistik script. Es sollte alles angepasst sein aber es werden keine Werte gesetzt. Angelegt wurde alles es wird aber zur festgelegten Zeit nichts reingeschrieben.
Im Log:javascript.0 2020-10-17 07:05:00.010 warn (460) TypeError: Reduce of empty array with no initial value at Array.reduce (<anonymous>) at Math.sum.temps [as sum] (script.js.common.wetterstation-statistik:152:53) at Object.cb (script javascript.0 2020-10-17 07:05:00.009 warn (460) States system pmessage messagebox.system.adapter.javascript.0 {"command":"query","message":{"result":[[],[],[]],"ts":1602911100007,"error":null},"from":"system.adapter.influxdb.0","callback":{"mEdit: sehe gerade ich muss MANUELL die Influx Loggings erstellen ? ? Welche Werte den alle ? Vielleicht kann man das im Wiki ein klein wenig erweitern ? Gibt ja auch Werte von Das Wetter ..
@ChrisXY sagte in [Linux Shell-Skript] WLAN-Wetterstation:
sehe gerade ich muss MANUELL die Influx Loggings erstellen ? ?
Wie sonst? Ich kann schlecht mit einem Javascript für dich im Influx-Adapter klicken ;)
@ChrisXY sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Vielleicht kann man das im Wiki ein klein wenig erweitern ?
Ich bin immer für alles offen, auch Kritik, aber gerade im Wiki steht:
Voraussetzung: laufendes WLAN-Wetterstation Shellscript, laufender Javascript-Adapter im ioBroker, laufende InfluxDB [inkl. logging der benötigten Datenpunkte "Aussentemperatur", "Wind_max" und "Regen_Tag"]
Das ist nicht böse gemeint, aber wie (oder was) soll ich da noch dazu schreiben? Je mehr und länger das wird, desto weniger ließt es der Nutzer. Kenne ich auch von mir, ist also kein Vorwurf an irgendwen. Ich erkläre immer alles gerne, auch ausführlich, aber irgendwo muss auch ich mal eine Grenze ziehen und kann zB. hier jetzt nicht auch noch erklären wie Influx funktioniert. Dann kommt der nächste und fragt wie man Influx installiert, bis wir bei der Installation des ioB angelangt sind. Wenn ich ein Auto kaufe, kann ich auch nicht automatisch Auto fahren ;)
Was natürlich nicht heißen soll, dass ich fehlendes, nicht verständliches oder was auch immer nicht ergänzen oder ersetzen würde. Wenn also einfach überlesen, alles gut, sonst wie oder was soll noch da stehen? -
@ChrisXY sagte in [Linux Shell-Skript] WLAN-Wetterstation:
sehe gerade ich muss MANUELL die Influx Loggings erstellen ? ?
Wie sonst? Ich kann schlecht mit einem Javascript für dich im Influx-Adapter klicken ;)
@ChrisXY sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Vielleicht kann man das im Wiki ein klein wenig erweitern ?
Ich bin immer für alles offen, auch Kritik, aber gerade im Wiki steht:
Voraussetzung: laufendes WLAN-Wetterstation Shellscript, laufender Javascript-Adapter im ioBroker, laufende InfluxDB [inkl. logging der benötigten Datenpunkte "Aussentemperatur", "Wind_max" und "Regen_Tag"]
Das ist nicht böse gemeint, aber wie (oder was) soll ich da noch dazu schreiben? Je mehr und länger das wird, desto weniger ließt es der Nutzer. Kenne ich auch von mir, ist also kein Vorwurf an irgendwen. Ich erkläre immer alles gerne, auch ausführlich, aber irgendwo muss auch ich mal eine Grenze ziehen und kann zB. hier jetzt nicht auch noch erklären wie Influx funktioniert. Dann kommt der nächste und fragt wie man Influx installiert, bis wir bei der Installation des ioB angelangt sind. Wenn ich ein Auto kaufe, kann ich auch nicht automatisch Auto fahren ;)
Was natürlich nicht heißen soll, dass ich fehlendes, nicht verständliches oder was auch immer nicht ergänzen oder ersetzen würde. Wenn also einfach überlesen, alles gut, sonst wie oder was soll noch da stehen?@SBorg Ich bin auch über das loggen gestolpert und mir war eingangs nicht klar ob diese drei DPs ausreichend sind.
Vielleicht kann man das noch etwas deutlicher hervorheben.
Z.B.: Für diese drei Datenpunkte muss das loggen aktiviert werden.....
Oder so ähnlich.
Sonst eine tolle Sache was du da auf die Beine gestellt hast!
Danke dafür!!! -
@SBorg Ich bin auch über das loggen gestolpert und mir war eingangs nicht klar ob diese drei DPs ausreichend sind.
Vielleicht kann man das noch etwas deutlicher hervorheben.
Z.B.: Für diese drei Datenpunkte muss das loggen aktiviert werden.....
Oder so ähnlich.
Sonst eine tolle Sache was du da auf die Beine gestellt hast!
Danke dafür!!!@wendy2702 said in [Linux Shell-Skript] WLAN-Wetterstation:
nicht klar ob diese drei DPs ausreichend sind
na das ist aber etwas anderes, als sich zu wundern, das logging selbst erstellt werden muss. wie sollte das automatisch bewerkstelligt werden? die DP heissen oft bei jedem anders, ok, in dem fall nicht.
bin auch grad am überlegen welche es werden soll. schwanke da zwischen Eurochron EFWS2900 und Froggit HP1000SE Pro.
wird wohl eine bauch entscheidung, oder gibts vor/nachteile? -
@wendy2702 said in [Linux Shell-Skript] WLAN-Wetterstation:
nicht klar ob diese drei DPs ausreichend sind
na das ist aber etwas anderes, als sich zu wundern, das logging selbst erstellt werden muss. wie sollte das automatisch bewerkstelligt werden? die DP heissen oft bei jedem anders, ok, in dem fall nicht.
bin auch grad am überlegen welche es werden soll. schwanke da zwischen Eurochron EFWS2900 und Froggit HP1000SE Pro.
wird wohl eine bauch entscheidung, oder gibts vor/nachteile? -
Ich schreibe die Wiki nicht für mich, sondern für euch. Wenn also etwas nicht ganz eindeutig ist, immer her mit der Kritik/Änderung :)
So besser ?:Voraussetzung: laufendes WLAN-Wetterstation Shellscript, laufender Javascript- und InfluxDB-Adapter im ioBroker, aktiviertes logging per InfluxDB der drei benötigten Datenpunkte "Aussentemperatur", "Wind_max" und "Regen_Tag" (falls diese noch nicht für Grafana oä. schon geloggt werden)
@da_Woody sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Eurochron EFWS2900 und Froggit HP1000SE Pro
Ich habe ja selbst die Eurochron und bin super zu frieden. Bei der Pro kannst du halt weitere Sensoren dazu packen. Würde ich auch gerne unterstützen, nur hat sich wohl der Hardware-Support durch Ecowitt erledigt. Meine Testsamples wollen einfach nicht bei mir ankommen... :(
...und ich habe mich für die automatische Datenpunktresettierung entschieden. Ich gehe von mir aus, und ich vergesse das in x Monaten auch einfach durchzuführen...