Not really. The cc2625 and EFR32MG21chips were released about the same time, the cc2625 by TI, the EFR32MG21 by Silabs. They don’t differ to much in capabilities, one is a little bit better at some things, the other at other things.
Honestly, (and forgive my frankness here) I think you’re blowing this out of proportion.
So, your network is unavailable for a few minutes after a restart. That’s hardly the end of the world, is it?
If you really have to restart, just schedule it at the time when it’s least inconvenient to your family. Wait till they head out for the weekly shop, or while they’re sleeping, then restart at your leisure.
Do they complain when their computer restarts because of a Windows update? If not, explain to them that this is essentially the same thing - you’re still looking at a >99.9% uptime at the end of the day.
For a HACS update, no reboot necessary, a simple restart of HA will do.
I’ve been doing that for the past 1-2 years, but I prefer a system with minimal downtime. A simple example: lights that are only controllable through HA and not manually. I haven’t seen widespread support for Matter binding yet, which would allow direct connections between a switch and a light bulb.
What’s wrong with wanting the networks to stay up independently of HA? All I’m asking is how to identify standalone devices that keep the networks running and are also user-friendly. The simple answer for Thread is probably: buy one or two Homepod Minis and join all your devices with the Thread network created by these. I didn’t have a solution regarding Zigbee until Francis, Chris and Nathan replied in this thread.
True, I wasn’t being completely precise. But a restart will also reboot all addons, including the Open Thread Border Router, which causes the network to collapse. Since I prefer to do one update at a time and check if everything is running smoothly for an hour, this can lead to multiple restarts in a single evening, causing multiple Thread devices to be offline for a few minutes each time. That’s why I want to move OTBR and Zigbee controller away from HA.
For Thread, that is why I added those 2 Espressif OTBR to my network. They don’t come with a case, but they keep the Thread network in the air if HA is rebooting.
This is the problem to fix. The infrastructure is designed to take a short outage. If you don’t have physical controls that’s a completely separate issue.
I will NOT (this is a hard no, includes smart bulbs that don’t support direct connect or zigbee binding) install a lighting control that doesn’t have local control and therefore my System can completely dump itself and take a vacation and I honestly don’t care because I still have lights. Coupled with a good backup and restore strategy that can get me back up and running form a complete systems failure in less than 24 hours…
I agree you’re probably putting too much weight on the infrastructure ND not enough on planning for no connection
A bit overkill, I already own the hardware where proxmox is running (an i7 fujitsu esprimo q920 and a beelink mini s12 pro. the third node will just be a quorum node from my Truenas server).
The device looks pretty interesting though! Tks!
a MariaDB LXC… I guess I need to play with dns names to have it dynamically addressed! Tks for the heads up!
Thank you for all the suggestions! I think I’ll go with two different (network) devices.
I’ll let you know at the end how I implemented the whole High Availablity system. It seems there aren’t lots of topics about high availability with rather complex systems like mine… but as a devops engineer, I feel compelled to make it as reliable as possible
I know there’s the HaHa thread (high availability home assistant) in these forums.
Not sure whether it fits your needs, but it’s a start.
I didn’t though of looking for “HaHa” tks, I’ll take a look!