I'm a new convert from Vera to Habitat. I'm excluding/including all of my devices and I figured out that most of the switches in my house were being added with the wrong driver.
I have Leviton DZS15-1LZ switches throughout and it's adding them with type "Generic Z-Wave CentralScene Dimmer" rather than "Generic Z-Wave Switch".
Is there a way to change the default so I don't have to change the type on the rest of my switches?
Thanks,
--Chris
There's nothing you can do, as the platform picks the best-match driver on inclusion by using the "fingerprint," which for Z-Wave is normally the vendor and product ID plus the supported command classes.
However, if you want to prevent this for other users in the future by sharing some information that may help staff address that underlying issue:
In the meantime, you can always switch drivers manually, as it seems you know. It's usually a good idea to run the "Configure" command after you do so. Good luck!
I don't think so.
This has happened to me a few times over the years.
The include looks at the Z-Wave signature and decides what device is trying to connect.
My Leviton outlets had to be changed to Generic Z-Wave afterwards as well; I don't think Leviton has a broad range of specific drivers in HE.
If the system really can't make up it's mind you just get "Device".
Thanks for the quick feedback!
Leviton DZS15-1LZ
fingerprint mfr:"001D", prod:"0301", deviceId:"0334", inClusters:"0x25,0x27,0x2B,0x2C,0x85,0x72,0x86,0x91,0x77,0x73", outClusters:"0x82"
Switching it to Generic Z-Wave Switch seems to be working fine. Super excited to move to a supported platform and the performance difference is shocking!
--Chris
Tagging @bcopeland to see if he can look at the fingerprint for ths device/driver since it's Z-Wave (even though I'm pretty sure this fingerprint was added to the driver before his time 
).
I'm running into this issue as well. My GE Jasco in-wall switch keeps showing as a generic dual outlet (lists 2 component devices: Switch-1 and Switch-2). All of my other switched were included as the appropriate device type.
Hi,
I just take a chance to ask because its look related a little to the topic... I already added my inovelli plug with built in driver. It created the 2 child plug for the product. But I just found a better driver with more capability, so I just installed it and then I changed the type from the built in one to the new driver... The child plug not seems to be linked anymore... So I was wondering if its normal and if we could change driver like that on live devices? If not, is there a proper way to do it? Would I need to add the plug again?
Thanks!
I believe (and @bertabcd1234 will be able to correct me if I'm wrong) I was told that if you assign a different driver to the device after it's paired, the next time you pair the same device type HE will use that assigned driver...I could have sworn someone told me it would work that way, but memory is fleeting and full of gaps. 
Robert?
This question seems to have nothing to do with the device or driver in the original topic, so it may have been better to start a new one. (But don't now; once again, I suggest you only post your question in only one place. It seems you may be starting to again for the device in question based on posts I've read in the last few minutes. Besides being in line with the Community Guidelines, this will also be much easier for you to get help and other people to help since bits and pieces of information will not be scattered all over.)
That being said...
Changing a parent driver can have consequences for child devices, which typically use a driver that expect the parent driver to behave in a certain way. Same thing with swapping a child driver. Sometimes, you can find the right child driver and switch to it. Other times, something like a "Configure" or "Save Preferences" on the device detail page will create the necessary child devices for you. I'd suggest removing the child devices the original driver created -- after making sure they are not in use by any apps, of course -- and then trying one of these things to let your new driver create them on its own in the format it expects. (There is often more than just the driver that matters, typically also the DNI, but it depends on the driver and device.)
You might be thinking of Zigbee, where if you don't delete the device, it will use the currently selected (so possibly "new" in some sense, with respect to the initial pairing) driver. However, Z-Wave can't do this--it's not able to match up devices it already knows about based on a MAC address/long ID like Zigbee can. It only knows the node ID, which is assigned by the hub upon pairing (though maybe a Z-Wave Replace would work...I forget what commands, if any, it runs upon inclusion that way). The Inovelli device in question appears to be Z-Wave, from the other post.
thanks for reply! I will try to delete those child devices! The child device type cannot be changed, its grayed out and its generic switch component... The driver I installed seem to come with another driver that managed child devices... I dont know if the main driver will manage to use the child driver or if it will reuse the built in generic but I cannot change anything.
I use the child devices in webcore so it would be nice to add the new one without deleting the old. If I try to just paired the device, will it just recognize it and wont make the full install? or will it create a duplicate? If it would make a diplicate I could log to webcore and change the device with the new one before to delete...
Try letting the new driver create its own child devices with one of the above ideas. If they doesn't work, it might want to use the same DNIs your previous driver already used, and you'll have to remove them first or mahje change their DNIs to garbage temporarily to see if that helps.
You'll have to swap out the old and new child devices in all apps, including webCoRE pistons, manually. This may be easiest if they can both be on the hub at the same time, but temporarily using a virtual device you create instead can also work. You may have to do this if you want to get rid of the existing child devices, which appear to be stuck as "components" (not individually removable).
As mentioned above, you cannot "re-pair" Z-Wave devices in place, but even that shouldn't do something you can't already do somehow.
finally, with homekit desabled I could remove child and then rebuilt...then replace device in my piston...sounds good!
Thanks!
Download the Hubitat app
