Heating Decision Engine — A centralized heating control architecture for Home Assistant

Share your Projects!
, , , ,
1

Heating Decision Engine — A centralized heating control architecture for Home Assistant

Many Home Assistant heating setups end up with multiple automations competing with each other:

  • presence automations
  • window detection
  • vacation mode
  • manual overrides
  • weather anticipation
  • stove interaction
  • anti-freeze protection

Over time this becomes difficult to reason about.
Automations start to conflict and it becomes harder to understand why the heating changed state.

To solve this I built a small architecture pattern that centralizes all heating decisions into a single decision engine.

Instead of many automations directly controlling the heating system, the system works like this:

context signals → trigger automation → decision engine → execution scripts

Core idea

The decision engine evaluates the current context and decides between three possible outcomes:

  • comfort
  • reduced
  • neutre (explicit abstention)

The neutre state is important: it means

the system evaluated the context and intentionally decided to do nothing.

This prevents unnecessary service calls and oscillations.

Architecture

Context signals
(presence, windows, house mode, vacation…)
            │
            ▼
    Automation Trigger
            │
            ▼
   Heating Decision Engine
      (single authority)
            │
      ┌─────┴─────┐
      ▼           ▼
 Apply Comfort  Apply Reduced
    (execution)    (execution)
      │              │
      └───────► Heating System
                (API / climate entity)

Key principles

The project follows a few architectural rules:

Single decision authority

Only the decision engine decides if heating should change.

Decision ≠ execution

The engine decides.
Separate scripts apply the change.

Explicit abstention

neutre means:

Heating is already correct or no action is needed.

Strict priority hierarchy

The first matching rule always wins.

Anti-bounce protection

Optional timers prevent rapid oscillations or API spam.

Features

  • centralized heating decision logic
  • strict priority hierarchy
  • explicit abstention (neutre)
  • anti-bounce protection
  • prevention of redundant service calls
  • optional observability helpers
  • full YAML implementation (no custom integration)

Project structure

The repository contains:

scripts/
    heating_decision_engine.yaml
    heating_apply_comfort.yaml
    heating_apply_reduced.yaml

automations/
    automation_trigger.yaml

sensors/
    heating_thermal_target.yaml

helpers/
    helpers.yaml

packages/
    heating_decision_engine_example.yaml

docs/
    architecture.md
    decision_engine.md
    apply_scripts.md
    thermal_target_sensor.md

An example Home Assistant package is included to quickly test the system.

GitHub repository

Full project, documentation and examples:

https://github.com/antoinevalentinHA/ha-heating-decision-engine

Feedback welcome

I’m sharing this mainly as an architecture pattern for heating control in Home Assistant.

I’m curious to see:

  • how others structure their heating automations
  • whether this pattern could be useful for other setups
  • possible improvements to the decision logic.

Feedback and ideas are welcome.