Is there a way to Trigger a Rule when Device State doesn't change?

No. Apps subscribe to device events. No device event, no rm action. That's the way the system works.

You cannot get a second ON physical if the device is already on. It doesn't work that way. The only way to do this is to have a driver that treats everything as an event. And you are going to see dozens of extra events that normally would be filtered out by the platform. If this is a z-wave device and is being polled, you'd see an event every time the switch was polled.

Not possible at all without custom drivers. All drivers are designed to filter out exactly what you are trying to do.

Yes and No. I might want to do that but can't even figure out how to get the Rule Trigger to fire.

I might want a rule that uses one dimmer (main) to control another dimmer (slave). Let's say the main dimmer is On and the slave dimmer is Off and I want to use the main dimmer to turn on the slave dimmer. Using the common Triggers that check for an On, Off or Change would require you to first turn off the main dimmer then back on in order for the trigger to fire and turn on the slave dimmer.

BTW, the Group and Mirror Apps suffer from the same issue.

So again, how do you trigger a rule when a device receives a command but the state of the device remains the same?

From what I can see, at least with my z-wave plus dimmers, if the dimmer is On and it receives an On (either digitally or physically) the device and the hub knows about it. RM might not be able to test for such a scenario today, but why shouldn't it?

Why would you see dozens of extra events? The events are already being delivered, even if they don't result in a state change. Let's say there were dozens of extra events, if its important information, then what's better, they get filter out or let through.

If you read my question, I state my preference would be to not have to create a bunch of customer drivers. Therefore my question, how to test when a device receives a command that doesn't initiate a state change? Dimmer is On and it receives and On, Dimmer is 25% and it receives a 25%, Hue is 20 and it receives a 20.

That goes back to my original point. If a Dimmer is On and the wife taps the upper paddle, an On is generated but the state of the dimmer hasn't changed using the typical Turned On, Turned Off, Changed won't work.

@glenn You might want to read through this recent thread. Look at Dan.t 's posts. They could very well do what you want.

Glenn - I just noted that you are the OP of that thread, and that solution does involve a custom driver . . .

1 Like

I had and it helped solve a big problem with virtual devices. But using that scenario would require a custom driver for every one of my devices, which as I stated is something I wish to avoid. Furthermore, the fix, as he even points out is somewhat of a workaround. Basically it sends a state change when a device receives a command even when the actual state didn't change allowing for the trigger to fire.

And my answer is, it cannot be done without custom drivers. App subscribe to device events. If there are no device events there is nothing for an app to respond to.

No, it cannot.

So if a Dimmer is ON and the the upper Dimmer paddle is pressed or the Dimmer receives an ON digitally, we can't and sounds like from your tone, shouldn't be able to evaluate that situation.

Apps subscribe to Events from Devices. That's how the system works. So, unless anything you are talking about generates an event within the driver, an app cannot respond to it. That's just how it works. I'm very sorry that you don't like it but that doesn't change how it works.

Its not that I like or don't like something, just trying to figure it all out...

But you don't seem to be accepting the answer, that's all I'm saying. :man_shrugging:

The bottom line is, if you can get a driver to produce an event, then an app (including rule machine) can be triggered by it. But without that event, there is nothing for the app to respond to or check. Anything inside the device data or the device's state variable are not accessible by apps directly.

And anything we've talked about would mean a custom driver. Since the stock drivers are not designed to do any of this. I'm sorry it's not easier to achieve.

It would seem to me that instead of in-wall dimmer/switches what you really want on your walls is button controllers. Button controllers don't have such restrictions. They only have the restrictions you impose of them. This is why mike maxwell, THE device guy at Hubitat, has a system with micro-dimmers in-wall or smartbulbs with Pico remotes on the wall. That way, the button presses will do exactly what you program them to do. Your top button on a pico can be set to turn the light on to 100% if it's off or dim the light to 50% if the lights is already on. That's because the triggering device, the pico and the controlled device, the dimmer, are independent of each other. In situations where you want that type of freedom, you might want to adopt a similar setup. Just a thought.

2 Likes

What in-wall dimmer are you using? All "scene-capable" models I've seen will also send button events when you tap the up or down paddle, so you could use that instead of an "on" or "off" state trigger whatever you want. If you don't want to use custom drivers, replacing your switches/dimmers with scene models would be one way to avoid that. :slight_smile: (This basically adds the button device feature mentioned above to them; any Hubitat driver I've seen interprets Z-Wave Central Scene commands as button events.)

You don't have to go all-out on models that brag about scene support, either. The Inovelli LZW30-SN or LZW31-SN or HomeSeer 200-series would certainly work, but I think all current firmware on the entirety of Zooz's switch/dimmer line would do the same (not as many taps, but you'll only get two with stock Hubitat drivers anyway, and it sounds like even one would be good enough for you), as can recent GE switches/dimmers, though that feature is so poorly documented I'd be afraid to recommend them if I hadn't seen people here using it for that.

3 Likes

Over Thanksgiving, I replaced some GE z-wave switches with Zooz Zen 21s and was pleasantly surprised to see this switch has Central Scene capability and supported 2 buttons with the default Hubitat driver. And the button capacity comes in very handy to trigger RM rules.

3 Likes

You are correct but using the central scene dimmers button capability won't work for Alexa or Google and would require use of Button Tiles on your dashboard rather than a switch or dimmer tiles.

You also bring up a good point.

If your central scene dimmer is ON and you tap the top side of the dimmer, the hub will "see" an ON and a Push 1. You can then use RM to evaluate the Push but not the ON. A Push, Double Tap, Held, Released, Turn On, Turn Off, Dim Up, Dim Down are all Actions but RM doesn't evaluate the Turn On, Turn Off, Dim Up, Dim Down actions only if the action resulted in a state change.

So either I'm missing how to check for these actions, Hubitat missed it or they have a reason for leaving it out. I wish they would respond.

You could create a virtual switch, then use either a Dashboard tile, Alexa voice command, or a Z-Wave Central Scene (button push/etc. from a dimmer) to turn on that switch, then use that switch to trigger whatever automations you want. You could utilize the "automatic off" feature of that switch after a few seconds to turn it off automatically after it gets turned on, so it would functionally still act similar to a button and be able to get turned on again and trigger whatever rule you're doing. So, for example, every time button 1 on your Central Scene Dimmer is pushed or an On command is issued to that device, you could turn on the virtual switch. It would then be the trigger for...whatever it is that you are trying to do.

This may be a bit of extra work for you, so perhaps you could explain a specific scenario and what you want to happen, and someone may suggest other ideas.

Multi-taps are triggers in Rule Machine speak, not actions, but I'm assuming you were just using lay terms? Turn On is an action, not a trigger, but switch state changing or turning on or turning off could all be triggers that could result from an action somewhere else (but an "on" trigger won't usually fire unless the state is different than it was before, which is where the "secondary" virtual switch idea may work for you). Not trying to be picky, but just wanting to make sure you have the right things in the right spots. :slight_smile:

Can't use a Virtual Switch because RM will only trigger when the switch changes from On to Off or Off to On. I need RM to trigger when the switch is told to Turn On or Off. So even though RM will fire every time you push a Central Scene Switch Button 1 (ON), you can't check it switch to see if ON was pressed.

My assumption is that you would use the auto-off feature and use a different virtual switch for each automation, with auto-off enabled so successive "on"s are never a problem. But again, you might want to explain what you are trying to do in case there's a different approach you could take that would be less messy to set up.

Hubitat groups do not support the startChaningLevel and stopChangingLevel commands. So, you could not have ever done this.

No, RM cannot do double taps from a PIco because Picos don't support double tap.

Add the group device to your dashboard. If they are in a Hubitat group, they can be controlled by the group device they are part of.

In-wall dimmers control a load. They are not button controllers. That's why this won't work.