Freezing Home Assistant: architecture for LTS-style stability

Share your Projects!
1

The problem

I’ve been running HA for 8+ years. Feature-wise, I’ve been done for four. I don’t need new integrations — I need stability. Updates bring little value to me but require constant maintenance.

This isn’t new

“After more than 5 years using HA, I just can’t keep up with the maintenance”
— WTH can’t we have LTS

“I should not be afraid to update.”
— Stop breaking my sh*t

“The time I have to put into it because of stuff that is changed / deprecated is huge”
— I am so update tired

The LTS requests on GitHub were closed as duplicates without discussion. I don’t expect this to change — it’s a huge maintenance burden and HA optimizes for new features.

A different path

Instead of waiting for LTS, I’m prototyping an architecture that doesn’t need it:

Containerize HA as dashboard + automation only. Move device management to modular control planes outside.

┌───────────────────────────────────────────────────────────────────┐
│                   MQTT Bus (stable identities)                    │
└───────┬─────────────────┬─────────────────┬─────────────────┬─────┘
        │                 │                 │                 │
    ┌───▼───┐       ┌─────▼─────┐     ┌─────▼─────┐     ┌─────▼─────┐
    │ device│       │zigbee2mqtt│     │   Home    │     │   your    │
    │bridges│       │           │     │ Assistant │     │   tools   │
    └───────┘       └───────────┘     └───────────┘     └───────────┘

The system becomes more modular and with distinct responsibilities:

  • HA - dashboard + automations
  • MQTT - stable identity layer
  • control planes - device management

Each subsystem updates independently. Everything is run as a docker-compose stack. Update and roll-backs should be as easy as changing docker image label.

zigbee2mqtt as a control plane already works. Can we scale it to a full architecture?

Prototype

Early-stage containerized HA setup: espro/integration at main · sjev/espro · GitHub

Interested?

Looking for architectural feedback and collaborators. Related discussion: Decoupling ESPHome device identity from hardware

1 Like
2

As someone who has had so much broken in my system from upgrades that I haven’t upgraded now in years (and am very much happier with that decision), I very much like that idea.

I do think a modular setup where home assistant is really nothing more than a “kernel” for home assistant that is dedicated to not break user space (like the Linux kernel), and all the integrations running on top of that which can change, but generally strive for maximum compatibility with as many kernel versions as possible is the solution to this problem. Staying on older versions of some integrations until you can swallow really big changes that people make in them but not having to stay on an old version of the kernel to do so would be a huge benefit and IMHO is the “right” way for HA to. operate.

All that being said, where do you plan to get all of your device bridges from? Will you go through and containierize each integration?

3

Yeah, following the Linux setup with a kernel that is stable would be a smart way to approach it. But I’m afraid that the momentum of this project is moving farther away from such an architecture. Too big effort, too few people to care about it… so given that constraint the most reasonable option is to ‘isolate and contain’.

Well, we’ve got zigbee2mqtt already. That covers a wide range of devices. espro aims to be a comparable system that bridges esp devices. Control planes don’t have to be that complex, or reinvent the wheel - comissioning and managing devices is a common problem of industrial automation and it has been solved in a variety of ways. Think etherCAT, CANOpen etc. I don’t mean implementing those protocols, but reusing their ideas for comissioning and maybe data transfer as PDO/SDO.

This should be doable in man-weeks , not man-years.