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.
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.
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:
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.
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.
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.
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?
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.
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.