Hello Lalit,
Can you tell me what the solution was? Everybody with an problem like this will take a look in this ticket.
But there is no solution?
I hope you can tell me how you solved the problem.
Kind regards, Thetmar Wiegers
1 Like
I also wonder what the solution was. I just restarted the system and now I cant reach it anymore. If I ping the ip it works.
Same problem here. After restart I can’t reach the home assistant via IP or host name.
But it is reachable via the remote access (nabu casa / home assistant cloud).
Any suggestions?
I appear to have a similar problem. I flashed the image for a 32-bit Raspberry Pi 4 B. Booted the Pi but the web interface is not accessible either by host name or IP (using port 8123). Chrome says the connection is refused. I can ping the Pi’s IP address from my PC. I’ve shutdown the Pi to verify I cannot ping IP, proving it is the Pi.
The image file I downloaded and used is named hassos_rpi4-3.13.img.
When I connect with keyboard/HDMI, I can login and run nmcli to verify the IP address. The date/time is also correct.
Since this is the first time I’m using Hassio, I do not know what to check next. The device is accessible on the network, but it does not appear there is a webserver running.
Also hitting this and really disappointed I can’t find a solution 
Also been getting this issue on my nuc for the past few weeks. Have to keep restarting and hoping it lasts.
Interestingly I noticed when it stops, it also stops writing to the log and database
If you plug it into a monitor and watch it boot, are there any errors? I have the same outcome (can ping the pi but not see the webgui) which in my case I have narrowed down to be caused by reboots leading to hard disk corruption in HassOS (I posted my issue here
Has anyone found a solution for this? I’m stuck here now as well. Are you all just running away and not ever finding a solution?
Another person with same issue.
Can PING and see the Pi on my network, but GUI doesn’t work and automation stops working too.
Only way to get it back working again is a power pull.
Before I throw it all in the bin, has anyone found a solution?
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.
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.