Wetterstation: WEATHERMAN-Controller von Dr. Stall

Begonnen von bubu185, 22 März 2018, 18:59:56

Vorheriges Thema - Nächstes Thema

GU!DO


mgfhem

Gebe es ungern zu, aber genau das war auch mein Problem. Seither alles top. Bitte beachte noch die Änderung in der Zeile Windrichtung. Grüße

GU!DO


plinepa

Habe gerade meinen Weatherman nach der Anleitung in diesem Thread auf PUSH und das Log2Syslog umgestellt.

Funktioniert gut  :)

Nur das userreading für den Luftdrucktrend habe ich erweitert um bitte_warten und stark_fallend.

luftdrucktrend { my $w=ReadingsVal($name,"MSG_ESP-5F5A5B.fritz.box",0) ;; $w =~ s/.*"w_barotrend".*?"value":"(fallend|stark_fallend|stabil|steigend|bitte_warten)".*/$1/ ;; $w },


Der WM liefert nach einem RESET am Anfang scheinbar bitte_warten.
Das stark_fallend kam dann kurz danach.

Der WM läuft bei mir mit V138


SVLoneStar

Hallo - auch ich habe heute einen Weatherman (v138) zusammengebaut. Web-Interface geht, dort kommen auch Werte rein.
Allerdings kommt bei FHEM nix an.
Habe ein Log2Syslog-Device (v5.12.0) aufgesetzt wie beschrieben (raw, userReadings, ...), aber im Event Log kommen erst keine Daten des Weatherman an. Port ist beim Log2Syslog-Device auf 1885 gesetzt, dieser Port wird jedoch bei einem
sudo lsof -i -P
nicht angezeigt. Das Device zeigt auch nur 'initialized' an...oder muss das so? Reopen ändert daran nichts.

Weatherman wurde mit ?param:12:1885 konfiguriert.

Was mache ich falsch? Danke für jeden Tip!

Beste Grüße,
Stefan
FHEM 21222 auf Gigabyte NUC, CubieTruck & RasPis (Test)
CUL 868MHz, nanoCUL 868MHz, nanoCUL 433MHz, JeeLink Clone, JeeLink Classic, HM-CFG-USB2, Rademacher
Devices: FHT, FS20, KS300, MAX, IT, HMS100, LaCrosse, PCA301, Revolt, HomeMatic, ESA2000, UNIRoll, Sonos, Duofern, Tasmota, MySensors

plinepa

Zitat von: SVLoneStar am 05 Mai 2020, 19:25:01
Hallo - auch ich habe heute einen Weatherman (v138) zusammengebaut. Web-Interface geht, dort kommen auch Werte rein.
Allerdings kommt bei FHEM nix an.
Habe ein Log2Syslog-Device (v5.12.0) aufgesetzt wie beschrieben (raw, userReadings, ...), aber im Event Log kommen erst keine Daten des Weatherman an. Port ist beim Log2Syslog-Device auf 1885 gesetzt, dieser Port wird jedoch bei einem
sudo lsof -i -P
nicht angezeigt. Das Device zeigt auch nur 'initialized' an...oder muss das so? Reopen ändert daran nichts.

Weatherman wurde mit ?param:12:1885 konfiguriert.

Was mache ich falsch? Danke für jeden Tip!

Beste Grüße,
Stefan

Hatte da gestern am Anfang auch ein Problem damit.
Nach dem define des Log2Syslog lief der Prozess mit Port 1514 und UDP.
( Konnte ich im FHEM-Logfile sehen )

Danach habe ich dann den Port und das Protokoll geändert und auch mit reopen probiert.
Ging leider nicht.

Erst nach einem Shutdown restart stand dann im Log der korrekte Port und Protokoll.
Dann kamen die Daten auch schon reingerauscht.

Gruß
plinepa

SVLoneStar

#112
Danke Dir, plinepa!!!

Ich hab's gerade wie folgt hinbekommen, dass Daten in FHEM ankommen:
- beim Log2Syslog-Device explizit 'attr xyz disable 0' gesetzt
- dann wird (in der Shell) der Port auch als geöffnet angezeigt (1885, TCP)
- sobald ich aber in FHEM beim Device ein reopen mache, ist der Port wieder weg  :(

Ist eher Voodoo als eine Lösung.

Ich hatte zwar (gefühlt) mindestens 50 'sudo reboot' und 'shutdown restart' gemacht, aber wer weiß...ich werd's testen.  ;)

PS. Nach einem Restart von FHEM ist der Port geöffnet...so weit, so gut. Nach einem 'reopen' auf das Device ist der Port aber wieder weg. Blöd. Ich hatte früher mal ein Log2Syslog-Device nicht als Collector, sondern als Sender konfiguriert...evtl. liegt's daran. Im Moment ist der Weatherman das einzige Device, das Log2Syslog nutzt.

PPS. Ein Reopen macht das hier (im Log):
2020.05.05 19:59:50 3: Log2Syslog WeathermanJSON - Closing server socket tcp/1885 ...
Ein erneutes Reopen macht gar nix.
Ein 'set attr xyz disable 0' führt zu einem
2020.05.05 20:04:20 3: Log2Syslog WeathermanJSON - Opening socket on interface "global" ...
2020.05.05 20:04:20 3: WeathermanJSON: port 1885 opened
2020.05.05 20:04:20 3: Log2Syslog WeathermanJSON - port 1885/tcp opened for Syslog Collector on interface "global"


Ich denke, da passt irgendwas nicht...
FHEM 21222 auf Gigabyte NUC, CubieTruck & RasPis (Test)
CUL 868MHz, nanoCUL 868MHz, nanoCUL 433MHz, JeeLink Clone, JeeLink Classic, HM-CFG-USB2, Rademacher
Devices: FHT, FS20, KS300, MAX, IT, HMS100, LaCrosse, PCA301, Revolt, HomeMatic, ESA2000, UNIRoll, Sonos, Duofern, Tasmota, MySensors

plinepa

Hallo!

Mal eine andere Frage zum Weatherman:

Wie zeigt ihr im Plot die Regenmenge an?

Ich habe das Reading regen_pro_h verwendet und bekomme eine absteigende Treppe.
In den Quelldaten ist der absteigende Wert auch so enthalten.
Wie habt ihr das gelöst?
Bin für jeden Tipp dankbar.

Gruß
plinepa

PS: Die rote Kurve ist die vom KS300

andi11

Zitat von: plinepa am 11 Mai 2020, 09:19:15
Hallo!

Mal eine andere Frage zum Weatherman:

Wie zeigt ihr im Plot die Regenmenge an?

Ich habe das Reading regen_pro_h verwendet und bekomme eine absteigende Treppe.
In den Quelldaten ist der absteigende Wert auch so enthalten.
Wie habt ihr das gelöst?
Bin für jeden Tipp dankbar.

Gruß
plinepa

PS: Die rote Kurve ist die vom KS300
und was hättest du gerne anders?

mgfhem

Hallo plinepa,

kommt denke ich ganz drauf an, was du darstellen möchtest.
Ich z.B. verwende das Reading "regen_mm_heute" in Kombination mit dem aktuellen Füllstand meiner Zisterne, um zu prüfen, ob die gesamte Dachfläche tatsächlich in die Zisterne entwässert.
Hier ein Bild von heute, wie das dann aussieht.

Grüße


plinepa

#116
Zitat von: andi11 am 11 Mai 2020, 16:23:52
und was hättest du gerne anders?
Ich möchte darstellen wieviel es in der jeweiligen Stunde geregnet hat.
So wie im Plot rot dargestellt vom KS300.

Das Reading regen_pro_h habe ich als Userreading angelegt:
regen_pro_h { my $w=ReadingsVal($name,"MSG_ESP-5F5A5B.fritz.box",0) ;; $w =~ s/.*"w_regen_letzte_h".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },

Das Problem ist die Treppenbildung die dadurch entsteht dass ich ja jede Minute einen Wert bekomme und der immer die Regenmenge der zurückliegenden Stunde als Value hat.

Ich muss das irgendwie vereinzeln auf nur jede Stunde 1mal damit die Treppenbildung weg ist.

event-min-interval habe ich schon probiert:
event-min-interval regen_pro_h:3600
aber dann kommen keine Stundenwerte mehr in die DB.

Vielleicht weil das alles Userreadings sind?
Evtl. probiere ich mal das ExpandJSON

vencam

Zitat von: mgfhem am 11 Mai 2020, 16:38:00
Hallo plinepa,

kommt denke ich ganz drauf an, was du darstellen möchtest.
Ich z.B. verwende das Reading "regen_mm_heute" in Kombination mit dem aktuellen Füllstand meiner Zisterne, um zu prüfen, ob die gesamte Dachfläche tatsächlich in die Zisterne entwässert.
Hier ein Bild von heute, wie das dann aussieht.

Grüße

Hat jetzt hier nichts mit dem Thema zu tun aber wie misst du den Füllstand deiner Zisterne? Hab das auch noch vor :)

MadMax-FHEM

Bin zwar nicht mgfhem aber ich messe den Füllstand meines Tanks mittels Ultraschallsensor und ESP...

Es gibt aber im Forum einige Threads zu dem Thema.

Auch mal nach "Füllstand Öltank" suchen etc.
Da ist dann eine Lösung mit Drucksensor dabei...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

mgfhem

Genauso mache ich das auch.
Wasserdichter Ultraschallsensor in der Zisterne und ein ESP mit ESPEasy.
Mein größtes Problem war der WLAN Empfang in der Betonzisterne, deshalb sitzt der ESP außerhalb der Zisterne.