[RELEASE] GE/Jasco Z-Wave Plus Dimmer Driver

Thanks for your quick reply. Both DoubleTaps are now correctly being reported.

I am pretty sure my issue was not related to mesh performance. Specifically I observed that one button worked always and one worked never. I did recently change the driver to the built-in Basic Z-Wave Tool to try to gather some information on the firmware version of my switch. I noticed after switching back to your driver and doing a configure() that both taps are now correctly reported. I can't say if swapping drivers back and forth had anything to do with it, but I'm happy everything is working now.

On a side note, I wasn't able to retrieve the firmware version using the Basic Z-Wave Tool. Do you (or does any other poster) know if there is a way within the Hubitat ecosystem to do this, or would I need to use a z-wave stick on a PC to find this information? I know that Jasco does not offer updated firmware files, but I thought it could be useful to know what I'm working with...

Thanks again for your work on this and for replying to users' inquiries with your best information and ideas.

I can say this driver also works on the GE/Jasco 46202 non-dimmer switch.

Question ... curious if any thoughts if this driver might work actually dimming with the GE/Jasco 46203 ?

There are dedicated Enbrighten switch and dimmer drivers posted on here. Search for Enbrighten and it should be one of the first posts.

They are better than using this driver, as they were made for those devices and support both double and triple tap buttons, that this one does not.

Awesome !! Thank you for the FYI.

Posting here before the support forum.. Has anyone else noticed strange behavior the first time you turn on a switch with the latest HE 2.1.5.124? I don't know if it's the "first time" since midnight, since mode change, or what, but basically the first time in a day that I turn on one of the switches with a physical button press, it recognizes it as digital!

It's only the first time I hit the paddle switch On, and works as expected the second time. Wondering if others are encountering this as well? Log attached to show what I mean:

  1. I hit the paddle switch up for on (physically)
  2. I hit the switch physically off
  3. I hit the switch physically on (and it runs my auto brightness rule that is triggered only by physical switch)

I'm trying to figure out how to reproduce this beyond the "first time" every day so that I can dig into the logs, but before I go down that rabbit hole, I figured I'd check if anyone else had experienced this? Not sure if it's Driver or Hubitat related (I suspect Hubitat, since this previously worked fine, then they introduced a bug around physical switches, and now that the bug is "fixed" this is occurring)

Is this happening with my user driver (linked at the top of this thread), or the in-box driver?

If mine, I'll take a look when I get home. If the in-box, then submit a support ticket to Hubitat.

With your user driver from this thread, and I've replicated the behavior on multiple switches. I just can't figure out why it only happens once, and what the "timeout" is. I.e. it happened last night, and again this morning, so I thought maybe it was after a mode change.

I changed the mode manually back to night and then to day, and couldn't replicate it, so it appears unrelated to mode change, and either due to a timeout or a new calendar day (if I'm guessing at this point)

Edit: I've turned on debug logging for a couple of the switches, so I might have more information tomorrow after it occurs next.

Ok. I'll take a look. I so rarely use physical presses, I'm not sure I would have seen this even if it is a driver issue. I'll post back.

I managed to capture the behavior with the debug code on. Unless there's some kind of time out that is resetting something, it could be when my mode manager changes the mode based on time of day (since it didn't work manually?).

Just speculating...but what I see here, it looks like the debug logs show the same command being sent, so I'm thinking this is a bug on Hubitat's side. Would you agree? I'll open up a thread in the support forum if I'm not missing something.

This is the same as earlier: physical on, physical off, physical on, and it reports the first as digital.

I think you need to make a slight adjustment to how you are reporting the switch events. When you call the command "ON", you immediately set the switch state to on-digital, which is correct. When you just get a report from the device without having the switch already in that state, you can assume that the change was physical. Since it appears there is no report confirmation when the switch is set to on by the hub, the state.bin variable is not being reset to 0. So, the first physical change comes up as digital. Changing the two references to change type from newType to physical for the switch commands made everything report correctly for me. The newType is still applicable to level change commands and that seems to work and report correctly. I can do a pull request to show you the two changes if I've completely confused you.

It's strange but it seems that there is no z-wave report back for the digital switch change and there is for the digital level change.

Yeah... That is odd. I don't remember it working that way in past Hubitat releases... Weird. It is almost like it is grabbing the basic report and trashing it. Unless the device isn't actually sending it, but I thought it did...

Maybe it has always been that way though? I would have thought I, or someone else, would have noticed it before though.

[EDIT: See 2 posts below for the reason why it doesn't send a basic report on ON/OFF]

@mike.maxwell Did anything change on zwave basic report parsing in 2.1.5? I assume no, but have to ask.

nope...

Yeah, looks like I broke it in my 8/28 driver update. The issue is that different GE/Jasco firmware act differently.

Some device firmware versoins turn the device off with a setlevel=0 and some don't. So I changed ON/OFF code and reporting to work with the new firmware and broke the physical/digital reporting for everyone. I'll get it fixed.

The device doesn't do basic on/off reports, as it uses those for DoubleTap the way I have the associations setup. The device can do basic reports for ON/OFF, but then it makes DoubleTap event reporting goofy.

I uploaded v2.2 to github. I think it should fix the issue.

Sorry about that. :confused:

2 Likes

I also noticed that repeated double taps are no longer working with any of the drivers that supported it previously. Nothing shows up in debug logs either. It's like anything after the first double tap is also being ignored.

I'll take a look at that too. I definitely don't remember seeing that in testing, and I did test multiple doubletaps - but maybe I did doubletap up then doubletap down each time instead of two up or two down in my testing?

If the device isn't sending the report, probably not much that can be done on that. But I'll look!

Don't have an answer on that one.

On my devices repeated doubletaps are making events as expected. Just did 5 doubletap up in a row, all showed up.

Awesome! Is it expected behavior to encounter the error one last time? I updated the driver on Hubitat (and even rebooted), but my first on was still digital at the 5 switches I tried (3 before and 2 after rebooting...I try to be thorough :joy:)

For a sanity check, I just checked my double tap ups and had no issues with sending multiple in a row.

It wouldn't surprise me if you got the reporting discrepancy one more time until you toggle it again. If you keep getting it after that though, let me know