Well… sure if you leave out occasional complete haos restarts from haos updates…
I can confirm that haos itself is rock solid. Other stuff like usb dongles, receivers … are a different story, like mike said.
I am still figuring out whether my Zwave performance has improved. I seem to have issues with two sensors.
Yay! @EndUser Glad it worked!
Sidenote: FWIW, I had been having a lot of ZWave issues but they improved a lot (though not completely) by migrating from a Zooz Zwave dongle to a ZWA-2. (Other issues were improved by getting rid of any Z-wave devices that do power measurement – like the nightmarish Zooz Zen15 which had all sorts of problems --, as these tended to clog up the zwave network even if I set a relatively high polling interval.) Zwave is still a relatively medium-reliability network for me… much less robust than wifi, but it mostly works now…
Thanks for the feedback. I hear positives and negatives of the ZWA-2, but if my Zwave issues come back I may consider it.
I have several Zooz devices but not the Zen 15.
Thanks @NathanCu . Appreciate the help!
And I definitely agree about the disaster recovery. That’s also one of the reasons I was happy to migrate from a now-discontinued-and-hard-to-replace Yellow architecture to a more-standard X86. Nicer to do that without the urgency of a failure!
FWIW, I’ve found the single-and-physically-removeable-drive approach to also help with disaster recovery: e.g., when a HAOS update bricked my HA Yellow last year, I was very glad that I had gone with a PI CM that didn’t have embedded storage because it meant I could just pull the MNVe out, stick it in a USB enclosure, and pull important files off of it. (Though this is apparently impossible on a Mac due to lack of Mac support for some of the filesystem flags used by HAOS… grrr…)
I love your suggestion of a quarterly “disaster preparedness” drill. How do you do this without confusing all of the devices on your network?
Yep @EndUser I’m not knocking Zooz in general – I have a bunch of their light switches and most perform ok (though a few frequently drop until I physically go to them and press the button) --, but I’ve had ~4 Zen15s and they had numerous issues ranging from physical failures that needed warranty replacement to inaccurate energy measurements to suspected network flooding. (I can’t say with 100% certainty that the issues were caused by the Zen15s, but removing those 4 out of about 60 devices was certainly correlated with a dramatic improvement in stability of my Z-Wave network. YMMV…)
Pick your favorite VM software and figure out how to get it to do a new HAOS VM.
Figure out how that VM software gets connected to your network. (is there a specific nic/bridge whatev)
Figure out how to sever that connection
Install new HAOS VM and transfer a copy of your backup somewhere in reach of your new test box.
Use either the restore backup at login or create a dummy account login and and restore your backup to the new install.
(this is the only tricky part) at this point I watch the network for this connection because git goes banannas downloading stuff and if yih cut the network before it’s done it fails. Basically you’ll see the machine with a high network read then suddenly… None.
Disconnect the network for the VM.
At this point I usually let it cook because it’s really close to restarting and when it does… It will start disconnected from the network.
Im not looking for full boot to a panel at this point. I’m ONLY looking at my VM console at the HA console screen. Then I just pop a few core logs commands until I am satisfied the system is booting properly (ignoring anything potentially related to can’t see network, try it once just to see what THAT looks like it’s a very unique signature in the logs).
Because at this point I’m ALSO not trying to troubleshoot it. The only question is ‘is this a valid HA backup with my stuff. Yes or no.’
Whether it boots SUCCESSFULLY is a completely different question, ![]()
but for the purposes of is this a valid bootable backup. Y/N it just passed. Because if it’s broken at this point I’m confident that I have backup files for each configuration I can get to and the machine boots enough to be recognizable and have any secrets or information I cannot recreate otherwise. The way HA is constructed if I have a valid entity registry and DB and recognizable filesystem (all in the backup and valid or invalid with this test if the DB or entity registry is bad - you’ll know… It looks very different than I just can’t see the internet…) the rest is re-installable.
Thank you!!
I may have consider Proxmox, though I know nothing of it. The local power went off for a few seconds and I noticed that the Beelink went off and I needed to switch it on manually. My solution, that worked with the Yellow Box, to put the box on a Kasa switch and then reboot it from the Kasa App did not work.
Google Gemini tells me that the Beelink Mini PC can be set in BIOS automatically to turn ON after a power loss. I will try tomorrow.
Yes this would be my recommendation. (I believe the setting you want is to return to the previous state after a power outage. So if the Beelink was powered on before the power went off it would turn itself back on when the power returns, and if it was off prior to the outage it would stay off…)
It makes me a bit nervous to “play” with the BIOS (I am not a super experienced techie) but will follow the instructions:
Yes, you can absolutely set a Beelink Intel Mini PC to power on automatically after a power outage. This is a common requirement for servers or home automation hubs where you need the device to be "always on" without manual intervention.
To enable this, you need to change a setting in the **BIOS** (the system's firmware). While the exact menu names can vary slightly depending on your specific model, the process generally follows these steps:
### How to Enable "Auto Power On"
1. **Enter the BIOS:** * Shut down your Mini PC.
* Press the **Power** button to turn it back on.
* As soon as the Beelink logo appears, repeatedly tap the **Delete** key (some models may use **F7** ) until the BIOS menu opens.
2. **Locate the Power Settings:** * Use the arrow keys to navigate to the **Chipset** or **Advanced** tab.
* Look for a section titled **PCH-IO Configuration** or **South Cluster Configuration** .
3. **Adjust the Power Loss Setting:** * Find a setting named **Restore AC Power Loss** , **State After G3** , or **AC Power Loss Options** .
* Change the value to **Power On** (or **S0 State** / **Always On** ).
4. **Save and Exit:** * Press **F4** to Save and Exit. Confirm by selecting **Yes**.
Yeah….it worked and I can use the Kasa switch remotely if need be.
Proxmox and other containers or virtualization are not needed. They add a learning curve and are yet another vector for possible complications, such as USB port pass-through. If your PC is exclusively for running Home Assistant, bare-metal is the easiest and most straightforward installation method.
When you click on “Restart” after installing updates, you are only restarting Home Assistant Core. Not the supervisor and not the OS.
I am not sure to fully understand.
My issue is that I want HA to power cycle (when HA restart does not work) even when I am not at home. This morning I changed the BIOS of my Beelink to automatically restart when it is turned off (like when the local power goes off and then on again). I also put the Beelink box on a Kasa switch, so that I, if needed, turn it off/on, in the Kasa App on my phone. Am I missing something ?
True, but you can reboot whole VM from proxmox by choosing reboot VM…
This will reboot everything, yes. Brutal way though, so this is to be used only when really necesarry…
Yes, it is a brutal way but I only use it when I can not restart HA in the system (url or iPhone app) and I’m not at home, so rarely.
Nope. It should work. It’s been a couple of years since I had to power-cycle my HAOS server and even then, it was because of something I did to the PC hardware itself.