Ugh I hate this so much. Have done full reinstall and still have the same intermittent issue.
I have the exact same problem had the raspberry on for the hole night and at morning I was able to access to the GUI but after a reboot the GUI wasn’t able to access anymore. I can also ping the Pi, but cannot acces any of the GUI. I use the cable on the pi and now the pi don’t have any internet connection, but I cannot se that this is nessesary? Is there anything to do with WiFi settings?
Having the same issue…hassio on a pi4 wired with DHCP static reservation. The interesting part is that I can access HA from my phone and work laptop (both on same wifi network) but not from personal laptop also on same wifi network, both laptops with same OS.
This is the route table output from laptop that fails:
Destination Gateway Flags Netif Expire
192.168.x.x dc:a6:32:69:49:xx UHLWIi en0 1184
And this from laptop that works:
Destination Gateway Flags Netif Expire
192.168.x.x dc:a6:32:69:49:xx UHLWIi en0 1188
Also VERY interesting, nmap sees some services open but tcp/8123 appears to be a filtered port (e.g. behind a firewall) – WTH?
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-09 13:16 EDT
Nmap scan report for 192.168.x.x
Host is up (0.0041s latency).
PORT STATE SERVICE
8123/tcp filtered polipo
MAC Address: DC:A6:32:69:49:xx (Raspberry Pi Trading)
Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-09 13:14 EDT
Nmap scan report for 192.168.x.x
Host is up (0.0046s latency).
Not shown: 8973 filtered ports
PORT STATE SERVICE
22/tcp closed ssh
25/tcp closed smtp
53/tcp closed domain
80/tcp closed http
88/tcp closed kerberos-sec
110/tcp closed pop3
139/tcp open netbios-ssn
143/tcp closed imap
389/tcp closed ldap
443/tcp closed https
445/tcp open microsoft-ds
465/tcp closed smtps
587/tcp closed submission
636/tcp closed ldapssl
993/tcp closed imaps
995/tcp closed pop3s
3389/tcp closed ms-wbt-server
5800/tcp closed vnc-http
5900/tcp closed vnc
6129/tcp closed unknown
MAC Address: DC:A6:32:69:49:xx (Raspberry Pi Trading)
Nmap done: 1 IP address (1 host up) scanned in 4.74 seconds
from: https://wiki.onap.org/display/DW/Nmap
Filtered means that a firewall, filter, or other network obstacle is blocking the port so that Nmap cannot tell whether it is open or closed.
Clearly layers 1-3 are fine so not an issue with the network itself – spent too much time troubleshooting this already. Think I’ll flash again & see if something is different.
quick update…using ssh local port forwarding through a linux system that can access HA for now.Will try a fresh build soon.
Having the same issue. Suddenly, after reboot, the device simply not accessible. Can ping, but not SSH and no web. Mobile app also cannot connect. Seems my only option now is to completely reinstall this thing.
HA just isn’t ready. WAY too many issues that are so elementary. There’s potential, but I’m a systems engineer and software engineer and even I find myself wasting just hours of time with it.
For me, its not an issue of money. It’s privacy and performance that are important. And I want a more universal way to connect various technologies. If I could buy a hubitat right now, I think I’d do it. This just wastes too much precious time.
1 Like
I was able to login via HDMI console with a keyboard. It now says…
[ERROR] Somethings going wrong! Jump into emergency console...
It then drops you at a console. But that’s it. I will try to check into network settings I guess…
How about asking for help first? To help we would need to know what installation method you used, hardware etc. HA is super easy to set up so there must be something you have done wrong, no offence.
Flashed to brand new sd and completely new RPI 4. Same issue. It did initially seem to start, but then if you type CORE CHECK, it says connection refused to the hassio supervisor. In other threads, they are saying the ip gets blocked? I also checked the time on the RPI, but the date is good.
I am going to try to scrap the idea of running on a PI and install again on Hyper-V - which is what I used during some initial testing. Perhaps that’s more stable.
Have you set the pi up to have a fixed IP address? Where are you typing ‘core check’? And why?
I tried core check to see if it was actually running because the web ui never would come up.
The IP is from dhcp, but it is reserved.
I just tried again a fresh install. Flashed the RPI 4 image again and tried to allow it to boot. I connected a monitor because it still never fully boots up. Can ping, but that’s it. I can type in root for login, and then it immediately says Somethings going wrong" Jump to emergency console.
When typing docker ps, there are no containers. Just an empty list.
Maybe the current version (hassos_rpi4-4.11.img) is just not working.
At the moment, I am running virtualized in Hyper-V. But it’s not a good solution because I want to connect my conbee 2. Hyper-V has no way to use the host’s USB ports when the VM is not windows based.
So… I guess I will just wait for the next release? I have now tried this on two RPI 4 machines and two different SD cards. Same outcome.
Update:
This seems to have been a DNS issue - as far as the root cause. The hassos supervisor image was never getting pulled from the repo due to a DNS resolution issue. The local DHCP server was issuing a local DNS IP, but for some reason that server was not able to provide proper name resolution.
A workaround was to hard code 1.1.1.1 into the /etc/resolv.conf file and then issue a restart for the hassos-supervisor service.
systemctl restart hassos-supervisor
After a short while, the image was pulled and finally the supervisor could communicate. The error message that is thrown is a bit misleading “connection refused”. In fact, it can’t connect at all because the service is not even running. So perhaps it should say something like timeout, or something a bit more useful.
FYI… there are other tips that suggest setting the system time, but that seems to be an old “fix” that does not apply in this case.
My permanent fix to this is to set the DNS (not from DHCP) so the name resolution issue does not come back.
2 Likes
Well for me it was entirely the fault of the crappy micro SD card I had. No issues for over four weeks now I’ve got a Sandisk.
Thanks a lot! A non reachable DNS server was exactly the problem …
I am a reasonably experienced Linux sysadmin and been running a number of wikis and forums for over a decade, I’ve also been using NodeRED for some home systems for over 3 years. I’ve recently installed hass.os on an RPi config on my home LAN (a pretty standard RPi dedicate os install as per your installation instructions). I do connect to my HA system over HTTPS using a certbot issued certificate that I share will a few other services within my domain that I either offered publicly (such as a blog) or host privately on my LAN. This is standard for me and all works fine. (BTW, I am also a github committer on a couple of reasonably large projects, so understand these S/W lifecycles.)
What doesn’t work fine is that I get intermittent “hass.io not available” placeholder screens when I attempt to log into the default Lovelace dashboard with system vanishing for a few hours. I can log into SSH:22 and SSH:22222; I can open bash sessions on the various running containers. I can do a ha core log. What I am used to doing on normal server set ups is to drill down into the normal /var/log error and other logs to diagnose root causes for this type of intermittent failures. In this case I can’t even find the logs, nor can I find any user documentation which might point me to them. It doesn’t help that the different containers have different templates for R/W, logging etc. varies from container to container. Few include a standard set of utilities, so you can’t even use lofs to find out that way.
Perhaps some nice developer or mod can point me at the relevant howto or documentation of ha core
and supervisor logfile locations Thanks 
Oops. Shutdown ha core and restarted the server. journalctl is now producing what I’d expect. Sorry,
What I’ve found is that I can have multiple clients on the same LAN where one can see and serve HA pages fine whilst another will get the “System available” place holder page. Going into the Chrome “developer tools” console and drilling down, the issue seems to be that client-side cached HA JS scripts get into a latching state whereby once a manifest or other request has timed out, the page render JS code always times out, instead of retrying. Hence one browser gets the “system unavailable” whilst another browser on another PC can see the system fine.
This seems to happen mainly on my chromebook which never truly exists the chrome browser. A work around is to reboot my chromebook and on reboot, the site appears fine.
BTW, this isn’t a DNS caching issue. I’ve checked and the DNS entry is fine.
The access to HA became very flaky lately.
Wiped/flashed my SD card and restored a backup.
After the restore, the onboarding page was not reachable.
I was able to regain access to the UI with https://homeassistant.local:8123/ : note the secure connection with httpS (Chrome gave me a warning but I proceeded anyway)
I need to fix my database : logs show multiple errors such as
Error saving events: (sqlite3.DatabaseError) database disk image is malformed [SQL: INSERT INTO events (event_type, event_data, origin, time_fired, created, context_id, context_user_id, context_parent_id) VALUES (?, ?, ?, ?, ?, ?, ?, ?)] [parameters: ('state_changed', '{}', 'LOCAL', '2021-02-06 15:02:12.042440', '2021-02-06 15:02:12.042440', '4e393462f68474a31f9f54dba4c18fc6', None, None)] (Background on this error at: http://sqlalche.me/e/13/4xp6)
This might be the reason for my unstable HA…
2 Likes
Delete the homeassistant_v2.db file and restart HA. You’ll start with a fresh one.
I typically delete that file after a restore.
And it sounds like you restored a duckdns configuration, where you would have to use https://
1 Like
HI,
I lost 2 weeks on this Problem ,tried everything, new install, new sd, differtent RPI, almost threw everything out the window and started doubting HA.
Thanks for the post, after deleting homeassistant_v2.db in the config folder, everything worked fine again. I still don’t understand the link with this problem if i hadn’t find this post, i would have become crazy
Hi. Hope that someone is looking.
I have configuration with RPi 4B with SSD. Original RPi power supply and recommended RPI installation. System was working stable for over a year. After August upgrade, I have problems that from time to time system becomes inaccessible. Only thing I can ping IP. No SSH, no Samba, no http… After power on/ off it is back up again. Issue is that installation is on 300 km from me and I can’t do it every time it happen. It is static IP
Any tip on this?