Leviton Driver / Fingerprint not matching

I am developing a driver for the Leviton Z Wave Smart Dimmers, to have access to all their Z Wave parameters and I have verified the fingerprint, but when adding new devices, it always seems to default to "Generic Z-Wave Smart Dimmer" and not my new driver.. I have to manually select it from the list after its added...

fingerprint mfr: "001D", prod: "3201", model: "0001", deviceJoinName: "Leviton Decora Z-Wave Plus Dimmer DZ6HD"

Any idea on what I might be doing wrong?

I don’t believe your doing anything wrong, the hub is also going to default to the built in driver. You always have to manually select custom drivers.

1 Like

Yeah, that's not our fingerprint format.
Replace your driver with the driver Device, open live logging and hit get info. The correct fingerprint will be printed out.

Hubitat will choose a user driver over a system driver given the same fingerprints.


ok perfect, sounds good! i have implemented all the zwave parameters of this dimmer, just have association groups left and hail.

since hail is a deprecated command and the official zwave docs are really slim on this patented command, i am really unsure how my driver should react to the hail command. should i just be refreshing the device status when I receive a hail command? anybody know?

Unless you need it in some way, and you shouldn't really, then just ignore it.

If I recall correctly, this device responds to any change in state with a "hail". So the only way to track a physical change in state is to look for a hail.

Looking at the command classes for this device on the z-wave alliance device page seems to bear this out -- hail is the only "controlled command" i.e. a command issued by the device. All others are "supported commands" i.e. commands which the device can receive and act upon.

(I may be completely wrong about this, in which case I'm sure someone will correct me :slight_smile: )

Actually I'm curious how the Hubitat built-in driver for this device distinguishes between a logical and a physical state change, given that the device responds with the same hail command in both cases.

1 Like

I'm not a developer, but if you search these forums you will see that there are a few different ports of this driver for HE:

(Search for 'jasonxh')

The drivers work, but could use some polish IMO. I'd really like to see the start/stop level change functions of the generic dimmers added.

In general I use a state variable for this, a digital command sets it to a specific value, it gets reset when send event is called.
When the frames come in I check the value of this.

I would be interested to test this driver out when you are done. With the stock smart driver, I get about a dozen log entries saying the device was turned off physically after the device was turned off digitally. I've reported this to support and they said they were looking into it but I haven't heard anything back even when asking if there was anything to update yet.

Sure, I'll create a github repo this weekend and post the link here to what I have. Been using it for a few days now, and I don't use association groups, so working well for me. Hopefully I get to the association group stuff next week.


no association group support yet, i dont use it, so unsure what i will add support for it.

@joe.roback I tried it and it mostly works. There seem to be some status update issues.

  1. if controlled from the physical dimmer the status on the Hubitat device page does not update without pushing 'Refresh' on the device page,
  2. changes to configuration parameters get successfully sent to the dimmer, but the Hubitat driver doesn't recognize them even when pushing 'Refresh'. Example: set Preset Light Level, save preferences. The 'On' command when controlled from Hubitat device page turns on to the previous Preset Light Level. Turning on from the physical dimmer turns on to the new level. And then after that the Hubitat device page turns the dimmer on to the proper level too.

Thanks for putting this together.

Can I ask what firmware you have on the leviton, all 20 of my dimmers are 1.20, though I did at times experience weird behavior which seem to come from the device ...

Not sure how much more I will invest in this, as I not too happy with the levitons and looking to replace with HomeSeer or Inovelli dimmers.

Mine are all 1.20. I really like the Levitons as they highly configurable and fairly closely match Lutron Maestro dimmers. What don't you like about them?

The other thing I'd like to do is to be able to set the Preset Level as a custom action. So that I could use Rule Machine to set the 'on' level based on time of day. For that I think the driver has to have that setting as a Command rather than a Preference. Not sure if that is possible.

while i love the separate dimmer on the leviton, i have tried out Zooz ZEN27, HomeSeer WD200+, and now the new Inovelli Red Dimmer.. What I thought was weird behavior in Home Assistant, SmartThings, and Hubitat with Leviton, after writing this driver, I realize it seems like the Leviton firmware is garbage. It seems to wedge itself it you send it commands too fast, etc.. The Zooz and HomeSeer do not seem to ever miss a beat. Testing the Inovelli soon.

Also the homeseer having 2/3/4/5 taps in both up/down direction being programmable is super nice.

Even using the stock 'Generic Z-Wave Smart Dimmer' driver? I've never had a problem with it even as it does not give access to all the Leviton configuration parameters (which is why I'm interested in your driver).

yea, i think the levitons work for me nearly all the time, but when they dont its frustrating. The HomeSeer has been 100% flawless on all 3 platforms, Home Assistant, SmartThings, and Hubitat.

As far as the generic zwave dimmer, same for me, works nearly all the time, but since it does not do anything with any zwave parameters, it send a lot less zwave commands, which is where I think the leviton firmware breaks down vs zooz or homeseer.

I did also seem to see a difference with changing the driver vs adding the device new. Not sure if hubitat has some stale state or something, their developer documentation is basically non-existent and closed-source, which all of this is based off looking at other drivers and then experimentation. :thinking: