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

⚙️ Custom Apps and Drivers
74

Just getting started with Hubitat, and moving my GE Dimmer switches over from SmartThings. I am using is driver because I need the double-tap functionality, as well. Try as I will, try as I might, i cannot get OFF to work. OFF simply does nothing when pressed from the devices screen. ON works, Set level works. OFF Does not. What might I be doing wrong??

[dev:85]2019-08-24 01:32:29.239 pm [debug]Parse returned null for zw device: 21, command: 2603, payload: 00 , isMulticast: false

[dev:85]2019-08-24 01:32:29.236 pm [info]M B Center Light was turned off [digital]

[dev:85]2019-08-24 01:32:29.224 pm [debug]---SwitchMultilevelReport V3--- M B Center Light sent SwitchMultilevelReport(value:0)

[dev:85]2019-08-24 01:32:29.221 pm [debug]cmd: SwitchMultilevelReport(value:0)

[dev:85]2019-08-24 01:32:29.214 pm [debug]parse() >> zwave.parse(zw device: 21, command: 2603, payload: 00 , isMulticast: false)

[dev:85]2019-08-24 01:32:26.030 pm [debug]setLevel(value, duration) >> value: 0, duration: 0, delay: 3000

[dev:85]2019-08-24 01:32:26.026 pm [debug]setLevel(0, 0)

[dev:85]2019-08-24 01:32:26.021 pm [debug]Turn device OFF

[dev:85]2019-08-24 01:32:20.531 pm [debug]Parse returned null for zw device: 21, command: 2603, payload: 63 , isMulticast: false

[dev:85]2019-08-24 01:32:20.521 pm [info]M B Center Light is 99%

[dev:85]2019-08-24 01:32:20.515 pm [debug]---SwitchMultilevelReport V3--- M B Center Light sent SwitchMultilevelReport(value:99)

[dev:85]2019-08-24 01:32:20.512 pm [debug]cmd: SwitchMultilevelReport(value:99)

[dev:85]2019-08-24 01:32:20.497 pm [debug]parse() >> zwave.parse(zw device: 21, command: 2603, payload: 63 , isMulticast: false)

[dev:85]2019-08-24 01:32:19.289 pm [debug]setLevel(value, duration) >> value: 99, duration: 0, delay: 1000

[dev:85]2019-08-24 01:32:19.286 pm [debug]setLevel(99, 0)

[dev:85]2019-08-24 01:32:19.283 pm [debug]state.level is 99

[dev:85]2019-08-24 01:32:19.278 pm [debug]Turn device ON

75

I use this driver on 30+ dimmers, and they work fine on all of mine. See my suggestions in the other thread - maybe it is some weird 1st time initialization issue.

If you are getting the report back from the device, like the device shows, then it received the off command. So no clue why it is not shutting off.

76

First, Thanks for your work to create and maintain these drivers for the Jasco products!

I switched to this driver today for a 14294 GE branded dimmer that I've had since late 2017. Everything seems to work as expected, except for one unusual thing... I see doubletap being passed in the logs for the lower paddle, but not for the upper paddle?

When I doubletap down, I get:

[dev:71]2019-08-24 18:05:58.391 [debug]Parse returned [[name:doubleTapped, value:2, descriptionText:Bedroom Light had Doubletap down (button 2) [physical], type:physical, isStateChange:true]]

[dev:71]2019-08-24 18:05:58.387 [info]Bedroom Light had Doubletap down (button 2) [physical]

[dev:71]2019-08-24 18:05:58.384 [debug]Double Down Triggered

[dev:71]2019-08-24 18:05:58.381 [debug]---BASIC SET V1--- Bedroom Light sent BasicSet(value:0)

[dev:71]2019-08-24 18:05:58.377 [debug]cmd: BasicSet(value:0)

[dev:71]2019-08-24 18:05:58.369 [debug]parse() >> zwave.parse(zw device: 04, command: 2001, payload: 00 , isMulticast: false)

--- Live Log Started, waiting for events ---

When I doubletap up, I get nothing - even with debug logging enabled.

Not a show stopper for me, but I was wondering if this was an issue that anyone else had encountered? Any ideas for how to troubleshoot it?

I did send configure() and then eventually refresh() after changing the driver for this device. (Un)fortunately, this is the only one of this particular device in my network, so I can't compare to see if this is a problem specific to this one device.

One other odd thing. Although singletap up turned the light on 100% and singletap down ramped back off as usual, I couldn't get "on" from the device page to do anything until I set level to 100% on the device page. Seems like that was a one-time deal that needed to be set...

77

Don't know. I re-tested and both doubletap up and down are reporting events on my GE 14294 dimmers. Also tested both ON and OFF, both worked fine on my devices.

Maybe you have a zwave mesh issue and some of the commands aren't actually making it to/from the device?

78

As a carryover from a discussion in another thread... To make OFF work correctly on newer firmware devices when using the v2.0.0 of this driver:

  1. Comment out line 299 ( setLevel(0, 0)).

Add two new lines below it:

  1. sendEvent(name: "switch", value: "off", descriptionText: "$device.displayName was turned off [digital]", type: "digital", isStateChange: true)

  2. delayBetween ([zwave.basicV1.basicSet(value: 0x00).format(), zwave.basicV1.basicGet().format()], 1000)

This has a couple of goofy side effects on reporting, so I should take a few minutes and do this properly. I should have time over the 3 day weekend.

Let me know if the above does not work though. Works fine on my devices - just tested it.

79

OK I made the change....

Definitely fixed the issue, which lets me move forward.

The other thing that would be a reason to do both on and off with basic commands, is the switch should fade on and off, not jump directly to it, which is what setLevel does. We could possibly make this a preference in the driver, in case someone prefers the jumping/immediate on/off.

Thanks for your help --- this definitely lets me move forward, and I will be happy to help/program/test as needed.

80

Yeah, I used to do it with basic commands, and there was a specific reason I changed it. It was to work around some weird quirk in the Jasco/GE firmware... For the life of me I can't remember exactly what the reason was now though... I want to say it had something to do with doubletap... But whatever.

81

OK, new version posted (FYI @bjlled ) . I only did limited testing, but it worked as expected for me, including the reporting.

  • 2.1.0 (08/28/2019) - Changed ON and OFF commands back to using basicSet instead of multilevelset
82

Hi JasonJoel
Is the double tap feature a hardware dependant feature or implemented on you driver?

I would like to ask you (or the others of course) if there is any way to implement that feature on a GE/Jasco Zigbee Dimmer (45857)?

Modifying your driver can be possible? sorry maybe a dummy question

83

Double tap as implemented on these devices requires both hardware support and driver support.

EDIT: I have no idea if the zigbee version supports double tap. I only maintain drivers for the zwave versions. Sorry, I can't help you here.

84

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.

85

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 ?

86

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.

87

Awesome !! Thank you for the FYI.

88

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)
    36%20AM
    Screen Shot 2019-10-15 at 10.49.36 AM.png1264×322 33.1 KB

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)

89

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.

90

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.

91

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.

92

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.

05%20PM
Screen Shot 2019-10-15 at 6.35.05 PM.png1596×984 280 KB

93

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.