Hi Jaap, welcome to the forum!
Good that you can ‘lol’ with it…
You better off by creating a new topic in the right subforum if you want us to help you instead in a thread under social.
Also, you better check this topic: How to help us help you - or How to ask a good question - #3
Ah thanks! Will do that.
Sometimes problems. Even if they are annoying are fun to debug. I dont mind lossing al my Zigbee devices (as long as its fixable) 
Yeah, I feel your pain.
For those interested in a structural approach to this problem, I wrote up an architecture experiment here: link. The idea is treating HA as a rebuildable frontend rather than the control plane.
I’m going to ask you one question:
Why do you think an architecture can solve integration problems that are sourcing from changes in systems outside the platform. Eg. API changes of devices, deprecation, modernization, firmware updates etc. The IOT world will definetly outpace you with changes and you can’t fix inside a LTS version.
(it’s my opinion, based on 20 years payment industry integrations and 5 years integration platforms. You are allowed to have yours ofcourse, this is just for the sake of discussion, no offense intended)
No offence taken — this is actually a very good question and I’ll try to answer it.
You’re right: external changes (API updates, firmware, deprecation) will always happen. No architecture can prevent that. The goal isn’t to stop change — it’s to contain its blast radius.
A simple analogy: when a lightbulb breaks, you replace it with a socket-compatible device. You don’t solder the wires, update the fuse box, or change anything in the rest of the house. That’s because the interface (socket) is stable and the responsibilities are clearly separated.
Right now in HA, things are tightly coupled. One change propagates through everything. That’s the coupling I want to break.
The idea isn’t to freeze the world — it’s to split the system into subsystems with clear boundaries:
When the Zigbee spec changes, zigbee2mqtt absorbs it. HA doesn’t need to know. When HA updates its dashboard framework, devices don’t care. Each layer evolves independently.
This isn’t a new pattern — it’s how industrial automation, automotive systems, and Linux itself handle heterogeneous, constantly-changing components and still provide LTS versions. I’ve been building systems like this for 15+ years (background: ROX System Architecture - ROX Docs — designed for mobile robots, but the principles apply to any sensor/actuator system).
Will things still break? Absolutely. But they’ll break locally, not globally.
by stepping away from monotlic approach, you’ll be making the production setup pretty complex. Probably complex enough to scare newcomers from entering.
Also, your broker will become single point of failure and broker maintanance is something i would not advice for consumer grade solutions
Next to that, this setup will be reliant on ‘eventual consistency’ which is a pattern that will not be easy to manage too.
You have a point, but the solution wil bring other challanges for a lot of users and contributors. Not sure they outweigh the benefits
Yes it is not for everyone. But newcomers already got HAOS, that will stay minstream.
In my experience, deploying a docker stack provides granular version control AND stable deployment strategy. Mosquitto is a solid piece of software. One can argue that it’s a ‘single point of failure’, but this may be purely theoretical because in practice it (almost) never fails, other parts of the system are orders of magnitude less reliable (like tyres on a bycicle vs frame).
To be more explicit, I’m not trying to solve a ‘consumer’ problem. I’m trying to find a setup that is acceptable for professionals.
I think it’s interesting that you think it’s better than commercial products but expect perfection from an open source project.
Is Home Assistant perfect? No. Do I get annoyed when things break? Absolutely.
However at the end of the day, it’s far more useful than buggy and with some of the plugins, they’re maintained through partnerships. There’s tradeoffs but I like what I get.
When I find a bug I report it because there’s only so much you can test. If I cared that much about an issue I’d be looking into helping fix it myself.
It’s more flexible than commercial products. It’s more open and more configurable.
Open source means that the source code is open and you can fork it and develop your own version (being compliant with the license). It’s not about architecture or software quality.
As you can see the Open Source has nothing to do with the level of perfection. If a project maintainer allows to merge certain code changes to his project, he takes responsibility for the product quality. Again, it’s not open source guilty. It’s project owner who decides about strategy of how his software gonna evolve.
I know open source projects that are very strict in terms of what is merged to the product.
In terms of an architecture I also use HA as a system orchestrator and GUI. From beginning my Shelies goes through mqtt, zigbee through z2m, govee through govee2mqtt. And I automate with NodeRed.
This setup is more feature complete thus more stable. It’s because every of these components alone together with mqtt integration is more matured and way changing less frequently. And if something changes it’s done in very selective way, not hitting everything in perimeter.
Someone said that broker is a single point of failure. Yes it is. Isnt HA single point of failure too? but more complex software-wise to secure it stability?
Specialized components don’t fail as often as software built on top of them. For instance, neither MQTT or NR or Z2M ever failed in my setup.
Every architecture based on database or message bus depends on these data layer components. But they provide reliability as basement for soft built on top of them.