The issue is that with the v1 VersionReport response from the device everything gets set as null when parsed as Version v2.
v1 Version Report:
VersionReport(zWaveLibraryType:6, zWaveProtocolVersion:3, zWaveProtocolSubVersion:52, applicationVersion:2, applicationSubVersion:0)
v2 Version Report:
VersionReport(zWaveLibraryType:null, zWaveProtocolVersion:null, zWaveProtocolSubVersion:null, firmware0Version:null, firmware0SubVersion:null, hardwareVersion:null, firmwareTargets:null, targetVersions:)
I just updated the code to fix an error. Try downloading again from github and let me know. If this one doesn't work, I have another fix that might. Thanks.
Restart Hubitat twice after updating.
Not quite working yet... It appears you are getting firmwareVersion before commandClass versions, so the version is being parsed as v2 (default?).
(Feel free to take this to PM to avoid cluttering the thread.)
Some more fixes throughout the day. Update to driver version 6 and try again. I probably won't touch this much for the next week -- if you find any errors, post them on github please!
You should always restart after updating this driver -- and restart twice if you have many devices using the driver. It gathers a lot of data on first-start and on a driver version change (that data is stored for subsequent restarts, but gets reset on a driver version change) and sometimes during that data gathering it seems to overwhelm Hubitat and the Z-wave network (I'm working on fixing that, but since a double-restart tends to solve the issue, its not super high priority).
By restart - are you saying to reboot the hub twice?
Yes.
Hopefully, that won't be needed in the "final" release, but its needed in the beta just to be sure that all required data is gathered.
Dec. 22:
Dec. 23 - Known Bugs: Parameter changes are unreliable. Expect to fix that within the next few days.
Just FYI that I get this error on all GE/Jasco/Honeywell New Style Dimmers, even though a value is specified for parameter 19:
[dev:139](http://192.168.2.162/logs#dev139)2020-12-30 10:12:28.329 am [warn](http://192.168.2.162/device/edit/139)Device 4-Left Dimmer: Can't set parameter 19, Incomplete parameter list supplied... syntax: setParameter(parameterNumber,size,value), received: setParameter(19, 1, null).
Thanks! I've fixed a number of errors in the setting of parameters. Please be sure you're using the latest version. I just set this up on Hubitat Package Manager, so you should be able to get the latest using that. Or directly download from here: GitHub - jvmahon/HubitatCustom
I am using the one form 3 hours ago.
And thanks! Very interesting concept and driver.
Should this work for non-plus dimmers? I used to use the nuttytree driver back in my ST days and miss the ability to set the advanced parameters!
Ok, that's the latest. I may not get to that problem right away (I'm currently adding support for multiple endpoints, which is nearly complete -- it seems to work with my LZW36 fan controller, and I hope to expand it to others.).
Glad you find the concept interesting.
The idea here is I eventually plan to release this as a single consolidated and modular codebase which can be used for almost anything and which already accounts for the interactions between multiple capabilities (an whether they exist or not). I do this using a bit of .hasCapability and .hasAttribute testing, but not that much is really needed.
Not surprisingly, the hardest part of this driver is gathering "fixed" device capability information from the devices at initialization -- I'm hoping that in future Hubitat OS releases, more of this would be gathered by the Platform at device pairing (like is currently done for manufacturer ID, device type, product type), rather than leaving it to the driver during execution, but, for now, this is where the most work is! . Some of this I may address by including a way of adding predefined data in a map array which could then be used to reduce startup data gathering.
I indicated only "plus" since I don't have non-plus to test with, but it might work - give it a try - it may depend on how old the device is. Also, I don't include any polling in the driver, so I'm not sure about how it would know of updates when a change is made from the physical switch. I guess you would have to use the "polling" app.
No hurry at all. It isn't a big problem or anything. I just thought I would report it.
One other thought, on the device's web page, there should be a choice "Reset Driver State Data" click on this, then click "Initialize" then try to set your parameter. That may clear the problem. Or not. Still a work-in-progress. Or try changing the parameter, then changing it back.
Pending changes should never be a "null" value, so I'll look into why that may happen.
FYI - the "pending changes" description is intended to be there for battery operated devices which only update on a wake. For always-on, the updates should happen right away so this should have cleared.
Tried that, no difference. I didn't actually want to change that parameter anyway - so no big deal to me. I was just following the directions in the README and got the error when I hit save preferences.
What I see is that no matter what I select in the drop down for that parameter I get the error when clicking save preferences.
Again - no big deal to me. Just wanted to report it.
Very helpful to know that this is in a drop-down. I didn't notice that the first time and it may help me get this fixed. I don't have that particular device, but at least I know to check that the drop-downs in my devices are working. As an aside, for any other errors, please report on my github page if you can (that way, I don't forget them).
No problem at all. I can, and will! 
I tried the switch version of this driver on my HS WS200+ switch and got some errors. Hope this helps in the debug process...
Oops - I see I put a testing version out for distribution.
I have some WS200 switches and I don't think I've seen that error, but I'll look in more detail.
Download the Hubitat app
