Bresser Wetterstation 868Mhz - wie in FHEM integrieren?

[beaune]

Ups Du hast Recht, hatte vergessen die anderen Geräte abzuschalten. Das waren FS20-Telegramme. Hab nochmal aufgezeichnet, und jetzt sollte es sortenrein sein.

Eine LED gibts leider nicht, aber das Funk-Display zur Wetterstation hat eine Empfangsanzeige, die zyklisch kurz blinkt. Ich vermute mal, das signalisiert ankommende Telegramme. Das wäre dann in einem Abstand von 12s. Hab wieder etwa 3 Minuten aufgezeichnet. Vielleicht ist jetzt was erkennbar?

[Ralf9]

hier
https://github.com/andreafabrizi/BresserWeatherCenter
steht zwar daß es eine AM modulation ist

The sensor transmit the packet on the 868.300M frequency with AM modulation.

aber wenn ich es in audacity anschaue sieht es eher wie FSK aus (siehe Anlage), zum vergleich ist in der Anlage auch noch ein ASK/OOK

hier steht, das es eine FSK_PULSE_PCM Modulation ist
https://github.com/merbanan/rtl_433
https://github.com/merbanan/rtl_433/blob/master/src/devices/bresser_5in1.c

ich schreibe dazu hier weiter
https://forum.fhem.de/index.php/topic,106594.0.html

[Ralf9]

Der Beitrag https://github.com/merbanan/rtl_433/issues/719#issuecomment-388896758 ist sehr interessant. Ich kann zumindest bestätigen, dass ich durch diesen Kommandozeilenaufruf die nachfolgende JSON-Ausgabe im 12s-Raster bekomme, die auch tatsächlich die Werte enthält, die im Bresser-Display angezeigt werden:

Code Auswählen Erweitern

rtl_433 -f 868272000 -F json -R 119

Code Auswählen Erweitern

{"time" : "2021-04-10 19:13:38", "model" : "Bresser-5in1", "id" : 67, "battery_ok" : 1, "temperature_C" : 22.800, "humidity" : 35, "wind_max_m_s" : 0.000, "wind_avg_m_s" : 0.200, "wind_dir_deg" : 157.500, "rain_mm" : 4.000, "mic" : "CHECKSUM"}

Die Bresser-5-in-1 entspricht also dem in rtl_433 implementierten Gerätetyp 119. Es bleibt also die spannende Frage, ob es möglich ist, die FSK-PCM im CC1101 zu realisieren.

So jetzt sieht es besser aus. Hab nochmal recherchiert, was denn die richtige Datenrate ist, und hab diese Untersuchung gefunden: https://github.com/jgromes/RadioLib/issues/168. An der Datenrate scheint es zu hängen. Ändere ich nur die Deviation, ändert sich so gut wie nichts. Setze ich aber die Datenrate auf 8220, dann kommt etwas vernünftiges an, meine ich.

Und das ist das Log-Ergebnis:

Code Auswählen Erweitern

2021.04.22 17:22:43 4: sduino/msg READ: MN;D=E6837FD73FE8EFEFFEBC89FFFF197C8028C017101001437600000001;R=230;
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/time:2021-04-22 17:22:43
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/id:124
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/battery_ok:1
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/temperature_C:11.0
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/humidity:43
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_max_m_s:4.0
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_avg_m_s:1.7
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_dir_deg:270.0
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rain_mm:7.6
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mic:CHECKSUM
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mod:FSK
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq1:868.24013
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq2:868.37171
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rssi:-6.00578
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/snr:29.14872
2021.04.22 17:22:43 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/noise:-35.1545
2021.04.22 17:22:55 4: sduino/msg READ: MN;D=E6837FE11FE7EFEFFEBD89FFFF197C801EE018101001427600000002;R=215;
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/time:2021-04-22 17:22:55
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/id:124
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/battery_ok:1
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/temperature_C:11.0
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/humidity:42
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_max_m_s:3.0
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_avg_m_s:1.8
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_dir_deg:315.0
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rain_mm:7.6
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mic:CHECKSUM
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mod:FSK
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq1:868.22938
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq2:868.37658
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rssi:-6.21577
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/snr:25.92842
2021.04.22 17:22:55 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/noise:-32.1442
2021.04.22 17:23:07 4: sduino/msg READ: MN;D=E6837FE11FE7EFEFFEBD89FFFF197C801EE018101001427600000001;R=213;
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/time:2021-04-22 17:23:07
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/id:124
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/battery_ok:1
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/temperature_C:11.0
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/humidity:42
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_max_m_s:3.0
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_avg_m_s:1.8
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_dir_deg:315.0
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rain_mm:7.6
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mic:CHECKSUM
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mod:FSK
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq1:868.23424
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq2:868.36512
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rssi:-5.93452
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/snr:27.17878
2021.04.22 17:23:07 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/noise:-33.1133
2021.04.22 17:23:19 4: sduino/msg READ: MN;D=E6837FEB1FE9EFEFFEBC89FFFF197C8014E016101001437600000002;R=216;
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/time:2021-04-22 17:23:19
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/id:124
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/battery_ok:1
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/temperature_C:11.0
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/humidity:43
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_max_m_s:2.0
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_avg_m_s:1.6
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_dir_deg:315.0
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rain_mm:7.6
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mic:CHECKSUM
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mod:FSK
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq1:868.22726
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq2:868.36768
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rssi:-6.00578
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/snr:24.67714
2021.04.22 17:23:19 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/noise:-30.6829
2021.04.22 17:23:31 4: sduino/msg READ: MN;D=E6837FEB2FE9EFEFFEBC89FFFF197C8014D016101001437600000000;R=218;
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/time:2021-04-22 17:23:31
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/id:124
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/battery_ok:1
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/temperature_C:11.0
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/humidity:43
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_max_m_s:2.0
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_avg_m_s:1.6
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_dir_deg:292.5
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rain_mm:7.6
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mic:CHECKSUM
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mod:FSK
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq1:868.22912
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq2:868.3609
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rssi:-5.93763
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/snr:29.21686
2021.04.22 17:23:31 4:   mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/noise:-35.1545


Man sieht hier im Log die Ausgaben, die ich über den SDR-Stick per MQTT bekomme, und passend dazu die MN_Telegramme des Signalduino. Das kommt regelmäßig alle 12 s. Alle gültigen MU-Telegramme haben als zweites Empfangsbyte die 83. Das ist das inverse des Stationscodes 7C, den man 13 Bytes weiter hinten wiederfindet. Auch die Temperatur hab ich in diesen Telegrammen gemäß https://github.com/merbanan/rtl_433/blob/7480c9c9f986859fdf0f661562f05509cc30a383/src/devices/bresser_5in1.c#L31 stichprobenartig gesucht und gefunden. Man kann die Werte im Log 1:1 mit den Werten vom SDR-Stick vergleichen, die anderen sollten dann wohl auch passen.

Läßt sich damit jetzt eine Integration in fhem vornehmen?

ja, das passt so.
Wie hast Du die Datenrate von 8220 ermittelt?

Ich vermute, daß die Datenrate der Kehrwert von der Dauer eines Bits ist
hier ist die short_width = 124
https://github.com/merbanan/rtl_433/blob/7480c9c9f986859fdf0f661562f05509cc30a383/src/devices/bresser_5in1.c#L188

demnach wäre die Datenrate 1 / 124 = 8065

Hab ich probiert:

Code Auswählen Erweitern

ccconf: freq:868.350MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:8058.55Baud)

Modulation:2-FSK (SYNC_MODE:16/16 sync) DEVIATN:57.129kHz

Aber das passt nicht, dann kommen keine sinnvollen Telegramme mehr an, also so läßt sich die Datenrate nicht ermitteln.

Der ursprüngich verwendete Wert 8220 stammt aus dieser Untersuchung: https://github.com/jgromes/RadioLib/issues/168#issuecomment-662631134. Die Herleitung kann ich ehrlich gesagt nicht nachvollziehen, aber es ist Fakt und mehrfach bestätigt, dass sie richtig ist.

Ergänzung: ich hab Deinen Konfigurationsstring nochmal mit meinem verglichen. Ganz wichtig ist der SyncMode in 0x12 MDMCFG2. Das muß auf "0x02 - Modulation:2-FSK (SYNC_MODE:16/16 ohne Preamble)" stehen, sonst kommt gar nichts an. Aber auch wenn das stimmt, passt die Datarate 8065 nicht, es kommen dann nur ungültige Telegramme an.

1 / 8220 ergibt 121,65us
das sind nur ca 2,5us weniger als die 124.

Evtl stimmen die short_width = 124 nicht ganz.
Die Frage ist wie genau der SDR die Bitdauer messen kann.

In irgendeiner bresser_5in1.c war auch mal 122 statt 124 angegeben. Daraus ergäbe sich dann eine Datenrate von 8196 Hz.

[Ralf9]

Und eine Frage hab ich dann noch:
Mir ist nicht ganz klar, was die Wetterstation als "rain_mm" meldet und wie man das am besten darstellt. Meine meldet aktuell immer denselben Wert, den sie schon seit einer Woche meldet, in der es nicht geregnet hat. Das Bresser-Display zeigt den Niederschlag tageweise, inzwischen nichts mehr. Der anscheinend kumulierte Wert in der Übertragung bleibt aber anscheinend. Ich vermute mal, man muß den Messwert in fhem in Verbindung mit dem Zeitstempel verarbeiten. Wie genau ist mir aber wie gesagt nicht klar, auch nicht, was man dementsprechend als Reading optimalerweise anbieten sollte. Vielleicht sowas wie "Niederschlag heute" und "Niederschlag der letzten Woche" oder so. Können wir uns hier an bestehenden Wetterstatiinsimplementierungen orientieren, oder müssen wir hier was Neues erfinden? Gibts dazu schon eine sinnvolle Visualisierung fürs Dashboard?

Laut bresser_5in1.c:

Code Auswählen Erweitern

R = rain in mm, BCD coded, RRxR = 1203 => 31.2 mm
ist das nur ein fortlaufender Zähler, der bei 99,9 wahrscheinlich überläuft und wieder bei 0 beginnt. Warum angeblich das 4. Nibble nicht verwendet wird, ist mir ein Rätsel. Das können wir nur beobachten, oder du schüttest mal ne Menge Wasser in den Regenmesser

Für stündliche, tägliche u.s.w. Auswertungen würde ich das Modul statistics empfehlen.

Auch das sieht gut aus.

Zu der Sache mit der Regenmenge:
Es scheibt so zu sein, dass der Sensor einen kumulierten Niederschlagswert liefert. Aktuell ist das identisch mit dem Niederschlagswert des letzten Monats, was aber auch an der bislang kurzen Betriebsdauer liegen kann. Bin gespannt was ich dann am 1. Mai als Messwert bekomme.

Das Modul statistics kannte ich noch nicht. Damit könnte es möglich sein, mithilfe der Delta-Funktion stündliche oder tägliche Niederschlagsmengen auszurechnen. Ganz warm bin ich mit dem Modul aber noch nicht; es rechnet anscheinend erst ab Einrichtung und ignoriert früher aufgezeichnete Daten. Weiß jemand, ob man das irgendwie beeinflussen kann? Sonst muß ich wohl auf den nächsten Regen warten...

Das ist richtig, das Modul statistics muss erst Daten sammeln.
Wenn du jetzt schon etwas sehen willst, kannst du auch ein SVG-Plot mit der Funktion delta-h oder delta-d erstellen.

[Ralf9]

Was passiert denn jetzt eigentlich mit der Geräte-ID? Die sehe ich als Reading noch nicht. Wird die einfach ignoriert? Was passiert dann, wenn man die Batterie wechselt oder Reset drückt, und sich damit die ID ndert? Und was, wenn man zufällig zwei unterschiedlioche Wetterstationen empfängt? Das sollten wir noch klären.

Es gibt das sduino Attribut "longids", wenn dies gesetzt ist, dann wird die Id an den Devicenamen angehängt
z.B.: "SD_WS_108_7C"
damit können dann mehrere Wetterstationen empfangen werden, der Devicename ändert sich dann aber beim Batteriewechsel.

Ein reading id gibt es noch nicht.
Wie soll es heissen? "id" oder sensorId" oder ??

Soll es immer und bei allen Modellen angelegt und aktuallisiert werden?

Oder nur wenn das Attribut "longids" nicht gesetzt ist?

Wieder was dazu gelernt: Das Attribut kannte ich noch nicht. Ok, dann ist klar, wie man mehrere Wetterstationen verwalten kann.

Das Reading macht meiner Meinung nach trotzdem Sinn. Ich würde es sensorID nennen. Und ich würde es in beiden Fällen anbieten:

• Wenn man longids nicht gesetzt hat braucht man die ID prinzipiell nicht zu wissen. Aber man könnte zumindest auf eine ID-Änderung reagieren, dies anzeigen, Email schicken oder so. Einfach nur um zu verhindern, dass hier eine unbewußte Umstellung auf die neue Wetterstation des Nachbarn erfolgt. Was würde überhaupt passieren, wenn longids nicht gesetzt ist und dann mehrere Wetterstationen senden? Wird longid dann automatisch gesetzt, oder gibts Kuddelmuddel?
• Auch wenn longids gesetzt ist, könnte ein solches Reading auch helfen. Hier müßte man ja nach einem Batteriewechsel eine Konfigurationsänderung vornehmen. Auch das könnte man mit fhem automatisieren und hätte direkten Zugriff auf die ID, um das Device umzubenennen.

Letztendlich kann ich mit allem leben; wir sind hier schon beim Feinschliff. Insgesamt bin ich sehr zufrieden mit dem Ergebnis. Schon mal vielen Dank an alle Beteiligten!

[Ralf9]

Ich habe mal hier die Beiträge von "FSK mit dem SIGNALDuino" über den Bresser 5in1 zusammen gefasst.

Das BRESSER 5-in-1 Comfort Wetter Center kann inzwischen mit den Signalduino empfangen werden.

Die aktuelle Version des angepassten 14_SD_WS.pm Moduls ist in der Anlage von "FSK mit dem SIGNALDuino"
Im dritten Beitrag von "FSK mit dem SIGNALDuino" habe ich die cc1101 Registerwerte ergänzt.
https://forum.fhem.de/index.php/topic,106594.msg1004463.html#msg1004463

@beaune: der Feinschliff kommt noch. Es fehlt auch noch die Unterstützung für die Professional Rain Gauge

Gruß Ralf

[Ralf9]

Ich hab das 14_SD_WS.pm Modul aktualisiert.
https://forum.fhem.de/index.php/topic,106594.msg1004463.html#msg1004463

Ich habe rain_mm in rain umbenannt.
Bei Sensoren wie die Bresser Wetterstation, die keine Kanäle haben, gibts ein neues reading "id"
Die Professional Rain Gauge sollte jetzt auch unterstützt werden

Code Auswählen Erweitern


2021-05-12 19:13:03.115 SD_WS SD_WS_108 T: 11 H: 42 W: 1.8 R: 7.6
2021-05-12 19:13:03.115 SD_WS SD_WS_108 temperature: 11
2021-05-12 19:13:03.115 SD_WS SD_WS_108 humidity: 42
2021-05-12 19:13:03.115 SD_WS SD_WS_108 windspeed: 1.8
2021-05-12 19:13:03.115 SD_WS SD_WS_108 windspeed_kmh: 6.5
2021-05-12 19:13:03.115 SD_WS SD_WS_108 windGust: 3
2021-05-12 19:13:03.115 SD_WS SD_WS_108 windGust_kmh: 10.8
2021-05-12 19:13:03.115 SD_WS SD_WS_108 windDirectionDegree: 315
2021-05-12 19:13:03.115 SD_WS SD_WS_108 windDirectionText: NW
2021-05-12 19:13:03.115 SD_WS SD_WS_108 batteryState: ok
2021-05-12 19:13:03.115 SD_WS SD_WS_108 rain: 7.6
2021-05-12 19:13:03.115 SD_WS SD_WS_108 id: 124

Gruß Ralf

[Ralf9]

@beaune
wie weit ist der Rainzähler inwischen von 100 entfernt?
Ich könnte eine raw MN-Nachricht mit einem rainzähler von 100 oder mehr gebrauchen.
Das aktuelle 14_SD_WS.pm Modul müsste eigentlich auch rain werte von 100 oder mehr anzeigen.

Gruß Ralf

[beaune]

Ist leider erst so bei 70, aber wenn das Wetter so bleibt dauerte nicht mehr sooo lange 

[beaune]

Jetzt hat es ordentlich geregnet, der Zähler ist umgesprungen.

Das sind Ausschnitte aus dem Sensor-Log, wo man sieht, dass der Wert von 99.x wieder auf 0 umspringt:

Code Auswählen Erweitern

2021-05-25_18:55:57 SD_WS_108 T: 9.3 H: 92 W: 0.6 R: 99.6
2021-05-25_18:56:21 SD_WS_108 T: 9.3 H: 92 W: 0.6 R: 0
2021-05-25_19:04:45 SD_WS_108 T: 9.4 H: 93 W: 0.4 R: 0.4

Hier ein Ausschnitt aus dem Sensor-Log mit einem konkreten Messwert:

Code Auswählen Erweitern

2021-05-25_19:21:57 SD_WS_108 T: 9.1 H: 94 W: 0.6 R: 2
2021-05-25_19:21:57 SD_WS_108 windspeed: 0.6
2021-05-25_19:21:57 SD_WS_108 windspeed_kmh: 2.2
2021-05-25_19:21:57 SD_WS_108 windDirectionDegree: 157.5
2021-05-25_19:21:57 SD_WS_108 windDirectionText: SSE
2021-05-25_19:21:57 SD_WS_108 rain: 2

Und hier ein dazu passende Eintrag aus dem sduino-Log:

Code Auswählen Erweitern

2021.05.25 19:21:57 4: sduino/msg READ: MN;D=EA837FF78FF9EF6EFF6BDFEFFF157C80087006109100942010000002;N=7;R=239;
2021.05.25 19:21:57 4: sduino Parse_MN: Found 2-FSK Protocol id 108 length 56 RSSI = -82.5 -> Bresser 5in1
2021.05.25 19:21:57 4: sduino ParseMN: ID=108 dmsg=W108#7C8008700610910094201000
2021.05.25 19:21:57 5: sduino Dispatch: W108#7C8008700610910094201000, test ungleich: disabled
2021.05.25 19:21:57 4: sduino Dispatch: W108#7C8008700610910094201000, -82.5 dB, dispatch
2021.05.25 19:21:57 5: sduino: dispatch W108#7C8008700610910094201000
2021.05.25 19:21:57 4: sduino: SD_WS_Parse protocol 108, rawData 7C8008700610910094201000
2021.05.25 19:21:57 4: sduino: SD_WS_Parse decoded protocol-id 108 (Bresser_5in1, Bresser_rain_gauge), sensor-id 7C


Offenbar werden also nie Werte > 100 geliefert. Das deckt sich auch mit dieser Aussage:

Laut bresser_5in1.c:

Code Auswählen Erweitern

R = rain in mm, BCD coded, RRxR = 1203 => 31.2 mm
ist das nur ein fortlaufender Zähler, der bei 99,9 wahrscheinlich überläuft und wieder bei 0 beginnt. Warum angeblich das 4. Nibble nicht verwendet wird, ist mir ein Rätsel. Das können wir nur beobachten, oder du schüttest mal ne Menge Wasser in den Regenmesser

Für stündliche, tägliche u.s.w. Auswertungen würde ich das Modul statistics empfehlen.

[Ralf9]

Danke für die Bestätigung, der Zähler geht demnach doch über Hundert, er müsste demnach bis 999.9 gehen
7C8014D01610100143760000 rain 7.6
7C8008700610910094201000 rain 102.0

In der aktuellen Version des 14_SD_WS.pm Moduls ist dies bereits eingebaut
https://forum.fhem.de/index.php/topic,106594.msg1004463.html#msg1004463

Kannst Du bitte auch mal testen ob es auch mit ccmode=1 funktioniert

Code Auswählen Erweitern

get sduino raw ccmode=1

Falls es Wiederholungen gibt, müssten die damit auch empfangen werden

Gruß Ralf

[beaune]

Ok, also mit dieser Version der 14_SD_WS.pm kommen 3-stellige rain-Werte, das kann ich bestätigen. Das ist dann offenbar in rtl_433 nicht richtig implementiert; da kommen definitiv nur 2 Stellen.

Die Sache mit

Code Auswählen Erweitern

get sduino raw ccmode=1 verstehe ich noch nicht ganz, da kommt "Unsupported command". Meine Dateiversionen sind:

Code Auswählen Erweitern

version

V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: A4 B0*) - compiled at Feb 6 2021 00:26:38
versionmodul

v3.4.6-dev_ralf_24.04.
versionprotoL

v3.4.6-dev_ralf_24.04.

Muß ich da noch was updaten? Oder mache ich was falsch? Und warum ist das eigentlich wichtig...

Und dann nochmal ne ganz andere Frage: Inwieweit ist das statistic-Modul eigentlich für die Regenmengenauswertung geeignet? Ich frage aus folgendem Grund: In meiner Installation, wo ich zum Vergleich noch die Daten über rtl_433 abhole und über MQTT an fhem sende, bekomme ich ja die zweistelligen Regendaten. Durch den Umschlag von 99.9 auf 0 führt dies nun in der Berechnung zu negativen Werten. Muß man das händisch korrigieren? z.B. auf irgendeinen internen Zähler 100 aufaddieren, wenn man den Umschlag bemerkt? Es wird zwar so sein, dass der Umschag bei 3-stelligen Daten nicht häugig passiert, aber vorkommen wird es ja auch irgendwann. Wie geht man (bzw. das Statistic-Modul) damit richtig um? Gibts dazu Hinweise/Empfehlungen?

[Ralf9]

verstehe ich noch nicht ganz, da kommt "Unsupported command".

Ich hab noch mal geschaut, die Syntax hat nicht ganz gepasst, die raw Befehle zum Setzen der Konfigvariablen fangen immer mit "CS" an.
Eine Übersicht über alle Konfigvariablen bekommst Du mit "get sduino raw ?S"

Die richtige Syntax ist demnach:

Code Auswählen Erweitern

get sduino raw CSccmode=1

Die ccmode 3 und 4 wurden speziell für LaCrosse entwickelt, da wird nach jeder empfangenen Nachricht der cc1101 Empfangspuffer gelöscht und der Empfang kurz deaktiviert.
Falls der Bresser Wiederholungen sendet, werden diese damit nicht ausgegeben.

Kannst Du am rtl_433 erkennen ob der Bresser die Nachrichten mit Wiederholungen sendet?

Inwieweit ist das statistic-Modul eigentlich für die Regenmengenauswertung geeignet?

In der 98_statistics.pm steht unter knownReadings u.a.

Code Auswählen Erweitern

statisticType: 0=noStatistic | 1=minMaxAvg(daily) | 2=delta | 3=stateDuration | 4=tendency | 5=minMaxAvg(hourly)
  ,"rain" => 2
   ,"rain_rate" => 1
   ,"rain_total" => 2
   ,"temperature" => 1
   ,"total" => 2
   ,"voltage" => 1
   ,"wind" => 5
   ,"wind_speed" => 5
   ,"windSpeed" => 5
Mir ist aufgefallen, daß beim 14_SD_WS.pm Modul das windspeed mit kleinem s geschrieben ist. Soll ich's im 14_SD_WS.pm Modul in "windSpeed" ändern, damit es auch im statistic-Modul verwendet werden kann?

In der MAINTAINER.txt steht für das statistic-Modul, dort kannst Du mal fragen

Code Auswählen Erweitern

FHEM/98_statistics.pm        tupol                Unterstützende Dienste (Link als PM an tupol)

Gruß Ralf

[beaune]

Ich hab

Code Auswählen Erweitern

get sduino raw CSccmode=1 ausprobiert. Der Befehl passt so, aber in diesem Mode klappt der Empfang nicht. Offenbar ist Mode 4 erforderlich.

Beim rtl_433 werden keine Wiederholungen ausgegeben. Das ist aber kein Beweis, dass es sie nicht gibt; sie könnten theoretisch durch die Software ausgefiltert werden. Insofern kann ich es nicht sicher sagen. Aber es funktioniert ja insgesamt recht zuverlässig; insofern wären Telegrammwiederholumgen eh obsolet.

Zum Überlauf sagt tupol:

in statistics gibt es diesbezüglich keine Vorkehrungen. Die müssen in dem Modul der Wetterstation getroffen werden. So ist es auch bei meinem Regenmesser der Fall.

Was er damit genau meint, hat er nicht gesagt, aber irgendwas ist wohl zu tun. Vielleicht kann man das bei "seiner" Wetterstation abgucken...

[Brillomat]

Hallo,

ich würde mich hier mal gerne dran hängen. Ich habe ebenfalls versucht die Wetterstation nach den hier aufgelisteten Angaben einzubinden:

- sduino flashen mit V 3.3.4.
- Austausch der 14_SD_WS.pm und 00_SIGNALduino.pm, signalduino_protocols.pm
- setzen der Register BRESSER 5-in-1 Comfort Wetter Center - 868.350 MHz, Datarate: 8232.12 kbps   -  SYNC  = 2DD4,  bWidth =  203kHz, DEVIATN =  57.129kHz,  28 byte in RX ccN=7,   ccmode=4

Mit dieser Konfiguration empfängt mein sduino überhaupt nichts mehr. Da kommt rein garnichts an. (Antenne ist natürlich bereits getauscht). Nach einem Factory Reset (get raw e) und dem Anschluss einer 433 Antenne emfängt er wieder Daten wie meine anderen sduinos auch. Aber dann natürlich nicht die der Bresser. Diesen sduino habe ich aber wirklich nur zum Empfang dieser einen Station angebunden, alles andere was ich so an Sensoren habe wird durch zwei andere sduinos abgegriffen.

Hat vielleicht jemand einen Tipp, was ich (als Funknoob)  noch ausprobieren könnte?