I think part of that illusion of speed is that the V2 SmartButtons do not really have any travel as they use a microswitch. You barely have to put any pressure on them to get them to fire an event. By the time they register a click, the event has already been sent.
That's not exactly slow... 195ms and that includes the message returned from the SmartPlug indicating it's turned off. That's under 1/4 of a second. I would dare say that without any scientific instruments, it's impossible to be any more granular than that when comparing the response times with iris.
I think it's quite a bit higher than 200ms, going by what I see with my eyes. Iris is MUCH faster. At least until March 31. See if you can watch this video: youtu.be (slash) t_gXISyLHTc Crank the volume up and you can hear the buttons clicking and the Centralite plug's relay. The ST button is controlling the Iris gen2 plug (Centralite) there in front of me, and it's driving the light above me to the right. The Iris gen1 button is controlling a gen1 smart plug driving some overhead lights, and it responds far faster.
I'm just looking at the logs, they don't lie.
I see the button event received by the button driver, 12ms later the driver creates the event sent to the app, then less than 200 ms later the switch responds that it's off. what we don't see, and there's not much to be done about it, is how long from the time you start pushing the button until the driver gets the message.
I don't recall the Samsung button being particulary slow, but that shouldn't be much more than another 50ms.
This is all somewhat academic at this point, as you say, in 10 days Iris will be very slow...
We have three zigbee frames at 50ms each on average, 3 driver and one app load at 25ms each, that's 250 ms, you're at 195, honestly that's about as good as you're going to get on any all local hub that's actually capable of doing anything sofisticated...
Thatās not even close to being a scientific test. Completely separate devices, completely separate mechanical and electrical properties. An audible click is meaningless, itās when the message is actually sent. If the Samsung button is lagging by 100ms before sending itās message, not much that you can do.
A real test would be a V2 SmartPlug and Samsung button on Iris. But you canāt do that since Iris never supported it. My guess is that the Samsung button is probably taking a little extra time to wake up and send its message vs the Iris button.
These buttons have a history of not being consistent in performance. Firmware has something to do with it. But thatās nothing that Hubitat can control. Itās a Samsung issue.
As I noted, it could also be the Centralite plug, but it could also be the button as you mention. Another "real test" would be if I could use the gen1 button and gen1 plug on the HE. I have some gen2 buttons as well that I can try, but they are miserable to work with ... battery seems to lose contact constantly. I figure I may just take the PCBs out and stick them in another enclosure with a proper battery holder and a good button. I also have several the quad-button fobs.
In any event, the Iris is damn fast, and I've been using it for years, so I'm used to it, and I like it that way. I want damn fast again.
I tried using the Iris gen2 button on both HE and Iris, and rev gap in latency is far lower now. So, Iād chalk it up the ST button being the major culprit. Thatās rather disappointing, though, as the industrial design of the ST button is pretty nice, but I might send them all back, particularly if all my gen1 devices can be resurrected soon. There is still a noticeable gap, but that could be due to the plug. I See youtu.be (slash) KS90ywUe9FM
I have three of the ST/Samsung Buttons and I am not impressed. My unscientific analysis is they are "flaky". Sometimes slow, sometimes asleep. I am starting to use them as temperature sensors and use Picos for buttons. I was attracted to the clean design of the ST/Samsung . . .
I have them both, works perfectly fine. The waxman leaksmart zigbee valve and the iris zigbee water sensor.
The water sensor works with the built in driver and for the valve, i used the drivers linked in the previous reply.(oops here is the link to the driver, SmartThings/devicetypes at master Ā· krlaframboise/SmartThings Ā· GitHub
And yes the smatthings driver works in Hubitat for this device, but that is not true 100% of the time.
If you need any help, hit me up, happy to help
Hey you beat me to it, I just re-paired my valve, I guess you did it on desktop that's why your endpoints aren't cutoff like mine. Good for me to keep in mind next time dev:15122019-03-22 11:55:07.193 pm debugDevice, parse description: catchall: 0000 0006 00 00 0040 00 F5FF 00 00 0000 00 00 47FDFF040101190000
Did you ever get your NYCE Tilt Sensor to pair correctly? I'm having the same issue (NYCE Gen 1 Tilt Sensor). It is showing up as a motion sensor and even after I select it to the NYCE Contact Sensor and hit configure nothing changes.
Hi Mike, thanks for the quick reply.
I tried to pair my NYCE Tilt Sensor Gen 1 as an IRIS V1 ZigBee, but nothing happens.
It only joins using the ZigBee button, but it pairs as a NYCE Motion Sensor.
Sounds like any of us with the NYCE Tilt Sensor V1 are out of luck until you write the driver for it. Hopefully doesn't take too long. Thanks.
Yeah, it's not going to work with the inbuilt driver currently, the V1 sample I had wouldn't join using either discovery method.
What zigbee channel is your hub on?
No I havenāt, I sent it into mike but that was right before the updated Zigbee pairing update. Try what mike said above and please let me know if it works.
Ok thanks Ron, I'm not sure what you are referring to regarding "try what mike said" but I did try pairing it this morning using the IRIS V1 ZigBee button (nothing happened) and then using the standard ZigBee button (paired as an NYCE Motion Sensor) just like it did for you. I tried to change it to an NYCE Contact Sensor, but that didn't have any effect.
Looking forward to Mike writing the driver for it. Thanks for sending it in to him for the rest of us.