If you’re using HassIO then do a fresh install onto an SSD, and then restore a snapshot.
It does, but that’s the nature of Beta software, which this really still is. It’ll eventually stabilise, some time after 1.0, but for now this is a work in progress that changes every three weeks. Some of those changes are known to not be backwards compatible (like the recent changes to scene) and some come as a surprise to everybody, including the devs (like the full impact of the recent changes to scene).
If stability is important then there’s two things you can do:
Run a test instance with all the same integrations configured (obviously that’s impractical sometimes, like with Z-Wave). You can upgrade that first and sanity check all the things that matter.
Don’t rush to upgrade. Watch the chatter here, in the GitHub issues list, and most usefully on the Discord server. Give it at least a day to see what problems are falling out, if any, and upgrade the test instance only once you’re happy that there’s no show-stoppers for you.
That’s exactly what I do, and yes, it often means I’m a week (or more) behind in the upgrades. On the other hand, it also means that I very rarely have any real issues caused by an upgrade.
I have not experience these exact same issues as you, but my system does have other issues and a few creative workarounds.
The main issue for me is how often HA needs to be restarted when changes are made.
If you do need to restart HA then all automation + timers get reset back to 0. I like @flamingm0e’s workaround of using NodeRED, and am thinking of doing something similar myself.
I agree that stability if more important than features, especially with automation software, stability should be king.
Currenly I treat HA as beta software as it’s still v0.x, so wouldn’t want to rely on it anything critical.
Hopefully once HA reaches v1.x stability will not be an issue, but I don’t have a crystal ball!
We used to do something similar in PLC’s if you have a register (input_number) for the last reading you can multiply this reading by (say, and adjust this to your required responsiveness and the noise issues you suffer) 49, add the latest reading and divide by 50 putting this value back into your register.
Alternatively you will have to have 5 registers and rotate them (move 2nd oldest to oldest, 3rd oldest to 2nd etc. Then discard lowest and highest, averaging the rest, it just depends what gives you the best result for your needs. EDIT: Just a word of caution, try to minimise the frequency of this and any other forced sensor update, not just for loading on the sensor but to reduce processor load - just as good practice and common sense. EDIT2: use a time_pattern trigger for this, say - seconds: ‘/10’
I think the reason the maritime gear costs so much is that it is generally 99.9999 % reliable whereas HA gear … (with the best will in the world) … isn’t.
I think I’d have spares configured and paired ready to go and if you have an emergency … swap it out, rename the devices and you should be back up in mins rather than hours.
Look into (say) Visual Studio Code (other editors are available !) Mine runs on a separate PC as it can do name changes accross EVERY file in your instalation for this sort of thing.
OH ! and make backups after every major change (and some minor ones depending on the amount or repeated work involved).
Tink, he says he’s on a Pi 4 so the SSD route would require him to install Raspbian, this will soon be a deprecated route (Though I initially I dismissed for that reason, I’m going to set up a test system just like this (my SSD arrived today)) Anything as a consequence he (and I) should be taking into account ?
Quite a few people find the restarts a bind but we are wieghing in to try to improve this … (feel free to add your vote )
Thanks, by the looks of it I have already voted, I’d vote twice if I could!
I also use NodeRED and Domoticz as a part of my setup, and both of these only ever need restarting when plugins/nodes are added or removed, config/flow changes never need the host software to be restarted. I know these are very different pieces of software, but I’d like to think there’s a chance this may be possible in HA also.
I’m not using HassIO so my approach may not apply at all. I did it using dd and then resized the partition and fs. Probably Tinkerer’s advice would be easier to follow.
I was running HA on the PC initially because that was the expedient thing to do but it was problematic because rebooting the PC meant taking HA down too, even if the reboot had nothing to do with it. I wanted to avoid unnecessary reboots because (as you know) restarting HA is disruptive. I want it to restart only if it MUST. Besides, the PC is also a file server. Sometimes the disk checks at boot time take a long time to complete but over 90% of that time is spent with files that don’t pertain to HA. So HA would take a long time to come back for reasons that have nothing to do with HA. It was just not viable.
Making a fair comparison betwen the PC and the Pi on the basis of my experience is a bit difficult because the PC was not dedicated to running only HA, and my configuration became more complex after I moved to the Pi. One thing I can say is that moving from the sd card to a SSD drive on the Pi was critical. Prior to doing that I was thinking I might have to move to a NUC. The one thing I can say after having installed the SSD on the Pi is that I do not regret having moved HA to the Pi.
If you read the forum you’ll find quite a few people complaining about the Pi and moving their installation to a NUC, and implying that the Pi was just not good enough for HA. (Keep in mind through that some folks are talking about different versions of the Pi, sometimes very old.) I’m sure there are usage scenarios where’s that true. Some people try to have their Pi do too much. Then again, I’m sure there are cases where people just threw hardware at the problem rather than try to figure out how to tweak their setup on the Pi.
Absolutely – please do be aware of construction materials when considering placement of radio frequency devices. Large bulkheads or beads of steel that are a centimetre or more thick are likely to block and/or reflect radio waves, and if there is a density of transmitters in a corner then interference could well be affecting the ability for signals to be reliably transceived.
Also cheaper devices are likely to have less reliably tested software and when environmental conditions push tolerances to their limit, there is more in the chain of technology that can stop an intended automation from having its effect in the real world.
I occasionally swear at my HA system, maybe less now its on a NUC than when a Pi – but it tends to be the same group of low cost devices that don’t behave as I’d hope. And I can always reassure myself that I would not have been able to string together such a diverse range of Things into a branded solution, and that the whole setup would have cost $000s more if I had bought ‘it just works’ gear.
Enjoy your learning experience and I hope that this helpful community can help you with the individual niggles that you can manage to isolate and describe.
)