I just had this error. Ignore it from the list at the top and manually configure it from the big list lower down.
I’ve just re-done it AGAIN and left the discovery checkbox unticked as all my switches are manually configured already.
No, 139 was a fix for a horrible 138 error which sent supervisor container into a restart loop. If you rebooted while running 138 and mqtt v3 you had to delete discovery.json to get back up and running.
I currently have all my MQTT switches configured in config yaml.
If I decide to comment them out and restart and then enable MQTT discovery in the integration, will I need to reconfigure my switches to work or will discovery pick up the topic (command and state)?
I’m just tossing up if I should use the ‘new’ way as these things have a tendency to be broken without warning in the future and I’d like to keep ahead of the curve…
Ok This time I have it figured out (I know I’ve said it before…)
Update to latest HA version and supervisor.
1a) Delete mqtt: from your configuration.yaml
Create a HA user for use with mqtt
Delete and reinstall mosquito mqtt addon V3. Probably not necessary unless you made a mess like I did.
Start the mqtt addon.
Restart HA
Configure the mqtt integration. No need to add any username or password. If it asks for this retry after refreshing your browser cache (CTRL + F5) and you should get a dialogue box without login or password requirements.
Update all your mqtt devices with the user and password created in step 2.
I was playin around. A bit ago I set up owntracks on our phones and followed the manual by using homeassistant for a login on the phones. known_devices.yaml picked the phones up as homeassistant_richard and homeassistant_sandy for the device id’s. Changing today to a different login to avoid conflicts changed the known_devices name.
1541471412: New connection from 192.168.0.5 on port 1883.
[INFO] found hassio on local database
1541471413: New client connected from 192.168.0.5 as pi3 (c1, k60, u’hassio’).
1541471413: ACL denying access to client with dangerous client id “mosqsub/619-pi3”
1541471413: Client pi3 disconnected.
I have read up on the ACLs but that doesn’t seem to do it?
I have MQTT up and running, but it doesn’t seem to recognise MQTT Sensors.
I have this in my config, but it no longer shows up as a sensor, even though I can see the mqtt messages coming in.
Glad to see I’m not the only one. I updated to .81.6 and the mqtt add-on, and it completely murdered my hassio install.
3 hours and I ended up rolling back to .81.2 with a recent snapshot. All good now, but definitely the worst experience I’ve had doing an upgrade so far. I’m sticking with what I have until this is hashed out and explained better(where was the warning?!?!?!)
Well after messing with this all day and basically losing most of my current settings (always make sure to transfer your snapshots before update, you never know when your SD card will blow up from restarts) I ended up rolling back to an old version of the mosquitto add-on and everything is fine running on 81.6 and 139. So the mosquitto add-on is definitely the biggest issue.
f**k man, why do devlopers constantly brake things. We’re using this service in production here at my home. So i’m using homeassitant as a user for all my mqtt devices (and its hardcoded in my sensors) and now what? Do I have to change every. single. of my sensors because of a not well though idea of a developer?
mqtt is not working anymore. I can’t even connect using mqtt-spy. And now I have to go to work, leaving my hass unstable. Thanks!