FSK mit dem SIGNALDuino

[Ralf9]

Der ursprüngich verwendete Wert 8220 stammt aus dieser Untersuchung

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.


Zum Einbauen in Fhem kann ich noch ein paar MN-Nachrichten gebrauchen:

- mit fast leerer Batterie

- mit verschiedenen Temperaturen, Windstärken und Windrichtungen

MN-Nachrichten mit negativen Temperaturen wirst Du wahrscheinlich nicht mehr liefern können.

Ich würde gerne sehen ob sich beim Batteriewechsel die Stationsid ändert

Gruß Ralf

[beaune]

Ich bin auch überrascht, wie empfindlich das Ganze auf Änderungen der Datarate reagiert. Und ich frage mich auch, wie rtl_433 überhaupt funktionieren kann. Da gebe ich den Wert ja nicht an, und ich sehe auch nicht, dass dieser im Quellcode hinterlegt ist. Demnach müßte er ja online ermittelt werden können, oder eben doch mit den 124 + irgendeinem Detail, dass wir bislang nicht kennen, zusammenhängen....spooky.

Ich zeichne noch ein bisschen auf und hänge schon mal ein paar Telegramme an... der Wind dreht sich gerade öfters mal. Negative Temperaturen kann ich momentan nicht liefern, aber vielleicht wirds ja nochmal kühler. Die Wetterstation hängt draußen, vielleicht gibts ja Eisheilige.

Ne leere Batterie kann ich momentan auch nicht simulieren, aber das mit der ID kann ich dennoch beantworten. Die ändert sich definitiv beim Batteriewechsel, oder auch wenn man Reset drückt. Insofern wärs gut, wenn diese nicht in die Device Definition in fhem eingehen würde, sondern nur als gelesener Parameter, so dass man notfalls zwischen mehreren Wetterstationen unterscheiden kann, aber nicht bei Batteriewechsel die fhem-Konfiguration anpassen muß.

Was mir nicht so richtig klar ist ist, wie man den Regenwert interpretieren muß. Heute hat es nicht geregnet, dennoch wird ein Wert geliefert. Die Bedieneinheit zeigt aber einen Wert für "vor 4 Tagen" an. Muß also irgendewas kumuliertes sein. Vielleicht gibts da etwas übliches? Hab ich mich noch nicht mit beschäftigt.

2021.04.23 09:39:31 4: sduino/msg READ: MN;D=E8837FF76FEFEF9CFF8F89FFFF177C80089010106300707600000002;N=7;R=215;
2021.04.23 13:57:31 4: sduino/msg READ: MN;D=E5837FEB1FEFEFD8FEB989FFFF1A7C8014E010102701467600000002;N=7;R=215;
2021.04.23 14:00:19 4: sduino/msg READ: MN;D=E5833FE16FE6EFDFFE9A897FFF1A7C801E9019102001457200000001;N=7;R=207;

[Ralf9]

Ich bin auch überrascht, wie empfindlich das Ganze auf Änderungen der Datarate reagiert. Und ich frage mich auch, wie rtl_433 überhaupt funktionieren kann.

Beim rtl_433 wird die Samplingrate angegeben, die ist mindestens ca das 10 fache der Datarate.
Beim rtl_433 muss die Bitdauer nicht so genau angegeben werden, da die Flanken ausgewertet werden.

Ganz wichtig ist der SyncMode in 0x12 MDMCFG2. Das muß auf "0x02 - Modulation:2-FSK

ich habe es angepasst:

Code Auswählen Erweitern

CW0001,012E,0246,0306,042D,05D4,06FF,0700,0802,0D21,0E65,0FE8,1088,114C,1202,1322,14F8,1551,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D07,3E04,4042,4172,4265,4373,4473,4535,4631,4700

Ich habe mal mit dem Einbauen ins Fhemmodul angefangen (siehe Anlage), es ist im 14_SD_WS.pm Modul noch nicht ganz fertig, es fehlen noch einige readings.

Code Auswählen Erweitern

2021.04.24 11:57:54.622 4 : sduinoD/msg get raw: MN;D=E8837FF76FEFEF9CFF8F89FFFF177C80089010106300707600000002;N=7;R=215;
2021.04.24 11:57:54.622 4 : sduinoD Parse_MN: Found 2-FSK Protocol id 108 length 56 RSSI = -94.5 -> Bresser 5in1
2021.04.24 11:57:54.622 4 : sduinoD ParseMN: ID=108 dmsg=W108#7C8008901010630070760000
2021.04.24 11:57:54.622 4 : sduinoD Dispatch: W108#7C8008901010630070760000, -94.5 dB, dispatch
2021.04.24 11:57:54.623 4 : sduinoD: SD_WS_Parse protocol 108, rawData 7C8008901010630070760000
2021.04.24 11:57:54.623 4 : sduinoD: SD_WS_Parse decoded protocol-id 108 (Bresser_5in1), sensor-id 7C
2021.04.24 11:57:54.623 4 : sduinoD: SD_WS_Parse SD_WS_108 (7C8008901010630070760000)
2021-04-24 11:57:54.625 SD_WS SD_WS_108 T: 6.3 H: 70
2021-04-24 11:57:54.625 SD_WS SD_WS_108 temperature: 6.3
2021-04-24 11:57:54.625 SD_WS SD_WS_108 humidity: 70
2021-04-24 11:57:54.625 SD_WS SD_WS_108 RSSI: -94.5
2021-04-24 11:57:54.625 SD_WS SD_WS_108 Protocol_ID: 108
2021-04-24 11:57:54.625 SD_WS SD_WS_108 DMSG: W108#7C8008901010630070760000
2021-04-24 11:57:54.625 SD_WS SD_WS_108 RAWMSG: MN;D=E8837FF76FEFEF9CFF8F89FFFF177C80089010106300707600000002;N=7;R=215;

2021.04.24 11:59:10.709 4 : sduinoD/msg get raw: MN;D=E5837FEB1FEFEFD8FEB989FFFF1A7C8014E010102701467600000002;N=7;R=215;
2021.04.24 11:59:10.709 4 : sduinoD Parse_MN: Found 2-FSK Protocol id 108 length 56 RSSI = -94.5 -> Bresser 5in1
2021.04.24 11:59:10.709 4 : sduinoD ParseMN: ID=108 dmsg=W108#7C8014E01010270146760000
2021.04.24 11:59:10.709 4 : sduinoD Dispatch: W108#7C8014E01010270146760000, -94.5 dB, dispatch
2021.04.24 11:59:10.710 4 : sduinoD: SD_WS_Parse protocol 108, rawData 7C8014E01010270146760000
2021.04.24 11:59:10.710 4 : sduinoD: SD_WS_Parse decoded protocol-id 108 (Bresser_5in1), sensor-id 7C
2021.04.24 11:59:10.710 4 : sduinoD: SD_WS_Parse SD_WS_108 (7C8014E01010270146760000)
2021-04-24 11:59:10.712 SD_WS SD_WS_108 T: 12.7 H: 46
2021-04-24 11:59:10.712 SD_WS SD_WS_108 temperature: 12.7
2021-04-24 11:59:10.712 SD_WS SD_WS_108 humidity: 46
2021-04-24 11:59:10.712 SD_WS SD_WS_108 Protocol_ID: 108
2021-04-24 11:59:10.712 SD_WS SD_WS_108 RSSI: -94.5
2021-04-24 11:59:10.712 SD_WS SD_WS_108 RAWMSG: MN;D=E5837FEB1FEFEFD8FEB989FFFF1A7C8014E010102701467600000002;N=7;R=215;
2021-04-24 11:59:10.712 SD_WS SD_WS_108 DMSG: W108#7C8014E01010270146760000

Gruß Ralf

[beaune]

Habs auf die schnelle gerade mal probiert... und sieht gut aus! Die Wetterstation wird gefunden und ein fhem-Device dafür automatisch angelegt. Temperatur- und Feuchtigkeitswert stimmen auch. Ich lass es mal laufen, vielleicht gibts nochmal Nachfrost, so dass wir auch gleich mal negative Temperaturen mittesten können.

[elektron-bbs]

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.

[beaune]

Ich hab Euch mal weitere Logs zusammengestellt. Wir hatten Glück, diese Nacht war wieder Frost. Und tatsächlich werden die negativen Temperaturen noch nicht richtig ausgewertet: das Minuszeichen fehlt. Zwischen 6:00 und 7:10 waren die Temperaturen aber negativ, danach bis 8:00 positiv.

Ich hab anbei 3 Dateien zusammengezippt beigefügt:

• Das Device-Log der Wetterstation, wo die Daten über rtl_433 dekodiert und an fhem per MQTT weitergeleitet wurden.
• Das Device-Log desselben Gerätes, wo die Daten über den Signalduino empfangen und als SD_WS_108 dekodiert wurden.
• Ein Auszug aus dem fhem-Log, wo die signalduino-Telegramme zu sehen sind.

Letztere Datei ist leider relativ groß. Da wurde auch viel uninteressantes geloggt, auch von mindestens einer anderen Wetterstation. Relevant sind die Daten mit der Sensor-ID 7C.

Die erste Datei stammt übrigens von einer separaten fhem-Installation, so dass die Zeitstempel leicht abweichen könnten.

Das mit der Datenrate 8196 hab ich auch gleich probiert. Das Ergebnis der Konfiguration sah so aus:

Code Auswählen Erweitern

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

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

Daten kommen auch an. Kann also durchaus sein, dass dieser Wert richtiger ist als 8220, womit wir dann auch eine Erklärung hätten, woher der Wert stammt. Nur nicht, warum es mal in bresser_5in1.c geändert wurde.

[elektron-bbs]

Ich habe jetzt mal angefangen, die Wetterstation einzuarbeiten. Wie es der Zufall so will, empfange ich auch Daten von einer Station irgendwo aus der Nachbarschaft. Zumindest passen schon mal Temperatur und Feuchte.
Einen Unterschied beim Empfang mit den beiden Datenraten 8232.12 oder 8207.32 konnte ich in der Kürze bis jetzt noch nicht feststellen.
In der 14_SD_WS.pm von Ralf9 ist die Verarbeitung von negativen Temperaturen noch nicht eingebunden.

Frage an Ralf9: Wieso verwendest du eigentlich die invertierten Daten am Beginn der Nachricht und nicht die hinteren? Ich habe mich zuerst gewundert, wieso ich falsche Werte erhalte. Nach Umstellung auf die Bytes 13 bis 25, so wie in der bresser_5in1.c beschrieben, stimmen die Werte.

[Ralf9]

Frage an Ralf9: Wieso verwendest du eigentlich die invertierten Daten am Beginn der Nachricht und nicht die hinteren?

Durch diese Zeile am Ende verwende ich auch die hinteren

Code Auswählen Erweitern

$dmsg = substr($dmsg, 28, 24);

[elektron-bbs]

Ach so, hatte ich übersehen.
Die method => \&main::SIGNALduino_Bresser_5in1 will ich eigentlich einsparen und alles in die 14_SD_WS.pm einbauen. So ist das übersichtlicher.

[Ralf9]

Die method => \&main::SIGNALduino_Bresser_5in1 will ich eigentlich einsparen und alles in die 14_SD_WS.pm einbauen. So ist das übersichtlicher.

Das finde ich nicht so gut, meiner Meinung nach überwiegen da die Nachteile.
Bei fehlerhaften MN-Nachrichten kann es im ungünstigsten Fall alle 12 sek einen unnötigen dispatch zum 14_SD_WS.pm Modul geben.
In der 00_SIGNALduino.pm funktioniert in der Sub SIGNALduno_Dispatch dann die Erkennung doppelter Nachrichten auch nicht mehr so gut.

Gruß Ralf

[Ralf9]

in der Anlage ist eine neue Version des 14_SD_WS.pm Moduls.
Ich habe negative Temperaturen, rain, windspeed, batteryState und windDirectionDegree ergänzt.

Es fehlt noch windDirectionText und windgust

Code Auswählen Erweitern

2021-04-27 22:14:47.296 SD_WS SD_WS_108 T: 11 H: 42 W: 1.8 R: 7.6
2021-04-27 22:14:47.296 SD_WS SD_WS_108 temperature: 11
2021-04-27 22:14:47.296 SD_WS SD_WS_108 humidity: 42
2021-04-27 22:14:47.296 SD_WS SD_WS_108 windspeed: 1.8
2021-04-27 22:14:47.296 SD_WS SD_WS_108 windspeed_kmh: 6.5
2021-04-27 22:14:47.296 SD_WS SD_WS_108 windDirectionDegree: 315
2021-04-27 22:14:47.296 SD_WS SD_WS_108 batteryState: ok
2021-04-27 22:14:47.296 SD_WS SD_WS_108 rain_mm: 7.6


Welche der beiden Versionen ist besser?

Code Auswählen Erweitern

@winddir_name = ("N", "NNE", "NE", "ENE", "E", "ESE", "SE", "SSE", "S", "SSW", "SW", "WSW", "W", "WNW", "NW", "NNW");
oder
@winddir_name = ("N", "NNE", "NE", "NEE", "E", "SEE", "SE", "SSE", "S", "SSW", "SW", "SWW", "W", "NWW", "NW", "NNW");

[beaune]

Habs gerade probiert... sieht gut aus

Zu Deiner Frage: Ich kenne nur die erste Form der Benennung der Windrichtungen. Die würde ich dementsprechend bevorzugen.

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?

[elektron-bbs]

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]

in der Anlage ist eine neue Version des 14_SD_WS.pm Moduls.

Ich habe windDirectionText und windgust ergänzt

[beaune]

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...