I do love the User Groups and how it will hide the config menu because I have a few people that need access to my UI but I do not want all of them to be able to change, or remove the Automatons and Scripts I have made. So thank you for that
I would like to suggest that you add Hass.io menu hidden for the Group “user” as well. Otherwise they can mess with the MQTT service among other things. It would be nice to lock down the UI changes for “user” as well until individual account UIs can be made.
Until then, if anyone has a good way to hide the Hass.io menu option for “user”, or even all accounts, I would love to try it.
That is something better fit for for-profit business. The important one is S, e.g. support, that is not an easy job for contributor to backport their changes to some long term supported branch.
There’s no need to roll back the PR. The warning message legitimately indicates the entity has failed to convert the received payload into a valid state. The solution is to improve the entity’s value_template so it always returns a valid state.
That was a bad update. Got there eventually though.
MariaDB and Mosquitto both had problems after the update.
Had to reinstall MariaDB.
Had to restart the MQTT broker a few times before it would use HA user authentication correctly.
I tried updating HassOS -> v2.11, and the addon it self to the latest version. That didn’t seem to help unless the broker restart after updating those two did the trick.
I hesitated for a week before updating from 0.89.0 to 0.90.1
Had to do nothing at all after that.
However, our configs may be different - I use internal database engine and Mosquitto add-on.
Even managed to disable its allegedly insecure 1883 port (just for fun)
Thanks for your answer, I waited for something like that for so long…
What exactly does that mean? I’m still confused…
Does an entity HAVE to change its state every time something is posted to a topic it subscribed to?
I think it’s something to do with HA/mqtt implementation’s guts as I had no idea it should return anything 8()
And many of my sensors don’t use value_template at all…
To clarify, I presume that many people have issues with that warning because their use case includes ONE topic for ALL their devices so they all listen to that topic but have different payload_on and payload_off values, like this
I agree, I used “LTS” just as a generic example of a version which is considered to be working very well before jumping into one that includes a major new feature, which usually comes with quite a few initial issues.
The payload_on and payload_off options are designed to match the payload from the sensor’s unique topic. However, in the case where a single topic is used by multiple sensors, the payload may be intended for one sensor but not others. As a result, the “others” receive a payload that fails to match their payload_on and payload_off.
The simplest solution is to create a value_template that, when it receives a payload that isn’t intended for it, simply reports it’s current state.
FWIW, my preferred solution is to demultiplex the single topic using an automation (or a Node-red flow). The demultiplexer creates one unique topic per sensor thereby simplifying the configuration of each sensor (i.e. value_template is no longer required for each sensor).