[Linux Shell-Skript] WLAN-Wetterstation
-
@crunchip Hehehe, eins haben und eins fehlt sind dann schon zwei
Aber im Prinzip eigentlich egal, denn für die Station ist es eh dann immer um 23:58 Uhr UTC, egal wie viel Uhr es bei uns ist. Es wird wohl keinem auffallen, dass zwischen 23 - 0 Uhr die Jahresregenmenge nicht zu 100% stimmt, bzw. den Wert ohne den aktuellen Tageswert anzeigt
-
Gestern bzw. heute bei dem Sturm kann man den Windwächter mal richtig testen …
hier das mit der Froggit Software:
Was mir auffällt ist die Aktualisierung z.b. die Windgeschwindigkeit IST und Max …
die Wetterstation hat ein Intervall von ca. 16 sek. so kommen die Daten auf dem Original Display an ,
… mit dem Script ( 16 sek eingestellt ) und allen Verzögerungen eingerechnet ist es ungefähr dann bei ioBroker in ca. 90 sek. - 120 sek. aktualisiert. aber dann gerade mit einem kleineren Wert von zb. ca. 2 km/h also weit deutlich weniger.Was sehr interessant ist , das der Wind Max . bei 105.1 km/h im Display liegt , und bei Auslesen und Übergabe an Iobroker 3,5 km/h liegen .
Gibt es hier noch ein Feintuning , damit die Werte vom Wind bzw. von der Anlage schon recht Zeitnah angezeigt werden !?
-
@Glasfaser Ich kann mir schon denken woran es im gesamten liegt
Mach bitte mal ein./wetterstation.sh --debugim Installationsverzeichnis. Dort sollte dann eigentlich bei WS_POLL: 30 stehen.
Das passt aber zur 4000er nicht, denn die sendet im Gegensatz zu den "kleineren" Stationen tatsächlich im 16 Sekundentakt (wie in deiner Config angegeben). Ich hatte aber ganz zu Anfang eine Sicherung eingebaut, die keine Werte unter 30 Sekunden erlaubt (kleinster Sendeintervall). Das ist dann aber bei der 4000er Kontraproduktiv, da sie nun im falschen Rhythmus auf ein Datenpaket wartet und sogar ev. welche nicht empfängt. Die Berechnung habe ich gerade noch mal kontrolliert, die stimmt:
92.9 mph lt. Google 149,508.. km/h
Berechnung per Script: 149,51 km/h (korrekt, denn auf zwei Nachkommastellen gerundet)Dir ist anscheinend "nur" der Spitzenwert flöten (so.) gegangen...
Kommentiere versuchsweise mal in der wetterstation.sh #67 aus:
#if [ ${WS_POLL} -lt "30" ]; then WS_POLL=30; fiSollte sich dann nach dem speichern binnen 1-2 Minuten korrekt synchronisieren; booten musst du nicht.
-
So … danke erstmal ….
Zeit wird dann per ./wetterstation.sh --debug als WS_POLL:16 angezeigt .
Aber viel Unterschied merkt man da nicht .
Der Zeit Intervall / Aktualisierung ist dann eher so : ca. 180 sek, 35 sek., 180 sek. 180 sek. , 35 sek.
Neustart danach durchgeführt , das gleiche.
WS_POLL:8 eingestellt : 120 sek. 35sek. 180 sek.
WS_POLL:1 eingestellt : ditoWas mir auffällt ist die Zeit : 17:44:49 / 17:45:19 / 17:48:49
Sie Sekunden sind immer im Wechsel : 49 , 19 , 49 , 19Gibt es noch etwas ??
-
@Glasfaser sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Was mir auffällt ist die Zeit : 17:44:49 / 17:45:19 / 17:48:49
Sie Sekunden sind immer im Wechsel : 49 , 19 , 49 , 19Das sind genau alle 30 Sekunden. Wahrscheinlich schickt auch die 4000er die Daten nur im 30 Sekundentakt.
Ich habe mir mal die Bedienungsanleitung gezogen und überflogen. Genaues steht nicht drin, aber es sieht so aus als wenn der "Wettermast" fest im 16 Sekundentakt seine Daten an das Display funkt. Das zeigt die Werte dann auch so an. Das Display selbst, die Daten dann aber nur im 30 Sekundentakt ins WLAN schickt.- stoppe mal versuchsweise das Skript mittels
pkill -9 wetterstation.* - dann starte den nc von Hand mittels
nc -lv -p 9999 ( 9999 dein Port ) - wenn ein Datenpaket eingetrudelt ist aktuelle Sekundenanzeige merken und
- gleich wieder den nc starten
Kam das 2. Datenpaket nun nach 16 oder 30 Sekunden? Ich tippe ja auf 30...
- stoppe mal versuchsweise das Skript mittels
-
Werde ich heute Abend testen ...
Wenn der Abstand der Messung / Aktualisierung zu ioBroker 30 Sekunden bleiben würde währe es ja Ok , aber wie schon oben geschrieben varrieren die Zeiten . (180 sek, 35 sek., 180 sek. 180 sek. , 35 sek. oder mal mehr .)
-
@Glasfaser Ist dein Datenpunkt "_Kommunikationsfehler" true (nach ein paar Stunden Laufzeit des Skriptes; beim Start wird er automatisch auf false gesetzt)?
Dieser asynchrone Modus ist "OK" so, denn wenn die Timings zwischen senden der Station und hören des Client-Rechners nicht synchron laufen, macht er quasi munter weiter bis er mal zufällig "hört" wenn der andere gerade "sendet". Laufen beide dagegen synchron, klappt die Übertragung zumindest in dem Zeitryhtmus, in dem auch die Station sendet. Aufbereiten der Daten und an den ioB senden dauert max. 1-2 Sekunden.
Ev. muss ich auch nur das Fenster etwas erweitern, in dem er "hört". Kann ich aber ohne Station halt nur raten...
Aber wenn sie im 30 Sekundentakt sendet, muss zumindest der WS_POLL auch auf 30 stehen. Das andere kriegen wir auch noch hin, ist dann halt etwas rumprobiererei -
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@Glasfaser Ist dein Datenpunkt "_Kommunikationsfehler" true (nach ein paar Stunden Laufzeit des Skriptes; beim Start wird er automatisch auf false gesetzt)?
(Wie blöd ich habe dein Beitrag nicht gesehen ... daher weis ich nicht was vorher war !)
Er ist ist true .... passt auch von der Zeit ,vom absetzen des pkill Befehls.
Nach dem Start ist er false .
Der Abruf ist 16 Sekunden mit nc -lv -p 9999 und bleibt auch vom Abstand/ eintrudeln der Daten.
-
Wird für die Anbindung noch das Display benötigt? Oder fragt das Script die Station direkt ab
-
@eviltrooper Für die oben genannten, ja. Die funken auf 8xx-9xxMHz an das Display und das schickt dann erst die Daten ins WLAN. Das Skript wartet dann auf diese Daten. Also ohne Display leider auch keine Daten, außer es gäbe einen Wettermast direkt mit WLAN.
-
@Glasfaser Ist nicht schlimm mit dem DP, "true" wird er eh nur bei Fehlern, was auch zu deinem Fehlerbild passt. Was mir im Moment noch nicht so klar ist, ist das warum. Ich gebe dem Client 5 Sekunden Zeit zu starten (dauert < 1 Sekunde) und warte dann 10 Sekunden ob ein Datenpaket kommt. Ev. muss ich bei der 4000er wg. des schnelleren Versandes der Pakete von der Vorgehensweise abweichen. Logge bitte mal per History den Zeitstempel für ~10 Minuten mit, ob das wenigstens ein System hat oder eher zufällig ist.
Zumindest kannst du dann theoretisch, wenn es mal läuft, im 16 Sekundentakt aktuelle Werte empfangen. WS_POLL auf 16 ist also korrekt. -
Gehört hier zwar nicht hin aber wie sieht es bei den Stationen mit der sofort Regenerkennung aus. Die soll bei dem Homematic Teil ja nicht soooo toll sein
-
Das ist eigentlich bei allen gleich. "Echte" Sensoren für Regenerkennung nutzen ein anderes Prinzip wie bspw. Leitfähigkeit. Die Wetterstationen müssen erst eine gewisse Regenmenge sammeln bis der Sensor auslöst (zB. weil sie mittels einer Wippe die Regenmenge messen. Die muss aber erst mal voll sein damit sie auslöst).
Ich habe soeben die V0.1.4 Beta released. Javascript beim updaten nicht vergessen, da neuer Datenpunkt "Jahresregenmenge kummuliert". In diesen Datenpunkt könnt ihr dann die bisher aufgelaufene aktuelle Jahresregenmenge eintragen, sofern ihr einen Wert habt. Das Skript wird dann auf 23:58 Uhr UTC getriggert, ließt den aktuellen Jahreswert ein, addiert den aktuellen Tageswert hinzu (der um 0:00 Uhr UTC genullt wird) und schreibt den Jahreswert neu. Dies gilt unabhängig vom Stationstyp. Der Test muss auch etliche Tage laufen, da ich mir nicht sicher bin, ob die neue Funktion ev. mit alten Funktionen kollidiert. Das ist ein Test der nur unter realen Bedingungen (=mit Station) funktioniert
Noch den Trigger per
sudo crontab -ehinzufügen (Verzeichnispfad ggf. anpassen):58 23 * * * /home/iobroker/wetterstation.sh --rain &Durch die feste Vorgabe der Station darf hier der Zeitpunkt nicht frei gewählt werden! Dieser muss auf 23:58 Uhr bleiben
-
Ok, danke...
Also entweder direkt Homematic oder die von Conrad...
Ohne Windrichtung geben die sich beim Preis ja nicht viel -
Arrgh, Mist, Denkfehler...
23:58 Uhr Trigger ist dann CET, was für die Station 0:58 Uhr UTC bedeutet (Sommerzeit dann 1:58 Uhr). Da ist auf jeden Fall der Wert der Station immer schon genulltVergesst die V0.1.4 Beta, dass funktioniert so keinesfalls...
-
@SBorg mal so nebenbei, man muss doch an der Station, Sommer/Winterzeit incl Zeitzone manuell einstellen...(hatte ich nämlich vergessen zu ändern
)übrigens gibts mal wieder ein Software update (WS VIEW)...gerade geladen
-
@crunchip Man merkt so langsam, dass ich im Trüben rumstochere..
Wahrscheinlich ist die Umstellung nur für die Uhrzeit am Display. Trotzdem müsste ich jetzt Winter-/Sommerzeit berücksichtigen, nur wie lange gibt es sie noch...
Ich werde es vom externen Trigger auf einen internen umstellen. Dann wird automatisch um 23:58 Uhr UTC addiert. Dann ist CET/CEST völlig egal. Ich muss dann nur verhindern falls bspw. zwei mal um 23:58 Uhr ein Datenpaket eintrudelt (bei 16 Sek. könnten es sogar drei sein), dass mehrmals für den Tag die Menge aufsummiert wird. Muss ich also noch den "tc" abfragen, ob ber älter als x Minuten ist... -
@SBorg
WS_POLL ist auf 16Hier die Aufzeichnung von der Raspberry ( dort läuft nur dein Skript) , zu Synology wo ioBroker ist :
hier ist die Aktualisierung , jede 30 sek.
12.02.2020 18:05:50 false simple-api.0 2020-02-12 18:05:59.691 12.02.2020 18:05:20 false simple-api.0 2020-02-12 18:05:25.176 12.02.2020 18:03:50 false simple-api.0 2020-02-12 18:03:59.549 12.02.2020 18:03:20 false simple-api.0 2020-02-12 18:03:25.084 12.02.2020 18:01:50 false simple-api.0 2020-02-12 18:01:59.482 12.02.2020 18:01:20 false simple-api.0 2020-02-12 18:01:25.034 12.02.2020 17:59:50 false simple-api.0 2020-02-12 17:59:59.386 12.02.2020 17:59:20 false simple-api.0 2020-02-12 17:59:24.956 12.02.2020 17:57:50 false simple-api.0 2020-02-12 17:57:59.193 12.02.2020 17:57:20 false simple-api.0 2020-02-12 17:57:24.763 12.02.2020 17:55:50 false simple-api.0 2020-02-12 17:55:59.177 12.02.2020 17:55:20 false simple-api.0 2020-02-12 17:55:24.743 12.02.2020 17:53:50 false sql.0 2020-02-12 17:54:54.975hier ein Neustart von der Raspberry um zu sehen ob der Abruf sich ändert :
hier ist die Aktualisierung , jede 60 sek. / 30 sek. / 60 sek.
.12.02.2020 18:19:50 false simple-api.0 2020-02-12 18:19:53.802 12.02.2020 18:19:20 false simple-api.0 2020-02-12 18:19:32.322 12.02.2020 18:18:20 false simple-api.0 2020-02-12 18:18:28.708 12.02.2020 18:17:20 false simple-api.0 2020-02-12 18:17:25.180 12.02.2020 18:15:50 false simple-api.0 2020-02-12 18:16:00.567 12.02.2020 18:14:50 false simple-api.0 2020-02-12 18:14:57.002 12.02.2020 18:13:50 false simple-api.0 2020-02-12 18:13:53.489 12.02.2020 18:13:20 false simple-api.0 2020-02-12 18:13:31.998 12.02.2020 18:12:20 false simple-api.0 2020-02-12 18:12:28.503 12.02.2020 18:11:20 false simple-api.0 2020-02-12 18:11:25.035 12.02.2020 18:09:50 false simple-api.0 2020-02-12 18:10:00.476und nochmal ein Neustart :
hier ist die Aktualisierung , 120 sek. / 60 sek. / 30 sek. / 60 sek.
12.02.2020 18:32:20 false simple-api.0 2020-02-12 18:32:28.679 12.02.2020 18:31:20 false simple-api.0 2020-02-12 18:31:25.186 12.02.2020 18:29:50 false simple-api.0 2020-02-12 18:30:00.645 12.02.2020 18:28:50 false simple-api.0 2020-02-12 18:28:57.053 12.02.2020 18:27:50 false simple-api.0 2020-02-12 18:27:53.538 12.02.2020 18:27:20 false simple-api.0 2020-02-12 18:27:32.101 12.02.2020 18:26:20 false simple-api.0 2020-02-12 18:26:28.615 12.02.2020 18:25:20 false simple-api.0 2020-02-12 18:25:25.135 12.02.2020 18:23:50 false simple-api.0 2020-02-12 18:24:00.539 12.02.2020 18:22:50 false simple-api.0 2020-02-12 18:22:57.034also verschiedene Zeiten….
EDIT :
hier die weitere Laufzeit nach 18:32 Uhr -
@Glasfaser Danke. Ist zwar ziemlich regelmäßig, verstehen tue ich es aber nicht.
Da ich für die kumulierte Jahresregenmenge sowieso Änderungen im Bereich des netcat vornehmen muss, dürfte sich das Problem (hoffentlich) aber auch damit erledigt haben. Die Station kann dann senden wann immer sie lustig ist -
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Umstellung nur für die Uhrzeit am Display.
Zumindest wurde der Datenpunkt Uhrzeit geändert, da ich dann eine Stunde hinterher war.
Und deshalb wahrscheinlich meine Regenmenge um 23.00...
