You put a Tuya ZigBee temperature and humidity sensor in the living room and a cheap dial thermometer next to it. They differ by 2.5 degrees. You buy a second smart sensor, put it beside the first, and now the two smart sensors disagree with each other by a degree. Nothing is broken. You are comparing three instruments that are each measuring something slightly different, and almost every smart home humidity problem people report is actually a temperature problem wearing a costume.
The sensor measures its own microclimate, not the room
This is the single most important thing to internalise. A sensor reports the temperature of the air immediately around its own PCB. It has no idea what the room is doing.
Everything near it shifts that local air. An internal surface a few millimetres from a warm enclosure reads warmer than the bulk air. A sensor mounted on an outside wall reads the wall's temperature as much as the room's, and that wall is a cold bridge in winter and a warm one in summer. One above a radiator, a TV, a router, or a plug-in power supply reads a plume. One inside a cabinet reads a box.
Put the same sensor in four places in one room and you will legitimately get a spread of two degrees or more, all of them honest. When you want to know the room, place the sensor where the room air actually is: on an interior wall, at breathing height, out of direct sun, and at least a metre from anything that makes heat or blocks airflow.
Self-heating is real and it is worse than you think
Every wireless sensor dissipates heat. The radio transmit burst is the obvious part, but the regulator, the charging circuit if it is rechargeable, and the sensor's own measurement current all add up. Milliwatts sound negligible until you remember the sensor sits in a small sealed plastic box with almost no airflow, and the thing it is measuring is a few millimetres from the heat source.
The practical signature: the reading sits high, it climbs for the first hour after you insert fresh batteries, and it drifts with how often the device reports. A sensor configured to send updates every minute reads measurably warmer than the same hardware reporting every ten minutes. That is not a firmware bug. It is the transmit duty cycle showing up in the temperature channel.
Battery-powered ZigBee models are far better than mains-powered WiFi ones here, which is one of the few places where the low-power protocol wins outright. If your main sensor is USB-powered, expect it to run warm, and do not use it as the reference for judging the others.
Humidity is a function of temperature, so temperature error becomes humidity error
Relative humidity is not an independent quantity. It is the ratio of how much water vapour is in the air to how much the air could hold at its current temperature, and that capacity rises steeply with temperature.
The consequence is brutal and widely misunderstood: an error of one degree in temperature produces roughly five percent of error in relative humidity. A sensor whose temperature runs two degrees high will report relative humidity several percent low, consistently, and people will swear the humidity sensor is defective.
It gets worse at the extremes. Below about twenty percent and above about eighty percent relative humidity, the sensing element is outside its well-characterised range and error grows quickly. So a bathroom reading right after a shower and a desert-dry room in winter are exactly where the number is least trustworthy.
If two sensors disagree on humidity, check their temperature readings first. Fix the temperature and the humidity usually follows.
Response lag looks like a broken sensor
The sensing element has thermal mass, and the housing around it has more. When room conditions change quickly, the reading does not follow. It approaches the new value over minutes.
Open a window on a cold day and watch. The room changes within a minute; the sensor takes ten to thirty minutes to get there. Someone glances at the app two minutes after opening the window, sees no movement, and concludes the device is dead or offline.
The housing matters as much as the chip. A sensor in a sealed enclosure with a tiny vent responds slowly but is protected. One with generous openings responds fast but is exposed to dust, grease and salt. Most of the "my sensor is slow" complaints are really "my sensor is in a box", and that is often the correct trade-off for a device meant to run for years.
What the accuracy number on the box actually means
A datasheet that claims plus or minus 0.3 degrees is not lying, but it is not describing your use case either.
That figure is typically quoted at a specific temperature, usually around 25 degrees, and often describes interchangeability — the spread between many units of the same model — rather than the absolute accuracy of any one unit against a calibrated reference. Across the full operating range, plus or minus one degree is a realistic expectation for a good part and worse for a cheap one.
Humidity is the same story: the headline tolerance applies to the middle of the range, not the ends. And there is a second term nobody advertises, which is long-term drift — typically a fraction of a percent per year, and more if the part has been exposed to condensation or contaminants.
None of this makes the device useless. It means the correct question is not "is this accurate" but "is this accurate enough and stable enough for the decision I am making". Comfort and trend monitoring: comfortably yes. Anything requiring calibrated measurement: no, and no consumer sensor is.
Drift and contamination cannot be undone
The humidity element is a polymer or capacitive film that interacts with water vapour. That same interaction is why it is vulnerable to everything else in the air.
Cooking aerosols, cigarette smoke, salt air near a coast, cleaning product vapours, and ordinary dust all shift the reading over time. Condensation is the worst: if the sensor ever gets wet enough for water to condense on the element, the reading can be off for a long while afterwards, sometimes permanently.
This is why a sensor that has lived in a kitchen for two years will not match a new one out of the box, and why no amount of app-level recalibration fixes it. You can offset a consistent error. You cannot offset an element that has chemically changed.
Hysteresis and why automations oscillate
Humidity sensors do not retrace the same path going up and coming down. Expose one to a humid bathroom and then let it dry, and the descending reading sits slightly above the ascending one.
Combine that with self-heating and response lag and you get the classic failure: an automation that switches a fan or dehumidifier at a threshold, sitting right at that threshold, turns on, the local air changes, the reading crosses back, it turns off, and it cycles. The device is fine. The control loop has no deadband.
The fix is not a better sensor. It is hysteresis in the automation — turn on above one value, turn off below a meaningfully lower one — plus a minimum runtime so the device is not short-cycled. If your platform lets you average over several minutes rather than reacting to a single sample, do that too.
How to actually settle an argument between two sensors
Do not trust any single reading until you have controlled for placement.
Put both sensors side by side, on the same surface, at least a metre from heat sources and out of any draught. Leave them alone for an hour without handling them — your hand is a heat source and holding one for ten seconds is enough to move it. Then read both.
If they agree within the stated tolerance once co-located, they are both fine and the original disagreement was placement. If they still differ by more than that, take the newer one as more likely correct and note the offset on the older one.
That side-by-side number is the only calibration most people can actually do. You cannot create a reference humidity at home without a saturated salt solution, and guessing against a dial thermometer just imports that thermometer's error. What you can do is establish a consistent offset and apply it in whatever layer consumes the data.
Where the money goes in a better sensor
Three things, and none of them is the app.
The sensing element itself. Known parts behave predictably and drift slowly; unbranded ones are a lottery, and the failure mode is not obvious wrongness but a reading that slowly wanders over a year.
Board layout. A good design puts the sensing element physically away from the regulator and the radio, sometimes on a small separate tab, with slots cut in the board to reduce heat conduction along the copper. A bad one puts it next to the power stage.
The enclosure. It needs openings large enough that the element sees room air, positioned so the device's own heat does not rise past the sensor, while keeping dust and splashes out. This is the hardest part to get right and the cheapest part to get wrong.
I work on the manufacturing side of this category, so I am biased toward explaining these disagreements as physics and placement rather than defective units. That is genuinely what the failure data looks like, but run the side-by-side test yourself before believing either of us.
If you are specifying sensors for a project where the numbers feed decisions rather than just display, the construction differences above are worth asking about directly. The range is laid out here, including temperature and humidity models built around low-power ZigBee reporting, and vibration and tilt sensors that solve a different class of problem by ignoring ambient conditions entirely.
Top comments (0)