Tasmota: Alexa integration (Belkin + Hue) have no option to retain because they don't populate the cmnd topic

[thehookup]

One more, I'm making a video about retain topics and tasmota and how to properly use them. The one issue that I can't seem to overcome is if using built in alexa functionality the messages never populate into the cmnd topic.

For instance: If I turn the light on with a button it published retained "ON" to cmnd, if I turn it off with alexa there is still a retained "ON" in cmnd, so if the device reboots or reconnects it will receive "ON" even though the previous state was "OFF".

[Frogmore42]

The simple answer is, "Do not use retain. If you have a Home Automation system that depends on retain, either don't use Tasmota, or figure out how to make your HA not require retain, or use a Home Automation system that does not depend on retain (there are a few)."

The more complex answer is retain is a really bad idea for solving the problem of I don't know the state of things, when used on topics that control things, ie the cmnd ones in Tasmota. This might be required for control elements that don't have their own memory (Tasmota is not this case). It might also be the "easy" way for the developer of HA software, since he doesn't have to worry about persistence. He says let's just let MQTT worry about that. It might have seemed like a good idea at the time. But, having seen how many people have had issues with it, it has caused way more harm than good.

[thehookup]

All I'm saying with this feature request is that retain options are available for all other input methods (button + switch), but not for alexa commands. If you were attempting to use a retain based system you could get really close to setting it up correctly, but alexa integration would be the exception.

[ascillato]

Hi

@thehookup

Have you tried the command PowerRetain 1 ?

[thehookup]

@ascillato that's actually what my video is about, correct use of PowerRetain, SwitchRetain, SensorRetain, and ButtonRetain.

PowerRetain only retains messages sent in stat, so it doesn't change the problem with command sync where you could have a retained message of "on" in cmnd, turn the lights off with alexa, then if tasmota reboots or reconnects to mqtt it will turn "on" with the retained message even if powerOnState is set to 3.

[ascillato]

Ok, I understand.

I don't have an Alexa to test it, so I was just looking into the code and when receiving a command from HUE or WEMO's emulations, it executes mqtt stat publish routine that uses the power retain flag.

So, with Alexa, Tasmota also should send a stat with retain flag if setting power retain.

To find what is the issue, please, can you share your console logs using weblog 4?

[thehookup]

There's no issue with powerRetain, it's just that powerRetain only publishes to stat, which doesn't have any affect on changing relay state.

What I was wondering is if it would be possible to treat alexa as a switch and publish a message to cmnd when used.

[ascillato]

Ok, I understand.

When Tasmota receives a command from MQTT, Alexa, a button, etc, it publish the change of status by a stat/sonofftopic/power. And with powerRetain, the message will be with Retain flag.

But your MQTT broker will kept the cmnd/sonofftopic/power that was sent before. Right?

So, this problem will be also if you click the sonoff physical button or the webpage right?

[thehookup]

@ascillato Clicking the sonoff physical button publishes to cmnd when buttonRetain is on, the webpage button does not publish to cmnd.

[ascillato]

Ok,

So, a workaround to make a publish to cmnd with retain flag in all cases (including the webpage button and Alexa) could be with the use of rules:

rule1 1
rule1 on power1#state do publish2 cmnd/sonofftopic/power1 %value% endon

Do you have another idea to solve this?

[Frogmore42]

I know you can use retained messages for this, but that kind of like using a sledgehammer for putting in finish nails. You can do it, but you are likely to get hurt in the process and the results are likely to be messy.

Using retained messages to get quicker updates from sensors that update infrequently for clients that start and stop frequently is the use case for which retained messages make sense. Using them on command topics is a generally bad idea. Encouraging people to use them is even worse. So you should really tell people: first don't use retained messages and second if you feel you really need to use them, you probably don't, and only if you really really really feel there is no other way, this is how you can do it, but it will probably still have issues.

[thehookup]

@Frogmore42 Retain doesn't have to cause issues, it's not magic, it just needs to be set up correctly. I agree that most people don't need switchRetain or buttonRetain, but there are plenty of use cases where they do. The purpose of the video is to demystify the different tasmota topics and retain options.

[Frogmore42]

@thehookup please enlighten me to the plenty of use cases where retain of button and switch topics are useful. The only one of which I am aware is Home Assistant. And even there it is not really needed.

[Frogmore42]

My point is that retain is a tool that will likely cause more grief than it will help solve the short comings of a poorly designed system. It is much better to desgin a system that does not depend on it, or use a different one that already has a design that does not depend on retain.

[arendst]

When I use the current released version and enable powerretain I receive these messages when I select the web gui toggle button:

powerretain on
12:53:29 CMD: powerretain on
12:53:29 SRC: Serial
12:53:29 RSL: Group 0, Index 1, Command POWERRETAIN, Data on
12:53:29 MQT: stat/ring2/POWERRETAIN = {"PowerRetain":"ON"}
12:53:30 CFG: Saved to flash at F8, Count 2368, Bytes 3584
12:53:47 SRC: WebGui from 192.168.2.1
12:53:47 MQT: stat/ring2/POWER = {"POWER":"ON"}
12:53:47 MQT: stat/ring2/POWER = ON (retained)
12:53:48 CFG: Saved to flash at F7, Count 2369, Bytes 3584
12:53:57 SRC: WebGui from 192.168.2.1
12:53:57 MQT: stat/ring2/POWER = {"POWER":"OFF"}
12:53:57 MQT: stat/ring2/POWER = OFF (retained)
12:53:58 CFG: Saved to flash at F6, Count 2370, Bytes 3584

Notice the appended message (retained). As WeMo and Hue emulation do the same call to ExecuteCommandPower I guess they use the retained message too.

Same kind of message when I press the physical button:

13:04:19 APP: Button1 multi-press 1
13:04:20 SRC: Button
13:04:20 MQT: stat/ring2/POWER = {"POWER":"ON"}
13:04:20 MQT: stat/ring2/POWER = ON (retained)
13:04:20 CFG: Saved to flash at FA, Count 2380, Bytes 3584
13:04:24 APP: Button1 multi-press 1
13:04:25 SRC: Button
13:04:25 MQT: stat/ring2/POWER = {"POWER":"OFF"}
13:04:25 MQT: stat/ring2/POWER = OFF (retained)
13:04:26 CFG: Saved to flash at F9, Count 2381, Bytes 3584

[thehookup]

@arendst Yeah, I was referring to a retained message on cmnd similar to what you get with buttonRetain or switchRetain.

If you had buttonRetain on, pressed the button and got an "on" retained message on cmnd, then turned off via alexa, the next reboot would result in the retained "on" message being sent to tasmota turning it on instead of the intended state of off.

I was looking for a functionality similar to buttonRetain or switchRetain that populates the cmnd topic when using alexa and the webUI toggle.

[thehookup]

@Frogmore42 retain is great for being able to send commands to devices that are offline most of the time. It's also great for storing state information in devices that have no non-volatile memory to store states.

[arendst]

@thehookup I understand. That option, being cmnd instead of stat, has never been available for power. Only for button and switch (on request from the HAss community) and in that case it's retain on cmnd.

I have to agree with @Frogmore42 that since retain was made available all issues reported are from the HAss community; when no retain was available they lost their states, once retain was available they had no idea what the consequences were and kept making issues about devices that turned without them sending any commands. So concluding, without HAss we never had that many non-issues.

There are so many Home Automation tools available with a decent persistent database why do people still use HAss perhaps other than it must be very simple to get some initial thing going...

[ascillato]

@thehookup

Hi, I just want to understand the control technique for retained messages.

For example:

• In a Master/Slave environment, you will have a central control unit that will store and handle all the internal states of all the devices. So, the rest of devices just follows what the Central say. No internal decision is taken in the rest of the devices.
• In a distributed control environment, there is no central unit for performing all tasks. Instead there is a telesupervisor unit that will gather information and can send some commands for higher layer of decisions. The most common decision are being performed inside the devices.

So, in the first case, you need to set tasmota to not remember its power state.

In the second you set tasmota to remember its state and take some decisions using rules etc.

So, what should be the use case of retained commands?

Because seems to be something in the middle. Both, central unit and controller have the status of the internal state and these issues shows up when those states are different.

I understand that what you are requesting is because a mqtt server by itself can not link the retained status with the retained cmnd and will scramble states.

I'm using HomeAssistant and I have never had those issues because I don't use retained messages. If a device goes offline, it is shown as offline as I wanted to be instead of showing last state. And if I need some historial, the actual HA database works fine. I use the mqtt broker just as a link between devices. The data is stored in a database and the internal status of devices stored in the devices.

[thehookup]

@arendst hopefully this video will help with that. HAss actually does have a persistent database, but like retain, it also needs to be set up correctly.

[arendst]

@thehookup You'll make my day if you can get HAss users from retain to database ;-)

[Frogmore42]

@thehookup I agree with @arendst
People using retain don't understand how to use it and the HAss documentation seems to suggest that retain is necessary. Teach people how to use HAss without retain and you will doing everyone a huge service.

My point about retain being a bad choice is because I believe the solution in this case is worse than the original problem.

As far as the use case for retain. I already agreed that using it for very sleepy sensors where you also needed to have clients that are also sleepy was fine. Tasmota devices do not fit in this use case, since they are normally mains powered and always connected. A home automation generally doesn't fit this use case, since it too should normally be always on and always connected. So, teaching people to use a solution that is really sub-par to solve a problem that can be better solved by using persistence in HAss is probably not the best idea.

[Frogmore42]

While I have avoided using HAss so far, I almost started to try it when I had a bad experience with Domoticz (does a bad job with non-metric units, while I have used degrees C before and can relate to it, my sensors are set up for F, which confused Domoticz and it converted them again) and OpenHAB (much of the documentation is out of date and it has so much abstraction and many UIs that it is extremely frustrating). But, I came to my senses 😉, and finally figured out OpenHAB. It supports using two topics for a switch. One to control it and another to maintain state. Using retain on the topic (the one with cmnd in it) used for control is, in my opinion, a generally bad idea. Using retain on the topic (the one with stat in it) used to report the results of the control is probably safe enough.

[thehookup]

@Frogmore42 I think you've been feed some bad information about HAss, you've had the ability to use different topics for state, command, and availability for over 2 years now.

[Frogmore42]

I don't doubt it, but so have many others who actually use it. I have seen many people come and file an issue on Tasmota because their lights turn on randomly, and when there is a power change or they reboot their server. Almost always it's because they have retain turned on the cmnd topic. Now maybe they don't know what they are doing. Very likely that is true, they just copied something that they found on the Internet. The wiki here now says retained messages will cause issues, but people still miss it. Details in a video are even more likely to be missed. I have no personal experience with HAss. Based on the experience of HAss users who come here for help, I am not inclined to try it. I have been using NodeRED for a long time and like it. I just started using OpenHAB and it is anything but intuitive. But, at least, it appears to be quite capable and has the possibility of okay UI if I put the effort in it.

But, I will stop, since this seems somewhat off topic.

[wongnam]

In my home system that i don’t use mqtt retain solution due to many unexpected issue happen. Instead of that my system read the current relay state to update the system. In this case your system will return to function correctly even power cycle.
Update: sonoff tasmota auto save relay state to flash every time relay changes(on/off) its state.

[ascillato]

https://youtube.com/watch?v=31IyfM1gygo

[ascillato2]

@thehookup nice video. It is super useful. Thanks.

[wongnam]

Yeah, video as same as my idea descript above. Thanks for nice video.

[Frogmore42]

@thehookup very nice review of the issue. Thanks for making something that I am sure will help many people. There should be a link to it from the wiki topic here on HA.

[meingraham]

Even though it references HA, much of the tutorial is applicable to retain issues in general. I use openHAB so the specifics on configuration are different, but the concepts are similar if not the same. I would recommend placing this in the wiki in the general area of the retain parameters.