0.90: Remote UI, Streams, User Groups

[Richard_Albritton]

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.

[mac_intos (mihai stoenescu)]

I have the same message for days now, never was in other state. @SadGamerGeek where did you see those errors ?

[gregg098]

Lets hope it doesn’t follow Microsoft’s versioning.

Home Assistant 1.0
Home Assistant 3.1
Home Assistant 95
Home Assistant XP
Home Assistant 7
Home Assistant 10
(I’m sure I missed some in there)

[grangemd (Matt)]

How could you miss the awesome Windows 8.

[awarecan (Jason Hu)]

@johnflorin

“LTS” releases

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.

[123 (Taras)]

@AhmadK

It’s an old change in HA , people are still waiting for that PR to be rolled back… without a hope :\

@AZDane

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.

I provided two examples in this post.

[tom_l]

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.

[nickrout]

You particularly missed the best ever, Windows ME.

[DavidFW1960 (David)]

@tom_l

Had to restart the MQTT broker a few times before it would use HA user authentication correctly.

This doesn’t even make any sense… Not doubting you and others have reported this as well… but why?

[tom_l]

Yeah I’m not sure why.

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.

[AZDane]

@123

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 .

I provided two examples in this post .

Thanks 123. I will try your solution

[AhmadK (akasma74)]

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)

[Klagio]

and Vista!

[AhmadK (akasma74)]

Thanks for your answer, I waited for something like that for so long…

@123

The warning message legitimately indicates the entity has failed to convert the received payload into a valid state

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?

@123

The solution is to improve the entity’s value_template so it always returns a valid state

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

- platform: mqtt
  name: "safe"
  state_topic: !secret rf_bridge__topic
  device_class: door
  payload_on: !secret door__safe__open__code
  payload_off: !secret door__safe__closed__code

Anyway, I’ll try to digest your examples and we can carry on there if you don’t mind

UPDATE: I think I get your point - here is my thoughts.

FINALLY…

[Klagio]

In few days my log file exceeded 2Gbyte!! and I just have

logger:
  default: error

[DavidFW1960 (David)]

The recorder: will be recording every state change of every device/component

[Klagio]

I was referring to home-assistant.log file (BTW also my home-assistant_v2.db is 2Gb but for that I know its because I have many components)

[johnflorin (Florin)]

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.

[jimz011 (Jim)]

And Windows ME

[123 (Taras)]

@AhmadK

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

Exactly.

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).