[Linux Shell-Skript] WLAN-Wetterstation
-
@SBorg wäre ein Ansatz, jedoch, wenn das so wäre, müsste doch das Problem schon immer bestehen bzw hätte schon früher auftauchen müssen.
sollte eigentlich schon so passen
root@IoBroker:~# timedatectl Local time: Do 2020-06-18 13:23:08 CEST Universal time: Do 2020-06-18 11:23:08 UTC RTC time: Do 2020-06-18 11:23:09 Time zone: Europe/Berlin (CEST, +0200) System clock synchronized: yes NTP service: active RTC in local TZ: no -
@crunchip Stimmt und stimmt auch (leider
). Nur will mir da nicht allzu viel einfallen. Selbst wenn ich jetzt extra Debug-Ausgaben einbaue, zeigen die auch nur den Sprung von 23:00 --> 23:58 Uhr, außer der History-Adapter hätte eine Stunde nichts geloggt und just in der Stunde ist auch das Skript "gestorben". Kannst du den Sprung ev. in anderen geloggten Zuständen nachvollziehen?Wie schon gedacht, so gering war die Abweichung dann doch nicht:
(~5h waren bisher mein Spitzenwert, und der gestrige Solarertrag bescheinigt durchaus viele Wolken)V1.3.0 Beta (RC) steht auf GitHub zum testen bereit
Für Nutzer der bisherigen 1.3.0 Beta genügt der Austausch der *.sub und ein
systemctl restart wetterstation
Update von anderen Versionen kpl. Tausch, JS ausführen und *.conf konfigurieren.Changelog: # V1.3.0 / 19.06.2020 - + letztes Regenereignis und Regenmenge # + Fehlermeldung bei falscher WS_ID / ID der Wetterstation # + Sonnenscheindauer + Solarenergie vom Vortag # ~ Änderung/Fix Sonnenscheindauer -
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Kannst du den Sprung ev. in anderen geloggten Zuständen nachvollziehen?
ich logge nur die drei tempData Werte in der History, alles andere läuft in influx,
ansonsten ist mir auch nichts weiter aufgefallenwas ich nicht so ganz verstehe
- Sonnenstunden zählte von 0 wieder los, für Heute/Woche/Monat/Jahr
- Sonnenenergien zählte von 0 wieder los für Heute/Woche --- Monat und Jahr blieben aber leer
wer weiß was da los war, ...Verkettung eines unglücklich und ungünstig gefallenen Zufall´s
und dann kam noch Pech dazu....
mal beobachten, zumindest wie es der Zufall so will, war es ein Wochenwechsel 14/15.06 -
Moin, bei mir mit neuer 1.3.0 *.sub alles unauffällig
-
@Nashra Danke für die Info
Die Nullstellung um Mitternacht funktioniert jetzt auch korrekt. Um 23:58 Uhr wurde zwar korrekt auf "0" resettet, dann hat er aber 2-3 Impulse gezählt und ab kurz nach Mitternacht dann ~1-3 Minuten Sonnenscheindauer attestiert...
...ja, macht den Bock jetzt auch nicht fett aber Fehler müssen auch nicht sein...@crunchip Das ist zumindest in soweit einleuchtend, dass du alle Werte (Tag, Woche, Monat, Jahr) verloren hast. Da Tages- und Wochenwechsel an stand, wurden die korrekt auf "0" gesetzt und es kam zum Datensatz "0 0 [Nix/Leerzeichen] [Nix/Leerzeichen]". Wenn das Morgen (Wochenwechsel) ev. wieder auftritt, könnte es uU. ein Cronjob sein...
Ich warte jetzt noch 1-2 Tage ab, dann geht die 1.3.0 Beta (RC) als Release
-
Soeben die V1.3.0 auf GitHub released. Keine weiteren Änderungen seit V1.3.0 Beta (RC), Update also nicht unbedingt nötig falls man diese schon einsetzt.
Update von einer Vorgängerversion: alles ersetzen, JS ausführen (neue Datenpunkte), *.conf konfigurieren und mittels
[sudo] systemctl restart wetterstationden Dienst neu starten. -
@SBorg Ich wollte es gerade mit einer froggit HP1000SE Pro probieren. Als Linux Device habe ich einen Intel NUC auf dem u. a. Deconz (Proxmo VM Debian) drauf läuft der es dann wieder zu einem anderen Intel Nuc wo der ioBroker (Proxmox VM Ubuntu) drauf läuft weitergeben sollte... Verbindung Deconz zu ioBroker hat eigentlich damals auf anhieb funktioniert.
Bei WU eingebunden ist die Wetterstation und zeigt auch brav die Werte an. Bei deiner Anleitung bin ich bis zu dem Ausführen im debug Modus gekommen.... Allerdings bringt er da in Endlosschleife nur:
Ports habe ich schon 80, 9999 1026 ect. probiert... Leider ohne Erfolg.
Hast du vielleicht eine Ahnung woran das liegen könnte?
-
@Stormbringer, mit Proxmox VM Debian hatte ich auch Probleme, konnte keine Daten empfangen. Irgendwo ganz weit oben in diesem Thread gab es die Lösung zu meinem Problem.
-
Nein, glaube nicht, sieht nach einem neuen Problem aus. @crunchip bei dir hatte er Probleme mit dem Port/nc. Bei @Stormbringer macht mich Zeile 100 get_DATA.... stutzig. "get_Data" ist eine Funktion aus der *.sub und kann anscheinend nicht gelesen werden. Bevor er da aber hinkommt, hat er schon den Versionscheck erledigt, nur konnte er da die Datei noch lesen!?!
Funktioniert den ein./wetterstation.sh -v:
Versuch dann mal angehängte Datei, da habe ich das "function" entfernt. Braucht Linux nicht, stört aber auch nicht, oder doch gerade bei deiner Installation... (und stand genau bei get_Data...)
wetterstation.sub -
@SBorg Wollt ich auch gerade schreiben, dass ich die Fehlerbehebung von crunchip schon probiert habe aber nicht weiter verfolgt habe, weil die Fehlermeldung anders aussieht.
Danke für die neue Datei aber da bringt er leider die selben Fehlermeldungen.
Falls es interessant ist, nc -lv -p bringt folgende Ergebnis:
-
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
./wetterstation.sh -v
Hab jetzt mal als Spaß -v probiert da meckert er aber. LS habe ich auch noch ausgeführt damit man sieht, dass die Datei da ist.
-
@Stormbringer Ich ahne das Problem...
Benenne bitte mal dein Verzeichnis in WLAN_Wetterstation oä. um. Ich vermute mal, dass das Leerzeichen im Verzeichnis stört. Hatte wohl noch keiner eines im VerzeichnisEDIT : liegt am Leerzeichen. Kannst auch von GitHub die V1.3.1 der wetterstation.sh zum testen laden, damit sollte es dann gehen
-
@SBorg Danke das wars
Daten bekomme ich leider aber noch immer nicht rein. Habe oben schon einmal den Fehler "Kommunikationsfehler! Stimmt die WS_ID in der Konfiguration mit der der WS View-App überein?" gefunden aber das "?" im Dateipfad von der App habe ich eigentlich drinnen. Die Stations IDs von App und Config sind auch gleich. Simple API Adapter beim Broker hat Port 8087. Trotzdem kommt: -
Hi,
sieht nach einem Netzwerk-/Routingfehler aus. Du hast den ioB mit SimpleAPI auf 10.1.1.3 Port 8087 konfiguriert. Den ruft das Script dann auch auf, bekommt aber eine andere IP zu Gesichto-frost-prox.fritz.box [10.1.1.2] 8087 (?) open
Dort wird wohl dein ioB nicht drauf laufen, deswegen auch o-frost-prox.fritz.box [10.1.1.2] 8087 (?) open, normal wäre bspw.
Connection to 192.168.1.30 8087 port [tcp/*] succeeded! -
@SBorg Die IP und der Port stimmen aber leider zu 100 %. Habe keine Ahnung wo er sich fritz.box da herzieht. Fritzbox wäre die IP Nummer 10.1.1.1
telnet Befehl auf dem Zwischen-Linux-Device bringt folgendes, wenn ich den Broker anpinge:
Wenn ich es richtig interpretiere ist doch dann die Verbindung ok oder? Kann es sein, dass er die ID von der Wetterstation nicht findet, weil ich nirgends was gefunden hab ein Passwort oder IP der WEtterstation in die Config einzugeben?
-
@Stormbringer Jetzt ja, du hattest aber mal IPP: 10.1.1.3:8087
Deswegen dürfte jetzt zumindest die Netzwerkkonfiguration stimmen
Passwort wird eh nicht benutzt, nur ohne eine Eingabe schickt das Display keine Daten.@Stormbringer sagte in [Linux Shell-Skript] WLAN-Wetterstation:
weil ich nirgends was gefunden hab ein Passwort oder IP der WEtterstation in die Config einzugeben?
Meinst du in der App oder im Skript? Die ID befindet sich in der wetterstation.conf unter WS_ID= und ist case sensitiv, muss also identisch zur Eingabe der Station ID in der WS View-App sein.
-
@SBorg ja erwischt, hab die IP Nummer vorsichtshalber geändert fürs öfftliche posten und mich vertippt
aber braucht man bei internen IPs glaub ich gar nicht..Meinte in der config... Die Station ID ist in der config aber die selbe wie in der Starion, also die Nummer die ich bei der WU Registrierung bekommen habe. Hast du dann noch ne Idee?
-
@Stormbringer Ich sehe ALLES
Ist ja auch nicht schlimm, Hauptsache es funktioniert (dann mal...)
Die ID kannst du selbst vergeben, denn du schickst ja nicht an Wunderground, sondern über die Einstellung lokal an einen Rechner in deinem Netzwerk. Sollte zwar auch mit der Wunderground-ID gehen, nimm aber mal was einfaches wie "Daheim".
Ob die Kommunikation Station --> PC funktioniert kannst du mal mit./wetterstation.sh --datatesten. Da sollte nach kurzer Zeit ein kpl. Datenpaket der Station empfangen werden. -
@SBorg Mag er leider auch nicht mit "Daheim"
--data bringt:
Und weil du es merkst, ich hab spaßhalber den Port auf 1026 geändert g
Aber so wie es scheint mit meinen beschränkten Linux Kenntnissen ist eher der Port von der Wetterstation zu oder? Aber wie macht man den auf?! Meine Fritzbox hat noch nie innerhalb vom Netzwerk was blockiert...
-
@Stormbringer Ob das Display auf ein telnet reagiert kann ich dir ad hoc nicht beantworten. Aber ich glaube du hast "einfach" ein netcat "nc" - Problem. Den gibt es in der "traditional"-Version (die funktioniert nicht korrekt) die von einigen Distris eingesetzt wird, und in der "openbsd"-Version (die ist getestet und funktioniert).
Installiere also mal versuchsweise netcat-openbsd, der läuft danach wieder einfach unter "nc". IMHO funktioniert dann auch alles weitere wie bspw../wetterstation.sh --debugWenn es jetzt laufen sollte, muss ich dies noch im Wiki erwähnen, zumal ich auf GitHub genau dazu aktuell einen Issue hatte, der sich damit lösen ließ
...und ja, IPs im Heimnetz braucht man nicht maskieren. Nutzt dem Hacker so nichts, und wenn er "einbrechen" konnte und sich im Heimnetz befindet, bekommt er recht einfach die IPs sowieso raus
