[Linux Shell-Skript] WLAN-Wetterstation
-
@HerrKlaus sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ist der Money Pool schon geschlossen?
Habe ich gerade ca. 1 Stunde vorher aufgelöst, da ich die Conrad-Rechnung damit ausgeglichen habe (kannst dich aber auch ggf. per Chat bei mir melden). Einer Unterstützung für weitere Hardware-Modifikationen wäre ich nicht abgeneigt, nur müsste man zuerst klären ob das gewünscht ist. Ich werde es tun, brauche aber keine zusätzliche Arbeit hineinstecken wenn es sonst keiner möchte
Deswegen bzgl. der Hardware-Erweiterung weiter hier: https://forum.iobroker.net/topic/23147/projekt-diy-smarte-wetterstation/14
-
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
würde ich es wieder hinzu addieren usw.
warum wieder, das ist genau das was ich nicht verstehe,
man definiert einen Zeitbereich, in diesem Zeitbereich(letzten 60sec vom Tag), einmalig den Tageswert zur Gesamtsumme addieren.
Meiner Meinung spielt es doch keine grosse Rolle ob man da ne Minute "zu früh" den Wert schreibt.
Wie oft kommt es vor, das genau zu diesem Zeitpunkt es aus Eimern gießt?
Die "Jahresmenge" dient doch mehr oder weniger eh nur als eine Art Richtwert, denn so genau misst eine solche Station eh nicht.
Hatte es so verstanden, das der (Zeitstempel/Uhrzeit) der Station in der Abfrage mitgesendet wird, (also die Uhrzeit wie sie in der Station eingestellt ist), dann wäre es doch wurscht ob sie 2 Minuten vor oder nach geht. man definiert doch dann nur : addiere einmalig Wert zwischen 23:59 und 0:00 und das ist der Zeitraum bevor die Station den Wert auf Null setzt. Einzige Bedingung Abfrageintervall muss kleiner 60sec, sein, also so das mindestens eine Abfrage in der letzten Minute gesendet wird.Oder lieg ich jetzt mit meiner Denkweise völlig daneben?
-
@crunchip Ne, nicht völlig daneben
Du musst nur eine klare Trennung vornehmen. Du bist auf der "Anwenderseite", ich auf der "Entwicklerseite". Was sich jetzt vielleicht zuerst mal recht hart anhört, sind aber tatsächlich zwei unterschiedliche Dinge.
Du kannst mit Daten und Voraussetzungen arbeiten die ich nicht habe. Du weißt dein Abfrageintervall, ob deine Uhrzeit stimmt, hast Daten vorliegen...
Ich kenne nicht das Intervall der Anwender, dass kann von 16 Sekunden bis xx Minuten reichen. Geht deren Uhr richtig, (noch) Sommer-/Winterzeit, habe nur einen Datensatz der Wetterstation vorliegen usw. Auf all das muss ich reagieren.
So gesehen ist deine Denkweise völlig richtig, aber leider nur aus "Anwendersicht"."Meine" Herangehensweise (+ "wieder"
) ist zwar ähnlich, aber halt doch anders:
wg. dem "wieder" bzw. mehrmals addieren, machen wir es erst mal falsch...Um die Systemlast zu minimieren, möchte ich nur zu bestimmten Zeiten eine "Regenberechnung" durchführen. Um Sommer-/Winterzeit und eine nicht korrekt gehende Uhr abzufangen, prüfe ich zuerst die Systemzeit des verarbeitenden Rechners (=der auf dem das Skript läuft). Ist es 23:50 Uhr - 0:00 Uhr, 0:50 - 1:00 oder 1:50 - 2:00 soll der Regenpart überhaupt nur stattfinden.
23:49:30 - nix passiert
23:50:00 - Regenberechnung durchführenJetzt kommt der 2. Teil. Egal wie nun die genaue (oder eben nicht) Uhrzeit der Station ist, prüfe ich ob es 23:58 oder 23:59 Uhr auf der Station ist, denn nicht "unsere" Zeit ist maßgeblich, sondern die der Station, da sie aus "ihrer" Sicht ja um 0:00 Uhr den Tageswert nullt.
Passt jetzt nicht, also passiert vorerst auch nix...23:51...
23:52...
...
23:57:30 - bei der Station ist es jetzt, weil sie etwas vorgeht, zB. 23:58:03Ok, 23:58 = 23:58 wir holen den Jahreswert vom ioB, addieren den Tageswert auf und schreiben den Wert wieder in den Jahreswert. Soweit eigentlich alles Ok.
23:58:00 - (Station nun 23:58:33) 23:58 = 23:58 wir holen den Jahreswert vom ioB, addieren den Tageswert auf und schreiben den Wert wieder in den Jahreswert. Nicht Ok, denn jetzt addieren wir zum zweiten Mal den Tageswert auf.
...und das passiert jetzt noch 2x (wenn einer zB. 20 Sekunden Intervall hat sogar 6x usw.)Deswegen der "richtige" Weg per LC-Timestamp. Beim 1. Treffer oben um 23:58 Uhr schreibe ich ja einen neuen Jahreswert in den DP. Bevor ich das tue, prüfe ich jetzt aber das Alter des LC-Timestamp. Der müsste dann vom letzten geschriebenen Vortag so um die 24 Stunden alt sein. Damit man ihn ändern kann (zB. beim erstmaligen setzen auf einen bis dato aktuellen Jahreswert wenn man mit dem Skript startet) und hinsichtlich der Sommer-/Winterzeitproblematik nehme ich nur 1 Stunde.
Ist der LC Jahresregenmenge_kumuliert also älter als 1 Stunde, schreibe ich den neuen Wert hinein.
Beim nächsten Datenpaket schlägt aber die Prüfung fehl, denn der LC ist nun genau so alt wie das Abfrage-Intervall des Users (also zB. 30 Sekunden beim ersten Durchlauf, 60 Sekunden beim 2. usw.). Ich addiere also kein 2. - n. mal den Tageswert auf.
Also wird der Tageswert nur genau 1x aufaddiert, egal wie oft ich die Routine (= Poll-Intervall des Users) aufrufe. Somit umgehe ich Zeitdifferenzen, und was eigentlich viel wichtiger ist, keinerlei Datenverlust durch Kommunikationsfehler der Station. Hat der User bspw. 30 Sekunden eingestellt, habe ich bei 2 Minuten 4x die Möglichkeit ein funktionsfähiges Paket auszuwerten.Ich hoffe das war nicht zu technisch und einigermaßen verständlich
Du siehst, ich muss "einfach etwas mehr" berücksichtigen als du
-
@SBorg hier der output:
root@iobroker:/opt/iobroker# which cron /usr/sbin/cron root@iobroker:/opt/iobroker# ps -aux | grep cron root 8497 0.0 0.0 12788 964 pts/0 S+ 23:24 0:00 grep cronBin leider kein linux Experte, sieht aber so aus also ob cron nicht läuft!?
-
@rollerfreak2 Sieht nicht nur so aus
Um sicher zu gehen:service cron status(ev. sudo davor)
zum starten:service cron start(ev. sudo davor)Falls er nach einem reboot wieder nicht startet (wovon ich ausgehe):
update-rc.d cron defaults(ev. sudo davor) -
@rollerfreak2 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
ich bin der Anleitung gefolgt und soweit funktioniert auch alles,
Was mich wundert ... das es bei dir auf anhieb geklappte hat , da du auch nochdazu im ioBroker Verzeichniss arbeitest .
Ich habe auch eine Synology und bin schon bei bc und nc gescheitert , deshalb habe ich ohne viel zu überlegen eine Raspberry dafür genommen .
Wie hast du es denn gelöst ... vielleicht komm ich mit dem Cron dann auch dahinter -
-
Kaum möchte ich mal was draußen machen, ist seit 3 Tagen Dauerregen, Schauer und Strumböen angesagt. Ist ja klar...
Also habe ich die Wetterstation mal Indoor in Betrieb genommen. Tja, simulieren ist halt doch etwas anderes als reelle Daten.
Einen Fehler in der Datenkommunikation entdeckt, da muss ich mir was überlegen...
...und die kumulierte Jahresregenmenge ist mir nun auch klar warum es nicht funktioniert. Muss ich "einfach" nur ändern -
@SBorg
Ich denke wenn erstmal Deine eigene Wettervorhersage steht gehört dass der Vergangenheit an,....
ich hab hier übrigens voll Sonne ...
und mein Geburtstag naht auch ..... -
Leider verheißt Freitag der 13. nichts gutes
Ich muss euch leider mitteilen, dass die Arbeiten an der V0.1.4 mit sofortiger Wirkung eingestellt sind und es diese Version nicht geben wird...Erstmal sacken lassen und in 5 Minuten weiter lesen...
SBorg proudly presents V1.0.0 steht auf GitHub bereit
Es ist zwar kein offizielles release (bisher) aber auch weit über eine Beta hinaus. Kumulierte Regenmenge funktioniert nun auch, dazu noch einen Fehler in der "Kommunikationsunit" behoben. Pauschal kann man nun alle 16 Sekunden (schneller sendet die Station nicht) ein Datenpaket empfangen. Einen Wermutstropfen hat es allerdings. Obwohl meine Signalstärke und sonst alles Tipp-Topp sind, kommen von 10 gesendeten Paketen nur ~7-8 an. Warum die Station stellenweise einfach mal ein Paket überspringt konnte ich nicht eruieren. Sie sendet im eingestellten 16 Sekundentakt, dann überspringt sie ohne ersichtliches Muster mal ein Paket und sendet dann 16 Sekunden später wieder korrekt eins?!?
Daran kann ich leider nichts ändern, denn wenn das Display schon nichts sendet, habe ich auch nichts zum auswerten...Warum Abschied von der V0.1.4 und hin zur V1.0.0?
Zum einen weil die Version dann Stand Heute alles hat was möglich/gewünscht wurde und (hoffentlich) fehlerfrei läuft. Zum anderen ich eine maßgebliche Änderung eingeführt habe. Die wetterstation.conf ist nun wirklich nur eine Konfigurationsdatei. Wenn hier nichts neues hinzukommt an Parametern, genügt es dann einfach nur die "sh" und/oder "sub" auszutauschen. Womit auch ersichtlich ist, dass mit der V1.0.0 nichts zu Ende sein mussZum Update also sh, sub und conf ersetzen (js ist unverändert zur V0.1.4, beim Update von V0.1.3 auf V1.0.0 muss aber die js ebenfalls ersetzt und ausgeführt werden).
Freue mich auf euer Feedback und da das Wetter endlich mal passte:
Da ich keinen kurzen Mast mit geringer Ausladung fand, wurden es einfach zwei Rohrschellen mit Stockschrauben, ein imprägnierter Holzstab, der in dem kurzen beigelegten Rohr steckt und mittels einer Schraube gegen verdrehen gesichert wurde. So komme ich ohne Leiter an den Regentrichter und kann so auch die Batterien wechseln
...ein letztes mal Danke dafür. Ich weiß nicht wie viel Zeit ich verbrannt habe bzw. noch verbrannt hätte, um die Fehler zu finden. Auch wenn gut 90% der Entwicklung nur aus dem Kopf heraus stattfand, muss ich dennoch gestehen, es ist was ganz anderes "live" daran zu arbeiten als nur zu simulieren. -
@SBorg Schreck lass nach
und freu mich zu lesen, das es nun voran geht
Für deine letztens ausführliche technische Erklärung nochmals Danke, wollte eigentlich daraufhin auch antworten, nachdem ich mir 3 Tage lang den Kopf zerbrach, wie man das am besten lösen könnte, mit der Jahresregenmenge..Glaub, hatte viermal nen riesen Text geschrieben und doch immer wieder gelöscht, da meine Idee/Gedanken, es richtig umzusetzen, nicht zu Ende gedacht waren
Werde die neue Version dann heute gleich mal testen.Edit: was ich noch fragen wollte, (hatte ich auch schon in der Vorherigen Version)
javascript.0.Wetterstation._Kommunikationsfehlerbleibt auf true, sollte das nicht auf false wechseln?
-
@crunchip sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Schreck lass nach
Wären wir ~2.5 Wochen weiter, hätte ich es ev. sogar mal paar Stunden so im Raum stehen lassen...
Ich habe es bereits gestern umgesetzt und heute Nacht selbst probiert. Eigentlich ist es ziemlich easy, wenn man es halt tatsächlich sieht und es sich nicht ausdenken muss wie es ev. ist.
Das Grundkonzept ist noch geblieben, nur die Parameter haben sich etwas geändert. Tatsächlich sucht sich das Display per NTP-Server immer die aktuelle Zeit. Dadurch brauche ich keine großartigen Zeitdifferenzen einkalkulieren oder auf Sommer-/Winterzeit zu achten. 0:00 Uhr ist 0:00 Uhr + da setzt er die Tagesmenge auf 0. Also frage ich ähnlich deinem Blockly ab 23:58:00 - 23:59:59 ob der Zeitstempel LC von der "kumulierten Regenmenge" älter als eine Stunde ist.
true: (es wurde also noch nichts aufaddiert), hole alten Wert, addiere aktuellen Tageswert hinzu, schreibe neuen Jahreswert (+damit erhält der LC den aktuellen Zeitstempel = ist beim nächsten Datenpaket eben keine Stunde alt)
false: mache nix (der Tageswert wurde für heute schon aufaddiert)Das hat halt den Vorteil, dass ich je nach eingestelltem Zeitintervall des Users nicht auf ein Datenpaket "hoffen" muss, sondern einfach mehr Zeit habe eines zu bekommen. Bei 16 Sekunden Intervall und 2 Minuten Dauer wären das 7-8 Pakete, bei 30 Sekunden immer noch 3-4 Pakete und bei 60 Sekunden zumindest noch 1-2 Pakete. Da wird schon ein gültiges kommen/dabei sein.
Ich hätte natürlich auch einfach stur um 23:58 Uhr den Datenpunkt "Regen_Tag" auslesen können und einmalig einfach zum Jahreswert hinzu addieren können. Das wäre der Notfallplan gewesen, da ich so keinen Programmierfehler mehr sah....und gerade zu deinem EDIT: das ist dem Kommunikationsfehler geschuldet, denn da gingen tatsächlich öfters Datenpakete flöten
Ist jetzt aber gefixt und habe ich auch in Grafana eingebaut:
-
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Wären wir ~2.5 Wochen weiter
Du Schlitzohr
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
gingen tatsächlich öfters Datenpakete
das bleibt aber immer auf true und den Wert von
- Zeitstempel
- letzte Änderung
verstehe ich nicht, hatte ja vorhin(ca. 16Uhr) frisch die neue Version installiert und Iobroker neu gestartet
übrigens, wie bekommst du das in Grafana so hin, ich logge zwar den Datenpunkt mit, aber ich bekomm keine Zeichen rein.
hatte es mit single stat und Value Mappings probiert -
@crunchip sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Du Schlitzohr
Ev. hast du das Skript 2x laufen? Beim starten sollte er es immer auf false setzen. Macht er auch und funktioniert wie es soll:
Mal sehen ob noch jemand selbiges Problem hat.@crunchip sagte in [Linux Shell-Skript] WLAN-Wetterstation:
hatte es mit single stat und Value Mappings probiert
Damit habe ich es auch realisiert, nur habe ich per "alias" einen Datenpunkt erzeugt und true/false auf 1/0 umgesetzt.
Wetterstation.json -
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Macht er auch und funktioniert wie es soll
bei mir nicht, habe den Datenpunkt ja geloggt
oberhalb der roten Markierung das alte script,
ab der roten Markierung läuft das neue script,
ab der blauen, hab ich den den Wert manuell auf false gesetzt.man sieht auch, das ab Uhrzeit18:34:47.848 kein simple-api mehr geschrieben wird, nur noch die automatischen alle 1800 sec
-
-
ich hab den Datenpunkt mal gelöscht und neu angelegt, immer noch das gleiche.
Danach habe ich mal das script gestoppt und wieder gestartet, jetzt bekomm ich nicht mal mehr Werte.
Iobroker neu gestartet, Wetterstation kurz vom Strom genommen, keine Werte.Einzigte was heute geändert wurde, das Script auf v1.0 und ein Update der App war heute
Edit:
in Putty eingegeben./wetterstation.sh --debugkeine Wertepkill -9 wetterstation.*nc -lv -p 55555Werte kamen./wetterstation.sh --debugkeine Werte
in der Proxmox Konsole, iobroker VM
./wetterstation.sh --debugno connection fortlaufend
ioBroker neu gestartet, läuft nun wieder
geloggter Datenpunkt zeigt, genau einmal zum Scriptstart ein
falsespringt dann um auftrue- Liste aktualisiert,
einmal wird geschaltet um 2020-03-14 00:02:01.336
false true simple-api.0 2020-03-13 22:32:09.799 true true simple-api.0 2020-03-13 22:32:14.947 true true influxdb.0 2020-03-13 22:35:22.514 true true simple-api.0 2020-03-13 23:05:22.521 true true simple-api.0 2020-03-13 23:35:22.522 false true simple-api.0 2020-03-14 00:02:01.336 true true simple-api.0 2020-03-14 00:02:06.555 true true simple-api.0 2020-03-14 00:32:06.558 true true simple-api.0 2020-03-14 01:02:06.560 true true simple-api.0 2020-03-14 01:32:06.561 ... -
Moin, habe genau das gleiche Problem wie @crunchip . Gewechselt auf 0.1.4 und es läuft erstmal wieder.
-
Vorweg: etwas ist bei euch nicht so wie es sein sollte
Aber es liegt wohl auch ein Fehler im Gedankengang vor wie der DP "Kommunikationsfehler" genau funktioniert:
- beim Start des Skriptes wird er einmalig auf false gesetzt
- wenn alles korrekt läuft tut sich jetzt gar nichts mehr, er wird auch nicht aktualisiert (*)
- konnten 5 Datenpakete(**) nicht empfangen werden, wird er einmalig auf true gesetzt
- mehr passiert da nicht
(*)hier liegt wohl das Missverständnis. Aber warum sollte ich diesen alle xx Sekunden aktualisieren? Müllt nur das System unnötig zu, um dann was genau zu machen (außer mitzuteilen "habe keinen Fehler"
)? Schließlich ruft doch auch keiner jeden Kilometer in seiner Autowerkstatt an, nur um mitzuteilen, dass das Auto noch fährt. Ich melde mich erst wenn was nicht funktioniert... (oder auch nicht, bin im ADAC ) Genau so verhält es sich hier: keine news sind good news. Ich melde mich erst mit true wenn ein Fehler auftritt. So kann ich auch mit wenig Daten in die influx loggen: nur auf Änderung + alle 12h mal einen Wert schreiben (sonst läuft ggf. Grafana ins Leere mit "No Data")
(**) egal wann sie auftreten, es gibt keinen Unterschied ob 5x hintereinander, oder insgesamt 5 Fehler in x Stunden. Da bspw. um 0:02 Uhr per cronjob das Skript beendet wird, wird zu diesem Zeitpunkt auch der Zähler wieder auf 0 gesetzt. So führen gelegentliche Fehler nicht gleich zu einer Anzeige. Erst "schwere" Fehler wie zu geringe Empfangsleistung, leere Batterien etc. führen dann zu einer Fehleranzeige.Sieht dann bspw. so aus (als "alias" geloggt wg. Anzeige in Grafana):
Deswegen wäre
false true simple-api.0 2020-03-14 00:02:01.336völlig Ok, was aber nicht sein darf ist der 5 Sekunden später auftretende:
true true simple-api.0 2020-03-14 00:02:06.555So schnell ist das Skript nicht. Es muss mindestens 16 Sekunden warten (genau genommen sogar 2* 16 + 6 Sekunden). Das wäre aber ein Fehler. Es kann also frühstens nach (2*16+6)*5 = 190 Sekunden auftreten.
Fallen mir nur zwei Szenarien ein.- nc (ev. falsche Version, in der V1.0.0 werden zwei neue Parameter benutzt)
- das Skript läuft mehrmals
Leider hat der "nc" keine Versionsinfo. Kann das euer nc:
Sicherheitshalber das Skript mittels
pkill -9 wetterstation.shbeenden. Bei ".*" ist mir aufgefallen, dass es nicht immer beendet wird. Nochmals mittelsps -aux | grep wetterstation.shprüfen, dass es wirklich nicht mehr läuft!
Das würde genau zu @crunchip Fehlerbild passen. Erst keine Werte, da das Skript schon auf dem Port läuft, dann bekommt die 2. Instanz keinerlei Daten.btw: Jahresregenmenge hat wieder funktioniert, scheint also zu funktionieren
-
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
das Skript läuft mehrmals
ist doch normalerweise gar nicht möglich, da ich die Maschine(VM) neu gestartet habe. ich habe auch nur eine Version installiert. dementsprechend würde ich sagen,
2. fällt da flach, muss also etwas anderes sein@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Kann das euer nc:
wie macht man das?
-
@crunchip sagte in [Linux Shell-Skript] WLAN-Wetterstation:
da ich die Maschine(VM) neu gestartet habe
= bei dir iobroker? Wenn du also schreibst "iobroker neu gestartet" ist dies nicht der/unser iobroker sondern deine VM
Schau mal was bei gestopptem Skript mittels./wetterstation.sh --datakommt. Ist dies ein Datenpaket oder irgendeine Meldung?
