My quoted post points directly to that section on ACL configuration.
But agree, there is much good will here, but sometimes mis-directed. Always read the docs. Read them again and try to make that work first. Then turn to the community. Very glad you are up and running!
I just went over to ACL and I am glad to say I got all things up and running again!
Everything was 100% working with v4.1 before converting to ACL.
I did not have a .yaml entry in my configuration file for mqtt, I only have discovery: there. (same as @Milster)
I was already using the mosquitto broker addon and had mqtt configured thrue the integrations page.
What worked for me was
"active": true, and deleted local login in the addonWhat confused me was deleting the ports on the addon page (set them as blank) conform the docs:
This is not working for me, but when I reset the ports back to default it all works.
Is there someone who has the ports deleted (blank) and still have it working?
I still use 1883, so not experienced in this area. I found below on Google, so would suggest that you not blank-out all of your port entries just the insecure 1883/1884 ones. Retain 8883/8884 and make sure your Broker integration knows to use them.
“TCP/IP port 1883 is reserved with IANA for use with MQTT. TCP/IP port 8883 is also registered, for using MQTT over SSL.”
NB. You’ll also need to make sure all your devices know to now use 8883, if they are Sonoffs they are probably defaulting to 1883.
Mind you that heading in the docs on ports is not strictly speaking a default part of the setup that you need to “conform” to. It’s a config option.
ACL on the other hand; post v4.1, is something worth conforming to.
Ps. Guessing here… To make things even more complicated your broker integration’s IP might now have to be a https:// address. Thus sending your mqtt traffic out into the internet to be SSL verified then back into your local network. I’d stick with 1883 if I were you.
Strange that Mosquitto MQTT 4.1 works for some but not others.
I found the local user in .storage/auth_provider.homeassistant so I deleted it.
I removed the local username from the MQTT login section and restarted HA.
After that I was able to add the MQTT username as a HA user and restarted HA.
I was able to get Mosquitto working as per the documentation except I had to
allow the homeassistant and MQTT users access to the MQTT topics explicitly.
Strangely, the MQTT username is back in .storage/auth_provider.homeassistant and MQTT still working with ACL.
I think the homeassistant user is system generated. Maybe it is one of the Hass.io users I see.
You must really like hacking to keep up with the HA changes. It is a retirement hobby for me.
It’s a reserved system user name. I don’t see it in my auth files though. Using it in the acl fixed it for me anyway.
It’s bizzare! The following are my observations. Not to be taken as strict instructions - do what you think best.
I tried to be scientific in my approach and compare what didn’t work in a system upgrade to v4.1; to what did work in a fresh start with v4.1 as the starting point.
With a fresh start:
Maybe, once upon a time Mosquitto wrote something to the system when it had higher privileges. v4.1 is not meant to be run as a superuser, so maybe something remains that Mosquitto can’t clean up or undo. Just guessing. It seems odd that some are now explicitly including homeassistant in their ACL, when the docs specifically say not to use homeassistant or addons as a user.
@Milster …
Your issues sounds more complicated than just pointing your finger at Mosquitto broker.
… which is why I included information regarding TASMOTA. I’m sure you must have overread that.
I was merely providing information and events I have observed. Please reread ^^^. I have an ESP8266 connecting to wifi fine. It does not however connect to MQTT broker. I too, like almost everyone on this forum, have encountered the same log entries noticed for the MQTT addon. I’m interested in the log entries. I can troubleshoot the SONOFF’s later; regardless, the MQTT broker is logging multiples of entries of devices failing to connect (as is everyone else’s).
Because someone asked:
HASSIO was installed on a brand new SD card. I copied the text from all my .yaml files as well as the properties for all my addons. I copied the www folder off of the old SD card from my previous install. The reason for the fresh install was due to issues after updating, I then rolled things back to a snapshot pre update and then just decided I would reinstall on a 64G card instead of the 16G I had previously
I’m not sure how I can help then. If you have a snapshot pre-v4.1, you can install a prior version of the addon without doing a total system restore. Just unclick all the checkboxes other than Mosquitto.
Not sure if it will help you but the Tasmotta version isn’t always the culprit with connection problems but the core that the firmware is built on. You have a choice between Core version 2.3.0, 2.4.2 or 2.5.0. Each has it’s own set of quirks.
Firmware can be found here.
It seems odd that some are now explicitly including
homeassistantin their ACL, when the docs specifically say not to usehomeassistantoraddonsas a user.
The documentation tells you not to create a user with these names. No harm referring to homeassistant in the accesscontrollist file.
For me it was a problem with the .storage/auth_provider.homeassistant file from previous versions which was not compatible with the next. It is a “hidden” file and it will be recovered when you restore a snapshot. Before the use of .storage files the HA function was determined solely by a set of yaml files. Not any more. This is an artifact candidate.
I get it now. thanks
@Milster …
If you have a snapshot pre-v4.1, you can install a prior version of the addon without doing a total system restore
…they’re on different SD cards. How do you propose rolling back an addon install from diff cards? You must have overread that. Please reread ^^^.
I’m okay if you don’t have a solution, again, I was merely providing my observations.
@Everyone :
Currently I’m looking into troubleshooting the 127.0.0.1:8080 authentication. The MQTT logs show the local, home, IP trying to authenticate, I wonder if some router/port configurations need to be looked into
You realise 127.0.0.1 isn’t the PC you are viewing Home Assistant on right? It’s the Home Assistant Pi…
David, yes, I do, realize that… I have no belief that my pc is doing any of the MQTT authorizations… your logs, my logs, and the logs from others, show the login from that IP, (home)… i recognize it’s not my own PC and realize that my own PC doesn’t have that IP.
ipconfig /all
ifconfig -a …
yes, I know my pc’s IP address.
1553834614: |-- mosquitto_auth_unpwd_check(mmm)
1553834614: |-- ** checking backend http
1553834614: |-- url=http://127.0.0.1:8080/login
1553834614: |-- data=username=mmm&password=mmm&topic=&acc=-1&clientid= [INFO] found mmm on local database
1553834618: |-- getuser(mmm) AUTHENTICATED=1 by http
1553834618: Socket error on client <unknown>, disconnecting.
1553834618: New connection from 192.168.1.138 on port 1883.
1553834618: |-- mosquitto_auth_unpwd_check(mmm)
1553834618: |-- ** checking backend http
1553834618: |-- url=http://127.0.0.1:8080/login
1553834618: |–data=username=mmm&password=mmm&topic=&acc=-1&clientid= [INFO] found mmm on local database 1
`
Just reviewing your posts… You say that it doesn’t even connect to wifi for very long? And Tasmota 6.4? Well that will be the issue… If it’s not stable on WiFi, it will never connect reliably with broker. Upgrade Tasmota to 6.5.x and that should fix the WiFi issue and then maybe we can look further at MQTT.
What does the acl.conf and access control list file look like? What is your broker configuration?
You think? I mean, I’ve got an ESP8266 that’s having issues also trying to log into the broker… I hadn’t even thought about the SONOFF’s messing with the broker… I’m up for it, I just see that “gg” (that’s my ESP8266 garage door opener) has trouble connecting.
I used to have all my SONOFF’s with u/p as “%%”, but I wasn’t sure about the special characters… so i changed them to mmm.
I’ll give it a shot, upgrading one of them to 6.5, but it seemed that all MQTT devices couldn’t connect to MQTT, only the SONOFF’s had issues with wifi … “ping x.x.x.x -t”
Thoughts, David?
Use Samba to copy your snapshot files to a computer. Swap cards. Copy those files onto the other card. Go to Hassio>Snapshots. Hit the refresh button and they will be available on your preferred installation.
{
“logins”: [
{
“username”: “%%%”,
“password”: “%%%”
},
{
“username”: “%%”,
“password”: “%%”
},
{
“username”: “mmm”,
“password”: “mmm”
},
{
“username”: “gg”,
“password”: “gg”
}
],
“anonymous”: false,
“customize”: {
“active”: true,
“folder”: “mosquitto”
},
“certfile”: “fullchain.pem”,
“keyfile”: “privkey.pem”
}
and then my control list…
I’ve changed this up quite a bit trying to cover all bases:
topic #
topic readwrite #
user mqtt_username
topic readwrite #
user homeassistant
topic readwrite #
user %%
topic readwrite #
user gg
topic readwrite #
user %%%
topic readwrite #
user redacted
topic readwrite #
user Scott
topic readwrite #
user redacted
topic readwrite #
user Sonoff
topic readwrite #
@Milster
that goes against how “snapshots” actually work, but I’ll give it a try.
I’m assuming HA doesn’t actually make “snapshots”, rather “backups”. Snapshots are typically just pointers to old storage LBA’s. I work in storage… copying snapshots logically, makes no sense, but, I will attempt what you are suggesting.
Really strange… it looks good to me. 6.4 of Tasmota will drop out all the time but 6.5 is stable… (different core used in 6.5.0) I don’t understand why you’re having an issue. I don’t have any local users like you do… my only MQTT user is a regular home assistant user…
What happens if you set active: false?