Trying to fix false triggering when a scene controller goes to “unknown” state…and I’m struggling. I’d also love if I could tell “KeyPressed” from “KeyPressed2x” or “KeyHeldDown” and other possible events.
I’m confused why this doesn’t seem to work when it sounds like I should be able to test on an attribute according to the documentation – this only fires once, then won’t fire ever again even when the button is pressed again later, unless it goes unavailable and then gets pushed I get 1 more fired event detection:
But if I use a template conditional, it works as expected, triggering only when the event_type has a value of ‘KeyPressed’, EVERY time the button is pressed once:
The only thing I can think is that the attribute doesn’t change after the first key press even though the state might. That would explain the difference between the two behaviours.
You are using a state trigger, but those are events, so try to see if you can use an event trigger instead.
You will need the events to set it up, so open up the developer tools and select the events tab.
Set the bottom field to *, which will capture every event occurring in HA, so in somewhat rapid succession do the following.
Click the Start listening button, click the key press combo you want to capture and then click the stop listening button.
This will give you a list of all the events, as said earlier. Your key press combo is in there too, so start going through the list.
The key press combo might consist of multiple events, so look through the entire list and find them all.
I can’t seem to use the “events” developer page because as soon as I hit start, the events page begins blasting them so fast I can’t scroll back fast enough to hit the stop button, even before I manually trigger any.
Surely there has to be another way to figure it out?
I was using this post as the suggested way to get the button presses:
That’s correct, but I’d expect it to still fire every time, no? I have other state automations that fire every time the “to” matches, even if it went from the same thing to the same thing.
State triggers are not designed to trigger on updates to the same value and it is downright impossible for you to have existing automations where they do. Either those automations are not configured the way you think they are, or whatever state it is that those automations are watching changes to something else and then quickly back again.
Again, it is simply impossible. The only way this could happen is if your state trigger did not specify any of to, from, not_to, not_from or attribute. That would make the trigger fire not only on a change of state but also on any change to any of its attributes.
See the bullet points right at the beginning of the state trigger documentation. To only fire on a change of state, even if you don’t care what the old or new state is, you need to specify any one of to, from, not_to or not_from but set to null / ~.
If I’m understanding correctly, your second block of code in your first post is working with the exception of triggering on “unknown” states? And then you’re looking to expand to other events?
If that’s the case, just trap for unknown/unavailable on your trigger, remove your condition, and use event_type to determine what kind of button press was recorded. Something like below:
I was hoping there’s a way to not need to use the conditional and have it just happen all in the trigger - and then I can specify easily which of those events I want to trigger on.
Otherwise as I add other triggers I have to also start making FAR more complex conditionals to match each trigger.
If I can make it work with all the conditionals and entity as part of the trigger state, I can then also name the trigger and simply reference the desired one in the templates in my automation without all the many if/else/condition statements.
I’m just stuck on how to make the trigger fire only for the button press, and on every button press (even if its pressed once again later with nothing inbetween)
The way to do this is with a single trigger (when the event changes state). Don’t use any conditions in the conditions section. In the actions section you use a choose block, and put the conditions in each choose option.
If you look at that example I had in my last post, using choose on the event_type is pretty clean so long as all the events you’re triggering on come from this same event entity. It might help if you give some examples of what you’re wanting to add as other triggers though if it’s something more than that.
I’m on my computer (Mint 22) and it seemed to scroll automatically
EDIT: Ok, apparently it doesn’t like Firefox but Chromium behaves better.
Though in the like 5 seconds of listening it got 229 events and I’m not seeing any that look like this button
I think all entities are changed based on these events, so it must be there somewhere, but much of the information on the event might be unrelatable to the event from your view. However the states you see in the entities should be there, so look for a KeyPressed state.
I did try and search for “Key”, “Pressed” and “KeyPressed” on the page without success.
I wonder if that’s why the other examples I have seen went the other route
EDIT:
I just had a brainstorm that maybe it works the same as the Inovelli scene controller function of my Red series light switches - and it looks like it does!
Searching instead of * I tried zwave_js_value_notification and hit the button…and it came right up! So maybe I can use the Inovelli Red automations I have as templates for this now that I have worked this out.
It does really suck that there isn’t a friendly name though for the node_id or anything else though.
event_type: zwave_js_value_notification
data:
domain: zwave_js
node_id: 61
home_id: 3282841160
endpoint: 0
device_id: 299cbee800fe7c596b5f8fd257090c24
command_class: 91
command_class_name: Central Scene
label: Scene 001
property: scene
property_name: scene
property_key: "001"
property_key_name: "001"
value: KeyPressed
value_raw: 0
origin: LOCAL
time_fired: "2025-01-20T00:06:52.802397+00:00"
context:
id: 01JJ0GH742M9QT7RE4H00RDJ9J
parent_id: null
user_id: null
.
So then I can take the above, and plug it into the same form as the ones I use on the Inovelli Red switches: