I have a GE Enbrighten ZWave motion switch and have it doing what I want using "Basic Rules".
I have the switch configured in "manual" mode, which means motion doesn't turn on the device's load switch. Instead, the motion "event?" turns on two other lights in the room.
While it works, there is an objectionable delay. And, the hub must be powered on for the motion event to be forwarded to the lights I want it to control.
Another ZWave device I have (RGBGenie touch panel) can be configured to control other Zwave devices even when the hub is not active. Hub is required to specify which lights to control, but it's not required after configuration. The latency to control the lights is imperceptible.
I'm brand new to ZWave--is there a way to associate devices or make a group to accomplish what I'm doing with "Basic Rules" that might decrease latency between motion detect and the lights turning on?
Yes, Z-Wave devices can be linked (Associated). There is a build-in app called “Z-Wave Association Tool” that will allow you to make those direct association. Each group can be used for a different type of association (on/off vs dimming, etc.) between Z-Wave devices.
Not sure I understand your question, but I use "Basic Rules"
This is true, but do you plan to keep your hub powered on only sporadically?
I don't mind keeping the hub on all the time. I just added this comment since it indicates that the hub itself must be sending commands to the lights after noticing the motion event. I suspect that's the source of the latency.
You'll want to be careful about controlling devices via associations between the devices - it can cause the Hub to get out of sync. From my experience (primarily with HomeSeer switches and dimmers), the "controlled" device doesn't tell the Hub if its been changed via an association (I think this is vendor-dependent).
For example, say dimmer devices A and B are both included with your hub C. If C changes A or B, then C knows of this change, so the Hub has an updated record of the state of A or B.
On the other hand, say A is associated to B. Now if A changes, it sends a change command directly to B, avoiding the hub, which causes B to change. But since the hub wasn't involved, it won't know that B changed. Thus, the next time that the Hub goes to do something that is dependent on the state of B (e.g., a rule: if A changes and B is Off, then do ..) the Hub won't know the state of B so the rule operation will be inconsistent.
If you use plugins like the Google Home or Apple HomeKit (Homebridge) plugin, the problem will propagate to those platforms - i.e., since Hubitat isn't "correct" since its lost synchronization with the devices, then the reports and controls using these other platforms will also be incorrect.
My suggestion - pass everything via the Hub and use rules at the Hub. For the tiny bit of delay, you avoid a major headache.
app:32021-05-24 12:47:59.504 pm infoact: Turn on Over Cabinet, Under Cabinet
app:32021-05-24 12:47:59.470 pm infoevt: Overhead motion active
The log seems to indicate that from when the motion event was received, the rule was forwarded in less than 100 msec! Yet, the latency is about 1 second.
I didn't see the relative long latency when the motion detector is controlling its own load switch by being configured in that mode (no hub required). Another reason I thought using an association instead of a Simple Rule might improve things.
If it is a dimmer, sometimes that is just the fade on time of the device. Try sending a level=99 duration=0 instead of an ON command and see if it is faster...
EDIT 1: I edited my text above, I forgot that you can't set a duration on level commands in Basic Rules (unless it would take a 99,0 - but I doubt it, although I didn't try it).
EDIT 2: If it is a switch, and not a dimmer, the above advice would not apply.
I'm already having issues with the assumed switch state causing issues--before I mess with trying to do associations.
Really, I think I'd prefer the hub to be stateless--regardless of whether a device is on or off, just send the message. At least for simple on/off control.
Why would I care if "turn off" command was sent to a device already off (or vice versa) I can't think of why current state would be useful in my use scenario.
For example, I wanted the motion sensor to turn the lights on automatically, but allow the wall switch to turn them off. But, something is filtering the off button push. It won't work unless I first push the on switch.
Maybe the switch itself doesn't send the "off button pushed" unless it thinks it is in the "on state". Or maybe, the driver/app in Hubitat is making that decision.
How could I tell if that's the case, or whether Hubitat is "filtering" based on what it thinks the switch state is?
Could I fix things like this by writing my own drivers?
However, the lights the switch controls via the Simple Rules app have a transition time. I set to ASAP, but it really didn't change the latency or the slew on/off time.
Gotcha. I don't know then. I have TONS of GE Motion Dimmers and Motion Switches - many of which I run in manual, with what I would call a minimal delay. Certainly not 1s.
Now, if you are controlling other devices based on that motion, what they do would depend on what brand they are and how they are made/configured.
I'm doing manual mode and its controlling other devices (RGBGenie ZWave RGBW led controllers). Latency is never less than 1 second, usually around 2 seconds.
A different device (RGBGenie Zwave RGBW touch panel) that controls the same RGBGenie devices does it what seems instantaneously And works without the hub.
Maybe it's just that the motion detect signal is time integrated in the switch itself. But, maybe some code in Hubitat is doing something to mitigiate false triggers. Is there a way I can review handlers/app code to check for this?
The in-box device drivers are not open source/available.
That said there are user drivers for the GE Motion switch and dimmer you could try and see if it does anything different. That code you can review, too. The guy that wrote them is a definite hack, but maybe they will be useful for you!
Available in Hubitat Package Manager or on my github:
Well, that “hack” does some fine drivers. I would suggest his other driver for the same device:
The nice thing about it is that it logically splits the motion sensor from the switch, useful for rules if you have the device in Manual mode. I use it on several in our home, works well.
