For all who are interested in keeping their system in a hibernating state:
First i will thanks for the first instructions @rdekruyf on how to keep our systems running without the need to immediate migrate to other solutions.
I did several tests, I have the following result
latest version of the supervisor that still works is 2021.01.8
I am currently using Core version 2021.2.3
except for lines (which need to be commented out or deleted) in the file
/usr/src/supervisor/supervisor/misc/tasks.py
async def _update_supervisor(self):
"""Check and run update of Supervisor Supervisor."""
if not self.sys_supervisor.need_update:
return
_LOGGER.info(
"Found new Supervisor version %s, updating",
self.sys_supervisor.latest_version,
)
await self.sys_supervisor.update()
then the automatic nightly supervisor update should no longer take place
If you are interested in newer versions of addon packages, this is always case by case:
I use the following procedure:
update the supervisor to the current version
updating addon package
make a snapshot
update the supervisor to version 2021.01.7 (2021.01.8)
do a snapshot recovery
if running a new version of the addon package, under the old supervisor it’s OK, if it doesn’t work I implement an older snapshot for addons
finally, don’t forget to edit the file (/usr/src/supervisor/supervisor/misc/tasks.py) again and comment out or delete the lines
We all knew it was coming; however, I had hoped we could spin it out a little bit longer
Looks like my planned move to a NUC needs to be accelerated. @fredrike Thank you for creating the package, without it I would not have started my HA journey. And thank you for all your help over the years. Same goes to everyone else in this thread!
Hold you horses, I’ve got a QEMU (Virtual Manager) instance of Home Assistant Supervised to run on my DS716+II (officially not supporting VM) and restore my snapshot from the spk-version.
There are still some tests to be made but it surely looks promising.
Here is a quick guide on running HomeAssistantOS on Synology VMM (perhaps we can add this to the official documentation as this is an supportedTM installation method).
Thank you so much.
I don’t know which way I will follow with my HA, but right now, all that I know is that I’m so thankful. Thanks to you and your amazing work, I discovered HA.
Hi, also from me and a couple of others not logged in the community - great work, fun and a very good way to get understanding and get going with home assistant. I agree with all that see it as a pity, but also want to highlight that everyone that built Home assistant are sharing the same goal.
If it would happen that you or someone else get an epiphany on how to make the installation work somehow I am all ears and would love to support with coffee/beer/patron.
I am (with several probably with me) on high end NAS but that is on the border that do not support VM.
and as for not feeling the love… you have it in the Swedish corner!
Just to conclude what I have written up there.
I’ve received my RAM extension (HyperX Impact HX318LS11IB/8), simply plugged it in and it after rebooting, the 218+ instantly showed 10GB RAM. Using Synology’s VMM to import the ‘hassos_ova-5.10’ OVA was quickly done and after waiting a couple of minutes for HomeAssistant to get prepared, the login screen was shown. Restoring a freshly taken snapshot from the old system was surprisingly simply (different to what I’ve experienced before) and the system was ready. I only had to update the URLs of my Influx/Grafana installation, because the VM has a different IP and that’s it. Updating each component and addon to the newest version went without problems and now I’m satisfied.
The VM normally takes 5-6% CPU load and 4 GBs of RAM. It works like a charm.
So what’s left is to again say thanks for the hass.io-Synology extension. It enabled me to start using HA and I’m not sure whether I would have started without it. But now I’m going to remove this package and continue using the VM way.
So as I said I’ve got my 4GB RAM so in total 6GB on DS218+. Running inside VM no problem at all.
Comparing how quick stuff loads Node-RED instance Dockerized running on Synology host system opens 600-700ms faster than the one running on virtualized as an addon (hence also Dockerized). But, overall, I must say, no issues at all.
You must keep in mind that I don’t have any video surveillance or something that may destroy the CPU.
My setup is Node-RED, Zigbee2MQTT (this one I kept running on host Synology (dockerized) as well as the MQTT Broker, as I’m lazy to re-pair all devices (haven’t found a way to recover devices list)), VSCode, SSH Terminal and few other Wi-Fi devices like Xiaomi, Slide curtains etc. so nothing special.
With Zigbee2Mqtt the only issue or smth unusual I noticed is the fact that logs were absent after line in the log like node ./index.js, usually it’s full of logs, so I didn’t like that either. But in Zigbee2MQTT if I asked to build a map it did build one, but with a coordinator only and that’s it (CC2531), no errors or so.
But it may be caused by the fact that I “mounted” USB stick after VM launch and not while it was in a disabled state. Anyway, never bothered trying to figure it out.
I’ll try now
