I have two Red series VZW31-SN (v. 1.04) switches running in dimmer mode on Hubitat (C8-pro).
Hubitat is running the latest ZwaveJS (not Zwave legacy)
Driver: Inovelli Dimmer 2-in-1 Red Series VZW31-SN (2024-10-22)
The issue is that the devices are reporting a brightness of 255 whenever the switch is triggered ON.
I've tried changing the "14. Default Level (Remote)" parameter, but this does not resolve the issue. Currently, it is set to '99'.
Any suggestions?
I only have a C-8 so I'm not running ZwaveJS. I see I can pick your same driver for my LZW31-SNs, but mine are currently set to using the Inovelli Dimmer Red Series LZW31-SN driver. (When I opened the dropdown mine was right below yours). I have no idea if the driver you are using was designed for ZwaveJS or not. So proceed at your own risk, but you may want to try the other LZW31-SN driver that I am using.
It is the latest official driver available on Inovelli.
I don’t doubt it. I was only mentioning that I have a bunch of those and I’m using the other driver with no issue just in case you want to try that.
What exactly is the 'other' driver and where do I find it?
Mine just says: Inovelli Dimmer Red Series LZW31-SN
I haven’t added anything since the big UI overhaul but you used to be able to type into a driver search field. If that is still there start typing that in and see if it comes up. In my driver drop-down mine is right below the one you are using now.
I don't see it, and from doing a bit of searching I don't think the older LZW driver is compatible with the newer VZW series.
Probably isn’t. If yours is a 2 in 1 then it is a newer one.
I see the same behavior, with the same setup (zwavejs, c8+pro) I also see the additional rub of when commanded digitally to turn on every other time it will report back as being OFF after going on for 1/2 second or so. The light remains on even though hubitat shows off.
Issue both the dim level reporting as 255, and the toggling back to off only happen when interacting with lights though hubitat not at physical switch.
This behavior is consistent between 2 different c8-pro hubs with zwavejs running on them.
This is a pretty lame work around, but what one can do is use the "Generic Z-Wave Plus Dimmer" driver. This fixes these gremlins though you lose access to a bunch of what makes inovelli switches great.
UPDATE:
Even the generic driver has this issue, however unlike the innovelli one it quickly correct to the correct value:
level 17 9/21/2025 8:16:17.468 pm
switch on 9/21/2025 8:16:17.111 pm
level 255 9/21/2025 8:16:17.110 pm
The 1/2s delay before switch reports off is caused by the innovelli's "short delay" between sending commands. When I change the "short delay" from 500ms to larger values, the false reporting of "off" is also delayed.
def on() {
if (infoEnable) log.info "${device.displayName} on()"
state.lastCommandSent = "on()"
state.lastCommandTime = nowFormatted()
def cmds = []
cmds += zwave.basicV2.basicSet(value: 0xFF)
cmds += zwave.basicV2.basicGet()
if (debugEnable) log.debug "${device.displayName} on $cmds"
return delayBetween(cmds.collect{ secureCmd(it) }, shortDelay)
}
This leads me to believe something is wrong with the basic get and basic set in ZWaveJS, as 0xFF is 255, which should map to 100%.
Here is the logs, with the short delay set to 5 seconds.
dev:13872025-09-21 08:50:18.450 PMdebugLoft track lights long wall on [BasicSet(value:255), BasicGet()]
dev:13872025-09-21 08:50:18.564 PMdebugParsed {"cc":32,"cmd":3,"ep":0,"values":[{"commandClass":32,"commandClassName":"Basic","endpoint":0,"newValue":255,"prevValue":0,"property":"targetValue","propertyName":"targetValue"}]} to BasicReport(value:0, targetValue:255, duration:0)
dev:13872025-09-21 08:50:19.935 PMdebugParsed {"cc":133,"cmd":3,"ep":0,"values":[{"request":{"args":[4],"command":"endpoint.invoke_cc_api","commandClass":133,"endpoint":0,"messageId":"expected8175","methodName":"getGroup","nodeId":162},"response":{"maxNodes":10,"nodeIds":[]}}]} to AssociationReport(groupingIdentifier: 4, maxNodesSupported: 10, reportsToFollow: 0, nodeId: [])
dev:13872025-09-21 08:50:21.587 PMdebugParsed {"cc":38,"cmd":3,"ep":0,"values":[{"commandClass":38,"commandClassName":"Multilevel Switch","endpoint":0,"newValue":99,"prevValue":0,"property":"currentValue","propertyName":"currentValue"}]} to SwitchMultilevelReport(value: 99, targetValue: null, duration: null)
dev:13872025-09-21 08:50:23.617 PMdebugParsed {"cc":32,"cmd":3,"ep":0,"values":[{"commandClass":32,"commandClassName":"Basic","endpoint":0,"newValue":255,"prevValue":255,"property":"targetValue","propertyName":"targetValue"},{"commandClass":32,"commandClassName":"Basic","endpoint":0,"newValue":99,"prevValue":0,"property":"currentValue","propertyName":"currentValue"}]} to BasicReport(value:99, targetValue:255, duration:0)
The inovelli driver uses its dimmerEvents method to parse messages from the switch. Taking the above logs We get the following 3 events
0 seconds BasicReport(value:0, targetValue:255, duration:0) // Results in On, with a level of 255
3 seconds SwitchMultilevelReport(value: 99, targetValue: null, duration: null) // Results in Off with a level of unchanged (255)
5 seconds BasicReport(value:99, targetValue:255, duration:0) // Results in On with a level of 255
private dimmerEvents(hubitat.zwave.Command cmd, type="physical") {
def value = (cmd.targetValue ? "on" : "off")
def result = [sendEvent(name: "switch", value: value, type: type)]
if (cmd.targetValue) {
result += sendEvent(name: "level", value: cmd.targetValue, unit: "%", type: type)
}
return result
}
What hub platform version are you running? Check Settings > Hub Details to see. (There are lots of Z-Wave JS fixes coming up in 2.4.3 if you are not currently in the beta, though I don't know if this is related.)
I am on: 2.4.2.160 I should be able to patch the inovelli driver to work around these issue, but that seems like a poor long term choice as these seem like platform issues.
Yes, the ideal thing would be for no driver changes to be necessary (well, except for ones that weren't using the documented classes, which these are). I'd see if 2.4.3 happens to fix it if you feel like trying again after release, which will probably be soon, then it can be looked at by staff if needed after that -- though, of course, any workarounds you find for now would certainly work, too!
Here is my updated driver which works arounds these issues. Likely has the side effect of delaying light status update longer than it should, since the targetValue cannot be used to reliably predict where the light is going.
Also includes work around for start/stop dimming issue in zwavejs gateway.
2.4.3.122 released and installed today. Issues with 255 is fixed, but switch status remains all sorts of messed switch reporting off when it is on, and start/stop level change remains broken with inovelli drivers.
I have updated my driver to work around 2.4.3's flavor of bugs. It appears the BIG issue at the moment is cmd.targetValue is ONLY being populated once the switch hits steady state. It is no longer null some times, but it is basically still useless for predicting the state the switch is driving towards.
Going from On->Off is particularly problematic as the inovelli driver does a basic get. Since we can't rely on the targetValue to contain anything useful this basic gives us a value which is positive, since the dimmer is in most cases still ramping down towards 0.
The on case is less of a problem the basic get gives us a value which is no 0 almost instantly because no matter how slow your ramp ups are the first step always results in a non-zero value.
TLDR: Updated my driver to work around 2.4.3
Sorry for being late to this party, I am looking for a workaround to this issue to implement into the driver. Is the root cause that Hubitat Z-Wave js isn't parsing target value correctly?
I see this in the hub logs:
dev:12025-10-07 03:30:54.508 PM
debug
Parsed {"cc":32,"cmd":3,"ep":0,"values":[{"commandClass":32,"commandClassName":"Basic","endpoint":0,"newValue":75,"prevValue":75,"property":"currentValue","propertyName":"currentValue","value":75}]} to BasicReport(value:75, targetValue:0, duration:0)
But in the zniffer packet I see this:
Checking
I know what it is.. Will get a fix out
Fix will be in the next build .134 or higher.. 133 was already built and about to be public.
Start/stop level change are also broken btw.
I am still seeing some BasicReport "targetValue" being read as 0. It seems when the switch is turning on from a BasicSet command and two BasicReports come in around the same time. The first one has a targetValue of 33, but the logging shows it as 0.
dev:102025-10-16 04:06:40.162 PMdebugBASIC TARGET VALUE --------------------------------------> 0
dev:102025-10-16 04:06:40.160 PMinfoInovelli Dimmer 2-in-1 Red Series VZW31-SN Basic Report: value on (27)
dev:102025-10-16 04:06:40.158 PMtraceInovelli Dimmer 2-in-1 Red Series VZW31-SN zwaveEvent(BasicReport(value:27, targetValue:0, duration:0))
dev:102025-10-16 04:06:40.156 PMdebugParsed {"cc":32,"cmd":3,"ep":0,"values":[{"commandClass":32,"commandClassName":"Basic","endpoint":0,"newValue":27,"prevValue":7,"property":"currentValue","propertyName":"currentValue","value":27}]} to BasicReport(value:27, targetValue:0, duration:0)
