Is there a way to Trigger a Rule when a Devices receives a command but that command doesn't change the state of the Device?
Let's assume we're talking about a Z-Wave Plus Dimmer using Generic Z-Wave Plus Dimmer.
Dimmer is currently ON and the Dimmer receives an ON either physically or digitally. So no State change but I still want to fire the rule.
Alternatively the Dim Level is 25% and the Dimmer receives a command to set the Dim Level to 25%. Again, no change but still want to fire the rule.
Are there any Triggers that can test for this?
I understand you can use a customer device type that includes a "isStateChange: true" but I'd like to if this can be accomplished with having to rely on custom device types.
I think what you are saying is you want to compare the current state of the device to the action your rule has just sent to the device to see if the state is already what you sent. I don't know of a simple, built-in way to do that.
I'm not a coder but it would seem the way to do this is to watch all the devices that could control your dimmer and if they send out an event you could then run your rule.
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.
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.
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.
But you don't seem to be accepting the answer, that's all I'm saying.
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.
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. (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.
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.
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.
(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.)
