Just received three beacons. It seems that the temperature fraction of each beacon is always zero. Is this intentional or some issue with the sensors?
This is intentional on weather station firmware, as changing the fraction would change the URL, and show up as a new notification which is incredibly spammy.
For higher resolution, we have experimental Sensortag firmware: https://github.com/ruuvi/ruuvi-sensor-protocols .
Sensortag is meant to be used with data loggers, and it sends also accelerometer and battery voltage data.
We’re going to reIease the SW soon. I can send you the package if you want to try it out earlier, please PM me for details
1 Like
Is the firmware out yet somewhere? I can’t use PM to request it since the forum system does not support it or does not allow me to use it as I just registered…
I pushed a DFU package to git branch: https://github.com/ojousima/ruuvitag_fw/blob/feature-sensortag/builds/distribution_packages/sdk12/debug/sensortag_06.zip . Please note that the package is experimental, and it may do anything or nothing at all 
. We have been running that package on environmental test chamber, and so far we have not discovered any major issues with the package.
Edit: Sensortag mode is now supported by base weather station firmware, press button “B” to change mode
Perhaps an alternative Weather Station fw could be supplied that has the fractional data enabled without having to go all the way to the SensorTag protocol?
Collecting and parsing the Eddystone advertising is much easier (in Node-RED and other platforms) than having to resort to low(er)-level custom Manufacturer Data blocks, and I don’t need all the extra data and frequency of update: just fractional temperature (even just one decimal place) and humidity. In fact, updating once a minute or so would be fine too, for long-term data.
There’s such a huge learning curve and complexity gap between simple iBeacon / Eddystone level work on BLE and dealing with custom data. I’ve clicked the B button on the new firmware to get the high-precision data, but none of the common libraries and utilities see that data out of the box now.
As setting up a build environment for custom firmware is a chore, a simple variant of the existing firmware to populate the fractional field would be very much appreciated!
EDIT: Oh, hang on… it looks like it’s reporting fractional temperature in the newer protocol (4?) I’m not sure why it wasn’t working when I wrote the message above. If so, never mind
Note that the new weather station code released on 20170418 resets the fractions back to zero.
Could you please post the source.
GitHub - ruuvi/ruuvitag_fw: RuuviTag firmware projects , ruuvi_examples/weather_station and folders “drivers” and “libraries” as well as Nordic SDK 12.2.
Yes, it looks like that. Does anybody know if the next weather station firmware has again temperature fractions with the high-precision mode? Any idea on the publishing date?
Sending fractions in URL is very spammy, as the URL updates whenever fraction updates and this leads to high amount of notifications.
Please use the sensortag mode (press B) and use one of the scanner libraries if you need higher precision.
Thanks Otso. That is what I did. I am running newest Ruuvitag weather station firmware and the high precision mode. I am using the ruuvitag-sensor python library and running it on python2 on raspberry PI 3. I already reported today a bug related to this library when run on the python2, it looks now like there is also another problem and it is the temperature fraction. I made some printouts to the library code and I can see that the fraction information is coming. I.e. data[2] is 23 and data[3] is 16. But the function simply returns 23 instead of 23.16. I am assuming that the data[3] contains the fraction.
Yes, the problem is in the ruuvitag-sensor library when using python2.7. I’ll report this bug