New update of the OS 5.8 probably broke my home assistant

Tags: #<Tag:0x00007f326f74db48>

Hello Everyone

Hope I can get some help here since I am completely stuck

I have a RPI 4, 8gb with home assistant.
Up until yesterday (13 December) I had home assistant running.
After the release of OS 5.8 I decided to do the update (I do have a snapshot) and everything seemed to be fine. I could still get in the frontend and my automations still ran.

Today, I was changing some entities and then went to update the scripts with said entities. ran the checker and since everything seemed fine I restarted the rpi to have everything clean.

Hell, broke loose. Home assistant seemd to not be reconnecting and indeed I was not able to load the front end, however I tried to enter the files through the network and I was able too. This intrigued me. So The rpi is booting but the front end isn’t? I tried deleting everything inside the scripts file thinking I might have done something there, but that didn’t change anything.

I then went and got my rpi and pugged it to a monitor to see what was going on. Seems like after turning on, it starts booting but then it just shows

Welcome to Home Assistant
homeassistant login:

I have no idea where to go from here. Everything seemed to be going so well 3 hours ago lol

Much appreciated for any comments

My system is a RPi 4 with 4gb.
I let it update to OS 5.8 last night (14 December)

I’m not sure what “broke loose” on your system. Is MQTT working?

On mine, devices trying to connect to MQTT on hassio.local stopped connecting.
The errors on the sensor devices look exactly like they did last week with this error
https://community.home-assistant.io/t/mdns-name-changed-with-4-13-os-update/226843/4
Except hassio.local still works for the user interface, so it’s not the mDNS, or at least, I don’t think it is.

Devices connecting to MQTT with and IP address still work. Devices connecting to hassio.local don’t.

Without sensors, my system is effectively down.

Hi,

This is where a little network knowledge can go a long way.

Firstly, Windows file sharing use a server daemon called Samba - this is separate from HASS itself, and client machines locate the HASS server via a different method from the web GUI (typically WINS \\servername\share, rather than mDNS homeassistant.local). That SAMBA is working suggests the RPi4 itself is fine.

What did you enter into a browser to access HASS via HTTP please? Typical values are:

Many sensors (e.g. Tasmota using MQTT to a broker like Mosquitto) connect via the IPv4 address, rather than a mDNS name - your router probably set the address via DHCP and this is unlikely to change.
It’s a good idea to know the IPv4 address of your RPi for troubleshooting - shown under HASS -> Supervisor -> System -> Host System.

The first point is to find out if the network has changed, or if HASS itself is broken?

What’s the name / IPv4 address used for SAMBA file shares? Can you use the IPv4 address directly in a browser? (192.n.n.n as above) Does it work if you add -2 on the end of the name before the :8123/?

If the IPv4 address or -2 works via HTTP - the problem could be the mDNS bug @MikeSherman linked to.

As you’ve got console shell access, here’s the reference to login and check the network:

With console access you can find the RPi IPv4 LAN address, but be careful here as HASS uses virtual machines with PRIVATE addresses in the range 172.n.n.n, rather than typically 192.n.n.n used on LANs

 homeassistant login:
# login username = root, password = <blank>

~ $ ha network info
docker:
  address: 172.30.32.0/23
  dns: 172.30.32.3
  gateway: 172.30.32.1     # PRIVATE address, not used on your LAN
  interface: hassio
host_internet: null
interfaces:
- connected: true
  enabled: true
  interface: eth0
  ipv4:
    address:
    - 192.168.1.9/24       # **LAN IPv4 address**
    gateway: 192.168.1.1
    method: auto
    nameservers:
    - 192.168.1.254

In this example, I’d try browsing to http://192.168.1.9:8123/ - the LAN IPv4 address.

With console access, it is also possible to restore the last snapshot if the network is OK, and HASS itself is broken:

You could also install a SSH client (e.g. Windows - Putty) and try connecting that way.

I know my Pi’s IP address
My Sonoff devices talk to MQTT at 192.168.1.190 with no problem.

Other ESP8266 sensors running my code for well over a year are trying to talk to MQTT at hassio.local.

They have broken a couple of times before; once when I reloaded the system after the mDNS name changed to homeassistant.local, and twice (after OS updates) when the name on my network changed to “hassio-2.local”.
The change to hassio-2 was easily fixed by changing the name twice in Superisor->system, as in the link I provided.

When the name had the “-2” added you could open the UI with http://hassio-2.local:8123

After the OS update to 5.8:
I still can open the UI with http://hassio.local:8123/
Samba works at smb://hassio/config/ or smb://hassio/share/

So the mDNS hostname has not been changed this time.

But there’s something broken between hassio.local and MQTT in OS 5.8.
The code on the devices has not changed.
The router has not changed.

I don’t know where else to look.
-Mike

After the upgrade my switches also does not work. The sliders switch on an off again automatically without triggering the actual devices. Nothing works…

Can not install using OS 5.8, tried on RPI3 and RPI4

Hi Guys,
Was this resolved, I am in the same predicament, there is Homeassistant login and password required, when I enter my HA UI login and password it says invalid password, I am running Ha on a virtual machine.

Regards
CN

I have not found a resolution yet.

External devices (ESP8266) can not connect to the MQTT broker at hassio.local (mDNS), but they can connect to the IP address.

From a Linux machine, I can now connect to HassIO with http://hassio:8123 (LLMNR). I intend to try ESP devices with LLMNR.

-Mike

1 Like

mine gets stuck here when I start the VM, not taking my username and password, “root” as a login takes me to the second screen.

using root as login

seems

 ha> supervisor repair

fixes it , it’s now running and all the updates have been done :grinning:

Really sorry for only now putting a response

The way I fixed it was to just start over in a new SD card and upload a snapshot

I believe my problem was, I was changing the scripts.yaml file but since I am not an expert I probably deleted it making the file unreadable and it was not starting because of it? We will never know I guess

OS update 5.8 broke mine completely too. Can’t even get into SSH session. It’s always the same story… updates break it completely. This is the only thing why HA sucks big time. Otherwise it’s a really nice system. But reliability is virtually non-existent.

Caswell1000 wrote:

ha> supervisor repair
fixes it.

Didn’t do anything to my HassIO OS on a Raspberry Pi.

I did program a D1 Mini to connect to MQTT on “hassio” instead of “hassio.local” and it works.

So it appears “hassio.local” is what’s broken.
Now I have to bring all of my sensors and devices in to the computer and reprogram them.
Totally defeats the purpose of naming the device instead of using the IP address.

-Mike

Do the sensors support mDNS name resolution? (*.local domain)

For instance, Tasmota removed mDNS libraries to save flash memory space on ESP devices. Before then, mDNS was optional and often disabled:

The Tasmota Wiki has details:

Host = your MQTT broker address or IP ( mDNS is not available in the official Tasmota builds , means no .local domain!)

So you PC / Mac might work, but Tasmota and Android will never resolve *.local to an IP address. And that’s before HASS changes the hostname, mDNS name, and added LLMNR resolution in HASS OS 5.8.

Some consumer routers also support the *.home DNS zone based on DHCP hostname. As this done on the router, basic sensors have a better chance of working.

My Linux machine can’t do mDNS, but the ESP8266 sensors I coded used to work with the MQTT broker at hassio.local. They no longer do. I reprogrammed all of them to connect to hassio.
My Tasmota / Sonoff devices are programmed with the IP address.