WeatherStationDataRx
WeatherStationDataRx copied to clipboard
Zwer2k
Data interpreted wrongly for MX-RM-5V & Auriol H13726A
I'm using the Wemos D1 mini together with MX-RM-5V receiver and the signal is picked up, however it seems that data is not parsed correctly. I'm getting a lot of "New device paired" messages as well as some wild readings, e.g.:
WeatherStationDataRx Test
00:03:16.644 -> Data pin 14
00:03:16.909 -> New device paired 128
00:03:28.653 -> New device paired 7
00:03:28.819 -> New device paired 15
00:03:37.509 -> New device paired 0
00:03:37.974 -> New device paired 192
00:03:39.102 -> New device paired 64
00:03:39.201 -> New device paired 1
00:03:40.396 -> Temperature: 24.20°C
00:03:40.396 -> Humidity: 140%
00:03:40.396 -> Battery: OK
00:03:40.396 -> Sensor ID: 1
00:03:42.022 -> New device paired 32
00:03:42.022 -> Temperature: 0.00°C
00:03:42.022 -> Humidity: 0%
00:03:42.022 -> Battery: OK
00:03:42.022 -> Sensor ID: 32
00:03:43.846 -> Temperature: -51.20°C
00:03:43.846 -> Humidity: 155%
00:03:43.846 -> Battery: OK
00:03:43.846 -> Sensor ID: 64
00:03:44.609 -> New device paired 99
00:03:44.609 -> Temperature: -200.40°C
00:03:44.609 -> Humidity: 0%
00:03:44.609 -> Battery: OK
00:03:44.609 -> Sensor ID: 99
00:03:45.837 -> New device paired 129
00:03:45.837 -> Temperature: 19.20°C
00:03:45.837 -> Humidity: 80%
00:03:45.837 -> Battery: Low
00:03:45.837 -> Sensor ID: 129
00:03:54.065 -> New device paired 143
00:03:54.065 -> Temperature: -3.20°C
00:03:54.098 -> Humidity: 1%
00:03:54.098 -> Battery: Low
00:03:54.098 -> Sensor ID: 143
Any idea what am I doing wrong? Or is it possible that the protocol is different? Thanks!
Hi, I'm experiencing the same problem, but I believe they are just badly received messages: if I keep the station very close to the receiver I get only a few of them, but I get many, many more if I move the receiver away. That's not a big problem for me as I'm publishing to MQTT the sensor ID, and reading only values from the ID that corresponds to the "real" sensor.
The real problem is that sometimes the sensor ID is correct but the reading values are WAAAY off (like in your log, temperatures like -120.2 °C or so).
I tried putting a check in the code so only values that are close enough (<0.5 °C difference) to previous reading are published, but I'm still getting ugly spikes like that:
I strongly believe that something is wrong with the message CRC check (Auriol protocol has it, don't know if the library uses it): how can so many wrong messages pass CRC test? I can imagine some wrong message pass every now and then, but there are multiples in just a few minutes (these are the MQTT log from about 30 minutes of readings, only the first 2 - 132 and 162 - are the right sensors):
I can confirm that these one work very bad in receiving (The transmitter performs much better). I am not using them, I am using an RXB6/MX-RM-5V as suggested. After some thinkering I added an antenna (17 cm solid wire), changed poistion and now reception is much better, but I still get some very off values (like 110 °C) and some "ghost" stations ID, things that I think the CRC should not let thru. Anyway I added a light filter in Home Assistant to smooth and eliminate the spikes and it's now working good. I still think there's room for improvement.
The checksum is just 4Bit, i.e. the probability is relatively high that an bad packet will get through.
Do you use the pair() function with device-ID to receive data only from your station?
byte myDeviceIDs[] = {34, 63}; wsdr.pair(myDeviceIDs, sizeof(myDeviceIDs));
Still strange that so many come out (they're now A LOT less than in my first post after orienting the antenna and finding the right spot). Anyway I prefer not to use the pair function and publish to MQTT every ID received, so I don't have to recompile and reflash every time I change batteries (the ID changes). I just filter the right ID number in the Home Assistant config.
@Zwer2k
hi, thanks for your reply. I use exactly that receiver :)
I'll try to get RXB6/MX-RM-5V then.
thanks!
There a is one more option beside CRC how to "check" the received data, but it's not that simple.
When you read the protocol structure (or analyze on your own) you can see, that the values are sent in bursts. The same data (packet) in that burst are repeated more than once. Currently we are reading (using function rx433Handler) only the first one. We identify it by waiting for 1 sync bit, which occur at the beginning of every burst.
If we could read the second, third etc. packet in that burst as well, we could compare them and throw away if they're not same. But there is one problem. The packet separator between packets in the burst is not the same. Combined sensor separates them with 4 sync bits and rain sensor with 1 sync bit.
This will require some state machine and more than one buffer. Do you have any ideas how to implement this?
I am using a Rxb6 433mhz and do have the same defective packages. I installed a 433 MHz antenna which turned out to be quite an improvement. I am currently trying to filter wrong values but without too much success... I would really appreciate an improvement as explained by @rforro. I am quite busy due to too many projects (in parallel) but I might find some time to hack it.
I still do not trust the values for wind speed (and gust) at all. The values seam way too slow. Is there somebody observing the same errors? BTW... there is about three times the wind speed and i already multiplied by 3.6 to get km/h (from m/s)...
Took a while now. With version v0.5.0 the problem should be solved. Please test. Since I do not use radio signals, but the signal directly at the transmitter, the error does not occur so often. Unfortunately I can't say anything about the problem of the wrong wind speed, because I don't have any comparison values. Does anyone have the possibility to compare the values with another weather station?
German version: Hat jetzt eine Weile gedauert. Mit Version v0.5.0 sollte das Problem gelöst sein. Bitte testen. Da ich die Signale nicht per funk, sondern direkt an dem Sender abgreife, ist der Fehler bei mir nicht so oft aufgetreten. Zu dem Problem der falschen Wind-Geschwindigkeit kann ich leider nichts sagen, da ich keine Vergleichswerte habe. Hat jemand Möglichkeit die Werte mit einer anderen Wetterstation zu vergleichen?
Super...
Ich werde so bald wie möglich auf deine neue Version updaten und dann berichten....
Vielen Dank!
hello, feel free to close this issue if you managed to test it and you think it is resolved. I unfortunately no longer have the HW
So... Deine neue Version ist nun im "safe mode" im Einsatz. Mal sehen ob die Fehler nun raus sind...
Danke!
Update: Ich erhalte weiterhin fehlerhafte Messungen/Werte. Das ist bisher nur bei der Temperatur aufgetreten und dort erhalte ich stets Werte von "0". @Zwer2k Hast du auch soetwas beobachtet? Soll ich noch irgendwas debuggen? Also brauchst du mehr Input?
Update2: Es gibt immer mal wieder sporadisch falsche Werte (bisher nur bei Temperatur). Nach Auswertung durch einen Rolling-Median-Filter habe ich aber seit etlichen Stunden bzw. einigen Tagen keine Fehler mehr beobachtet.
Sind es immer unterschiedliche Werte oder bekommst du nur "0" als fehlerhaften Wert? Aktuell habe ich überhaupt keine fehlerhafte Messwerte mehr. Ich habe mir alte Messwerte genauer angeschaut und habe festgestellt, dass ich auch davor keine fehlerhafte Messwerte hatte. Ich hatte beim Reboot von meinem ESP32 (mit dem ich die Daten erfasse) die werte bereits übermittelt, bevor die von der Wetterstation abgerufen worden sind, dadurch hatte ich falsche Werte in der Statistik, hatte aber nichts mit der Lib. zutun. Wie gesagt, ich greife den Signal direkt an der Wetterstation ab, dadurch ist meine Signalqualität viel besser.
Nein..? Die fehlerhaften Werte sind auch von Null verschieden. Aber auch tatsächlich seit deinem Patch seltener.
Hab mal "develop" Branche soweit erweitert, dass eine Bestätigung durch zwei Pakete erfolgen kann, dazu muss bei der Initialisierung der Schalter ARMUseAsConfirmation2x verwendet werden. Ich konnte es bis jetzt noch nicht testen, darfst du gerne schon mal machen :-).
Hab mal "develop" Branche soweit erweitert, dass eine Bestätigung durch zwei Pakete erfolgen kann, dazu muss bei der Initialisierung der Schalter ARMUseAsConfirmation2x verwendet werden. Ich konnte es bis jetzt noch nicht testen, darfst du gerne schon mal machen :-).
Mache ich... Das heißt man braucht schon mindestens drei identische Pakete damit die Bibliothek einen neuen Wert zur Verfügung stellt? Ich befürchte der Bug liegt woanders. Sonst müsste, da diese Pakete ja etliche Male wiederholt werden, nach einem falschen Wert gleich ein korrekter folgen oder anders herum. Ich befürchte wir haben ein Nebenlaufgleisproblem. Deine Bibliothek schreibt die Variable während ich in dem Haupthread darauf zugreife. Der von mir eingestehen ESP32 hat ja zwei echte Kerne und daher echte Parallelität. Wir könnten Mal versuchen atomare Datentypen zu verwenden (alle Datentypen über ein Byte sind auch bei Klassifikation durch volatile nicht wirklich atomare). Ist das möglich?
Update: Habe mir den code mal angeguckt und festgestellt, dass du auf den globalen Ringbuffer (dataBuffer) sowohl schreibend in der ISR als auch lesend im Hauptthread zugreifst und durch das Deaktivieren von "interrupts" (noInterrupts()) versuchst den Zugriff zu isolieren. Aber was spricht dagegen, dass im Hauptthread noInterrupts() aufgerufen wird während gerade ein interrupt abgearbeitet wird? Ich glaube wir brauchen dort einen binären Semaphor oder eine volatile Variable die zu Begin der ISR auf "buzy" gesetzt wird und zum Ende auf "waiting" und auf dessen "waiting" status nach "noInterrupts()" gewartet wird.
Ahhh hatte nicht gesehen, dass es dort noch einen weiteren branch gibt... Ich hab es nun mit deinem neuesten patch und "ARMUseAsConfirmation2x" im Einsatz... mal sehen :)
Update:
Habe gerade festgestellt, dass der Patch "panic'ed" :( .oO(jedenfalls mit ARMUseAsConfirmation2x)
Oops sorry. Der Ringbuffer wurde bei der Einstellung nicht initialisiert. Sollte jetzt behoben sein. Kann wie gesagt zur Zeit nicht testen. Hab mir dein Post zu den Datentypen/Interrupts angeschaut. Bin leider nicht ganz so tief in der Thematik drin, kann mir aber gut vorstellen, dass die Probleme davon kommen. Ich nutze auch ESP32 für meine Wetterstation, hab aber wie gesagt keine Fehlmessungen, ich habe allerdings sporadische crashes/neustarts die ich auch bei der Library vermute. Ich verstehe dein Vorschlag mit der Semaphor. Würde es aber nicht reichen wenn wir size, readPos und writePos auf byte ändern? Die pull und push Methoden sollten eigentlich immer auf unterschiedlich Werte im Buffer zugreifen.
Oops sorry. Der Ringbuffer wurde bei der Einstellung nicht initialisiert. Sollte jetzt behoben sein. Kann wie gesagt zur Zeit nicht testen. Hab mir dein Post zu den Datentypen/Interrupts angeschaut. Bin leider nicht ganz so tief in der Thematik drin, kann mir aber gut vorstellen, dass die Probleme davon kommen. Ich nutze auch ESP32 für meine Wetterstation, hab aber wie gesagt keine Fehlmessungen, ich habe allerdings sporadische crashes/neustarts die ich auch bei der Library vermute. Ich verstehe dein Vorschlag mit der Semaphor. Würde es aber nicht reichen wenn wir size, readPos und writePos auf byte ändern? Die pull und push Methoden sollten eigentlich immer auf unterschiedlich Werte im Buffer zugreifen.
Ich werde das heute Abend noch einmal testen. Das mit dem auf byte ändern ist sicher gut... Ist die Variable writePos schon volatile? Ich schaue es mir an.
Oops sorry. Der Ringbuffer wurde bei der Einstellung nicht initialisiert. Sollte jetzt behoben sein. Kann wie gesagt zur Zeit nicht testen. Hab mir dein Post zu den Datentypen/Interrupts angeschaut. Bin leider nicht ganz so tief in der Thematik drin, kann mir aber gut vorstellen, dass die Probleme davon kommen. Ich nutze auch ESP32 für meine Wetterstation, hab aber wie gesagt keine Fehlmessungen, ich habe allerdings sporadische crashes/neustarts die ich auch bei der Library vermute. Ich verstehe dein Vorschlag mit der Semaphor. Würde es aber nicht reichen wenn wir size, readPos und writePos auf byte ändern? Die pull und push Methoden sollten eigentlich immer auf unterschiedlich Werte im Buffer zugreifen.
Ich werde das heute Abend noch einmal testen. Das mit dem auf byte ändern ist sicher gut... Ist die Variable writePos schon volatile? Ich schaue es mir an.
Ich werde das heute Abend noch einmal testen. Das mit dem auf byte ändern ist sicher gut... Ist die Variable writePos schon volatile? Ich schaue es mir an.
writePos ist keine globale/classen variable, daher nicht erforderlich. readPos und size sind es aber, die waren aber tatsächlich nicht volatile. Hab ich vor zwei tagen in der develop Branche entsprechend angepasst.
Ich werde das heute Abend noch einmal testen. Das mit dem auf byte ändern ist sicher gut... Ist die Variable writePos schon volatile? Ich schaue es mir an.
writePos ist keine globale/classen variable, daher nicht erforderlich. readPos und size sind es aber, die waren aber tatsächlich nicht volatile. Hab ich vor zwei tagen in der develop Branche entsprechend angepasst.
Soooo... gerade den develop Zweig auf meine Station geschoben.... nun heist's abwarten :) Hatte durch meinen RunningMedian-Filter eigentlich eh keine "Ausfälle" mehr... Aber ich protokolliere die von deiner lib übergebenen Daten immer noch und kann so gucken ob es weiterhin zu Fehlern kommmt oder eben nicht...
Update: Bisher habe ich keine fehlerhaften Werte empfangen...
Hab diesen Entwicklungsstand jetzt auch mehrere Tage auf meiner Wetterstation gehabt und dabei festgestellt, dass die Abstürze weniger geworden sind. Zuvor 2-5mal an einem Tag, jetzt seltener als einmal am Tag.
Jetzt habe ich binäre Semaphore (wie von dir vorgeschlagen) eingebaut. noInterrupts() habe ich entfernt.
Darfst du gerne in der develop-Branche testen. Läuft bei mir seit einem Tag stabil.
Warum hast du Abstürze? Mir sind noch keine aufgefallen. Ich betreibe meinen Empfänger via POE und benutze ein wiznet W5500 Modul zur Kommunikation und habe WiFi komplett aus. Vielleicht sorgt eine Bibliothek in Verbindung mit dem WiFi für Komplikationen? Läuft deine ISR zu lange? Zusätzlich betreibe ich übrigens noch eine cc2530 Modul als Zigbee coordinator der über meine iobroker Instanz verwendet wird. Achja, meine Wetterdaten schicke ich via mqtt in den selben iobroker. Und bisher ohne Abstürze... Das wäre mir zumindest in den Wetterdaten schnell aufgefallen.
.oO(das USB Kabel ist da gerade nur zum Flaschen an dem ESP Modul)
Update: Werde morgen Abend wohl erst zu einem Firmware-Update kommen... Update 2: Ich habe übrigens auch mit der alten develop-Version meiner Fehler mehr gehabt. Dabei glättet der Rolling-Median-Filter zumindest die Temperatur sehr sanft aber effektiv.
Warum hast du Abstürze?
Das würde ich auch gerne wissen :-). Meine Wetterstation steht auf dem Dach, um an die zu kommen leihe ich mir ab und zu 5m Leiter von meinem Nachbar aus. Daher ist da nicht viel mit Debugging. Hab außer Ventus W132, ein Regenmesser, ein Tropfensensor mit Heizung, drei Lichtsensoren um komplettes Helligkeitsspektrum abzudecken, ein BME280 für Temperat/Luftfeuchtigkeit/Luftdruck (wobei diese Werte zu messen auf dem Dach kein Sinn macht). Um Berechnung der Regenmengen bei einem Nestart/Absturz nicht zu verlieren, werden die Daten in einem externen FRAM-Chip gespeichert. Stromversorgung erfolgt von eine Solarzelle mit LiIon-Akkus. Alles von einem ESP32 gesteuert, inkl. Ladesteuerung von den Akkus. Datenübertragung erfolgt hauptsächlich per LORA, zusätzlich ab und zu per WLAN (und als Fallback). Firmware wird per OTA aktualisiert. Um Strom zu sparen, bleibt WLAN meiste Zeit aus und der ESP wird so oft wie möglich in Light-Sleep versetzt. Ich nutze einige Bibliotheken, die Abstürze könnten davon kommen oder von meinen 2000 Zeilen Code. Ich hatte aber schon ganze Zeit WeatherStationDataRx im Verdacht.
Bist du sicher dass deine Stromversorgung steht und nichts mit den Abstützen zu tun hat? Immerhin haben wir gerade viel Sonne und du berichtest von seltener gewordenen Abstützen. Kann auch Zufall sein aber so von außen betrachtet drängt sich da einfach diese Frage auf. Was hast du denn für Abstürze? Brownouts? Schon Mal versucht einfach die Detektion zu deaktivieren (WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0);)?