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

Thanks. I'm curious, what's the difference between switch binding and mirror? They seem to be doing the same thing.

I liked associations because it's instantaneous and there's never a case of the hub being bugged down. Oh well...

Mirror only goes one way. Changes in the master will be directed to the slave. Switch bindings is bi-directional. Either of the dimmers can change and the other will match. There are time-outs and whatnot built in to catch that only one device acts as the master at a time. How close you can get to instantaneous will depend on how quickly everything reports back to the hub. Since z-wave plus dimmers don't report back until either the level change is complete or any configured fade-out/in time is complete, you will most likely see a lag between the two. For example, if you brighten one of the two by holding down the upper paddle, until you release it, the dimmer won't report it's level change to the hub so the hub won't know what you're doing. What is your exact use-case for this? Are you trying to create a virtual 3-way or something? Or are you syncing lights in two rooms? If you have two circuits of lights in a single room, then that is really bad wiring. If they ever share a gang-box, you could loop them into one circuit and then replace one of the two switches with a button controller.

1 Like

@JasonJoel, is the verdict that this is not a problem with either platform update 2.1.7 or your driver but, by elimination, probably with my individual system?

I didn't go through my GE switches and dimmers and click "configure" on all of them after updating to 2.1.7—I hit "configure" on one of them to try to restore the associations after all of them stopped working. After you mentioned that "configure" may wipe out associations, I went back to that one switch and tried deleting the associations, hitting "Save Preferences", adding back the associations, and hitting "Save Preferences" again. Still not working. Thanks for your thoughts…

I understand the unrelated concern raised by @mike.maxwell and others about associated devices not reporting their updated statuses to the hub. I haven't found this concern to apply in my case in the past—my past experience has been that all of my particular associated devices have reported their updated statuses to the hub.

None of the system drivers remove any existing association groups.

I don't know what the issue is. But I 110% believe Mike. If he says that the built in drivers don't remove associations, they don't.

Without some actual error it is really tough to figure out the issue. I'll keep thinking on it, though.

I tested associations on my driver with 3 different devices today, on the current HE release (2.1.7.121), and they worked fine. :man_shrugging:

Thanks, Jason. Could be an issue with my devices, I suppose. For my GE switches/dimmers, my associated devices include several Aeotec Smart Switch 6s (system driver), several Aeotec RGBW bulb 6s (system driver), several GE switches/dimmers (your driver), one or two Zooz ZEN15 plug-in switches (system driver), a Leviton Decora plug-in dimmer ("Generic Z-Wave Smart Dimmer" system driver), and a Leviton Vizia in-wall ELV dimmer ("Generic Z-Wave Dimmer" system driver). Before I updated to 2.1.7, all of these associations worked flawlessly with your driver for the controlling GE switches/dimmers.

I'll probably just end up replacing the associations with RM rules. My aversion to that is just that I feel like it's an unnecessary burden on the hub, given that Z-Wave provides a solution at the edge :slight_smile:

EDIT: I'm in v2.3.0 of your driver; I turned on logging and tried changing/setting the association group 2 on one of my dimmers, but I noticed that the "---ASSOCIATION REPORT V2---" from line 175 of your driver never appeared in the logs. I dug in a little more, and I noticed that, in some places, you are using associationV2 commands, while other places use associationV1 commands. Is this the intention?

I did recently (before updating to 2.1.7) update to a newer version of your driver, but it's possible (I don't recall) that I never checked the association groups after updating your driver and before updating the platform to 2.1.7. Possible that the updated driver broke something before I updated to platform 2.1.7 without my noticing.

Yeah... I should change those couple of v1 to v2, but it works either way.

I did all of my testing yesterday on v2.3.0 of my driver, and added/removed things from assoc group 3... I didn't try anything in group 2, but it should work too (same code as group 3, just with a 2 :slight_smile: ).

I also noticed that I wouldn't always get an association report when adding/removing associations - even though the devices were added/removed. Probably need to make a tweak in the code there... I would have thought 500ms is enough delay, but when it comes to associations they are pretty slow as there is some checking it has to do before adding a node to the list - so maybe it just isn't getting done quickly enough.

EDIT: I made those changes. New driver is on github - not sure that it will change anything in your case though @hans.andersson .

Another thought is that you could use associations, and then make RM rules to refresh the downstream devices. Would be easier than making an app.

The downside is you would have to make the rule, and manually add the devices you want to refresh in there, but it may be a compromise to keep the super fast association behavior (and hub independence for that association behavior), but get the downstream device status correct in hubitat.

The rule would basically be:
trigger: the appropriate master device state change (on/off?)
action: device 1 refresh, device 2 refresh, etc.

Thanks, @JasonJoel. The changes are at least getting me an association report in the logs that matches my expectation: Your driver seems to be correctly setting the associations on the devices. So I am back to my hypothesis that something in platform update 2.1.7 broke all of my associations for an unknown reason.

Of note: I have all toggle switches. Are you testing on the paddle switches with the LED lights? The firmware may be different on those devices.

Again, all associations worked fine for me before platform update 2.1.7.

Well, I have to agree that something to do with Z-wave changed unexpectedly in 2.1.7 since my Aeotec Doorbell 6 just stopped logging button presses in Hubitat. So I have rolled back to 2.1.6 for now and everything is working fine. The only definitive way to know for sure if that's the problem is to roll-back to the previous version and check it out.

I only have paddle style now. In my previous house I used the toggle, but didn't keep any for testing.

Thanks, @Ryan780. I will try that. Are any settings or other data lost when rolling back to a prior platform version? I have never attempted this.

I suppose the question could also be framed as:

  • When rolling back the platform, I assume the database is not also automatically rolled back (unless I choose to restore a prior version of the database), correct?
  • Assuming I'm correct on the above, if I do roll back to 2.1.6, do I also have to roll back the database manually to one that was active when I was on platform version 2.1.6? Or can I keep my current database?

The above may be questions better answered by @mike.maxwell.

correct

No

Thanks, @mike.maxwell.

@Ryan780 and @JasonJoel, I have rolled back, unset my association group 2, and set my association group 2; the association report is confirming the changes from the device, but the associated devices are still not doing anything. I'm going to revisit the hypothesis that the problem is coming from a change in the driver and look more deeply into what changed in the driver when I updated it sometime before updating the platform to 2.1.7.

EDIT: I have tried using an earlier version of the driver on platform version 2.1.6.118 and 2.1.6.113, unsetting the associations, and resetting them, but still not working. This is a real mystery to me, as I had probably half a dozen of these GE switches and dimmers working with associations just a few days ago… I'm just going to assume that the associations are irreversibly broken at this point. The upside is that I no longer have any need for the custom driver and can go back to the system drivers for my GE switches and dimmers, though the associations were nice while they lasted! Thanks, all, for your time and thoughts.

1 Like

Thanks. Will probably do that although I wonder if refreshing is also putting load on the hub. I definitely still prefer the super fast association behaviour. Coming to Hubitat, I actually thought the local execution would mean speeds like the association speed but I'm finding the speed to be more similar to ST (a bit faster). Maybe it's because I had fast internet that ST's speed hardly ever seemed so slow.

I'm using it in 2 use-cases:

  1. 3-way between 2 switches (1 GE and 1 Inovelli) with the GE connected to the load and the Inovelli controlling the GE (and thus, the lights) via associations. Both on = LED on, both off = LED off.
  2. For zone lighting e.g. I have 3 different KItchen switches (about 10 LEDs). Single tap on each switch turns the corresponding LED on/off. Double tap on either of the switches turns all the switches on/off.

In both instances, I could go through the hub but I like the fast speed of associations especially in case 1 where I want the light to switch on immediately after the Inovelli up paddle is pressed.

The second, the double tapping, can be handled within hubitat and get you results just as fast as the z-wave association would. Or at least close enough where you won't tell the difference. You can use rule machine to assign the button double press to whatever action you want.

For the first, like I said, hubitat isn't going to work for that. The dimmer won't report the level until it reaches it's final point. So, if you held down the paddle on the inovelli, it isn't going to report it's final level until you release the paddle and that;s when hubitat would change the GE. I would swap out your inovelli with a button controller rather than a dimmer. That will get you the button functionality you want.

Just curious, how would a button controller help here in a way the Inovelli can't? I already have the option of disabling the relay on the Inovelli (making it a button controller in essence) and it can send a held and release event to the hub. I'm more concerned with the speed.

Sorry, I got the posts crossed.....thought you were the guy with Z-wave association issues. If you're using the inovelli as a button controller, you weren't associating it with the GE in the first place.

The other guy was trying to control one GE from the other. Your solution wouldn't be available to him since you can't do that with the GE dimmer.

Your Inovelli IS a button controller now instead of a dimmer.

With the Inovelli Association Groups, that's not actually the case. There are 2 different association groups for dimming. The 1st sends an event after releasing the button to set a level which is similar to what you're describing. The 2nd sends a startLevelChange upon holding of the button and a stopLevelChange upon releasing the button. This works great with dimming my GE switch. The issue is in both cases, Hubitat doesn't recognize the GE change if I associate the GE directly to the Inovelli. The Inovelli can also send the held and released events to the HE hub but the HE hub can't actually send startLevelChange and stopLevelChange commands to this GE dimmer using this device driver so live dimming would still not be possible with a button controller going via the hub.