Trigger on 'off' is pressed, even if already off (luton dimmer)

Hello. I figured this would be easy but can't get it to work. What I want to do is trigger an action when the 'off' button is pressed and ONLY if the switch was already off.

Now I figured, if the switch was off, it might not report when I press off again and that would dash my hopes. But, I can confirm that pressing off, even in off state, logs another off event.

However, I can not get any trigger to work. I have even tried the "Custom Attribute" trigger.

Any hints or is this not possible?

You can't do that. The lutron bridge will not send a second "off" signal to hubitat if the switch is already off. Also, hubitat will not create another event if the switch is already off as well. Only when the state changes is an event created by the system. You can't get a dimmer to work like a button controller. If you want a lutron button controller, buy a pico.

Hello John, it is funny you say Lutron can't do something when I have clearly posted a picture of it doing just that :rofl: did you see my log? The Lutron switch is sending an off command everytime I press off, even if the switch is off.

So I think the limitation is at the hub end. I have lots of picos but I don't want to add one here if I can get this working (which it should). But thanks for trying.

I don't think what you're trying to do is possible. You can log a message, but I don't think you can read from the log and do actions with that

I'm pretty new to Hubitat but I think I'd make the trigger be the button being pressed and the IF statement test for the light being off. You might try that.

It doesn't matter if it shows up in the log, it needs to show up in the device event log. It is likely that the repeat event is getting de-duplicated, which means it can't be used as a trigger. You can verify that by looking at the device event log - if multiple OFF events are there you can use it as a trigger, if not then you can't.

The trick is getting the actual trigger event to fire. Since the HE is event based, 'like' actions do not trigger events. i.e. If the switch is off then there is no repeat trigger for 'off' because nothing has changed. You'll see logs report that something happened but I'm pretty sure that gets filtered in HE to avoid unneeded processing.

That being stated, I ran a quick test and with my HomeSeer dimmer/switches they have the added capability of reporting as buttons, too. I setup a quick rule that would monitor that as a button and fire everytime I pressed the 'off' side of the switch. That worked and would do what you want. However, not all the switches have that capability (my GE ones do not), you'll have to run a test on your lutron setup.

I wonder if you could pair the switch with a pico remote and then test the pico remote? I don't know if the events go both ways though.. i.e. "virtual" pico events generated by the switch.

Thanks for the suggestion Tivo. I did try that, but the trigger is never activated.

Jason, thanks for pointing that out. The system log shows multiple 'off' commands (e.g. pressing off in the off state) but the device events do not.

Mark, I think your saying something along the lines as Jason. RM is using events to trigger and events are only generated with a change in parameter state.

I was hoping the RM "trigger on parameter" would just fire when a device parameter is recieved that matches. But perhaps its the underlying 'event' layer that RM is using and not raw parameter reads.

So I am writing a groovy app to test to see if I can just overcome with that. the HE API provides two types of parameter subscriptions: one that filters repeated states and one that does not. Sounds like RM and device 'events' are subscribed to filter repeated parameter states. I need unfilter to achieve this with Lutron.

.. so over to the developer subforum I go.

Yes, RM is purely event driven. As an example, think of a run of the mill dumb toggle switch, if it's off and you push it to turn it off then nothing happens as there was no 'event'. You can't turn a switch off that's already off. Took a little bit to get that right in my noggin, I've been writing PLC code for decades which is scanned based and needs a different mindset,