Wrong rain counter values

[matthias-bs]

          Unfortunately i think there is a bit of an issue with the decoder! I decided to test the device by adding a little water to the rain counter, I made it tip four times. the 'rain_mm' value went from 910.0mm to 910,7999 (perfectly normal), the others ......

air_temp_c: 2.5 humidity: 93 id: 939865349 rain_day: -33619248 rain_hr: -107481312 rain_mm: 910.7999877929688 rain_mon: -33619248 rain_week: -33619248 status: object supply_v: 284 wind_avg_meter_sec: 0 wind_direction_deg: 354 wind_gust_meter_sec: 0

not sure whats going on here!, maybe you can shed a little light?

Originally posted by @mczakk in https://github.com/matthias-bs/BresserWeatherSensorTTN/issues/38#issuecomment-1402283170

[matthias-bs]

Is this data from the serial log or from the LoRaWAN/MQTT side? Did you see if the node retrieves the time correctly?

[mczakk]

this data is ffrom the ttn console, so post decoder, this is a grab from the serial output: 19:55:02.660 -> [D][WeatherSensor.cpp:219] getMessage(): [SX1276] R [D4] RSSI: -69.5 19:55:06.501 -> [D][WeatherSensor.cpp:238] getMessage(): [SX1276] Receive failed: [0] 19:55:14.651 -> [D][WeatherSensor.cpp:219] getMessage(): [SX1276] R [D4] RSSI: -69.5 19:55:14.651 -> [D][BresserWeatherSensorTTN.ino:1088] setup(): Receiving Weather Sensor Data o.k. 19:55:14.651 -> [D][BresserWeatherSensorTTN.ino:600] setup(): mySensor.setup() - done 19:55:14.651 -> [D][BresserWeatherSensorTTN.ino:891] NetGetSessionState(): o.k. 19:55:14.651 -> [D][BresserWeatherSensorTTN.ino:918] GetAbpProvisioningInfo(): 19:55:14.684 -> [D][BresserWeatherSensorTTN.ino:891] NetGetSessionState(): o.k. 19:55:14.684 -> [D][BresserWeatherSensorTTN.ino:789] NetJoin(): 19:55:14.684 -> [D][BresserWeatherSensorTTN.ino:604] setup(): myLoRaWAN.setup() - done 19:55:14.684 -> [D][BresserWeatherSensorTTN.ino:1160] getVoltage(): Voltage = 284mV 19:55:14.684 -> [D][BresserWeatherSensorTTN.ino:1177] getVoltage(): Voltage = 284mV 19:55:14.684 -> [D][BresserWeatherSensorTTN.ino:1285] doUplink(): --- Uplink Data --- 19:55:14.718 -> [D][BresserWeatherSensorTTN.ino:1289] doUplink(): Air Temperature: 0.8 °C 19:55:14.718 -> [D][BresserWeatherSensorTTN.ino:1290] doUplink(): Humidity: 96 % 19:55:14.718 -> [D][BresserWeatherSensorTTN.ino:1291] doUplink(): Rain Gauge: 910.8 mm 19:55:14.718 -> [D][BresserWeatherSensorTTN.ino:1292] doUplink(): Wind Speed (avg.): 0.0 m/s 19:55:14.718 -> [D][BresserWeatherSensorTTN.ino:1293] doUplink(): Wind Speed (max.): 0.0 m/s 19:55:14.751 -> [D][BresserWeatherSensorTTN.ino:1294] doUplink(): Wind Direction: 216.0 ° 19:55:14.751 -> [D][BresserWeatherSensorTTN.ino:1295] doUplink(): sensor_id: 939865349 19:55:14.751 -> [D][BresserWeatherSensorTTN.ino:1320] doUplink(): Supply Voltage: 284 mV 19:55:14.751 -> [D][BresserWeatherSensorTTN.ino:1323] doUplink(): Battery Voltage: 284 mV 19:55:14.751 -> [D][BresserWeatherSensorTTN.ino:1339] doUplink(): 19:55:14.784 -> [D][BresserWeatherSensorTTN.ino:1428] doUplink(): Rain past 60min: 0.0 mm 19:55:14.784 -> [D][BresserWeatherSensorTTN.ino:1429] doUplink(): Rain curr. day: 0.0 mm 19:55:14.784 -> [D][BresserWeatherSensorTTN.ino:1430] doUplink(): Rain curr. week: 0.0 mm 19:55:14.784 -> [D][BresserWeatherSensorTTN.ino:1431] doUplink(): Rain curr. month: 0.0 mm 19:55:14.784 -> [I][BresserWeatherSensorTTN.ino:1448] doUplink(): Payload length: 38 19:55:14.817 -> [I][BresserWeatherSensorTTN.ino:1449] doUplink(): sensor_id: 939865349 19:55:19.939 -> [D][BresserWeatherSensorTTN.ino:881] NetSaveSessionState(): 19:55:19.939 -> [D][BresserWeatherSensorTTN.ino:881] NetSaveSessionState(): 19:55:19.939 -> [D][BresserWeatherSensorTTN.ino:801] NetTxComplete():

which would suggest that the issue is with the decoder? BTW, timestamps are good :)

[mczakk]

Would it help if I added you as a collaborator on my ttn application?

[matthias-bs]

We missed a small but important detail during our little weekend-hackathon... ;-)

You are sending battery voltage and supply voltage in your uplink message, but the decoder expects only one value (supply voltage). This has the effect, that the bytes interpreted as the four rain counter values are each two bytes off to the begin of the message.

To fix this, just insert battery_v (with type uint16) after supply_v in the decode() function of ttn_decoder_fp.js. (I still have to sort out which input gives battery_v and which one gives supply_v, though.)

[matthias-bs]

Fixed in https://github.com/matthias-bs/BresserWeatherSensorTTN/commit/a0157f77734b3e0eacd9c07825cbf37aeadb1f19

[matthias-bs]

which would suggest that the issue is with the decoder? BTW, timestamps are good :)

The timestamps in this log are from your PC, but shortly after wake-up (and after initializing/re-synchronizing the real-time clock from the network), the sketch prints the time and date - this is what I was referring to.

The RainGauge class needs the time and date - it should not do anything if the initialization failed, but my first suspicion was that there were a bug in that part.

[mczakk]

trying new decoder_basic.js now, but there is a typo in your commiit. line 222, missing comma aftter 'battery_v' :)

[mczakk]

OK< now 'rain_mm' is 0 all other rain values are -1 if you are e matthias-bs on ttn i have added you as a collaborator on my application, if not I've added a random stranger the application is called Bresser_ttn

[mczakk]

seems to be working now, will test tomorrow by tripping the rain bucket :)

[mczakk]

not sure if this is the right place for this, but there is definetely something awry with the decoder! screenshot1 - raw data from bresser as decoded by rtl_433: screenshot 2 node_red output for 13:10-13:12 (decoded by rtl_433 for 13:10 result, by ttn for 13:12 result) scrfeenshot3: aws timestream for same period As you can see, at 13:22:35 and 13:12:37 the ttn decoder decoded the signal as battery_ok false and rain and humidity as 0 whereas the rtl_433 didnt see any change in battery state or rain value over the same period!

[matthias-bs]

Did you check dec_ok? As you can see in the first screenshot, the data is sent in two radio messages. Sometimes one of the messages cannot be received (either not at all or with errors) within the configured time. In this case, incomplete data is forwarded via LoRaWAN, but dec_ok will be false and the data should be discarded.

If you prefer missing uplink messages (in terms of regular cycle times) in favor of incomplete messages, you can set WEATHERSENSOR_DATA_REQUIRED in BresserWeatherSensorTTNCfg.h.

[matthias-bs]

Of course reception results can be different between rtl_433 and this project. I would be surprised if the antenna supplied with the TTGO LoRa32 were really good...

[mczakk]

how do i set the configured time to ensure two messages received?

Also, when i put the esp32 into the feild, it will be connecting to a bresser 5-in-1 chip, (not the 6-in-1 that it is currently connecting to) this unit only puts out one message so the error should go away!

[matthias-bs]

The default for WEATHERSENSOR_TIMEOUT is 180 [seconds], that's pretty long.

Yes, with the 5-in-1 things are much easier!

[matthias-bs]

Here are some hints about improving range/signal quality: https://github.com/matthias-bs/BresserWeatherSensorReceiver/wiki#radio-transceiver-range

[mczakk]

Here are some hints about improving range/signal quality: https://github.com/matthias-bs/BresserWeatherSensorReceiver/wiki#radio-transceiver-range

I think the reception will be better in the feild, in my bench setup the antenna is just on my desk, and the bresser is 10-15 meters away, outside(obvs!), whereas in the field the bresser will be about 15m away with the antenna inside the plastic gateway assembly box. I guess we'll just have to try it and find out!