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.
Regarding accuracy, it's been about a decade, but I did some embedded projects related to accurate temperature measurements back in the day. From what I recall, anything sensor that is < $100 or so is going to be 5% margin of error at the very best, and regardless of price, you're going to have to calibrate it and figure out the curves in your ADC, it's not going to be linear. Additionally, just the act of measuring will heat your sensor slightly so that will need to be taken into account as well.
In short, if you need less than a couple degrees of accuracy, it's going to take a bit of tinkering. I wouldn't trust a $1 sensor for a tropical fish tank, for example, but probably good enough for a home thermostat.
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.
If they change components the properties in this test would also change so not sure I get your point other than that any test is useless since manufacturers change stuff without telling the buyers pr changing model numbers.
Unfortunately a lot of these tests are useless because the manufacturers often change the insides without warning. It’s better when they mark different hardware revisions but still not great because reviews rarely get an update.
I have a bucket of devices which don’t do what I hoped they’d do because they were different from what the reviews said. And not just IoT unfortunately. Some do a better job at flagging these changes, some don’t.
But in the end taking the common case that the product is what it says on the box or that the changes have no impact on how it works, most people don’t care about the name of the chips. Not unless they are very keen on the tech and then there are more tech-oriented niche sites that might provide this.
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!
And because it's IKEA, they understand the "spouse acceptance factor" well. TIMMERFLOTTEs may be cheap in construction, but look decent enough, blend well (I have a dozen of them stuck around house, mostly next to light switches and nobody notices), and most importantly, the local display is only on for two seconds, and only when you press it.
They have a more expensive variant looks more like desk alarm clock, that also measures particulates and carbon dioxide (and tells time), and that one can stay always-on (and act as Thread router) - but they wisely remembered to add remotely triggerable switch to switch the display off, too.
I mean to get one of those next time I get near an IKEA. Here at least, it costs less¹ than the sensor inside it.² (Of course, IKEA purchases more than one…)
Except that many people already have Matter servers with Thread Border Routers in their household. Apple TV, HomePod, Google TV Streamer 4K, various Google Nest Hubs, recent Amazon Echo. Heck, even recent iPhones have a Thread radio, so that they can talk directly to Thread devices [1].
I have a lot of qualms with Threads, such as Thread device internet access through TBRs that do not allow you to disable NAT64 (or even worse, getting globally routable IPv6 addresses in Thread 1.4), but complaining that people have to buy another device is not one.
People are far more likely to have a TBR already than an IKEA Zigbee Hub. And even if they hadn't, they could get any other TBR/Matter Server besides IKEAs. So it's not a great way of selling smart home hubs.
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.
It does, though in my case I've purposefully put an IKEA smart plug (which acts as a Thread/Matter router) in the kitchen, too, so the signal only needs to reach 2-3 meters out.
For me, the Zigbee ones (generic ones from AliExpress) have been great inside both fridge and freezer. Bluetooth ones occasionally dropped off (and were much worse re: battery life.)
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
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
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.
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.
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.
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 also do the stick and twist method for opening them, but it always require new adhesive, so not a good solution. I also tried multiple 3d printed jigs for opening but those also didn't work very well
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'm just about to build my own external temperature and humidity sensor, using a Sensiron SHT45 sensor with integrated PTFE filter.
I've had Tuya and Aqara sensors outside, undercover and out of direct rain for the past 3 years, and every one lasts about a year before the humidity sensor gets stuck at the maximum reading. Even bringing it indoors doesn't get it working again. I'm hoping the built-in heater on the SHT45 will help when we're sat in sea mist or sea fog and keep the sensor working for longer.
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.
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.
Hue is super-reliable for most people. Easily one of the best Zigbee implementations out there. Most likely, 2.4 GHz WiFi channels (or Thread channels) are overlapping with your Hue Zigbee channel.
Deploying 2.4GHz Wifi, Zigbee, and Thread near each other requires some planning + corresponding configuration. A lot of Zigbee hubs try to find a quiet channel during the initial setup, but it does not always work.
How does Zigbee compare to Matter?
Matter over Thread is the most comparable to Zigbee (there is also Matter over WiFi). It's vastly more complex, since it uses IPv6 (ULE), mDNS, non-radio links between TBRs, provisioning is typically done through a smartphone with Bluetooth LE [1] etc. But it's also more standardized in that Matter defines the device types, so in principle a device will work with any Matter server, whereas with Zigbee support generally needs to be added per device (though there are generic drivers as well).
Big tech and IoT companies love Matter, because they can eventually gather analytics from devices or require cloud subscriptions. This is not just the case with Matter over WiFi, but Matter over Thread already allows devices to use NAT64 to connect to IPv4 servers on the internet (and TBRs like Apple TV do not allow you to disable NAT64). Thread 1.4 also allows for Thread devices to get globally routable IPv6 addresses. The Thread 1.4 white paper does not even try to hide what this could be used for:
Thread devices can now seamlessly connect directly to cloud services, enabling remote control, monitoring, and over-the-air firmware updates.
So, yeah, Matter + Thread does some things better, some things worse, and opens up new avenues for monetization that were not possible with Zigbee, because Zigbee devices were fully local and owned.
[1] There are workarounds, e.g. Home Assistant allows provisioning through Bluetooth proxies. Also, provisioning does not currently work on alternative ROMs like GrapheneOS.
That's my main problem with Thread. With Zigbee I have confidence that the mesh is 100% local and offline. How do I get that confidence with Thread? How can I really be sure that something isn't helpfully opening it up to the world?
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.
I recently tested a bunch including a lab-grade transmitter setup as control. My focus was on temperature in a lab refrigerator for home use and RuuviTag Pro was the best. You can also modify the firmware yourself which is a huge bonus. Pair with Shelly as a gateway and it’s quite useful.
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.
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.
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.
> 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'm looking right now at something like what I describe that I built 10 years ago, except the sensor is much less accurate (±1.0℃), the ESP8266 module I used didn't have USB so it is powered by an MB102 breadboard power supply, and I used NodeMCU.
On the breadboard there is the ESP8266 module [1], the sensor breakout (a BMP280, which uses I2C just like the newer much more accurate sensors), the MB102, and 6 wires. 2 wires are connecting the ESP2866 module the power and ground, 2 wires connecting the BMP280 to power and ground, and 2 wires connecting the BMP280 to the ESP8266.
If I had used an LLM it probably would have not left out the important thing that I completely overlooked: the SDA and SCL lines for I2C need pull-up resistors. Many sensor breakout modules include them, such as the BMP280 modules in my 10 year old project, so I forgot about them.
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've got a (generic from AliExpress) indoor Zigbee temp/hum sensor outside on the balcony inside one of those "weather station" cases[0] with the sensor raised off the bottom with a bit of plastic.
Works fine for me but I guess you might run into problems in a more exposed "watery" place (London doesn't really have extreme rain or humidity.)
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.
I'm a bit curious how this is showing up as posted 4 hours ago because I'm pretty sure I remember posting it about 2 days ago. Maybe it got stuck in a silent spam/moderation queue before getting approved?
Approximately the opposite. There's a "second chance" pool that automatically reinserts worthy stories into the queue as if they had been resubmitted. So rather than being moderated out and then released, this one was consciously selected for re-inclusion. More explanation here: https://news.ycombinator.com/item?id=11662380
In short, if you need less than a couple degrees of accuracy, it's going to take a bit of tinkering. I wouldn't trust a $1 sensor for a tropical fish tank, for example, but probably good enough for a home thermostat.
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.
Similar reasons: the intended audience isn’t the average person.
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 have a bucket of devices which don’t do what I hoped they’d do because they were different from what the reviews said. And not just IoT unfortunately. Some do a better job at flagging these changes, some don’t.
But in the end taking the common case that the product is what it says on the box or that the changes have no impact on how it works, most people don’t care about the name of the chips. Not unless they are very keen on the tech and then there are more tech-oriented niche sites that might provide this.
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!
They have a more expensive variant looks more like desk alarm clock, that also measures particulates and carbon dioxide (and tells time), and that one can stay always-on (and act as Thread router) - but they wisely remembered to add remotely triggerable switch to switch the display off, too.
¹ https://www.ikea.com/ca/en/p/alpstuga-air-quality-sensor-sma...
² https://www.digikey.ca/en/products/detail/sensirion-ag/SEN63...
https://community.home-assistant.io/t/ikea-kajplats-smart-bu...
I have a lot of qualms with Threads, such as Thread device internet access through TBRs that do not allow you to disable NAT64 (or even worse, getting globally routable IPv6 addresses in Thread 1.4), but complaining that people have to buy another device is not one.
People are far more likely to have a TBR already than an IKEA Zigbee Hub. And even if they hadn't, they could get any other TBR/Matter Server besides IKEAs. So it's not a great way of selling smart home hubs.
[1] https://appleinsider.com/articles/24/09/18/apple-enables-dir...
https://community.home-assistant.io/t/ikea-kajplats-smart-bu...
via
https://www.reddit.com/r/homeassistant/comments/1tvtyyj/ikea...
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.
Recommend this exercise to everyone.
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.
PS: You have seen Alec's unbelievably detailed encounter with the cheap red refrigerator, right?
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.
I'm 2 years in, I think, and I have never noticed any issues.
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 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.
I've had Tuya and Aqara sensors outside, undercover and out of direct rain for the past 3 years, and every one lasts about a year before the humidity sensor gets stuck at the maximum reading. Even bringing it indoors doesn't get it working again. I'm hoping the built-in heater on the SHT45 will help when we're sat in sea mist or sea fog and keep the sensor working for longer.
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.
https://www.oscium.com/training/zigbee-wifi-coexistence/
Deploying 2.4GHz Wifi, Zigbee, and Thread near each other requires some planning + corresponding configuration. A lot of Zigbee hubs try to find a quiet channel during the initial setup, but it does not always work.
How does Zigbee compare to Matter?
Matter over Thread is the most comparable to Zigbee (there is also Matter over WiFi). It's vastly more complex, since it uses IPv6 (ULE), mDNS, non-radio links between TBRs, provisioning is typically done through a smartphone with Bluetooth LE [1] etc. But it's also more standardized in that Matter defines the device types, so in principle a device will work with any Matter server, whereas with Zigbee support generally needs to be added per device (though there are generic drivers as well).
Big tech and IoT companies love Matter, because they can eventually gather analytics from devices or require cloud subscriptions. This is not just the case with Matter over WiFi, but Matter over Thread already allows devices to use NAT64 to connect to IPv4 servers on the internet (and TBRs like Apple TV do not allow you to disable NAT64). Thread 1.4 also allows for Thread devices to get globally routable IPv6 addresses. The Thread 1.4 white paper does not even try to hide what this could be used for:
Thread devices can now seamlessly connect directly to cloud services, enabling remote control, monitoring, and over-the-air firmware updates.
https://www.threadgroup.org/Portals/0/Documents/Thread_1.4_F...
So, yeah, Matter + Thread does some things better, some things worse, and opens up new avenues for monetization that were not possible with Zigbee, because Zigbee devices were fully local and owned.
[1] There are workarounds, e.g. Home Assistant allows provisioning through Bluetooth proxies. Also, provisioning does not currently work on alternative ROMs like GrapheneOS.
My friend has problems with zigbee and has moved to matter and is now trouble free. The only fine zigbee stuff for him was the Hue lights though.
CO2 and equivalents on the other hand is Wild West.
https://news.ycombinator.com/item?id=49957835
It's the most first world of first world problems, but purely for that reason any more I buy will be Sonoff.
> 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
I'm looking right now at something like what I describe that I built 10 years ago, except the sensor is much less accurate (±1.0℃), the ESP8266 module I used didn't have USB so it is powered by an MB102 breadboard power supply, and I used NodeMCU.
On the breadboard there is the ESP8266 module [1], the sensor breakout (a BMP280, which uses I2C just like the newer much more accurate sensors), the MB102, and 6 wires. 2 wires are connecting the ESP2866 module the power and ground, 2 wires connecting the BMP280 to power and ground, and 2 wires connecting the BMP280 to the ESP8266.
If I had used an LLM it probably would have not left out the important thing that I completely overlooked: the SDA and SCL lines for I2C need pull-up resistors. Many sensor breakout modules include them, such as the BMP280 modules in my 10 year old project, so I forgot about them.
[1] https://www.adafruit.com/product/2471
HA uses the external sensor readings to set an external measured value for the radiator thermostats.
Works fine for me but I guess you might run into problems in a more exposed "watery" place (London doesn't really have extreme rain or humidity.)
[0] Like this https://www.amazon.co.uk/Technoline-TXCOVER-White/dp/B08DKZD...
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.