Stop Freezing in the Dark: Build Unbreakable Sensors with the Failover Blueprint

Blueprints Exchange
, ,
1

Stop Freezing in the Dark: Build Unbreakable Sensors with the Failover Blueprint

A smart climate setup is a massive quality of life upgrade right until the tiny wireless sensor feeding it drops off your network.

Picture your bedroom on a cold night. Your automation fires up the space heater when the room drops below 18°C (64°F) and shuts it off at 20°C (68°F). At 1:00 AM, the Zigbee temperature sensor on your nightstand runs out of battery. The state flips to unavailable. Your automation goes blind. The heater keeps pumping out heat because the "shut off" threshold is never reached. You wake up three hours later trapped in a sauna.

Automations are incredibly literal. They trust a single source of truth. When that source vanishes, the logic breaks.

Sensor Failover fixes this by building a hierarchy of trust. You point the blueprint at your primary sensor. You give it a list of backups. It wraps them all into a single, unbreakable numeric entity. Downstream automations read this new wrapper sensor and never see the underlying chaos.

Worked Example: Unbreakable Climate Control

You want the nightstand sensor to drive the bedroom climate because it is right next to the bed. If it dies, the thermostat out in the hallway is close enough to keep the room safe. A smart plug across the bedroom also has an internal temperature gauge. It runs a little warm, but it is better than nothing.

You build the failover sensor like this:

template:
  - use_blueprint:
      path: TheThinkingHome/sensor_failover.yaml
      input:
        primary_entity: sensor.nightstand_temperature
        backup_entities:
          - sensor.hallway_thermostat_temperature
          - sensor.bedroom_smart_plug_temperature
        backup_weights: "80, 20"
        sensor_name: Master Bedroom Temperature
        unique_id: master_bedroom_temperature_failover
        unit_of_measurement: "°C"
        device_class: temperature
        state_class: measurement

The automation runs on trust. While the nightstand sensor is online, its reading is the only one that matters. If it drops, the blueprint instantly falls back to a weighted average of the hallway thermostat and the smart plug. You give the hallway an 80% weight because it reflects the ambient air better than the plug hardware.

Your climate automation now reads sensor.master_bedroom_temperature_failover. You get to sleep through the night. The dead coin cell battery is just a maintenance task for tomorrow, not a midnight emergency.

More Than Just Climate

This hierarchy of trust works for any numeric reading where a dead sensor causes chaos:

  • The Clouded Lux Sensor: You use an outdoor illuminance sensor to turn on the interior lamps when a heavy storm rolls in. But because it is mounted outdoors and far from the edge of your mesh, it frequently loses connection. Pair it with two less-precise indoor window sensors as backups, and your house never mistakenly thinks it is pitch black at noon just because the outdoor sensor dropped offline.
  • Wind Speed Safety: You have a local anemometer that retracts your patio awning when the wind picks up. If that local sensor drops off your Zigbee mesh, fall back to a cloud-based weather integration's wind speed. The local sensor is the most accurate, but the cloud fallback is vastly better than leaving the awning out in a storm because your hub lost a ping.
  • The Faraday Freezer: A wireless temperature tag buried deep in a chest freezer struggles to push its signal through the thick metal walls and drops offline intermittently. Fall back to a secondary tag sitting near the plastic lid. It reads a little warmer, but it keeps your "freezer is thawing!" safety alarm from crying wolf every time the primary sensor drops a packet.

Get It

The quick way, one click:

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

Note: This is a template blueprint, which means it does not have a UI for creation. The sensor is created with a few short lines in your configuration.yaml file.

The GitHub Readme covers the full setup, the parameters, and the longer story behind the design choices: Full Write-Up and Documentation

Tested with Home Assistant 2026.5.4 or newer.

Other blueprints in The Thinking Home series:

  • Recently Active — Create a "was active recently" sensor from any source, with a configurable look-back window.
  • Sensor Failover — Fall back to a secondary sensor when the primary goes unavailable.
  • Linked Entities Pro — Two-way sync for any number of entities across switches, lights, input_booleans, fans, and groups.
  • Sensor Watchdog — Detect sensors that have stopped responding and power-cycle them back.
1 Like
Linked Entities Pro: Keep entities synced. No loops. No drift. No recursion-guard blind spots
Recently Active: A Template Blueprint With an On/Off State Plus an Off Delay All-In-One
2

Generally, the automation does what you tell it to. If one applies the methods you are showing here and actually fix your automation that is a cleaner path. A second automation working the same entities could cause a feedback loop and new problems.

The real danger is HA failing for some power/DNS/Config problem and then no automation or blueprint will help you.
Best practice is a hardware backup failsafe. No computers.

Just one man's opinion...

1 Like
3

Exactly why I keep a completely manual thermostat in my basement set to 60°F. I'm in an area where freezing is a concern.

1 Like
4

A small note on how the blueprint works under the hood. What it creates is one sensor entity that wraps your primary plus a pool of backups. The wrapper reads from the primary when the primary is online and falls back to a weighted average of the backups when the primary goes offline. There is no automation involved, no separate logic that runs, no triggers firing. The wrapper is a template sensor, so everything happens inside the entity itself, transparent to whatever reads it. In practice that means you change one line in your existing automation: replace the bare primary entity with the failover entity. No second automation, no watchdog, no feedback loop. The automation you already wrote keeps doing exactly what you told it to, and the failover entity just hands it a number to act on.

If HA goes down, you are correct. But this is a failsafe working within HA.

Here is a worked example for a mission-critical setup. Picture a greenhouse heater automation that absolutely cannot fail to a stale or missing reading. If the temperature drops too low and the automation cannot read it, every plant in the greenhouse freezes by morning. The right move is to install two temperature sensors inside the greenhouse, deliberately, as a redundant pair:

  • sensor.greenhouse_temp_1: main, the one the automation has always trusted
  • sensor.greenhouse_temp_2: a second sensor installed alongside it as a hot spare, weight 100

Now extend it one more step. Add a third input from an outdoor temperature sensor that already exists for its own purposes, and give it weight 0:

  • sensor.outdoor_temperature: last resort, weight 0

Build the failover sensor with those three as inputs and point the heater automation at the failover entity instead of sensor.greenhouse_temp_1.

Three scenarios:

  1. Everything online. The failover entity returns the greenhouse_temp_1 reading directly. The two backups sit unused. This is the steady state.

  2. greenhouse_temp_1 dies. The weight-100 greenhouse_temp_2 kicks in. With only one non-zero weight available among the backups, the weighted average resolves to that sensor's reading exactly. The heater still has a temperature from inside the greenhouse, just from a different point. The automation never sees unavailable and never freaks out. This is the case the redundant pair was installed for.

  3. Both greenhouse sensors dead at the same time. Only the weight-zero outdoor sensor is reporting. The blueprint detects the all-zero-weights case and falls back to equal weighting (otherwise it would divide by zero and drop you to the default value). The heater now runs off the outdoor temperature, which is colder than the inside of the greenhouse, so the heater runs longer than it strictly needs to. The greenhouse stays warm. The plants live. It is not a good reading, but the failure errs on the side of safety.

The weight-zero slot is the failure-of-last-resort gear. While the primary backup is online, weight 0 means the outdoor sensor contributes nothing to the average and cannot pollute the reading. It only steps in when there is nothing else left. Three tiers, one failover entity, and the automation you already wrote keeps working through all three.