MQTT 5.11 issue

Yeah… really great idea. Shouldn’t devs make it alive?

This is why v5.1.1 should be rolled back. To make sure no other (new) people will be affected by the issue. It will give devs as much time as they need to fix that. And github issue wouldn’t need to be refreshed just to avoid automatic shutdown.

No, it will not be rolled back.

Maxym you shouldn’t even bother replying at this point. You’ve made it clear that you dislike the people who make the changes and nothing you’ve offered at this point has been relevant other than slinging insults that fit within the COC. You put yourself into this corner and your opinion has little weight at this point.

Never said that. I rather dislike part of community which accepts half-baked features and supports lack of any care about final quality or user experience.

This is insulting.

Now, I don’t care. It did make sense immediately after issue recognition. Now it’s only about how many people more will experience the issue.

The truth hurts sometimes. Just go through your own post history and find 1 positive thing you’ve said. Also, don’t forget that the tagging rule came about because you, yes you, abused that ability to purposely annoy a non-core dev (Your words). And when told to stop, you ingored this and it got you suspended for quite some time.

There is no one to blame but yourself.

1 Like

Yes… and this is why it fits into the COC. But obviously not anyone must be compliant with that.

As for the issue at hand with MQTT. Here’s a list of changes between 5.1.0 and 5.1.1, nothing here even indicates that downgrading will solve the issue. See for yourself:

Fixes devicemapping for SU 2021.02.5

Fixes log configuration

Sort and style lint

Fixes the password type

So, just looking through these, it’s apparent that even downgrading shouldn’t solve the issue and the issue is most likely something else entirely.

It shouldn’t but it does. AFAIK this behavior is reproducible for people who encounter that. I suppose this makes that part harder than expected.

Jeez i’m also suffering from the 5.1.1 like many others but how can you act like this towards a free and open project.

How do I downgrade to 5.1?

AFAIK, if you have an older snapshot from before the 5.1.1 upgrade, you should be able to load that and it’ll revert the addon.

The other course of action is to install mosquito (non-addon) on literally anything else; You could run it on another rpi, or even a small VM on another machine entirely. The memory and CPU requirements for mosquito are minuscule. Then, in HA, point your MQTT integration to use that instead of the local addon.

2 Likes

Thanks! But ugh, I’ll probably wait for a fix since my HA pi is the only device that’s on 24/7.

1 Like

Hey Petro,
Thanks for all this, I’ll read that with interest.

However, instead of focussing on the ‘why not’ and dismissing people trying to help find a solution, it would be most helpful if someone could focus on the ‘what if after all’.

Denial like this

won’t do any good, simply because the downgrade does solve the issue, thought isn’t really identified to the last word of code.

It’s not that we ‘demand’ immediate solution to this (through it would be very welcome of course). But a more customer friendly approach to the people who invest just as much time in this product, would be the wiser one.

Slamming people with this rather unwelcoming ‘tagging rule’ makes this community more and more awkward. How are we to get in touch with each other other than tagging every now and then. Or more frequently than that.

There seems to be a growing brick wall between the dev team and the many involved end-users.

That is not in the project’s best interest. Especially since this project is now employing a (growing) pro team. One would expect it to be in their own interest to face the customer/clientele with am little bit more courtesy. A milder tone of voice.
Even if you think that customer is nagging you with unjust complaints. Count to 10, check the other customers with comparable issues, and heck, maybe one could think there is some validity there after all?

I have experienced this personally too these last few days, and I was and am really flabbergasted. And see it happen now. Please let me ask the Team to think this over once, and start acting like a mature business.
‘Don’t bully the customer’ seems to be rule nr1 for a long term business model… Even more so than having a great product.

Back to 5.1/5.11 now.

1 Like

You seem to not understand what I’m saying. It’s being looked at but nothing stands out. You have to be patient. That’s it. Complaining about there not being a fix solves nothing. I’m not dismissing the issue and neither are the devs, so stop acting like it is.

I have installed this repo GitHub - drbugfinder/addons: Docker add-ons for Home Assistant in the supervisor addons and installed mosquitto 5.1 in place of official 5.1.1

Had to re-add/initiate some devices. Now working fine! (so far)

Will stay on this until issue is identified.

My CPU usage was 22% at times on 5.1.1 now sitting at 0.9

I think I fixed mine. 5.1.1

My configuration WAS this (was working for the longest time until today)

logins: []
anonymous: true
customize:
  active: false
  folder: mosquitto
certfile: fullchain.pem
keyfile: privkey.pem
require_certificate: false

and I changed it to

logins:
  - username: mqtt
    password: (The password for Home Assistant user mqtt)
anonymous: true
customize:
  active: false
  folder: mosquitto
certfile: fullchain.pem
keyfile: privkey.pem
require_certificate: false

After restarting the add-on all my clients instantly reconnected. Phew.

this is my config. I have anonymous set to false (in contrary to you)
See no overlap with diff between yours working and not-working ones.

logins: []
anonymous: false
customize:
  active: false
  folder: mosquitto
certfile: fullchain.pem
keyfile: privkey.pem
require_certificate: false

TBH I have no idea how authentication settings could affect described mqtt behavior (occasionally no ACKs, disconnects, long connection time). The only common point is that authentication might be done against HA user (which is my case). But why it would cause disconnections?

If you have anonymous false and no logins defined how could any client connect? Just trying to understand.

AFAIK using HA user (this is how it works in my installation)

FROM manual:

A list of local users that will be created with username and password. You don’t need to do this because you can use Home Assistant users too, without any configuration.

1 Like

Authentication is handled by Home Assistant (via Ingress). The User accounts you create in Home Assistant aren’t just to access Home Assistant but also Add-Ons that require authentication. It’s one of the management benefits of using either Home Assistant OS or Home Assistant Supervised (due to the inclusion of Supervisor).

My MQTT Broker’s configuration is identical to maxym’s. I haven’t bothered to upgrade to 5.11 because of the reported issue (and I don’t have time to sort out why the performance problem occurs, if it occurs for me).

NO. NO.
It’s not me not understanding what anyone is saying. Please stop blaming me or others.

My main point was not about the 5.11 specifically (I’m fine using 5.1. ), this was about the general atmosphere on the HA community and other fora of communication.