You can just copy and replace the driver that is currently there. Or you can click on the import button. Or, if you use Hubitat Package Manager you can just do an update.
There really isn't that much of a difference between the updated driver and the one that wouldn't work on the C-7.
If the device was included as S2 then you don't need to exclude it. Switching between the built in driver and the Inovelli driver shouldn't give you any issues. When you switch to ours you probably want to check that all of the preferences are how you want them and then hit "Save Preferences".
Hope you don't mind that I'm not Eric , bu you can just overwrite the current driver code with the new driver code (you can manually copy and paste if you want, but the "Import" button at the top should grab it right from Inovelli's GitHub because they specified an importUrl in their driver). The new driver adds S2 support for C-7 users but does not take away anything for C-5 and older users or S0 or non-secure pairings; they will continue to work as before.
To re-pair with security, however, you will have to exclude and re-pair the device. (And remember, the best practice is to remove the device from all apps/rules it's in use by before removing.)
I paired a Red Series Dimmer last night in S2 but I still had to use the hub shutdown and unplug procedure that @bcopeland documented earlier in the thread. Was this fix supposed to fix the “stuck on initializing” problem as well or just address S2 pairing? Thanks!
I think this was not aimed at the pairing bug, which occurs outside the context of the device driver.
Separately, I'm curious how you were able to include a device affected by the bug with S2. All of my affected devices have only been paired without security.
To test just now, I excluded one LZW31-SN that was affected, factory reset it, and rebooted the hub. Then I tried to include it. I got the grants menu and selected S2C0 and S2C1. At this point it got stuck in initializing and I never got any DSK confirmation. I rebooted the hub and discovered the switch in Z-Wave Details. As I expected, it was included without any security grants.
I don't believe I've successfully paired an impacted S2 device with S2 grants, can you walk me though how you accomplished it?
As @datavortex mentioned the driver is out of the scope of the pairing bug. I believe that will be resolved by the Hubitat team and maybe the Z-wave alliance. I'm sure they will get it sorted out.
To be honest, I'm not 100% sure that it paired in S2. I figured that if I checked the S2,1 and S2,0 and left S0 unchecked and it paired that it was in S2. I'm far from "knowing what I'm doing." However, when i was pairing with everything unchecked, the DNI would be named as 1,2,3,etc. whereas now when I checked the S2s only, the DNI comes out in the format 0A, 0B, 0C, etc. Strangely, I did have an easier time pairing the red series dimmers versus the red series switch.
S2 inclusion will use the highest security of those available to the device and as modified by the user.
Note that you can't add/check a security class that wasn't initially offered by the device.
These are shown in descending security order in the popup.
Class 1 and 2 offer the same level of encryption, a device may offer 1 or 2, but not both.
A device that was attempted to include with security will include an zwaveSecurePairingComplete entry in the data section with a value of true or false.
If the value is false it means the security key exchange wasn't successful and the device will need to be excluded/reset and included again.
I do see zwaveSecurePairingComplete as true for the Inovelli switches that I paired with S2. Do you have an insight as to why some S2 devices have DNI as hex and others as decimal data type?
Also, what do the numbers mean for the "S2" in the device data section?
I've never seen this, a screen shot of one would be helpful.
This value is parsed as a bit map and contains the security classes that were granted to the device.
It's used internally by the driver/hub to determine which level of security encapsulation to use for outbound payloads...
Not at all.. Ignorance and stupid are 2 completely different things.. We are all ignorant on subjects until we learn them. In case you are interested in the reasoning:
Hexadecimal is a clean way to transform binary into an easy to read format. 0-F is every combination of 4 bits.. So 8 bits (1 byte) is easily represented by 00-FF
With ghost nodes issue, I found that patience is key. I didn't try to remove them myself, just ran Zwave repair everyday. And after a couple days, all the ghost nodes cleared by themselves
, bu you can just overwrite the current driver code with the new driver code (you can manually copy and paste if you want, but the "Import" button at the top should grab it right from Inovelli's GitHub because they specified an 
