ok. something new
i even haven’t changed anything in the config. are there another breaking changes beside credentials system?
i even haven’t changed anything in the config. are there another breaking changes beside credentials system?
1 Like
I don’t think I can help except to (maybe) reassure you that I also had that at some point so it is probably not anything ‘extra’!
I think I got it when I had removed my whole mqtt: section form configuration.yaml - something to do with using Integrations. Don’t ask! 
I did not understand if this is a way to make money or a security update. anyway they made me lose an afternoon and at the end I solved, at least for the moment.
I installed mosquitto on nas sinology and now everything works regularly.
Thank you so much for making me lose an afternoon:rage:
1 Like
Finally i found the reason of all my fails:
DISABLED discovery: feature in the config!!!
So mqtt would NOT work if you removed/commented discovery
And i don’t even have mqtt: in the config. It works out of the box. But i had to add user/password to the addon configuration
I’m having issues, but I am a bit confused as to where I am going now with the numerous posts on here
I’ve got the DVES_USER issue
1 Like
Try these steps:
Addon config:
{
"logins": [
{
"username": "DVES_USER",
"password": "DVES_PASS"
}
],
"anonymous": false,
"customize": {
"active": false,
"folder": "mosquitto"
},
"certfile": "fullchain.pem",
"keyfile": "privkey.pem"
}
Configure mqtt in the Configuration -> Integrations
Make sure all your mqtt devices have correct creds (DVES_USER/DVES_PASS in case of Tasmota)
Make sure you included discovery: and GOT RID of mqtt: in the main config
Restart the hassio
PS: if you need to reboot the whole machine, make sure your hass supervisor is updated to v139. In other case you will get the docker container boot loop. To fix the loop remove discovery.json in the config folder (via ssh or direct access to the os file system)
PS2: make sure you disabled autoupdate for ALL addons. To save some time in the future 
4 Likes
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”…