Mosquito MQTT update v3 broke my hassio

Installation Home Assistant OS
66

They (home assistant or supervisor) don’t appear to be loaded/running yet. Refresh the page repeatedly or clear browser cache?

67

Samba v8 is not starting (it is not working).
SSH is closing my connection.

In other words I don’t have tools to control it. Now I will try with hard rest.

68

I had the same exact issue and ended up replacing Mosquitto with the following addon: MQTT Server & Web client

Works great

69

OK here is my situation:
After 5 hard restarts Hassio is not starting. I don’t have access to it via SSH nor Samba.
Please tell me what are my options. Do i have to restore backup?

70

I don’t grasp all the issues at play, so I’ll just say what worked for me (and how it stopped working). Updated Hassio 0.81.6 and also saw an update for Mosquitto, so I applied that. Don’t have any functioning mqtt switches/sensors yet, just using it for Owntracks, so it took me going to work today to notice that Owntracks had lost access to the mqtt server.

Reading through this thread, I updated the Hass.io configuration page with usernames and passwords that I had previously entered through the command line (I think. It’s been a while). Restarted Mosquitto, but no change. From the Hassio -->System tab, I hit “Reload” at the bottom of the Information pane. At that point it showed a new Supervisor version, 139. I upgraded from 138, restarted Home Assistant, and all seems well. I still have an mqtt section in configuration.yaml, giving the broker as “localhost” and defining the port, protocol, username, and password.

71

If you are running HassOS you can connect a keyboard and monitor to the pi (if that’s what you are using).
Then you use “root” to get to the Hassio CLI.
From there you use “login” to get to the host OS (with a # prompt).
Then you can use docker ps to see what is going on with your containers.
If supervisor seems to be restarting within a short amount of time repeatedly, you can remove discovery.json which is in /mnt/data/supervisor. Then reboot the whole thing and see what happens.

1 Like
72

I don’t know if this is related but I spent several hours last night and a few this morning trying to get my HA setup up and running again. It started when I went to upgrade from 81.4 to 81.6 which failed for taking to long (I think this was due to chromecast auto discovery hanging the boot up process), so it reverted back to 81.4 which was nice. Any ways, I then decided to reboot the host (RP3) and that was pretty much the end of that HA setup. I was able to ssh as root into the host and found that the hassio-supervisor docker image kept restarting after 6 or so second. I looked at the logs and found this:

Nov 05 06:57:03 hassio start-resin-supervisor[24592]: Traceback (most recent call last):
Nov 05 06:57:03 hassio start-resin-supervisor[24592]:   File "/usr/local/lib/python3.7/runpy.py", line 193, in _run_module_as_main
Nov 05 06:57:03 hassio start-resin-supervisor[24592]:     "__main__", mod_spec)
Nov 05 06:57:03 hassio start-resin-supervisor[24592]:   File "/usr/local/lib/python3.7/runpy.py", line 85, in _run_code
Nov 05 06:57:03 hassio start-resin-supervisor[24592]:     exec(code, run_globals)
Nov 05 06:57:03 hassio start-resin-supervisor[24592]:   File "/usr/local/lib/python3.7/site-packages/hassio/__main__.py", line 40, in <module>
Nov 05 06:57:03 hassio start-resin-supervisor[24592]:     loop.run_until_complete(coresys.core.setup())
Nov 05 06:57:03 hassio start-resin-supervisor[24592]:   File "uvloop/loop.pyx", line 1448, in uvloop.loop.Loop.run_until_complete
Nov 05 06:57:03 hassio start-resin-supervisor[24592]:   File "/usr/local/lib/python3.7/site-packages/hassio/core.py", line 56, in setup
Nov 05 06:57:03 hassio start-resin-supervisor[24592]:     await self.sys_discovery.load()
Nov 05 06:57:03 hassio start-resin-supervisor[24592]:   File "/usr/local/lib/python3.7/site-packages/hassio/discovery.py", line 36, in load
Nov 05 06:57:03 hassio start-resin-supervisor[24592]:     discovery = Message(**message)
Nov 05 06:57:03 hassio start-resin-supervisor[24592]: TypeError: __init__() got an unexpected keyword argument 'uuid'
Nov 05 06:57:03 hassio dockerd[781]: [[0;1;31mTraceback (most recent call last):[[0m
Nov 05 06:57:03 hassio dockerd[781]: [[0;1;31m  File "/usr/local/lib/python3.7/runpy.py", line 193, in _run_module_as_main[[0m
Nov 05 06:57:03 hassio dockerd[781]: [[0;1;31m    "__main__", mod_spec)[[0m
Nov 05 06:57:03 hassio dockerd[781]: [[0;1;31m  File "/usr/local/lib/python3.7/runpy.py", line 85, in _run_code[[0m
Nov 05 06:57:03 hassio dockerd[781]: [[0;1;31m    exec(code, run_globals)[[0m
Nov 05 06:57:03 hassio dockerd[781]: [[0;1;31m  File "/usr/local/lib/python3.7/site-packages/hassio/__main__.py", line 40, in <module>[[0m
Nov 05 06:57:03 hassio dockerd[781]: [[0;1;31m    loop.run_until_complete(coresys.core.setup())[[0m
Nov 05 06:57:03 hassio dockerd[781]: [[0;1;31m  File "uvloop/loop.pyx", line 1448, in uvloop.loop.Loop.run_until_complete[[0m
Nov 05 06:57:03 hassio dockerd[781]: [[0;1;31m  File "/usr/local/lib/python3.7/site-packages/hassio/core.py", line 56, in setup[[0m
Nov 05 06:57:03 hassio dockerd[781]: [[0;1;31m    await self.sys_discovery.load()[[0m
Nov 05 06:57:03 hassio dockerd[781]: [[0;1;31m  File "/usr/local/lib/python3.7/site-packages/hassio/discovery.py", line 36, in load[[0m
Nov 05 06:57:03 hassio dockerd[781]: [[0;1;31m    discovery = Message(**message)[[0m
Nov 05 06:57:03 hassio dockerd[781]: [[0;1;31mTypeError: __init__() got an unexpected keyword argument 'uuid'[[0m

No clue what any of that means. Any ways, I had a full backup of my config so I download the latest HassOS (1.12) got it up and running. Restored my backup and eventually got HA up and running again but back to the 81.4 instead of 81.6.

I trying to do the upgrade again a few more times and kept running into some sort of issue 1) seeming to be the chromecast auto discovery that would cause the home-assistant to hang on booting up issue which I temporally fix by turning off auto discovery or 2) the same hassio-supervisor failing to start after a host reboot.

After some trial and error I eventually got my setup up and running again on 81.6 BUT the only thing I haven’t done that I was doing before was upgrade MQTT to v3.

So obviously I’m currently gun shy to update to v3 right now since I have my HA working once again.

Is it possible that something with the MQTT v3 update would also cause the hassio-supervisor to fail to start with the “got an unexpected keyword argument ‘uuid’” I posted above when you do a host reboot?

73

so… I’m another victim. my hassio is dead.
I changed my mqtt settings, tried to reboot after that and that was the end.

whoever is responsible for this f* up, should be working now on fixing that thing.

1 Like
74

Same problems here. Can we have an official fix response from the devs do you think?

What version of Hassio and Mosquito should we be using, what settings in config.yaml, what setting for the broker itself and what usernames are not supported. I’m not really sure why they would go and stop you using ‘homeassistant’ as the username when this was the in previous documentation. Serious lack of change control.

1 Like
75

My whole setup looking pretty bad now, tried to update the Hass.io and now after forever when plugging in HDMI and restarting I am getting “Timeout poll on interupt endpoint”…

76

Just rebooted mine again to make sure things are still working and noticed the hassio-supervisor updated to 139 (from 138). Looking at the change log it looks like they might have fix the discovery issue which caused the supervisor boot loop.

77

Thanks, I can confirm that I got working again by doing what you recommended.

I have concluded that my initial problem was that I upgraded Mqtt mosquito to v3 and my clients would not connect as they were using the username ‘homeassistant’.

In an attempt to resolve the above, I rebooted hassio and it would not restart. I believe this was because I was still using supervisor 138 as the fixed 139 was not out yet.

78

have you got past the loop yet? thats where i am

79

I had to use a snapshot to a working earlier version of my setup and then re upgrade everything but I believe it is possible to fix the boot loop by deleting a discovery file if you can access the file system.

80

I’m back up… now running hass.io v1.12, supervisor v139, HA v0.81.6 samba v8 and Mosquito v3. Whew!!
Anyway, dunno if this is related but to remove UV package I had to delete it from /config/.storage/core.config-entries. I wasn’t sure about where that configuration began and ended so I just deleted the whole file, rebooted and prayed that it would reconstruct if necessary.
It did indeed reconstruct but reconstructed, without my asking, entries for mqtt even though I never attempted to configure it via the “Integrations” part of Configuration.

{
    "data": {
        "entries": [
            {
                "connection_class": "local_push",
                "data": {},
                "domain": "mqtt",
                "entry_id": "1324b14bf6a247e09192ee45fab64c6c",
                "source": "import",
                "title": "configuration.yaml",
                "version": 1
            }
        ]
    },
    "key": "core.config_entries",
    "version": 1
}

Just wondering if there is some overlapping of code going on here and the devs aren’t communicating well with each other.

81

I wish I hadn’t upgraded MQTT now… stupidly I hadn’t taken a backup!

1 Like
82

Ugggh… No clue what has happened now… I mentioned that I rebooted the host about 20 mins ago and it came back up just fine. I didn’t change anything except for the auto update of the supervisor to 139. MQTT was still v2.

I went away a few mins and now my HA is dead dead again. I can still ping it but I can no longer ssh into it to see what’s going on. WTF?

1 Like
83

I’ll give this a try:

  • Supervisor boot loop is fixed in 139. It was the discovery issue.

  • Mosquitto addon v3 now uses integrations. This means discovery: needs to be enabled.
    I was mistaken. Discovery component does NOT need to be enabled.

  • It also can use the new user auth credentials, so you could for example create an “mqtt” user and password (configuration > users in the UI) and use that on all your clients. OR you can specify a local user/pass in the “logins”: part of the addon config page and fill in existing user/passwords you are already using. You can NOT use the usernames “homeassistant” or “addons” in either place because they are already taken.

  • You remove mqtt: from configuration.yaml completely. (I am running it this way now.)

  • You go to configuration > integrations in the UI and select mqtt from the bottom list, then choose configure. You choose to use auto-discovery or not, and then it should show up in the top list as “Configured”. It is normal to not see any devices within, currently.

At this point you may want to restart HA in order to be rid of the old mqtt: in configuration.yaml. Or maybe a full reboot is better (now that the reboot bug is gone because you have supervisor 139).

Other details are here https://www.home-assistant.io/addons/mosquitto/

8 Likes
84

This screwed my system too. Seems OK now. My fix was -

I took out my SD card, connected it up to my Mac and opened the partition containing the homeassistant directory (using the trial of extFS for Mac by Paragon). Deleted the discovery.json file, took a backup at the same time, edited out the mqtt: section from configuration.yaml reinserted and it booted back up. Cleaning up a few errors, configured the MQTT integration and rebooted, things Seem to be working OK now. Also had to change the MQTT devices username from homeassistant but that’s not too much hard work, only 10 devices at the moment.

Ask away if you need any more help!

85

I’ve lost an entire day to this bug. So glad I found this thread to explain the various woes that befell me. First previously reliable sensors refusing to connect, then Hass itself totally giving up on me requiring a lengthy erase, etch, restore.

1 Like