My requirement is push top (1) turn on light A, push bottom (2) turn off light A, Hold top (1) turn on light B, hold bottom (2) turn off light B. I set up rules and it works as expected except for one issue. The hold function operates immediately but the push has a 3 second delay. The switch is GE enbrighten 46203. I have tried both switch and dimmer drivers in Hubitat. Does anyone have an explanation or suggestion?
While I have oodles of GE dimmers/switches, including 46203s... I don't get exactly what you are doing/explaining. I've certainly never done "hold" events on the devices. If I need secondary functions I use double/triple taps.
Understand -- I need to use the hold function since some users in my house have trouble timing the double tap. The hold works fine. It is the pushed function that has 3 second delay not the hold.
On the hold function...
(EDIT: Based on below, I guess I'm wrong) There isn't a "hold" event created by the device/firmware (that I know of/can think of). So I assume that is something Hubitat or RM is generating on the hub or driver side of things?
the inbuilt drivers provide push, hold, release and double tap for buttons 1 (top) and 2 (bottom)
Interesting. I didn't put hold/release on my user driver. Honestly, I never thought about it/looked for a hold/release event as I've never needed it.
I guess I should go add that too, if it is a reported scene event on those devices.
hold is synthetic in this driver, one of the few where it made sense to do it that way.
1 Like
Good to know. Thanks! I'll leave that out of my driver then. then. You saved me time looking for it! 
The previous discussion is about the hold function. The hold works perfectly . My question is why the push function takes 3 seconds to respond and the hold is immediate.
I don't know about 3 seconds, that's not been my experience with this device, but immediate it's not.
Casual observation on my part would be a 1000 to 1500ms.
The device itself seems slow in sending zwave responses to physical actions, slower than other zwave devices of the same class, this is a specific issue with this device in my observations of frame captures.
I actually have data on that... Because when I make a driver I test and log response time on hub messaging - digital and physical.
I genuinely don't remember what my data showed. I'll look later, just as another data point.
Anecdotally, I don't remember any event response taking 3 seconds though. But, sometimes it depends on what you are looking at and how your measuring it.
For instance, in my drivers I usually don't generate an "off" event until it is fully off... So if you have 3s of dim down on the device, I (typically) wouldn't report the off event until 3s after starting. As it isn't actually "off" until the dim down is complete.
Every driver writer has their own techniques and preferences on that type of thing, though.
yeah, I was specifically talking about the events generated by the central scene class, all of these should be sent immediately by the device, irrespective of the level and or switch reports...
True. And I do remember those taking somewhat longer than I would have expected. Although not 3s.
Oops. Never mind. In my driver I did ON/OFF on the multilevel report, not the central scene report. So my event response time data would not be applicable to the in-box driver anyway.
I only used the central scene report for double and triple tap events (exposed as button presses in my driver, since there is no triple tap capability).
Anyway, sorry to derail your original question. As you are using the in-box driver, only Hubitat would be able to conclusively answer as they are the only ones that can see the driver code.
As you can see by now I am not a code writer. I am an electrical engineer but with little experience in this field. My original question was prompted not by whether it is 1 sec or 3 sec but why held is almost immediate and push has a several second delay. Why is the difference?
This is an implementation issue on the device itself, call it a feature, a bug, or an oversight...
Thank you for your comments and suggestions!
Jim
For the record, I checked and my central scene reports register on the hub in less than 1s in all cases. I tried it about 30 times, never did it take >1s to register in the hub and create the event.
The 0.4-0.8s it takes to come in is definitely slower than a typical zwave report message, but certainly nowhere near 3s.
So, in summary, I have no idea why the OP would be seeing 3s delays.
1 Like
That is about what I see for the hold. But the pushed is much different. I thought it was something I did in the rule I set up but I guess not. The mystery for me is why should hold and pushed be so much different when they perform similar actions?
Don't know.
I have no idea how they are calculating "pushed". Held/released comes in via hardware, which is <1s - so I get why that is the speed it is.
If they are calculating "pushed" somehow in the software it could take longer I guess?
@jg.brown For my own education... How is "pushed" different than just turning the light on/off normally? Isn't that "pushed"? Or do you do something different than the normal local on/off press for a "pushed" event?
If I understand that a little better, maybe I could just add the capability to my driver a faster way... I already see how to add held/released.
@jg.brown Here ya go. It may/may not be faster than the in-box driver, but I am 100% sure it is as fast as it can possibly get as it is using the reported events from the device directly (no software emulation/calculation of pushed/held/released).
