State messages not retained is desired

[uphillbattle]

Hi again,

The plugin is working excellently - good job!

However, as I'm using 433 remotes, I soon ran into trouble: I use the state messages to trigger automations, and since the state messages are retained, my whole house is blinking for a while after restart of Home Assistant, since the MQTT client reads the retained messages again and triggers automations.

Even for remotely controlled switches, it is possible to think of a case in which it is not desirable that the state messages are retained, for example:

• You open a garage cover and the plugin publish an "OPEN"/"ON" state message for the cover
• The cover is closed manually
• There is a temporary power failure or an intentional restart of Home Assistant
• Upon restart, Home Assistant reads the retained state message and reopens the garage cover (which may not be desirable at this point)

A discussion can be found here: https://community.home-assistant.io/t/mqtt-how-to-remove-retained-messages/79029

Have you considered setting Retain to False for state messages. Or, if that is not what you desire, have you considered letting the user choose Retain or Not retain in the plugin configuration? I would certainly appreciate such an option.

[quazzie]

Try the 0.82.1 release (https://github.com/quazzie/tellstick-plugin-mqtt-hass/releases/tag/0.82.1) Added a config for state retain. Set "State retain" to 0 to disable retain on state changes. Sensors, availability and such still uses retain. Had to use number in settings as checkbox seems to be broken.

After uploading the plugin you must restart ;)

It should also clear retained state messages when saving and "State retain" is 0.

[quazzie]

And btw i think you should guard you automations with an from: to: state change. That way retain should not interfere. Ex: trigger: state from: off to: on

I haven't checked how HA handles restoring of state but if you don't have retain you could get in a state where HA does not know the state of the switches and such until you change them. That's why i use retain, to always know the last state.

[quazzie]

Just tested it and HA does not restore the state so with retain disabled HA will think your switches is off after restart even if they are on.

[uphillbattle]

Wow, thank you for providing a new release - and so quickly! Great!

With the new release the messages are no longer retained when I set the parameter to 0. The state messages are still (re-)published when/if the Telldus reboots. That may cause similar problems as the retain status did, and I guess it would mean another settings parameter to avoid publishing all states on Telldus startup.

For your information, I'm not using the "state" of the 433 remotes to trigger automations in Home Assistant. The reason is described here https://community.home-assistant.io/t/detecting-second-button-push-on-433-mhz-remotes-using-telldus-znet-lite-v2/98900 and goes like this:

The (Nexa) 433 MHz remotes have two buttons - one "ON" and one "OFF". Telldus sees the remote as a switch (as I mentioned earlier), so when you press the "ON" button, Telldus sets the "switch's" "state" to "ON". Similarly if you press the "OFF" button: The "state" is set to "OFF". If, however, you press "ON" and then "ON" again later, the second button push is not detectable as a change in state, because the state is already "ON". However, your brilliant MQTT plugin publishes an "ON" message even if the state was already "ON". In this way, by watching the MQTT messages, you can detect a second button push.

This is particularly useful if you have two (or more) remotes controlling (for example) the same light (for example the lights in a set of stairs - with a remote at each end of the stairs). If you switch the light on by pushing the "ON" button on the upstairs remote and then switch it off by pushing the "OFF" button on the downstairs remote, the state of the upstairs remote is still "ON", so if a second person wants to go down the stairs, he or she would have a hard time switching the lights on if the automation switching the lights on only watched the "state" of the remote instead of watching button pushes.

[uphillbattle]

BTW, I see your point, that without retain, HA won't (upon restart) know the status of (actual) switches (for example, wall plugs) when retain is False; that is clearly a disadvantage of setting retain to False.

It would all be solved very nicely, I think, if Telldus would stop seeing remotes as switches and instead having a separate device type for remotes. That way switches could be treated as switches - with retain set as a default - and remotes could be treated as remotes, reporting button pushes instead of states. Would perhaps solve everyone's (at least my) problem... :)

[quazzie]

I think i would solve that with the events built in to telldus live, 4 events like so: "remote 1 on" -> "turn on light and turn on remote 2" "remote 1 off" ->"turn off light and turn off remote 2" "remote 2 on" -> "turn on light and turn on remote 1" "remote 2 off" -> "turn off light and turn off remote 1"

And "light" could be the real light or a fake light used to detect the event in HA. If the fake light turns on, remote 1 OR 2 has turned it on..

[uphillbattle]

I agree, and your approach was how I initially tried to solve the challenge. The problem I ran into was that the turning on/off of the other remote would trigger the turn on/off automation for the light.

When using Telldus Live, which is a polling service, I ended up with blinking lights, although I can't quite explain why. I think it has something to do with HA sending a turn on command to the light and perhaps polling its state before it's actually turned on and so on.

With your MQTT plugin, on the other hand, this approach would perhaps work better as it's more of a push service rather than a polling service. I'll try it out.

I've sent an enquiry to Telldus asking if they have ever considered treating remotes as remotes (that is as devices that do not have a state) and switches as switches (devices that do have a state). It'll be interesting to hear what they say.

I have, further, thought I'd test leaving retain=FALSE (as you have kindly provided a release that enables me to do so), but after switching on a light, publishing (from HA) a state message with retain=TRUE for the switch - thereby providing retained messages for actual switches, while leaving remotes without retained messages. That way, states for actual switches would be retained during a HA restart.

Interesting discussion, though, thank you for taking the time. :)

[fredrike]

The old Telldus Live integration in Home Assistant didn't expose state. Or rather, it was shown as a ⚡️to turn either on or off. As 433 devices doesn't report state it makes sense to have something like this but it seems to be removed in later versions of HA. Perhaps @molobrakos remember how this was implemented. Or can shine some light on how it is implemented in https://github.com/molobrakos/tellsticknet.

I think that @uphillbattle needs a smart way to write the automations to handle 433 switches as remotes in HA (there is actually nothing like a 433 remote in Telldus Live today, I is just switches with the notation from HA).

[quazzie]

Hmm i think i have found out a way to check if it is a remote. So i made 0.82.2 if you want to test this.

Instead of remotes creating a switch in HA it creates a binary_sensor with expires_after: 1. That means the state will be ON or OFF for 1 second when you press the remote, after 1 second it will change to unknown/unavailable.

Think that will help ?

[uphillbattle]

Sounds like a good idea! I will test it and report back.

[uphillbattle]

Haven't had time to test thoroughly yet, but I've uploaded 0.82.2 and can see that the binary_sensor reacts and goes unavailable after a second. Looks good! Will test more over the next days with and without retain to see the effects.

[uphillbattle]

Tested more today and this is now looking very good!

I have set retain back to 1 in the configuration. In this way switch states are retained so that devices' states are known after restart of Home Assistant. Thumbs up!

Even with retain set to 1, the binary_sensor messages are NOT retained. That is excellent! In this way, restart of Home Assistant does not "retrigger" the automations.

The one thing that could still be improved, if I may make another request, is that when rebooting the Telldus, the last state of the binary_sensors should not be (re-)published. Upon reboot of the Telldus, config messages for all devices are published along with state messages for the devices. Publishing the state messages for switches makes sense because it allows Home Assistant to set device states correctly. For the binary_sensor, however, republishing of "states" will "retrigger" automations and is therefore not desirable (and does not make sense, since remotes only have a state when a button is pressed).

If it's possible to improve on that last issue, I think the plugin is actually a much better way of integrating the Telldus in Home Assistant than using the Telldus Live integration (which is based on cloud polling and therefore has slower response - and, of course, does not distinguish between switches and remotes).

[quazzie]

Yeah i missed that state push on startup. Fixed it in 0.82.3, please try that one :)

[uphillbattle]

Thank you! 👍

No state push on startup for the binary_sensors now. Excellent. I'll be deleting the Telldus Live integration and relying on your plugin now. Good job!

I'm no longer using the option of setting retain to 0 in the config, so if you wish to tidy up and remove it from the config, feel free to do so. But don't rush that, it does no harm. :)

Thanks again for your help!

[quazzie]

Great 👍