API values rounded


I’m running a weewx installation with a Tempest. I’m experimenting with the driver, as I don’t really like that it doesn’t record whenever weewx is not running. I want it to update even then so I’m experimenting with an extension to the driver that fetches data from the API when weewx starts and then starts listening to the UDP packages. This seems to be mostly working.

However I notice that some graphs look different when it has fetched data from the API. For example, take a look at this temperature graph from the UDP-only prod system:
Compare that to the image from the API-fetched data of the same time-period:

I see the same thing for humidity and other sensors. Checking the API I see the same thing happening. For example, when looking at the UDP-package just now, I see a temperature for 0.38. Fetching the same sensor readings via the REST API gives me 0,4. There’s rounding going on, which is explaining a lot I suppose.

Is there a good reason why the REST API values are rounded?


1 Like

I agree, the rounding should be left to the very last step. It is never a good idea to round values twice during a calculation. So if udp gives more precise data, so should the api. This for example increases the accuracy for people living in the country that doesn’t use metric system, as the conversion to Fahrenheit can be done without rounding twice.
It could also be useful for people that want to derive other parameters using some formula and prevent rounding twice.

1 Like

This is very interesting, not something I have noticed before, and definitely not ideal in my opinion for the reasons already outlined by @sunny. For certain fields (such as local day rain accumulation) the API reports up to 6 decimal places, so it is odd that other fields are rounded. I am going to tag @corrineb here in case it is a bug

PS @jjvdgeer - it would be great if you could share your extension when it is finished. What you are trying to achieve with the switch over from API to UDP will be really useful addition

1 Like

Let’s keep this on topic, but my work can be found in my own branch of the driver: GitHub - jjvdgeer/weatherflow-udp: WeatherFlow Personal Weather Station driver for weewx, via UDP broadcast packets but there’s no instructions yet, there’s some extra configs needed (API key for example) that are not documented yet. It’s my first work in python so… :slight_smile:

1 Like

Thanks for the report. Indeed, we are storing temperature and humidity and a few other variables at a lower resolution than the hardware reports. Although they’re still being stored at a higher resolution than the accuracy of the devices, we agree that it would be better to store the raw values, for all the reasons mentioned here. Any reduction in resolution should be done at the application level.

We’ll revisit this and come up with a solution soon. Thanks again.