Added support for Rain Gauge#1
Conversation
Added mapping for Rain measurement in SENSOR_PROPERTIES and updated
usage documentation.
Running samples/printAllLastData outputs:
```
Rain Gauge
rf_status : 60
battery_vp : 6402
When : 06:39:45
Rain : 0
Indoor
Noise : 34
Temperature : 21.2
When : 06:39:53
Humidity : 31
Pressure : 1035
Co2 : 542
Indoor 2
Co2 : 468
rf_status : 63
Temperature : 23
When : 06:39:38
Humidity : 27
battery_vp : 5882
Outdoor
rf_status : 59
battery_vp : 6132
When : 06:39:51
Temperature : 0.3
Humidity : 61
```
|
Hello, By the way, I wonder if we should add the rain measurement in the lastData call. All other informations are instantaneous values. Rain level doesn't make sense as an instantaneous value, you can only measure the rain quantity that has fallen on a given amount of time and units are not obvious (mm water per square meter or something else ?). What do you think would be the easiest way to supply the value ? Something like amount of rain in the last hour or day to now ? I don't know what units are available, I received my rain gauge a few days ago but had no time yet to test it. Have you tested the value in the data store, does-it give the number of ticks detected by the tipping bucket mechanism in the last "sent data" interval or something more "meteorologic" ? Thanks again for helping |
|
As far as I can see, lastData() is the only place where SENSOR_PROPERTIES is used. My change does fix lastData(). According to Netatmo, the contents of last_data_store is for "internal use only" (http://forum.netatmo.com/viewtopic.php?f=5&t=3113). It doesn’t help that they do include it in their API docs (which are quite thin on details regarding responses). Regarding the value type of the rain measurements, here is what I have figured out so far... Netatmo does not store the tick count of the bucket tips. You can calibrate the tipping volume of the buckets and Netatmo use that volume divided by the collection cone area to arrive at a quantity in millimetres. In other words each tip is equal to x mm of rainfall. The rain gauge seems to sum up the volumes between the times when it records a value to the main device/Netamo's servers. In other words, if the gauge is calibrated at 0.101 mm/tip, and the bucket has tipped 3 times since the last recording, then the next recording will be 0.303. When you query the API at "max" scale, and request the "Rain" data type, each value returned will be the total millimetres of rain accumulated during that recoding interval (average of about 5 minutes). When you query the API with other scales (e.g., "1day") and request the "sum_rain" data type, then each value returned will be the sum of rain accumulated over the scale period (e.g., 3.9 mm for 1 day) I was lucky (unlucky) enough to get rain (mostly snow really) the day after I installed my gauge. Here are the outputs of the API for that day at various scale levels: maxTotal = 3.939 30minTotal = 3.94065757819 1hourTotal = 3.94065757819 3hoursTotal = 3.94065757819 1dayTotal = 3.9 |
By default, for scales other than max, the timestamp of values is offset by +scale/2. For example, for a scale of 1day the times amps will be at noon. The real_time causes the timestamp to be the beginning of the period. Setting realtime to True keeps the timestamp from potentially exceeding date_end.
|
Just added another small change. Looks like Netatmo have added a new real_time argument to getMeasure(). I added this to the library. I thought I would be able to do a separated pull request, but I guess I would need to branch for that to work. New to GitHub. |
|
Hello, sorry for the delay, my bread and butter activity is frequently overloading my agenda these times and, unfortunately, this is rather good news. Still not had time to install my rain gauge. Thanks a lot for your inputs. I understand that the system is counting bucket ticks and compute a water volume with an adjustment factor. It means that, when you read an instant value, you juste have the volume of water that has been counted since the previous data sent which is a time interval not clearly defined (unless the software is continuously monitoring the sensor which is not the idea). I suggest we rather supply volume of water received in specific period of time : last hour, from start of the day, for last slipping 24h for example. That mean a new dedicated method of deviceList (something like getRainLevel(station, interval) using keyword as interval). As a gadget, we could had a function to tell wether it is raining or not (based on any water received in the last 20 minutes that should give two samples), something like deviceList.isRaining(station) returning True or False. We could assumed that there is only one rain gauge per station to ease usage (do you agree ?) Regards Le 29 avr. 2014 à 20:36, asphotographics [email protected] a écrit :
|
|
For my purposes I only need to get the log data from Netatmo. I will be doing all my calculations outside the API. Do you intend for lnetatmo.py to simply be an interface to the API, or do you think it should contain more helpful calculations? Not all station measurements are instant values. Noise/sound, for example is “the average noise level (in dB) over five minute interval”, according to Netatmo FAQs. I do suspect that the sound average is really over the recoding interval, which in my experience averages about 5 minutes, +/- a few seconds. But an average over a period is different from a sum. The question is, if I get two rain measurements from the API, one of 2 mm and one of 2.3 mm, how do I know that the 2.3 mm is due to an increase in the rate of rain and not simply a longer sampling interval (say 5:03 vs 4:57). It is a legitimate concern. From the max scale, one could simply compare the timestamps for the samples in question to calculate the average rain rate to 1 second of accuracy. This would smooth out any increases/decreases in rain rate due to interval length variation.
I think these mock numbers demonstrate that even for very heavy rain (24 mm/h) if the recording interval is +/- only a few seconds then the calculated rain rate for a 5 minute period only varies by less than a 0.1 mm. I think that is pushing the accuracy of the gauge (you would have to have a very accurate calibration). However, if for some reason the interval varies +/- a minute or more, then yes, a calculation accounting for that variation could be useful, perhaps a new helper method as you suggest. I think one does not know why the recoding interval might be extraordinarily long. Perhaps the gauge was not sampling during the entire time because it was rebooting for a few of those seconds (faulty batteries maybe)? Who knows. For anything other than the max scale, I think the API already provides what you are looking for — a sum of rain volume over time. I wouldn’t duplicate that functionality with a separate method. (Though an argument could be made that you still don’t know that exact length of the interval — a 1day summation might actually include samples from 0:00:03 to 23:59:47 one day and 0:00:01 to 23:59:59 the next — but the larger the scale, the less meaningful those few extra seconds at the beginning or end of the period.) Tipping bucket rain gauges are convenient but not perfect. They tend to under report the volume of rain. If rain partially fills a bucket and then stops, then that volume will not be reported until it starts to rain again, maybe hours later (or more likely never as the water will probably evaporate). So far the Netatmo rain gauge has tracked the forecast to within ~0.5 mm per day (haven’t compared it to other stations yet, or done a calibration) even when the precipitation has mainly been in the form of wet snow :( |
|
Your remark about noise being averaged was an interesting point I was not aware off. I thought it was the "instant" measurement that would be possible but with a risk of error due to the relative small size of the sampling (1 point in ms over 5 minutes). I have noticed the 5 minutes pool. But I have seen exception in the network traffic (probably due to migration or downtime of netatmo servers or dns load balancing delay). You are true that this library should stay a simple access to netatmo official library (despite the fact that netatmo refuse to endorse the use of last data store). As far as I have seen (done some network listening to study the protocol between the station and the netatmo server), the time interval is quite stable (at least to a few seconds resolution which is far enough as you said) and the major risk is a sample to be cancelled. The measurement interval for this point then switch from 5 minutes to 10 minutes and a cumulative value would then double ! I suppose this is a reason why netatmo upload the sample time with each sample measurement. They probably correct the value according with the real interval reported. Considering that these are rare events, we will stay with your proposal. The units of the value will be "mm of water fallen during the last 5 minutes"... Can you adjust your change in usage to add a note that specify this unit and I will be able to commit your changes. Thanks for your contribution Philippe Le 5 mai 2014 à 16:47, asphotographics [email protected] a écrit :
|
Added information about unit-of-measure for Rain in lastData method.
|
Change to usage.md done. Cheers, |
Added support for Rain Gauge
|
Thanks for your work. You may have not noticed that netatmo just changed the last_data_store structure without backward compatibility ! Cheers Le 6 mai 2014 à 16:38, asphotographics [email protected] a écrit :
|
2 participants
Added mapping for Rain measurement in SENSOR_PROPERTIES and updated
usage documentation.
Running samples/printAllLastData outputs: