Yesterday i updated to 2020.12.0 and installed localtuya for some chinesse things, and in the morning i was unable to access frontend, the solution was turning off the rpi4 and turning on again (classic), but when i come from the work, the hass was crashed again and i wan unable to get into the front end, i just updated to 2020.12.1, but i think i need to downgrade, so, any ideas what is happening?, im new to this.
Edit: i just downgraded to 5.6 “ ha os update --version 5.6” and it works fine for now (4days working without issues) i think is just the OS broken
I have also been experiencing problems with Home Assistant becoming totally unresponsive at least once, sometimes twice daily, requiring the host (RPi4 also) to be rebooted. Everything was totally stable until the upgrade to 2020.12.0 and OS 5.8 when released on Sunday just gone. Updating to 2020.12.1 has made no difference. Somehow, I suspect the OS update may be to blame, as my processor and memory usage starts spiking (causing processor temperature to soar) prior to everything becoming unresponsive. It looks like some sort of memory leak or process running out of control. I imagine there must be others with this issue. My system report is below in case this helps anyone shed some light on what is happening and hopefully issuing a fix. I would provide logs, if I could find a way to do so, but it’s impossible to access anything while in the unresponsive state and the logs are cleared on the host reboot.
System Health
version: 2020.12.1
installation_type: Home Assistant OS
dev: false
hassio: true
docker: true
virtualenv: false
python_version: 3.8.6
os_name: Linux
os_version: 5.4.79-v7l
arch: armv7l
timezone: Europe/London
GitHub API: ok
Github API Calls Remaining: 4904
Installed Version: 1.9.0
Stage: running
Available Repositories: 683
Installed Repositories: 7
logged_in: true
subscription_expiration: 13 January 2021, 00:00
relayer_connected: true
remote_enabled: true
remote_connected: true
alexa_enabled: true
google_enabled: false
can_reach_cert_server: ok
can_reach_cloud_auth: ok
can_reach_cloud: ok
host_os: Home Assistant OS 5.8
update_channel: stable
supervisor_version: 2020.12.7
docker_version: 19.03.13
disk_total: 116.5 GB
disk_used: 6.6 GB
healthy: true
supported: true
board: rpi4
supervisor_api: ok
version_api: ok
installed_addons: Samba share (9.3.0), File editor (5.2.0), Terminal & SSH (8.10.0), Check Home Assistant configuration (3.6.0)
I have the same problem. The day after or so, I updated to 2020.12.0 and new OS my automations didn’t trigger, and I noticed that I could get into the UI. The RPI 4 was very hot, and I unplugged the power cable as I had no other interface to it. Waited a good 20 seconds and plugged it in again and it worked.
Then a day or two later the same thing happened. The bad part is that I cannot access it at all, so when I am remote, I have no way to recovery. When at home I power it off and on.
It has been stable for a long time ahead of the last update.
I am having the same problem. I had recently enabled Home Assistant Cloud access and thought it was that. I am running the exact same version (latest) and it only recently started.
The heatskink on the Pi 4 is burning hot. It also kills all other internet connectivity for everything else on my network. As soon as I unplug the Pi then everything comes back.
If it helps i am running my system off an SSD.
Have you managed to resolve?
I have moved my OS version back to 5.6. This worked perfectly, will report back if its stable.
As far as I can work out, from the links to Gibthub above (thanks @oyta) the consensus appears to be that it’s possibly a firmware issue introduced in OS 5.8. I suspect there’s some sort of memory leak from what I am seeing on the RPi memory sensors etc.
I have just rolled back to OS 4.20. To go back to OS 4.20, use the following command in the terminal/SSH (take a snapshot before downgrading):
ha os update --version 4.20
I will report back if it crashes again. Hoping this solves the stability issue until a proper fix is implemented.
@pepe59 Comments on the Github links above indicate it’s not fixed by upgrading to OS 5.9. I don’t have time to tinker with this ATM and just need it fixed. I was stable before I upgraded, hence the decision to downgrade while waiting for this to be investigated and a proper fix issued. I’ve only been running OS 4.20 for an hour after downgrading, so too early to say if the issue is gone. Will need to get through at least 24 hours with no issue, before I have any confidence it’s resolved by the OS downgrade alone.
Same instability issues over here. Daily reboots and unavailability somewhere after the new 2020./2021. naming convention for ha versions.
I don’t have hassio but docker version of ha on centos8 server so doesnt looks like a problem on hassio only.
Running integrations like tuya, Sonos, unifi, deconz, hacs, homekit, mqtt, tasmota, Xiaomi gateways, Volvo on call
I suggest you downgrade to OS 4.20, as I described above. As far as I can see, the underlying issue has yet to be addressed (see the links provided by @oyta to Github above).
Out of interest are you running the 32-bit or 64-bit image on your RPi4?
Hi @robertwigley - I am using 32-bit image (could not get the 64-bit to boot with my SSD over USB) on my RPi4.
OK - I ran the roll back to OS 4.20 just now. I hope this fixes things!
ha os update --version 4.20
On a side note, I had this running on a much more powerful machine running debian testing under a ‘supervised’ install. It had the same issue and I could never figure out why so I moved back to the RPi4… so, I hope this OS roll back fixes things!
well shucks… I didn’t think this through. I doubt (does anyone know?) that 4.20 can handle the SSD boot.
I may need to move to a newer OS that supports SSD. It isn’t clear to me which version(s) are in the venn diagram of “supports SSD” and “is stable”
Interesting, I am also using the 32-bit image with RPi4. Unfortunately, I don’t think OS 4.20 supports SSD, but I could be wrong. You might need to use one of the earlier 5.x builds prior to 5.8 in that case.
Unfortunately, there doesn’t appear to be. Both issues (linked in the thread above) are still open on GitHub. You can use the OS downgrade fix as I describe above (if you don’t need e.g. SSD boot), until there is.
