Button Press and Programming

[lraesly (Lee Raesly)]

I’m just diving in to HA and need some advice on what I’m doing wrong. I have HA linked to Lutron RA3 system and am using HA to handle conditional programming. Or at least I plan to…

I have a simple programming example which I can’t get to work. I want to press a button on a keypad I my basement, turn on the light to the stairs, and after a certain period of time, turn off the light for the stairs.

Here is the YAML:

- id: '1708999304199'
alias: Basement Stairs Countdown Timer
description: ''
trigger:
- platform: state
entity_id:
- button.keypad_button_4
condition: []
action:
- type: turn_on
device_id: 3196dd355619c5aaa411becda30b00b0
entity_id: 83bfb1212829a94598a1d814d00dac06
domain: light
- delay:
hours: 0
minutes: 0
seconds: 15
milliseconds: 0
- type: turn_off
device_id: 3196dd355619c5aaa411becda30b00b0
entity_id: 83bfb1212829a94598a1d814d00dac06
domain: light
mode: single

When I press the button nothing happens. If I check the automations option it shows that this was never triggered.

Any help is very much appreciated!

[123 (Taras)]

@lraesly

Here is the YAML:

Is that its exact appearance in the automations.yaml file? If so then its indentation is wrong, thereby making it invalid YAML.

If it’s just a copy-paste error, please correct it so it appears exactly the way it does in your system.

[atlflyer]

Button entities are stateless, per the documentation, and therefore could never cause a State trigger to fire. Typically when an integration, like Lutron, exposes a button entity, it’s for you/HA to interact with the device, not for the device to notify you/HA something has changed. How exactly you need to set up this trigger depends on the integration, but with my Lutron Pico remotes, I have to create Device triggers. Here’s an example of how that looks in the UI:

And in yaml:

  trigger:
  - platform: device
    device_id: bbb7eb0879edc62214954e741fa3f22e
    domain: lutron_caseta
    type: press
    subtype: 'on'

[petro]

@atlflyer

Button entities are stateless, per the documentation, and therefore could never cause a State trigger to fire.

That’s not true, the state is the last time the button was pressed. State triggers will fire when that state updates. This is there intended use case.

Your trigger’s domain is lutron_caseta, not button. So what you’re posting will not work for OP.

[CO_4X4 (Colorado Four Wheeler)]

@petro

That’s not true, the state is the last time the button was pressed

This. So in the above your trigger should be if the button state changed and then toggle the light on or off, then a second automation (you could do it here but it gets trickier to do) that detected the light went on and then times it out after 15 minutes (or a tigger that states if light goes from off to on for 15 minutes).

One thing to point out, as I’m sure it will be, is there is a pitfall for auto timeouts via automation, if you restart HA then your timer won’t turn off the light. You can overcome this by using Timers instead of just a timeout trigger. Personally, that rarely matters to me in my automation because I’m restarting HA when there’s stuff going on in the house anyway and if a light stays on for 30 minutes instead of 15 then it will get reset naturally anyway (as most of my stuff is motion activated).

While timers are a great way to do things, personally I create DateTime helper entities to indicate when something else happens, then my trigger for automation is when that DateTime helper occurs. I do this for several reasons, the first is that I can create complex rules for the next date/time (i.e., for my vacuum to run it will then calculate the next run date/time based on a rule, for example, if I issue a command to delay the start for 90 minutes), second it survives restarts. This works well for button based entities because the date/time of the press is the state, so you can use that for calculations (i.e., turn off in 15 minutes unless it is dark outside, then turn it off in 30 minutes from the button states date/time).

This is to say that for things that you need to survive a restart there are several methods, depending on your needs, if you don’t care about surviving restarts then what I outlined in the first section would probably suit your needs.

[atlflyer]

I stand behind the core idea of my reply which is that the the button entity doesn’t seem to be how this integration reports keypad events to Home Assistant, that integrations typically use button entities to allow HA/users to interact with the device, not the other way around, and OP should explore what else is exposed by the integration.

I presented an example of Device triggers as an illustrative example of one such way Lutron, specifically, propagates when a physical device button is pressed. I was not trying to suggest that this is exactly how OP’s particular device will work.

[petro]

You’re confusing button entities with the events that lutron_caseta uses. They are not the same.

Events don’t have entities (not true anymore, some have entities).

Buttons are button entities, they have a state.

e.g.

[lraesly (Lee Raesly)]

It is a copy/paste error… good catch! I’ll repost later today, once I get home.

[123 (Taras)]

• When you get home, go to Developer Tools > States and find button.keypad_button_4 in the list.

• In the States column, take note of the button’s current state value. It should be a datetime string representing the last time the button was used.

• Press the physical button that represents button.keypad_button_4. The datetime string should change to the current time. EDIT Apparently it will not.

Let me know if the datetime string doesn’t change or there’s no datetime string (perhaps it’s unknown).

---

EDIT

See atlflyer’s post below. Testing shows operating the physical button doesn’t affect the button entity’s state.

[atlflyer]

@petro

Buttons are button entities, they have a state.

Yes, I was off base on this in my initial reply, but what I am not off base on is that integrations don’t use button entities to report that someone pushed an IRL button on a device.

[petro]

Yes they do. Maybe your integration doesn’t, that would be a bug (assuming it reflects a physical button).

[lraesly (Lee Raesly)]

Is there a way I can discover what happens when I press the button (like in an activity viewer)?

In my case, if someone manually turns on the stairs light, I don’t want to always turn it off after a timeout period. Only turn it off if the button is pressed.

I need to wrap my head around HA programming and YAML!

[lraesly (Lee Raesly)]

Will do. Thanks!

[petro]

You can watch the logbook, it will show you context. Using context is pretty difficult. 123 has a canned condition that you can use (copy/paste) to determine if something physically happened or not.

[CO_4X4 (Colorado Four Wheeler)]

@lraesly

In my case, if someone manually turns on the stairs light, I don’t want to always turn it off after a timeout period. Only turn it off if the button is pressed.

Now you are talking a bit of a different scenario, physical button versus virtual button. That is going to be either device dependent (i.e., Inovelli’s send notification of a physical button and lets you configure things based on physical versus virtual) or you are going to have to intercept the protocol packet to know it was turned on physically. If you don’t have the capability on the device nor the inclination to grab the packets you can use other sensors to help - i.e., if the motion sensor detects motion then don’t auto toggle off.

[atlflyer]

@CO_4X4

Now you are talking a bit of a different scenario, physical button versus virtual button.

This is the scenario OP has been asking about all along, as I understand it. The automation should run when a physical button is pressed on his Lutron keypad, but not if the light is controlled via it’s normal mechanism (presumably a wall switch).

I’ve confirmed in the code that the Lutron Caseta integration handles button entities for Picos and keypads the same way.

I’m reasonably confident this is the integration OP is using because the Lutron integration does not have button entities associated with its keypads (according to the documentation) and the Lutron Homeworks platform is 20+ years old and is only used by 7 active installations (also according to the documentation).

To confirm that the Lutron Caseta integration does not change its button entities states when the physical button is pushed, I set up this template and then pressed every single physical button on my Pico. Everything remained “unknown”. Then I “pressed” the button.kitchen_pico_ktch_lower entity in the HA UI which triggered automations just like if I had pressed the physical button and changed the entity’s state to the current timestamp.

I don’t plan on filing a bug report for this, as this is exactly my understanding of how this is supposed to work…

[123 (Taras)]

Thanks for carrying out the test I had suggested to lraesly (assuming your device uses the same integration). You’ve confirmed the button entity is effectively unidirectional (Home Assistant to device). Pressing the physical button doesn’t change the button entity’s state.

That is in line with what Lutron Caseta’s documentation says about Button entities.

tl;dr
If certain assumptions are correct, lraesly is using the wrong entities to detect physical button presses.

If it’s a Pico remote, the documentation suggests using Device Triggers.

[petro]

And device_triggers just translate events, specifically these events

into device triggers. Normal event triggers will still get the job done.

[123 (Taras)]

Just a side-note: I like the way the Hue integration handles button presses using event entities. It makes it much easier to use with a plain vanilla State Trigger (plus all the possible button actions are listed in the event entity’s event_types attribute).

[petro]

Yes, those are new. They will be the new normal for all events as soon as integrations adopt the entities. They were introduced a few months ago.