this work for me… now sonoff login into mqtt broker
1 Like
Broken Mosquitto, 100% SD Card Usage…what a lovely monday!
Now struggling to make the integration accept the broker…
1 Like
my SD card is going mental too, dont want to shut it down by pulling lead out. Ive been waiting for page to load for 30 minutes now
What if i don’t have v. 139. I don’t have such version. The latest is 138!
MQTT is not working. And now i got this message 
It is a total mess… HASSIO made M(a)yday
They (home assistant or supervisor) don’t appear to be loaded/running yet. Refresh the page repeatedly or clear browser cache?
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.
I had the same exact issue and ended up replacing Mosquitto with the following addon: MQTT Server & Web client
Works great
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?
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.
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
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?
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
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
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”…
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.
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.
have you got past the loop yet? thats where i am
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.
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.
I wish I hadn’t upgraded MQTT now… stupidly I hadn’t taken a backup!
1 Like