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.
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
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:
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.
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.
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.
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.
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
