How to detect when an Integration is/was reloaded?

I have a Tuya scene button integrated with localtuya. The button uses an enum list of “Single click”, “Double click” and “Long press”. It is a wifi button so it goes “unavailable” 5 seconds after the button is pressed.

Once it’s triggered on “Single click” you can’t trigger it again because it remains the same value. That’s ok (but not great) because it goes to “unavailable” after 5 seconds, and now I can trigger again. But reloading the integration somehow always wakes the button and causes the automation to trigger. I’m not certain the button is actually waking up, but nevertheless, it triggers.

I need to find some condition to test that the trigger came from a physical press of the button, and no any other way such as an integration reload or HA restart.

Are there any solutions?

The entities you are using have been introduced because people got confused buttons did not have entities, and because the original events that buttons emit are harder to use in triggers (i.e. you need to read documentation for it to know what events they use).

Initially I was very happy that they got introduced. That is, until I got the chance to actually use them, and discovered the design is seriously flawed. The flaw being: the state does not reset to idle shortly after triggering. I immediately thought of all the ways that may fail, and posts here on the forum suggest that is indeed the case.

As a consequence of the design, the trigger you need to use is not for a specific change, but for any change on the entity. The assumption made there was that this change could only have been a button action. But that isn’t true, because it could also be another attribute change, or what you describe: the device returning from unavailable or unknown. Which you then have to protect from.

It also breaks consistency: when normally you trigger on something specific happening and then check some conditions and do an action, you now need to trigger on a generic change. That is requiring you to use a choose in the action block, and makes it impossible to do something useful with the condition block. So the automation will be ome complex fast.

While maybe you could protect against this by checking for unavailable, unknown and any other change that may not be a button, this is even less likely for you to work because it always goes unavailable for you. Or maybe it does. But that is the point: the new entities are causeing more confusion than they solved.

So, TLDR: my advice would be to ignore the entity and trigger on the actual events coming from the buttons by using an event trigger, or use a device trigger if there are implemented on your device (even though they are advised against. It is the only reason I still use those). These should not be affected by the problem.

ps. it is not normal for wifi devices to go unavailable after triggering an event. I’m guessing it was an attempt by the integration builder to mitigate the design flaw in the entity. Unfortunately it does not solve it completely. Did you already use this with the state trigger:

    not_from:
      - unknown
      - unavailable
    not_to:
      - unknown
      - unavailable        

Although theyse might have worked when the button does not go unavailable, they probably will hurt in your case, because they might always go from unavailable to single press?

As Edwin_D says use Events instead of Entity.

Open up your developer tools and click the event tab.
Find the event in the right side for your localTuya (if it is not there, then you have to go with all = *)
Insert the blue text in the “Event to subscribe to” field (clicking the blue text inserts it in the wrong field!).
Now in somewhat rapid succession click “Start listening”, click the button, and then wait a little bit and then click “Stop listening”.

You now have a list of captured events and your button is in there somewhere, so go find the text.
There might be several events from the button, like one for the button pressed, one for the press type, like single, double, long and one for button released, and there might be more.
Get them all and then look into a event trigger for your automation and decide what of the found button events you want to react to.

Device triggers vs Entity triggers seem to make no difference in my situation. This is a battery powered Wifi button, so I think by design it goes offline to save power, then HA sets it to to unavailable.

I agree there should be an “Idle” state on this button, it is ridiculous and frustrating. But that got me thinking…

I added an automation and a HACS pyscript to manually set the Entity state to “Double click” whenever this button returns to an “unavailable” state. Since this Wifi version of the button can’t use “Double click” anyway, I can utilize that as a fake “Idle” state. I can now set another trigger when going from “Double click” to “Single click”. This seems to workaround issues like when the Integration is reloaded.

So, problem solved? Not yet…

To complicate things further, the button is 2-gang. So after button 1 is pressed, and then some time later button 2 is pressed, BOTH buttons will now trigger simultaneously. Looking at Developer Tools / States, I can guess it’s triggering from the “raw_state” Attribute, not the “Friendly Name”. The raw_state remains “single_click” even when setting the Entity state to “Double click”. In short, now both buttons trigger regardless of which button I press.

I tried a different HACS pyscript to try to also change the “raw_state” Attribute, but the script doesn’t function for some reason - perhaps the raw_state is not changeable, or is this script too old (over 4 years old) and needs tweaks?

Device and entity here is the same.
The device is just the “main” entity.

You need to use events.

I read your response a bit late, after first heading down the wrong road. Now after checking out Event Triggers, I feel like I’ve lifted up the hood on HA and can see how the system works at a more granular level. It’s all new to me but it is precisely what I was looking for! I got my script up and running in a matter of minutes. Thanks so much for pointing me in the right direction :+1:

Perfect description of how I felt when I started looking at the events. :smiley: