You tried this node, or just trying theory?
The firmware itself would require recompiling for calibration on sensor side, it would be possible to do the calibration on receiver software but we don’t have a ready-made example of this yet.
The temperature error sounds quite large, tags have been used to log saunas with reasonable results: https://graphs.2kgwf.fi/dashboard/db/sauna . Are you sure the error is not caused by tag placement (near stove or ventilation shaft, perhaps?)
Did you let sensor to acclimate before trusting the data? Conditions in plastic containers changes slowly comparing to outer conditions.
The weather station app just received a major update:
- Added support to RuuviTag basic
- Added “sensortag”-mode, where tag sends all sensor readings (including accelerometer) in binary. Switch between modes by pressing “B”. Green led blinks in URL mode, Red led blinks in sensortag mode.
- Added random identifier character to URL mode. This should help people to identify the tag if they have several tags nearby.
Please check out the update at https://ruu.vi/setup , and let me know if you find any issues.
Format of both messages seems to have changed?
I will check if I can see what has changed, but it would be great if you could document new formats.
The sensortag format should be exactly same, please let me know if there is some issue.
The URL mode now has “4” as first byte, and and ID character at the end of URL. Documentation is on Github.
The format “4” seems to now also include temperature fractions. Is that intentional?
The format includes the fractions, however the fraction should always read as “0”.
I seem to be now getting fraction parts different than 0.
For me, that is fine, I do not need to write new code to access the format “3”.
2017-04-17 1:32:09 (1492435929) beacon=makuuhuone (fbe375e302e0), t=21 C, P=1021 hPa, r=26 %
2017-04-17 1:32:09 (1492435929) beacon=vierashuone (e013b4dff14b), t=23.046875 C, P=1021 hPa, r=20 %
Just wanted to let you know in case this was not intentional
Managed to fix my python code.
I am also getting fractions now with format 4:
2017-04-17 19:58:19,551: INFO: MAC:cf:b0:a6:07:68:05 RSSi:-72 Type:W humi:28.0 temp:19.0 pres:1016.0 AccX:0 AccY:0 AccZ:0 batV:0
2017-04-17 19:58:19,555: INFO: MAC:d5:e5:4c:fd:55:b1 RSSi:-51 Type:W humi:30.0 temp:23.240000000000002 pres:1016.0 AccX:0 AccY:0 AccZ:0 batV:0
Thank you for the reports, there is a bug which makes URL format have too high precision. I’ll publish a bugfix tomorrow.
EDIT: Fix published, thank you for the reports. There is no need to upgrade if you’re happy with the fractions in data.
This function not working anymore, after update to version 2017-04-18. Why?
It could be caused by update to data format which now contains ID character. You can either update the code to accept format 0x04 or you can roll back to previous version here if you do not plan to use the sensortag mode.
Thank You for the information!
In addition to operating as sensortag there any difference between the two versions? Why is the protocol specification has changed?
This is my extracted URL, BGgKAMIkf
The URL has now ID character in the end, and format byte was updated to reflect this changes. Since you’re seeing only 6 bytes, I’m assuming you’re missing either first or last byte.
Is there a change in how this new sensortag code measures battery voltage? I get varying numbers with the newest version (like 2959, 2959, 2947, 2959, 2971, 2947,…) while the numbers with earlier beta release of sensortag have not changed at all since many days?
This is ther url, and base64 decoding give me 6 byte.
In my opinion, it is unfortunate that these two formats are not compatible backwards. What is the practical use of these 6-byte ID character?
You must decode only the 8 characters after the # in the url. The 9th is the ID char which has not been encoded, so do not decode that. Doing it like that makes formats 2 and 4 compatible.
The practical use for ID character is to tell the tags apart in web site, although this has not yet been implemented. Some people have for example 3 tags, one in freezer, another inside and third outside. Adding the ID character allows them to tell which tag sent the data.
Battery voltage varying a little sounds like normal ADC variance, I’d guess that there was a bug in beta release if the sent value was always exactly same.