Wireless Weather app does not like the rain value that is receiving from the Alecto v1 rain gauge.
19:45:28.507 Received payload for Alecto v1
19:45:28.510 [alectov1] 36 [0,1,0,1,0,1,1,1 ,0,1,1,0, 1,1,0,0, 0,0,1,1,0,1,1,0,1,1,0,0,0,0,0,0, 1,0,1,1]
19:45:28.514 [alectov1] Value out of range: 219 (rainrate)
Reason seems to be that the rain value provided by the gauge is actually the total rain it got since it was powered.
This 16 bits wide unsigned binary number represents the accumulated (since power on) rain data in 0.25 mm units.
Usually each tipping of a bucket means 0.5 mm, that causes this number incremented by 2, but in some cases the least
significant bit is also used.
extracted from: http://www.tfd.hu/tfdhu/files/wsprotocol/auriol_protocol_v20.pdf
I understand the application does not do much on the rain value now. Any plan to provide a rate value? (for example rain last 24 hours).
Thanks, I'll change it from 'rainrate' to 'raintotal'. Indeed a rain rate is only shown in case the sensor transmits that figure (like e.g. OregonScientific does).
Hi Ramon,
Time now for the rain gauge.
Wireless Weather app does not like the rain value that is receiving from the Alecto v1 rain gauge.
19:45:28.507 Received payload for Alecto v1 19:45:28.510 [alectov1] 36 [0,1,0,1,0,1,1,1 ,0,1,1,0, 1,1,0,0, 0,0,1,1,0,1,1,0,1,1,0,0,0,0,0,0, 1,0,1,1] 19:45:28.514 [alectov1] Value out of range: 219 (rainrate)
Reason seems to be that the rain value provided by the gauge is actually the total rain it got since it was powered.
This 16 bits wide unsigned binary number represents the accumulated (since power on) rain data in 0.25 mm units. Usually each tipping of a bucket means 0.5 mm, that causes this number incremented by 2, but in some cases the least significant bit is also used. extracted from: http://www.tfd.hu/tfdhu/files/wsprotocol/auriol_protocol_v20.pdf
I understand the application does not do much on the rain value now. Any plan to provide a rate value? (for example rain last 24 hours).
Thanks Javier