I've had the Hubitat hub for a few months but only began porting over from Smartthings during the holidays.
My in-wall devices are Leviton DZ6HD dimmers and GE 14291 switches. The built-in Generic Z-wave Dimmer driver works great with the DZ6HD dimmer. (It even shows physical vs. digital events which is a pleasant surprise. From what I can tell, that device responds to both physical and digital events with a Hail command - so I'm not sure how the built-in driver does its trick.)
Unfortunately the built-in Generic Z-wave Switch driver does not expose the double-tap feature of the GE switch. I was using Nuttytree's custom driver over at Smartthings, so I decided to try porting it to Hubitat.
Thanks to @stephack for porting the GE dimmer driver - I could use that as a reference when fixing the button implementation to work with Hubitat.
I also had to fix the reporting of physical vs digital events. I'm not sure if that worked correctly on Smartthings or not; in any case it needed some changes to work with Hubitat.
One thing I cannot figure out is how to generate events without an associated state change. The device does report such events - I can see them in the logs - but for some reason they are being filtered out when viewing the events link from the device page.
The driver has been working well for me for the past couple of weeks, apart from the above issue.
We may want to go back and convert the latest version of the dimmer dth, too. I think (?) @stephack did an older version (but I admit it is early, and I didn't go look ) . I'll look at that later today or tomorrow.
In the end the switch and dimmer device handlers should be basically the same code base, but with the dimming command handling on the dimmer, naturally.
Here is the code base I started from for the Dimmer. I believe this was the last version that nuttytree released for this device type.
He mentions that the dimmer dth is based of the switch dth that @smr06 ported. @JasonJoelOld, you will see in the changelog of my driver1 in the other thread what I changed to make it work with HE. One thing of interest to you might be this
switchMultiLevel V3 changed to V2 (hubitat compatible)
This was an issue back in March (eons ago in HE time) so I reached out to @chuck.schwer to see if this was fixed since then. If it was, you could probably do a more direct port of the original. I leave this driver in your more than capable hands.
I ported over (am still working on it though, as I think some of the choices they made are weird/not desired) the current supported ST GE Motion Dimmer DTH this morning, as I noticed it has the ability to set level without turning the light on/off.
It has one v3 item, but it isn't the switchMultiLevel so can't comment on whether that is fixed or not. Thanks for the head's up, though.
@MtView, thanks for the pointer. Yes, that is the same issue that I'm seeing -- the live logging shows the 2nd event, but the device event log does not record it.
The way I look at it, three things must happen for an event to be created even when there is no change in state:
The device must send a command
The driver must use the command to create an event
Hubitat must accept that event and enter it into the "event queue" so it can be used by other apps.
I can see the device sending a command, for example if I push "ON" and the switch is already ON. The following logs show an OFF followed by two ONs:
This is a mystery to me. It's almost like Hubitat itself is filtering out successive ON events at the system level,
Interestingly the built-in Generic Z-wave Smart Dimmer driver (which I'm using with the Leviton dimmer) does create multiple events without a state change. So there is a way to make it happen.
So it seems that Hubitat by default ignores successive events unless associated with a state change. And this behavior can be overridden via isStateChange:true. Good to know.
I've updated the driver in the repo with this change.
It seems this is being over used in some cases. I have some very large event logs due to this, specifically ApiXU. 58,000+ events for a single virtual driver. By forcing a state change, it has some knock on effects including logging it. I'm positive in this context, double-tap, it's required, but I think copy/paste may have run amok in many of our other drivers.