I didn’t have errors either, but in my log were some messages about components being installed. The last one wasn’t finishing, so I stopped home assistant and installed it manually (I’m running on hassbian, so installed in venv). After that, all is good.
You might look through the logs and see if HA is trying to install something on startup.
Home Assistant is a good open source software, but it is still far from a stable release.
The development is focused on the devices integration but the software architecture is incomplete. To reach a stable release, it is necessary to build a strong software architecture and to address: the component integration strategy, the security, the front-end UI for the devices customisation and the upgrade strategy. At the moment each upgrade is destructive, after the software upgrades, we need to review customised components, device customisation and front-end cards.
Am I the only person who has a complete working system after an update? Am I just lucky? Am I part of a silent majority who have stable systems?
Yes I have been using Linux since the late 90s. Yes I can type at a command line (but if you can type in a forum post, you can type at a command line). In other words I don’t think I have any special skills.
Is my system faulty? It just seems to work. I am concerned that I am alone here.
Mine is stable also. Did not had any major breaking change since the changes in authentication.
Things to note:
Thank you to all the amazing developers working on HA!
Same here, had a few problems earlier, now I read the release notes, assess if I am impacted and if I need that update. Then I usually wait for the initial storm to quieten down.
By then I have a good idea what will break and how to resolve it.
Of course I understand that I use the community as my Guinea pigs. And I am thankful for the brave people that test the beta version as well as the early adopters of every release.
Thank you!
No nick not alone. changed a couple of custom components to have the init.py and some required the manifest.json, but core HA stable as
Seems my issue might possibly be related to a script I recently added?
- alias: 'Check if alarm radio flips to idle'
initial_state: true
hide_entity: true
trigger:
platform: state
entity_id: media_player.ensuite_speaker
to: 'idle'
condition:
- condition: state
entity_id: alarm_control_panel.home_alarm
state: 'armed_away'
action:
- service: script.turn_on
entity_id: script.radio_alarm
If this script runs, it seems to kill HA and the front end can’t be accessed. Only a host reboot resolves the issue. Maybe I need to stop the script before I start it again?
thanx that was the problem. thought 32Gb would be enough for Hassio 
I’ve had an issue similar to what you describe for a few weeks. First, automations stop working and uptimerobot informs me it cannot reach my homeassistant. The frontend is not reachable but for a while at least I can access samba, so I check the log and there’s nothing in there. Hassio can be stable for anywhere between 4 hours to 5 days; previously it has been stable for weeks at a time with no hardware power cycles or reboots.
After a LOT of trial and error I’ve concluded that it started when I added the stream: option to my config. I have two dafang cameras, one of which has only about 95% uptime due to its positioning at the outer range of my wifi network. Various posts in this community have suggested that HASSIO can hang if you have stream: enabled and the connection to one of the cameras is not completely stable. I did notice that some of these freezing occurrences happened shortly after I had remotely checked the camera streams. And I don’t recall this issue happening before I happily added the stream: option to my config.
Having removed stream: from my config HASSIO has been stable for 3 days, even with me checking the cams every now and then. I miss the ability to stream the cam feeds to my TVs but stability is more important. Hopefully this is definitely the issue, because I thought it was my tinkerboard, so I moved to a VM on my server, and then back again when the issue didn’t resolve itself! Then I thought it was an MQTT issue so I spent considerable time making configuration changes to MQTT devices and the broker.
This reminds me of a similar issue last year when binary_sensors were killing hassio every 12 to 48 hours, very similar to this issue. There was nothing in the log that could point me in the right direction until I decided to peruse the github Issues section for home assistant and discovered the binary_sensors issue. There didn’t even seem to be much discussion about it in the community forum.
I have a high tolerance for issues like this in beta open source software but having such serious failures, with no indication in the log, can make life with home assistant very stressful. Stability needs to be absolutely paramount with a platform that is basically running your house. Don’t get me wrong, home assistant is great and the developers / community owe me nothing, but there have been a few times when I’ve considered scrapping the entire thing out of sheer frustration.
Thanks for the feedback. There is a conflict between the stream component and shell commands (which I use for PTZ control) noted here curl shell command hangs HA · Issue #1068 · home-assistant/supervisor · GitHub. I’m just testing rest commands now as an alternative which is a comment made in that issue thread.
I read about the shell_commands issue; I use quite a few rest commands to communicate with the camera PVR software but not shell_commands.
I can’t remember where I read about the unstable camera network connection causing the stream component issue, but there are other similar reports with circumstantial evidence that the stream component is locking hassio:
So the answer seems to be “fix your wifi”.
how so?
(or rather, what do you believe the issue is, and why would fixing his wifi fix it?)
In my case I’ve ha HA lock up a couple of time since moving to 0.92.2 (as seen above) - I dont believe there is any issue with my wifi network (or more specifically, no change in the last few months)
Because he said as much himself.
fair enough.
I dont use HASSIO, but instead have HA running natively under Ubuntu and a virtualenv - and it locked up a couple of times since upgrading.
I’ve now removed the streaming part and waiting to see if it is more stable.
ffmpeg seems to be a suspect too - but that would likely be restricted to a particular shipped version, such as the one shipped with hassio perhaps.
Extending my wifi network might fix it, but with wifi cams you can’t really expect 100% uptime. What’s more concerning is the rather inelegant way that hassio completely locks up without warning or logging. I also use Netcam Studio to manage the cams (recording, time-lapse etc) and it has no issue with a cam sometimes being offline for a moment.
The issue being caused by an intermittent connection is only a theory for now as well, hopefully the issue is identified and a fix implemented.
I accept some of what you say of course, but not the bit about uptime with wifi. It is a well tried technology of some antiquity now. I have to say that getting some Ubiquity AP’s improved every piece of my home wifi network performance, even the hosts that were close to the ISP supplied AP.
If the theory is correct (ie network dropouts in IP cams cause HA to lock up under certain conditions) then I thoroughly agree that HA should handle it gracefully. However if the problem really lies in ffmpeg, which is a steaming pile of hack upon hack built up over many years by lumping exception over exception to the point where spaghetti looks like good code, then that is a different problem altogether.
I second this. My wifi sucked before changing to Ubiquity, now it’s rock solid.
Update to 0.92 from 0.91.4 breaks, if https://www.home-assistant.io/components/nuimo_controller/ is active. Errors are not pointing towards nuimo, so debugging was really hard to me. After commenting out nuimo component…you know…