One of the things I never see in reports like this is what sensor is being used (is it a Bosch unit? Sensiron? Plain thermistor? Pixies and Fairy Dust? Some bodged together 1wire deal?) and what MCU (Nordic? Espresif? Microchip? Something else?) as those have a huge bearing on what the sensor is actually capable of, and would say a lot about precision/accuracy and battery life.
How is that relevant for the average buyer (as much as these things have an average buyer anyway)? Precision, accuracy, and battery life is helpful info but the inner components are an irrelevant detail. It's not like having a high quality part prevents them from using it wrong anyway.
The datasheet gives you much better fidelity data than an N=1 test. You'll never know what the tolerance is if you're just looking at one unit. Presumably the average buyer cares if they expect the temperature sensor to be 5% off on the unit they buy. The accuracy of all of these sensors have ratings, but they are often just copying the value on one component and not even considering a stackup. Devils lie in details.
The datasheet will gives you absolute best case scenario. Like current consumption in sleep mode, or what register to set for best accuracy. It does not mean the Firmware will do exactly that.
The datasheet gives you the 3 sigma worst case for accuracy.
For power consumption a system power tree needs to be constructed and that will set the bounds that firmware can achieve. That would be better than trusting the manufacturer but a real test is best.
Avg buyer wont read a token of tests before buying whats marketed best.the whole point in test like these is to provide non-average buyer with info average buyer doesnt care for.
There's no guarantee that the COOL SMARTHOME SENSOR V1 has the same sensor or MCU like the COOL SMARTHOME SENSOR V1 that I can buy. Sure, it's interesting to know, but it's not too usefuly
Chipset models only form a weak lower bound on crappiness.
You can certainly wreck connectivity with bad and old firmware. Similarly, housing design, PCB thermal isolation, not putting the sensor next to the MCU, measurement averaging settings, etc. all are going to affect accuracy even with the same sensor (particularly dynamic accuracy).
I think buyers care more about accuracy and resolution than which sensor. If it’s accurate, with hugh resolution and has good battery life, do you care if it’s Bosch or A Chinese name you’ve not encountered before?
I don't so much care if it's a Chinese knock off or a real deal Bosch BMP, but if you're interested in measurements that are better than vague vibes, the difference between a cheap poopoo glass thermistor hooked up to the noisiest 8-bit ADC (let's be real about what's actually in there), sets a real limit on anything that device will ever be capable of, especially if you have more than one. If a device has got a real deal BMP581 (yes that's a pressure+temp sensor, but let's roll with it) that's a whole other ballgame, and yeah they could have messed up the housing or it could brown out, have bad lower power characteristics, or bad firmware, but that BOM difference says a lot about what the engineer who designed it probably thought the device should be capable of.
For most of these small sensors you'll need to crack open the device to find out exactly what hardware is really there. More than once I bought at different times apparently identical Zigbee sensors which behaved very differently and it turned out they were different inside despite having the same model name. Probably a hardware revision thing but with no clear markings. Manufacturer couldn't find some component anymore or not for a good price and instead redesigned the device.
Those who care about the internals are techies who maybe want to build their own or are very curious. Most buyers don't care about that, they care about how well it works in practice. Just like they don't care what RAM chips are used in their phone or computer, what modem, what screen panel, what camera sensor, etc.
How does Zigbee compare to Matter? (as in, devices in the market, I know they are different levels but from a consumer perspective, there are zigbee switches and matter switches..) I've been using Matter switches because of HomeKit. Been pretty happy.
I do not have any Zigbee devices but I have many Hue devices. Their connectivity is shit. Button presses are not being registered. Sometimes commands do not reach devices etc. That's why I tried to avoid Zigbee.
But the low power battery operated zigbee stuff are pretty attractive if things work fine.
I have seen repeated discussions in Home Assistant adjacent forums that Matter based devices have considerably shorter battery lives, compared to zigbee things that run on one CR2477 cell. Or things that use zwave800 chipsets. I have no Matter devices myself, but I've seen it often enough and from different people who don't seem clueless that it is concerning.
Coin cell batteries are the bane of my existence. All the temperature sensor I have are all coin cell's. Every year I have to replace them and throw them out instead of using rechargeable batteries that you can reuse, so annoying.
I never knew Ikea had temperature sensors, might replace my current ones with Ikea even if they don't use Zigbee. AAA batteries are great!
The nicknames for the sensors is really annoying. I could only get one of the dots to actually tell me anything, and scrolling back and forth for the key suuuucks
I have 12 of the Aqara's deployed in my house. Initial setup was frustrating for some (they would lose connection after a day), but now that my Zigbee network is a little more solid (the Aqara's don't seem to use IKEA smart plugs as routers) I don't have any issues.
Aqara sensors use zigbee, but NOT the full protocol, like Ikea ones for example. So they work fine, until they lose a connection to a router. Zigbee protocol dictates that it will need to try connecting to another router, but aqara does not.
I have a lot of these sensors in my home, normally the connection is fine (5+ years) but sometimes I lose one. Because somebody turned off the lamp (ikea one, acting as a router) (by cutting the electricity to it) by mistake. Then, the connection is lost to that router and it will not try to reconnect.
When the router does not switch, the connection stays. I don't even need to re-pair when changing the batteries!
I've read this somewhere, take it with a grain of salt and validate it yourself if possible.
Hmm interesting I have 4-5 of them and quite like them. They've all stayed connected over a year except 1 which I just replaced the battery in and I think that fixed it. It was reporting 40% battery but would drop off shortly after connecting.
Aqara might be the ones with a crappy ZigBee implementation that doesn't roam right so if you move them or your topology changes, they'll drop off.
Very interesting. I wonder if there's some compatability thing or network topology/density/something that screws them up.
Half of people seem to swear by them, and half hate them. They did seem great until I kept having to reconnect them every couple days, so I get why the lucky ones are happy.
Same, I have scads of them (~8) and have never had connection issues with any of them. I made sure to only pull the battery tab and turn them on for the first time in their target location, maybe that makes a difference, and my zigbee network is quite dense, so there's no lack of mesh for them to connect to.
I'm 2 years in, I think, and I have never noticed any issues.
I have about 15 Aquara sensors in my house and had no real issues for the last ~3 years. Only real annoyance with the Aquara ones is that the battery opening mechanism has the worst piece of plastic I have ever seen. I still have not found a reliably way of opening those damn things without breaking the soft plastic. If anyone has found a way to do that I am all ears
I can't open those with a coin, the plastic is too soft indeed. But if I stick them to another object using the included sticker I can just rotate the device itself to reach the battery. If you want it to be mobile you can stick it to something small or a 3d printed piece of plastic.
I have to agree. Aqara make some excellent hardware, but their Zigbee firmware is typically awful. Their battery-powered switches also drop off the network at random.
I have several E1 wired switches and had to resort to replacing the firmware on them[0]. They don't drop off the network as their sleepy end devices tend to, but they also can't be bound to other devices.
Agreed. After the headache of getting them paired and dealing with repeated disconnections, I tried out a few bluetooth sensors and was pleasantly surprised. Specifically Govee H5074 and similar. No pairing troubles. They just work. Battery life is definitely over a year, possibly 2. A pack of three can be had for <$40.
I have one Bluetooth sensor, but its range is not enough to cover the distance to the router. Zigbee carries a lot further in my experience. I need 15-20 meters with two heavy walls in between.
My Zigbee sensors are these Aqaras, and the initial pairing has worked just fine.
It's a known issue with them that they don't ever change their routing. If you connect them in a different place than you use them, you're going to have suboptimal to unusable routes.
I haven't any issues with them, and I've had them for years. In fact, they were the foundation of my smart home setup, and continue to be central.
They worked fine with the ConBee 2, and work fine with the ZBT-1 that replaced it.
That said, they're used within a relatively small area, and have direct connection to the coordinator. My one (major) annoyance with them is how hard it is to open the battery compartment, the plastic is too soft.
I've since added some Sonoff T+H sensors which are fine, though twice as big.
My one disappointment is the Arre (Thread) sensor, which has low resolution and bad battery life.
I put the Ikea Thread sensor in my fridge a while back and it's been a lot more useful than I expected. My fridge had been periodically getting too cold or too hot, I suspect the issue is that the captive touch buttons that control the temp get occasionally bumped, changing the set temperature. With the thread sensor I can have Home Assistant send me an alert when the fridge leaves the safe zone for too long so I can manually correct it.
It's also been interesting to see when placing hot food in the fridge how long the temperature stays elevated for. I put the sensor in a ziplock bag and sucked the air out of it so it has weatherproofing.
What would normally happen is I’d start seeing things freeze so I’d adjust it hotter until one time some things went mouldy sooner than I’d expect so I put the sensor in the fridge to get a better idea what is going on. Seeing the data, the fridge seems to once every couple months just move to a colder temp and stay there until I adjust it back again which is why I think it’s just the button getting bumped.
Being able to see the fridge temp to a tenth of a degree and getting alerted when it’s wrong has been much more useful than I expected. The safe fridge temp is a fairly narrow band that’s basically impossible to hit without a proper temp sensor.
I've worked in grocery retail, and this is exactly the boring problem that quietly eats money: a fridge drifts a couple of degrees overnight and nobody notices until the stock has to go in the bin. a cheap sensor with an alert for "out of range for 20+ minutes" pays for itself the first time it fires. the "too long" part matters more than precision, door openings make single readings useless
I have a mix of Sonoff and IKEA. Both work well for me, but the IKEA DIRIGERA API reports the IKEA TIMMERFLOTTE as two separate devices with different names, and it messed up my Grafana dashboard.
It's the most first world of first world problems, but purely for that reason any more I buy will be Sonoff.
Testing a single unit and assuming the rest of the production units have the same variance is quite risky. Some sensor manufacturers calibrate at factory but even then we’ve seen outliers.
Ruuvi Air is perhaps the most open source device I've seen that measures CO2 etc. and is not set up to be an online device. The company itself (Ruuvi) does pretty much all their development in the open, and the Ruuvi Air sensor is the same. Uses a pretty high quality sensor module that includes actual CO2 and PM among others. I went for it after buying a cheaper sensor that only had a cheap sensor and algorithm based estimate of CO2, not a real measurement. Additionally it required an app so it was already a headache. Ruuvi Air only uses BLE so it shouldn't be able to send anything outside your BT range. The iOS/Android companion apps only include local push alerts when a measurement crosses over your set threshold.
> To get an accurate base for benchmarks, I decided to calibrate it against a lab-certified thermometer at a friend’s butcher shop, as weirdly as that sounds. His particular thermometer gets checked and calibrated by the state on a schedule (every 3 months) because it sits inside a commercial meat refrigerator and it is required by law. After calibration, my MHO-C401 needed an offset of minus 0.5°C and plus 4% humidity to match the reference reading exactly.
> It is worth clarifying from the start that my setup does not represent typical room comfort conditions, since the calibration was done at a much lower temperature, around 4°C. Sensors do not always respond in a perfectly straight line across a wide temperature range, so this fixed point is not a guarantee of the exact same accuracy at room temperature.
This can be fixed pretty easily if you are up to a little simple DIY.
Instead of using the MHO-C401, calibrated at one point against a lab-certified thermometer, build on a solderless breadboard your own temperature/humidity sensor using an ESP32 or ESP8266 dev board and a Sensiron SHT45 temperature/humidity sensor and program it using Arduino.
The SHT45 communicates with the ESP over I2C. The wiring is simple: ESP 3.3V, GND, SDA, SCL to SHT45 VCC, GND, SDA, SCL, in that order. Just 4 wires. The ESP dev board will be powered by USB. (If you need it to be battery powered, just use a small USB power bank).
The SHT45 has an accuracy of ±1% RH and ±0.1℃ out of the box.
If you want even better temperature accuracy add a tmp119 temperature sensor. This too uses I2C so the hookup is the same as the SHT45 hookup. It has a temperature accuracy of ±0.08℃ max and it typically is ±0.03℃ and is NIST-traceable out of the box. This is across a range of 0℃ to 45℃. (Outside that range it is ±0.2℃ from -55℃ to 150℃).
Adafruit has all the sensors [1][2]. Those have JST connectors using a standard pinout for daisy chaining I2C devices, which would be good for this application so when measuring temperature in the fridge or freeze you don't have to put the whole breadboard assembly in there. They have cables up to 400mm long [3].
You know what...you don't even actually need the breadboard! Here's a JST to female socket cable [4] that could connect one of the sensors to the pins on the ESP dev board.
ESP, that cable to the sensor, and if using two sensors, the sensors daisy chained with JST to JST cable.
Adafruit has ESPs also, but they seem to be out of stock on most of them. There are plenty of suitable ones on Amazon that are pretty inexpensive.
I'd say go for an ESP32 C5 or C6. They both support 2.4 GHz wifi and Zigbee, so your have the choice of reporting reading to a web server or making your DIY reference temp/humidity sensor use Zigbee. The Arduino library from ESP includes built in classes to make making Zigbee sensors easy.
Oh, they also support Matter over wifi, so you could make this a Matter device.
The C5 adds 5 GHz wifi.
Just remember that an ESP32 generates enough heat due to the radio that these sensors will pick it up if the are too close. If you build on a breadboard don't be the sensors right next to the ESP.
This is a fairly reasonable first project if you've not done any MCU stuff before but do have programming experience, especially nowadays with LLMs. They seem to have a pretty good grasp of Arduino stuff. (Don't just vibe code it! Just use them when you get stuck on something or want some documentation clarified or things like that. That will be a lot more interesting).
I have a sensor in every room. They are used to control radiator thermostats. The thermostats have their own temperature sensors of course, but can't be relied on because 1) it's literally next to the radiator, and 2) are often covered by curtains, so they're inside a hot air pocket.
HA uses the external sensor readings to set an external measured value for the radiator thermostats.
I run HA solely in my wine cellar, it's exceedingly useful to have an indoor hydrometer monitoring my conditions. I run 3 in different parts of my wine cellar.
It can replace expensive thermostat sensors. For example an Ecobee Smart Sensor two pack has an MSRP of $100. You can connect the Zigbee sensors to Home Assistant and adjust your thermostat based on your bedroom if it gets too hot when you sleep. Or turn on your whole house fan.
I seriously looked at yolink for fridge/freezer sensors, but just couldn’t stomach their pricing in Canada. (e.g. the Local Hub is 200 USD in the US, or 285 USD in Canada.)
I ended up with some Ecowitt (hardware sold under the Ambient Weather brand in the US) sensors and they’ve been working great for some months now. (900mhz RF has good penetration and the sensor hardware is generally appropriate for -20C operation.)
Hah. I did something similar a while ago, but I also did full saturated salt solution humidity calibration. It's very simple to do: get several different salts, create a saturated solution in a sealed container, and observe the humidity there.
The best sensor in my tests was CentraLite 3310-G. It was the only one actually precise to 1% of RH and 0.1C They are also pretty robust and long-lasting.
> you absolutely must press the pairing button on the sensor first to wake it up before sending the new reporting configuration. Sending the payload while the device is asleep just gets ignored
This stuff is still so user unfriendly.
Why cannot the software just save the desired setting to set it when the device comes online next?
I feel like many things in zigbee2mqtt are like that: I click something, it fires off some message and it often isn't clear if that worked, if it'll work later, and so on.
For power consumption a system power tree needs to be constructed and that will set the bounds that firmware can achieve. That would be better than trusting the manufacturer but a real test is best.
Similar reasons: the intended audience isn’t the average person.
Avg buyer wont read a token of tests before buying whats marketed best.the whole point in test like these is to provide non-average buyer with info average buyer doesnt care for.
You can certainly wreck connectivity with bad and old firmware. Similarly, housing design, PCB thermal isolation, not putting the sensor next to the MCU, measurement averaging settings, etc. all are going to affect accuracy even with the same sensor (particularly dynamic accuracy).
Those who care about the internals are techies who maybe want to build their own or are very curious. Most buyers don't care about that, they care about how well it works in practice. Just like they don't care what RAM chips are used in their phone or computer, what modem, what screen panel, what camera sensor, etc.
I do not have any Zigbee devices but I have many Hue devices. Their connectivity is shit. Button presses are not being registered. Sometimes commands do not reach devices etc. That's why I tried to avoid Zigbee.
But the low power battery operated zigbee stuff are pretty attractive if things work fine.
Ikea selle rechargable ones for really cheap additionally.
I never knew Ikea had temperature sensors, might replace my current ones with Ikea even if they don't use Zigbee. AAA batteries are great!
https://community.home-assistant.io/t/ikea-kajplats-smart-bu...
https://community.home-assistant.io/t/ikea-kajplats-smart-bu...
via
https://www.reddit.com/r/homeassistant/comments/1tvtyyj/ikea...
https://news.ycombinator.com/item?id=49957835
I have a couple of the Tuya ones and I'm pleased with them. The humidity accuracy is questionable, but it's fine.
I also have an airgradient (not zigbee, uses wifi) for high accuracy the one place I care about that. Works great in Home Assistant with esphome.
Aqara sensors use zigbee, but NOT the full protocol, like Ikea ones for example. So they work fine, until they lose a connection to a router. Zigbee protocol dictates that it will need to try connecting to another router, but aqara does not.
I have a lot of these sensors in my home, normally the connection is fine (5+ years) but sometimes I lose one. Because somebody turned off the lamp (ikea one, acting as a router) (by cutting the electricity to it) by mistake. Then, the connection is lost to that router and it will not try to reconnect.
When the router does not switch, the connection stays. I don't even need to re-pair when changing the batteries!
I've read this somewhere, take it with a grain of salt and validate it yourself if possible.
Aqara might be the ones with a crappy ZigBee implementation that doesn't roam right so if you move them or your topology changes, they'll drop off.
Half of people seem to swear by them, and half hate them. They did seem great until I kept having to reconnect them every couple days, so I get why the lucky ones are happy.
I'm 2 years in, I think, and I have never noticed any issues.
I have several E1 wired switches and had to resort to replacing the firmware on them[0]. They don't drop off the network as their sleepy end devices tend to, but they also can't be bound to other devices.
[0] https://www.ducktoast.com/blog/electronics-projects/aqara-e1...
My Zigbee sensors are these Aqaras, and the initial pairing has worked just fine.
+1, complete waste of time and money. I thought my Zigbee network or HA was the problem, but the sensors are just garbage.
They worked fine with the ConBee 2, and work fine with the ZBT-1 that replaced it.
That said, they're used within a relatively small area, and have direct connection to the coordinator. My one (major) annoyance with them is how hard it is to open the battery compartment, the plastic is too soft.
I've since added some Sonoff T+H sensors which are fine, though twice as big.
My one disappointment is the Arre (Thread) sensor, which has low resolution and bad battery life.
It's also been interesting to see when placing hot food in the fridge how long the temperature stays elevated for. I put the sensor in a ziplock bag and sucked the air out of it so it has weatherproofing.
Works great.
Being able to see the fridge temp to a tenth of a degree and getting alerted when it’s wrong has been much more useful than I expected. The safe fridge temp is a fairly narrow band that’s basically impossible to hit without a proper temp sensor.
It's the most first world of first world problems, but purely for that reason any more I buy will be Sonoff.
CO2 and equivalents on the other hand is Wild West.
> It is worth clarifying from the start that my setup does not represent typical room comfort conditions, since the calibration was done at a much lower temperature, around 4°C. Sensors do not always respond in a perfectly straight line across a wide temperature range, so this fixed point is not a guarantee of the exact same accuracy at room temperature.
This can be fixed pretty easily if you are up to a little simple DIY.
Instead of using the MHO-C401, calibrated at one point against a lab-certified thermometer, build on a solderless breadboard your own temperature/humidity sensor using an ESP32 or ESP8266 dev board and a Sensiron SHT45 temperature/humidity sensor and program it using Arduino.
The SHT45 communicates with the ESP over I2C. The wiring is simple: ESP 3.3V, GND, SDA, SCL to SHT45 VCC, GND, SDA, SCL, in that order. Just 4 wires. The ESP dev board will be powered by USB. (If you need it to be battery powered, just use a small USB power bank).
The SHT45 has an accuracy of ±1% RH and ±0.1℃ out of the box.
If you want even better temperature accuracy add a tmp119 temperature sensor. This too uses I2C so the hookup is the same as the SHT45 hookup. It has a temperature accuracy of ±0.08℃ max and it typically is ±0.03℃ and is NIST-traceable out of the box. This is across a range of 0℃ to 45℃. (Outside that range it is ±0.2℃ from -55℃ to 150℃).
Adafruit has all the sensors [1][2]. Those have JST connectors using a standard pinout for daisy chaining I2C devices, which would be good for this application so when measuring temperature in the fridge or freeze you don't have to put the whole breadboard assembly in there. They have cables up to 400mm long [3].
You know what...you don't even actually need the breadboard! Here's a JST to female socket cable [4] that could connect one of the sensors to the pins on the ESP dev board.
ESP, that cable to the sensor, and if using two sensors, the sensors daisy chained with JST to JST cable.
Adafruit has ESPs also, but they seem to be out of stock on most of them. There are plenty of suitable ones on Amazon that are pretty inexpensive.
I'd say go for an ESP32 C5 or C6. They both support 2.4 GHz wifi and Zigbee, so your have the choice of reporting reading to a web server or making your DIY reference temp/humidity sensor use Zigbee. The Arduino library from ESP includes built in classes to make making Zigbee sensors easy.
Oh, they also support Matter over wifi, so you could make this a Matter device.
The C5 adds 5 GHz wifi.
Just remember that an ESP32 generates enough heat due to the radio that these sensors will pick it up if the are too close. If you build on a breadboard don't be the sensors right next to the ESP.
This is a fairly reasonable first project if you've not done any MCU stuff before but do have programming experience, especially nowadays with LLMs. They seem to have a pretty good grasp of Arduino stuff. (Don't just vibe code it! Just use them when you get stuck on something or want some documentation clarified or things like that. That will be a lot more interesting).
[1] https://www.adafruit.com/product/5665
[2] https://www.adafruit.com/product/6482
[3] https://www.adafruit.com/product/5385
[4] https://www.adafruit.com/product/4397
HA uses the external sensor readings to set an external measured value for the radiator thermostats.
I ended up with some Ecowitt (hardware sold under the Ambient Weather brand in the US) sensors and they’ve been working great for some months now. (900mhz RF has good penetration and the sensor hardware is generally appropriate for -20C operation.)
The best sensor in my tests was CentraLite 3310-G. It was the only one actually precise to 1% of RH and 0.1C They are also pretty robust and long-lasting.
This stuff is still so user unfriendly.
Why cannot the software just save the desired setting to set it when the device comes online next? I feel like many things in zigbee2mqtt are like that: I click something, it fires off some message and it often isn't clear if that worked, if it'll work later, and so on.