Humidity readings problem

so I just got three RuuviTags a week ago and I was playing with humidity sensors for a while.
I have two old display sensors, some years old, then three other display sensors from „Pearl“ also about 2 years old, 5 breakout boards with BME280, 3 breakout boards with Sensirion SHT31, two Xiaomi MiJia (LYWSDCHQ) and 5 Xiaomi ClreaGrass (CGG1). The CGG1 should also use Sensirion sensors found that written somewhere.
So up to now I tried a lot with satured salt and boxes with and without fan and stuff to see how accurate all those sensors are and for now I am very disappointed.
I placed a mix of about 10 of the sensors mentioned above in a box for 2 days and in my case it seems the Bosch sensor are all way off. all others are within ±2% but I have no Bosch which is near or within his specs to that values all others read.
So to come to the Ruuvi tags, two of them show about 7% less humidity than the mean of all others and the third one about 10%.
I tried to reset my BME280 breakout boards like describe in the datasheet but no change, there I have also one which is way off but always too low…
I read which says the BME280 are the best but for me this is not the case.
My problem is that all other sensors show about the same values withnin a tolerance of about ±3%.
At the moment I placed all three RuuviTags in a sealed box, one reads 41%, second 42.5% and the third 38.5%.
But two other Sensors (a breakout Sensirion and a Xiaomi MiJia read 48%).
I have really no idea what I should do with all that.
Are all my other sensors wrong?
The problem with that assumption for me is that all others are in the same range and the Bosch are not even reading values in the same range to each other…
Any ideas?

1 Like


Just to clarify, are all of the BME280s including the breakouts having the offset or only RuuviTags?
Can you link to the code used on breakouts?

The RuuviTags read an offset compared to all my other devices.
The breakout boards with BME280 are also lower, I tested one yesterday which was ok (-2% compared to another device which is within its tolerance).
But overall they are not at the same level to each other nor to other devices.
As mentioned earlier two RuuviTag show about the same reading in a box, while the third one is 4% lower.
For testing the breakout boards I use Esp32 development boards with firmware created with Esphome. I checked the calculations used and they are the same as yours, copied from the datasheet using the calibration values.
Maybe all my breakout boards are not so good, China stuff, but I assumed at least that the RuuviTags read about the same values within their tolerance which is not the case.
I tested all my SHTC3 breakout boards which just show the same values.

So overall for me the BME280 don‘t work at all. Or it could be all others are wrong and they are… I have no idea, as I also said I tried with saturated salt solution NaCl and the other devices have an offset to 75%, never reached that, but while all other read 72% -74% the RuuviTags are at 65%, the third one even lower.

I read the blog entry I linked, I read your blog post about testing but I can‘t get reliable results.
I have chemical clean NaCl and destilled water and a sealed glass where I can place the sensor directly over the solution but nothing in the range of 75%…

How’s the temperature on the different sensors? Relative humidity is a bit problematic when it comes to changing temperatures (becuase RH is not an absolute unit of measurement, it is calculated from temperature and the absolute humidity), for example 8.67 g/m3 absolute humidity is 50% relative humidity at 20C and at just one degree more (21C) the relative humidity is 47.17%

I did some additional tests and monitoring.
I placed all three tags I have in a sealed box with a ventilator and an ESP32 dev board with a BME280 and an SHT3X on breakout boards.
Here are the graphs:

The change from first to second was I changed the breakout boards so the BME280_1 and the SHT3DX_1 on the second image are different sensors.
I have several issues with those graphs.
At first the humidity of the two SHT sensors is about 7% higher than those of the tags and the BME280 while the temp is about 0.5°C higher. Given their measured temp is higher, relative humidity should be lower and 7% is a lot for me and the delta of two SHTs is the same…
Regarding just the BMEs tag 3 has always the highest temp and the lowest humidity, that is ok given rel. hum is lower at higher temps with same abs. hum. But the temp difference is just 0.2°C and it is constantly +1% lower than the others.
Tag 1 and 2 are pretty much equal to the two BMEs on breakout boards.

So for sure you can base this all on the specs and maybe everything is within the specs, but my major issue is the global offset of about 7% of the BME.
And considering the SHTs are on the same level as all other and older sensors I have I tend to think the SHTs are what is ok for me.
From what I “feel” is that the SHTs are in the right range as 50% feels good, 60% feels wet, but the BMEs and the tags show ~53% when it feels wet.

So a simple way for me would be to just add 7% to all tags but this still does not give me a good feeling dealing with that topic…

1 Like

Ok here a third image:

I changed to the third SHT sensor breakout board and to another BME breakout board which is apparently faulty, green line is +4% of the SHT sensor…
Everything else as before, the SHT is +7% above the tags while reading just +0.6°C.
Funny is that the biggest humidity difference is to tag 3 but the temp difference to that tag is the least…

We have linked this post to Bosch field application engineers, and they’re looking into it. However these things always take some time. The offset in these units is higher than we usually have observed, for example the BME280 in this image has 43,4 %

Please contact and we’ll figure out the next steps.

Thanks @otso, think we will find a solution, I am not looking for some freebies or something else…
All I want is a reliable humidity measurement and I loved the project right of the start when I found you some weeks ago.
All I read about the BME sensors was that they are good and reliable, see the blog post of that guy who did all that test with various sensors, and I thought my initial problems with the breakout boards was because they are from China…
Then with all the sensors on my table I did as I already told, put them all in a sealed box and then I was in doubt, I had 10 sensors and 10 readings where all readings other than the BMEs have been at the same level withing the specs -+3% or so, so again I though “China junk”, and then I ordered the RuuviTags and did the same. And to my surprise the result was again the same.
As all the new sensors are at or around the level my previous “offline” sensors are I take the now for real, what would you do?

Sorry for all that trouble…

Just one question, I saw I got the very latest hardware version of the tags with that empty spot for an SHTC3 sensor, I have some naked SHTC3 sensors lying around, is the new firmware in a shape where I can use it to test both sensors on one board? If so I would like to try to place one of those on one tag just to see what they read in direct comparison…

Obviously the RuuviTags should display correct values. We’ll know more once Bosch reports back on how they would like to investigate this issue,

We have a sensor comparison firmware, but it’s meant for internal testing only. It’s not power optimized and the original firmware cannot be restored without a Ruuvi DevKit after update. You can install other development FW versions via DFU too though and we’ll probably release a stable and power optimized version soon enough.

I can share the firmware via private message if you wish, but naturally soldering new components and installing experimental firmware would void the warranty. Please email sales first.

That’s clear :smiley:
Yeah I will wait for further progress, will write your sales a mail…

Here another comparison, this time more real life, all tags in my office right under a Xiaomi CGG1 device:

and here the graphs of about the last 12 hours:

The spike was installation and firmware update, all tags run since then on the latest 2.5.9 firmware…