I created the files in the “Configurator” enviroment. I wasn´t able to create a file without extension in MAC…
YES !! It worked ciccio88it 
Thanks a lot ! I´ve used many hours trying to get this working again after update !
I’m glad it works! 
Don’t tell me. I have tried every combinations of false, true, accesscontrollist. I have also reinstalled the system several times. 
Out of curiosity, is your broker integrated by Discovery or by configuration.yaml ? And by “reinstalled” - you started from scratch with new SD or new VM drive?
In the configuration.yaml of home assistant, under “discover:” i have insert:
mqtt:
discovery: true
after, on setting → integrations i have configured manualy the mqtt integration, added ip user and password.
I have tried to restore many time from snapshots, but I believe that because of self-updates of add ons, the problem reappears. From last i have used VM drive, and now i stay on VM. it is much faster than the raspberry pi 2! 
This is how the configuration.yaml is:
mqtt:
discovery: true
broker: 192.168.108.202 # Remove if you want to use builtin-in MQTT broker
username: XX
password: XX
birth_message:
topic: ‘hass/status’
payload: ‘online’
will_message:
topic: ‘hass/status’
payload: ‘offline’
I saw this in the guide from zigbee2mqtt at Github. In the old setup only had discovery: true like ciccio88it has it.
Cool. I hope I am wrong but future updates of Mosquitto may enforce ACL in a stricter manner. Which could lead to breaking changes again. So many people just cant get ACL to work, through no fault of their own.
In my configuration.yaml, I simply have…
discovery:
Not beneath a platform, as a platform in itself. I have zero reference to mqtt after reading the install docs for Mosquitto.
I noticed that if I did have “Custom: false” in the MQTT setup, mosquitto still searched for the ACL files that I created.
I only way got that working was by creating the files inside the configurator environment because it´s not possible to create a file without extension in windows/mac…
I also lost a lot of time trying out ACLs.
On the home-assistant.io page it says that since version 4.1 the ACLs are required
https://www.home-assistant.io/addons/mosquitto/
Since version 4.1 of the addon, an explicit ACL definition is now required, see these instructions.
Very frustrating, I know. I now have ACL working and no local users as per my earlier post. If you are in a VM environment, you could try a fresh start as an experiment with no cost. Ie not having to buy a new SD card.
Someone else said this as well and it is NOT correct.
Simply enclose the file name in quotes:
“accesscontrollist”
When you create it.
It does but the default is active: false for some reason.
I was using the default settings and I also use a Home Assistant defined user… no local user in the addon. This worked. In fact, when I tried to configure the acl settings and set active: false it didn’t work. Others have reported disabling active and re-enabling it a few times and it works (which makes no sense). I then saw a tip on the weekend to use this for the accesscontrollist file:
user ***whatever-your-MQTT-User-is****
topic readwrite #
user homeassistant
topic readwrite #
That is to say, add a homeassistant user even though I don’t have this defined - it’s a ‘reserved’ user. When I added that and enabled acl it worked and I stopped getting acl messages in the log.
I don’t totally understand WHY this works and it doesn’t make sense from my (limited) understanding but it works.
A lot of the commentary and solutions around adding and deleting and reinstalling don’t make any sense to me.
I also scoured all my .storage files for a homeassistant user but none is found. I do seem to remember WAY back when HA auth was first introduced that there WAS a homeassistant user but they did away with that and I deleted it months ago and I see no references anywhere to it in my .storage files.
Anyway, for anyone having any troubles, try the above.
another way (which I have done because I didn’t know about this, thanks David) is to ensure that file extensions are not hidden and then just create a text file and remove the file extension when you create the file. Windows will throw up a warning about the file not being reaable or something but you just select yes / I dont care / whatever and you are done.
1 Like
Is there a way to pull down a repository that may have MQTT version 4.0?
I have added every MQTT user (from my devices) into the ACL file/folder and I am still getting the flood of messages.
Some thing to note however… My SONOFF’s don’t ever connect very long to my dd-wrt router. My Garage opener, which is a ESP8266 NodeMCU, it does connect to my router’s LAN. It does not however connect to MQTT. I can see it in the log as well… flooding the logs like everyone else is seeing here. This would make me believe that TASMOTA is the culprit… but my ESP8266 also has the issue of the MQTT logs.
I’ve speculated downgrading my TASMOTA version on my 4 sonoff’s… but this wouldn’t make sense really, because the esp8266 also has MQTT log issues.
I have added about 8 or 9 users to the ACL list within the /share/mosquitto/ folder slash files within. I don’t care to copy/paste the file/folder because if you’ve read this far, you should know what we are all talking about.
If everyone is in consensus they believe it is MQTT 4.1, is there anyone that has a way they can load a version, or a repository we can link to, for the MQTT version 4.0???
DISCLAIMER!!!
My hassio install is on a fresh SD card. Old Pi (3 B+) but I used a brand new SD card for the HASSIO install. No old users here from a residual update/migrate.
I too, am concerned about the log file exploding in size, which is why I have shut off MQTT until a further update or notice has been provided.
System was running fine before, SONOFF devices connected (AND STAYED CONNECTED) to wifi before, now they don’t. I do believe I am running TASMOTA 6.4, but haven’t confirmed, pretty sure I am, but not ready to downgrade TASMOTA version just yet.
My router includes a “-”. I’m not sure if this special character is a problem. All passwords and usernames are not special characters. U&P used to contain “%” but I have since removed it in my troubleshooting.
Hoping to add info in a means for a collective group resolution…
Your issues sounds more complicated than just pointing your finger at Mosquitto broker. I can’t understand why the broker would interfere with devices connecting to wifi. Have you tried disabling mqtt in one of your sonoffs to see if it connects to wifi ok.
Ok… So I have finally got mine to not spew out all those warnings. To be clear I never had a problem with 4.1 in any other way. All my MQTT devices worked 100%
In case it helps to learn from my ever so slight stupidity 
, the lesson is to be careful when following the instructions given here without reading the docs as well.
I followed all the advice given in this post in all its different variations and none worked. Yesterday I followed the link given by @ciccio88it to the docs.
Surprise, surprise there is another step needed that I don’t remember seeing explicitly mentioned in this thread, namely:
When I did this, MQTT behaved itself and no more log flood. As I said, it was my fault but the lesson here is that no matter how helpful people are (and they are) they might, unintentionally not give the whole picture.
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
- Creating a new user in Home Assistant.
- Set
"active": true,and deleted local login in the addon
3 Created acl.conf and accesscontrollist with the solution from @DavidFW1960
user whatever-your-MQTT-User-is*
topic readwrite #
user homeassistant
topic readwrite #
What 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?