Here is a template that appears in thousands of home automation configs, radiating quiet competence:
A sensor that dies loudly is a gift. A sensor that dies politely, holding its last reading with the composure of a butler who has been dead for some time, is the actual problem. Nothing in a dashboard distinguishes 'calm' from 'no longer reporting', and for weeks nothing in ours did either.
{{ states('sensor.something') | float(0) }}It looks like defensive programming. It is the software equivalent of writing
“probably fine” on a fuse box. That 0 is a
fabricated measurement, and it is indistinguishable from a real one.
Fail-open in a guard position
Suppose a rule reads "if power draw exceeds 3500 W, cut the supply". The sensor becomes unavailable, the radio dropped, the integration reloaded, the device is asleep. With a default of zero, the guard evaluates a comfortable 0 W and stays quiet. The condition it exists to catch can now happen freely, and the system reports no problem at all.
The same shape appears with | int(0), with | default(0), and
with any condition written as "value is below X" where a missing value is also below X.
Unavailable and unknown are not the same as a value
Most platforms distinguish "I have no reading" from "the reading is zero". Use it. A derived sensor should declare itself unavailable when its inputs are missing, rather than computing something from placeholder numbers.
availability: inputs are present and plausible
state: the actual computation, with no defensive defaults
This has a second benefit: an unavailable entity is visible. Dashboards show a gap, staleness detectors can see it, and history shows exactly when data stopped. A fabricated zero looks like a healthy measurement forever.
Do not emit a non-numeric state either
The mirror-image mistake is returning the literal string "unknown" as the state of a sensor that carries a unit. Platforms log that as an invalid state, on every update, which means a sensor designed to be quiet is now generating a steady stream of errors. Put the condition in the availability expression instead.
Two real examples worth copying
Severe-weather gates
A binary sensor that says "is there an active warning?" is built from a feed. If the feed freezes or returns nothing, the naive template evaluates false, no warning, which is indistinguishable from genuine calm. A weather warning issued inside that window simply never reaches you. Give the gate an availability expression tied to the raw feed, and a stalled feed becomes visible instead of silently reassuring.
Ratios that are noise at low input
Power factor is real power divided by apparent power, informative under load, meaningless at idle, when it is the ratio of two numbers near zero. Do not clamp it to something plausible; make the sensor unavailable below a sensible load threshold. "I am not measuring right now" is a legitimate and useful state.
Auditors need the same discipline
If you build something that reports on the health of other entities, it will eventually face entities that are unavailable on purpose, an integration you disabled, a device you unplugged for the season. An auditor that cannot tell "gone" from "switched off deliberately" will cry wolf, and you will stop reading it.
The generic fix is better than a list of exceptions: derive the set of deliberately-off entities from the platform's own registry, anything belonging to a disabled integration, and skip those. One rule, no maintenance, covers every future case.
For sensors that are unavailable by design only sometimes, a power factor at idle, a cloud-base height under a clear sky, the same registry does it with a label: mark the entity once, let the auditor read the label, and the exception list stops living in code. This paragraph exists because the auditor here flagged four such sensors one quiet morning, every one of them behaving exactly as designed, which is this page's rule enforced against its own author.
The rule that came out of it fits on a sticky note: a number without a timestamp is a rumour.