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).
I keep telling you it's not a mystery that we can solve since we have no control over the firmware in these devices.
I would write GE support and ask them what the deal is...
The inbult driver creates pushed this way, there is no delay...
Then the op may have a legitimate bug if his pushed and held events are taking such a significantly different amount of time...
1 Like
Could there be a delay with pushed because the hardware is waiting to make sure it isn't a double or triple tap before sending the event?
Not in my experience. I got the central scene report back for single tap, double tap, triple tap, held and released all in <1s in my testing yesterday.
I am sure that there is some delay for that reason though, as the "released" central scene report event comes back in like 0.2s - probably since it doesn't have to wait for any additional presses. The tap and held events come in more like 0.4-0.7s.
That data is only based on the 2 devices I tested it on. Admittedly, that isn't a lot of data points.
1 Like
I spoke with the Enbrighten technical support yesterday. They were aware of the delay issue. They said I need to change the "sensitivity" of the switch and this can only be done from the hub. They were not familiar with Hubitat but they knew it could be done from the Samsung Hub. I would appreciate your help!
No idea what they are referring to. There is no published configuration setting called "sensitivity" or anything close to that. It might exist as an undocumented command, but that doesn't really help you much.
You can certainly adjust how FAST it dims (parameter 6 - 0 or 1 value with 0 [the default] being fast), but nothing I would call "sensitivity". In my driver that parameter is called "Adjust the speed at which the ramps to a specific value".
Yeah, me either.
I'm not aware of any standard zwave command that sets or resets a response delay time, in fact no such command exists...
The delay is just under 2 seconds.
1 Like
I sent an email request to Enbrighten technical support . After 2 weeks I got the following reply. This is beyond my skill set. I would appreciate any help.
Thank you for contacting Jasco Products Company. There is a slight delay with just pressing it once as it ramps up and down to the light setting. So it is normal for that to happen. Z-Wave devices typically have parameters which allow you to tweak settings like this in order to change their default behavior. You use your hub to make these edits but how this happens differs from one system to another. I have provided a link to the parameters below:
This is nonsense, I know you don't understand why.
I'm not seeing a specific parameter in that list that would fix this issue, if you wouldn't mind please ask your guy which parameter is supposed to change this behavior, however he doesn't understand the issue, and there is no parameter to fix this problem.
So for those with any interest in this, and this is why Jasco's response is crap, and this firmware is buggy...
What the tech is referring to is level reporting, and for zwave dimmers they typically issue a final level report once that level is reached.
However we aren't talking about that here, we're talking about the central scene class, which in the world of zwave, translates into button events in hubitat.
For both the switch and dimmer models the key pressed one time event for both on and off is delayed by almost 2 seconds while key held down and key pressed two times are sent immediately as they should be...
additionally the binary reports (that represent on and off) for both the dimmer and switch are also delayed, and this is also not right...
1 Like
I can tell you that I personally tested EVERY report type on my 46203 devices after the OP posted this, and none of them - and I mean none - took 2s. Heck, none took over 1s either. That includes the single press events.
I guess it would be interesting to understand exact steps to reproduce, to make sure we're talking about the exact same thing, as I am just not seeing what you and the op are describing on my 46203 devices.
Or maybe there is more than one firmware, and it only happens on certain ones?
But I do agree that the tech's response was complete garbage. None of those parameters could cause, or fix, what the op reported.
Easy, fire up sniffer, hit the paddle on the device, on or off doesn't matter. Device produces a node information frame immediately, (and only on single press), ~1.8 seconds later a basic report followed by a central scene are sent from the device...
1 Like
Yup. That is NOT what my two 46203 do. 
It wouldn't be the first time that different firmware or hardware revisions did different things...
I'll take a look again when I get home tonight, but I am 100% my on/off reporting happens in less than 1s.
They must have updated the firmware, though my embrightens aren't even a year old yet...
Firmware listed on back of dimmer and switch is 5.4...
