GE 14291 Z-wave plus switch - port from Smartthings

[smr06]

Hi all,

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.

Here's a link:

smr-06/hubitat/blob/master/GE_14291_Z-Wave_Switch.groovy

[MtView]

This might be helpful:

RM Ignores Some Zwave Plus Switch Activity

I have a simple motion activated lighting rule I set up in RM. if active, turn on the lights and turn off after 2 min of no activity. I have another trigger rule set up so that if there is a physical on from the switch controlling the light turned on by the motion, pause the motion rule. The log logs the physical on. Hubitat knows it happened. Keep in mind the md has already activated the light. The problem is RM won’t act on it if the md has already turned on the light. If the log is picking…

[JasonJoelOld]

Thanks for this.

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.

[stephack]

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.

[BETA] GE/Jasco Z-Wave Plus Dimmer Switch With Double-Tap, Associations, And...

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.

[JasonJoelOld]

I saw that - thanks.

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.

[smr06]

@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:

1. The device must send a command
2. The driver must use the command to create an event
3. 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:

And here is the section of driver code which I believe converts physical Z-wave commands to events (beginning at line 170):

def zwaveEvent(hubitat.zwave.commands.switchbinaryv1.SwitchBinaryReport cmd) {
    log.debug "---BINARY SWITCH REPORT V1--- ${device.displayName} sent ${cmd}"
    createEvent(name: "switch", value: cmd.value ? "on" : "off", type: "physical")
}

I don't see anything in the driver which checks for state change before creating an event.

And yet I don't see the second ON in the events log:

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.

[stephack]

@smr06

createEvent(name: "switch", value: cmd.value ? "on" : "off", type:

Try adding isStateChange:true to the createEvent and see if that helps.

[smr06]

Yes! That did it. Thank you!

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.

[csteele]

@smr06

isStateChange:true

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.

Purge Device/Hub/Location events

Both devices referenced in this thread are sending events with "isStateChange: true" I would check to see if that is truly necessary. If that flag is not set then the system will determine if the attribute has changed and will store it in the event table only if that is the case.