on the clients I tried all the combinations. does not work. from pc with mqtt.fx I can not even login
Hi, I’m only running Mosquitto MQTT v1.4.15 but I managed to get it working after a lot of fiddling with settings. I didn’t know v3 was avaliable but I’ll stick with mt old (working) version for now I think!
I found
logger:
default: warning
logs:
homeassistant.components.mqtt: debug
in the config file really helped! Good luck!
This is a complete balls-up and for the first time I don’t think the “this is open source you get what you pay for and don’t you know the devs don’t get paid for this” argument holds any water.
How was there NO warning anywhere of what was about to happen when upgrading (ha! ha!) to Mosquitto add-on v3?
What would be nice would be some guidance on how to recover form this mess!!
The docs say this, which to me doesn’t make complete sense and even if I interpret what it is trying to tell me, nowhere does it say what password the clients need to use with these users.
HOME ASSISTANT USER MANAGEMENT
This Add-on is attached to Home Assistant user system. That means a user can log in with her credential. Currently, we support also local users they can add via config. For the internal Hass.io ecosystem we register homeassistant and addons , this user name will not work anymore inside configuration.
I’m in the same situation as @madmicio. I can’t get any Sonoffs to authorise and nor can I use mqtt.fx
11 Likes
I would really appreciate if somebody guide us how to downgrade mqtt addon to v2 OR to use password-less access to mqtt broker, since we’re all busy folks and have no time to re-programming hundreds of mqtt devices.
4 Likes
“homeassistant” and “addons” won’t work as users
https://www.home-assistant.io/addons/mosquitto/#home-assistant-user-management
Ok… I think I am back working (but see note at the end!)
For what it is worth here is my setup…
mqtt is configured using the Integrations page
My configuaration.yaml has the following entry:
mqtt:
broker: 192.168.1.25
My Mosquitto add on config is as follows:
{
"logins": [
{
"username": "my-username",
"password": "my-password"
}
],
"anonymous": false,
"customize": {
"active": false,
"folder": "mosquitto"
},
"certfile": "fullchain.pem",
"keyfile": "privkey.pem"
}
My sonoffs use the username and password specified in the add-on config.
I hope that is useful for someone although probably not really for people like @deviant with hundreds of clients to update.
How long this will work for I don’t know as the docs say “Currently__, we support also local users”
Thanks for the tip.
Unfortunately doesn’t work for me.
I’ve changed mqtt config to:
{
"logins": [
{
"username": "DVES_USER",
"password": "DVES_PASS"
}
],
"anonymous": false,
"customize": {
"active": false,
"folder": "mosquitto"
},
"certfile": "fullchain.pem",
"keyfile": "privkey.pem"
}
These creds are default Sonoff Tasmota creds. I dont care about sequrity since it is local network.
I also changed main config to
mqtt:
broker: 192.168.1.116
and configured integration.
The addon log is:
1541430941: Opening ipv4 listen socket on port 1883.
1541430941: Opening ipv6 listen socket on port 1883.
1541430941: Opening websockets listen socket on port 1884.
1541430941: Opening ipv4 listen socket on port 8883.
1541430941: Opening ipv6 listen socket on port 8883.
1541430941: Opening websockets listen socket on port 8884.
1541430941: Warning: Mosquitto should not be run as root/administrator.
1541430944: New connection from 192.168.1.104 on port 1883.
[INFO] found DVES_USER on local database
1541430945: New client connected from 192.168.1.104 as DVES_0F6870 (c1, k15, u'DVES_USER').
1541430945: New connection from 192.168.1.124 on port 1883.
1541430945: New connection from 192.168.1.122 on port 1883.
[INFO] found DVES_USER on local database
1541430946: New client connected from 192.168.1.124 as DVES_029D3D (c1, k15, u'DVES_USER').
[INFO] found DVES_USER on local database
1541430948: New client connected from 192.168.1.122 as DVES_0E3B9B (c1, k15, u'DVES_USER').
1541430948: New connection from 192.168.1.119 on port 1883.
1541430948: New connection from 192.168.1.115 on port 1883.
1541430948: New connection from 192.168.1.121 on port 1883.
[INFO] found DVES_USER on local database
1541430951: New client connected from 192.168.1.119 as DVES_B2E718 (c1, k15, u'DVES_USER').
[INFO] found DVES_USER on local database
1541430953: New client connected from 192.168.1.115 as DVES_AC8937 (c1, k15, u'DVES_USER').
[INFO] found DVES_USER on local database
1541430955: New client connected from 192.168.1.121 as DVES_9126AB (c1, k15, u'DVES_USER').
It looks like some devices are connected successfully. But none of them alive:
Try changing anonymous: to true. My understanding is that by having anonymous true and a login set, it will allow anonymous clients in a read only mode. (the client can send stuff but can’t read other stuff)
1 Like
Well, I’m glad I’m not the only one who has been spending a couple of hours today to find this problem.
I have recreated the issue a couple of times (reflash, install, install Samba, copy back backup, restore backup, etc) before I found the problem being the MQTT update. After each iteration I lose all connectivity except ping (so no Samba, no SSH)
What is the recommended way to test here? Every time I break my HA-instance now I have to redo the whole procedure again, not a very nice way to quickly test some options…
1 Like
yes. today i beat my own record. restarted 1000 times 
3 Likes
no luck with anonymous mode. i see that my mqtt devices connected to the broker, but there is no healthy items in the UI.
16:34:17 MQT: Attempting connection...
16:34:19 MQT: Connected
16:34:19 MQT: tele/siren/LWT = Online (retained)
16:34:19 MQT: cmnd/siren/POWER =
There is an update for Supervisor to fix the mqtt reboot problem. Version 139.
If you can’t get to the UI, delete discovery.json (/mnt/data/supervisor in hassos) and restart.
How can I do that? My SSH_connection is also refused. Removing the SD-card and mounting it somehow in my Mac?
ok. something new
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