A missing sensor reading is not zero

Zero is a reading, and missing is not

A temperature sensor in a spare room goes offline one evening. The automation that averages the downstairs sensors keeps running, and the average falls. Nothing announces the failure, so the heating works harder overnight. The sensor never reported cold. It reported nothing at all, and something in the pipeline turned that nothing into the number zero.

Missing data and a measurement of zero are different things. One of the easiest ways to lose the difference is a convenient default: a conversion that supplies zero whenever a value cannot be read. The default is not describing the sensor. It is inventing a reading, then handing it to logic that cannot tell the two apart.

Three kinds of not-a-number

Home Assistant documents two special state values, and they are worth keeping apart from an ordinary number.

There is a quieter third case: the value is present but old. Every state object carries last_updated, last_changed and last_reported timestamps, and they answer slightly different questions. None of them is the reading itself. A number that is still on a dashboard is not automatically current.

So a decision needs two separate answers before it acts: is there a usable value, and is it recent enough to mean what the decision thinks it means?

• unknown means the entity exists but Home Assistant does not know its value right now.
• unavailable means the entity cannot be reached at all, for example because a device is offline or an integration failed to load.
• Asking for an entity that does not exist also returns unknown, so a typo and a sensor that has not reported yet can look identical.

Every state arrives as text

Home Assistant stores every entity state as text, even when it looks numeric. That is why the documentation recommends converting with float(0) or int(0) before doing arithmetic: the zero is a documented fallback used when conversion fails, for instance because a sensor is unavailable.

That guidance is sound for its stated purpose. It stops a template from breaking when a value is briefly missing. It becomes unsafe when the fallback is fed into a decision. In arithmetic and comparisons, zero is not a neutral placeholder. It is a plausible measurement, and downstream logic treats it exactly like one.

The same documentation warns that expecting unknown or None to behave like a number breaks math operations. A fallback repairs the error. It does not restore the missing measurement.

When a fallback is legitimate

It helps to be honest that defaults are not always wrong.

The problem is the third case: a value that can genuinely go missing, used by a decision that cannot tolerate a substitute. Averages, thresholds, comparisons, alerts and any action that changes the physical world all belong here. The moment a fallback reaches one of those, a missing observation has been promoted to evidence.

• Presentation arithmetic. Adding a display offset, or formatting a value you already know is present, can use a fallback without changing a decision.
• A genuinely defined zero. A counter that resets each midnight really is zero at that moment. That is a reading, not a substitute for one.

A worked example: the average that drifts

Picture a fictional house with a spare room, a landing and a hallway sensor feeding one downstairs average. When the hallway sensor drops offline, a template that converts every reading with float(0) keeps producing a number, and that number is lower than reality because a real reading has been replaced by zero.

The documented alternative is to leave missing values out rather than invent them. Home Assistant's own averaging tutorial filters out states that are unknown or unavailable before converting and averaging, and its patterns guide uses has_value to select only entities with a usable state. The result answers a narrower question, the average of the sensors that reported, which is honest as long as the automation also notices when too few sensors remain.

A second documented pattern keeps a deliberate last-known value instead. A trigger-based template sensor can hold its previous value while the source is briefly unknown or unavailable. That choice is defensible for a slow-moving quantity, but it should be explicit and bounded: a held value is a memory, not a fresh measurement, and it should not be held forever.

Whichever policy you choose, the missing case deserves its own branch rather than a default buried inside a conversion.

A checklist before you trust a reading

Run through these questions for any reading that can disappear before it influences something.

• Name the real state. Is the entity unknown, unavailable, or carrying an actual value? Treat a missing entity as unknown, not as zero.
• Check freshness separately. Compare the relevant timestamp with now and decide what recent enough means for that quantity.
• Set a per-use policy. Display, averaging and decision-making can legitimately treat missing data differently.
• Gate decisions on a value test. Use has_value, or an equivalent explicit check, before a reading reaches a threshold, an average or an action.
• Bound any hold. If you keep the last value, cap how long it is trusted and say so inside the automation.
• Make absence visible. Alert on a sensor that stays missing, rather than on every momentary blip a hold or filter absorbs.
• Keep a manual path. A person should be able to see that a value is missing and act without the automation.

Where this stops helping

An available entity is not proof of a correct, fresh or safe reading. The developer documentation defines availability as whether Home Assistant can read the state or control the device, and the assumed_state attribute separately flags a state that is only an assumption. Neither test tells you that the physical world matches the number.

Filtering missing values has a cost too. A sensor that fails often can quietly vanish from an average while the remaining sensors keep the automation looking healthy, so watch the count of contributing readings and not only the result.

Finally, some decisions should not be automated at all. For heating, locks, valves or alarms, a missing reading should lead to a conservative manual position rather than a clever inference. Home Assistant automations that fail clearly covers that design discipline, and what your smart home does when the internet is gone maps the dependencies that produce these gaps in the first place.

What we would do next

Pick one automation that currently substitutes a default into a decision. Replace the default with an explicit missing branch, add a freshness check, and write down what a person should do when the value does not arrive. Then test it by making the sensor unavailable on purpose and watching what the automation actually does.

The goal is not to eliminate missing data. It is to stop pretending it is a measurement.

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. State and state object — Home Assistant. Documents that each entity state is a string holding one value at a time, and defines the last_updated, last_changed and last_reported timestamps carried by every state object.
2. Working with states — Home Assistant. Defines unknown and unavailable, notes that a nonexistent entity also returns unknown, and documents the float(0) fallback and the has_value test for decisions.
3. Types and conversion — Home Assistant. Explains that states are text, that float and int defaults are fallbacks used when conversion fails, and that treating unknown or None as a number breaks arithmetic.
4. Common patterns — Home Assistant. Shows has_value filtering of unknown and unavailable entities, ordering by last_changed, and a trigger-based template sensor that holds its previous value during a dropout.
5. Create a template sensor that averages all your temperature sensors — Home Assistant. The documented averaging example rejects unknown and unavailable states instead of substituting a number before averaging.
6. Entity — Home Assistant. Defines the available property as whether Home Assistant can read the state or control the device.
7. Template — Home Assistant. Documents the availability template: if it fails to render or returns a falsey value the entity is unavailable, and if it is not configured the entity is always available.

More from Server Attic

• 2026-07-22

  Make home automations fail safe first

  A practical checklist for designing Home Assistant automations that recover clearly, leave evidence and avoid doing the wrong thing twice.

• 2026-08-21

  What your smart home does when the internet is gone

  Map every smart-home dependency before an outage: where decisions happen, how updates arrive, what fails and which safe manual path remains available.

• 2026-07-20

  Home Assistant automations that fail clearly

  A practical way to design household automations so missed conditions, failed actions and recovery steps are visible instead of mysterious.