They are using the the ZemiSmart Zigbee Blind driver.
Unfortunately, they all get found as a zigbee valve and I have to change the driver over and restart the Hubitat for them to work properly.
This is fine, however it took me the first blind motor to work this out. This first blind I added now has a mix mash of blind and valve drivers with some parts missing like the ability to "Invert position reporting" and the hubitat refuses to let go of this no mater how many times I add it and delete it.
Is there a way to completely delete a zigbee device from the db so the Hubitat can not use the old info when you reset a previously connected zigbee device and repair it to the hubitat?
Edit:
Would changing the zigbee id and network id in the current device info, then reset the blind motor and re-add it make it be identified as a completely new device? Then delet the old entry after it is added as a new device work?
Just use temporary the HE inbuilt driver named 'Device' to clean up the states and whatever else has remained from the wrongly detected previous driver. Then change back to the Zemismart Blind driver.
I will add the fingerprint to the next Zemismart driver version so that it is selected automatically when paired as a new device.
Modifying the Zigbee and network IDs may mess up things, better to avoid changing these ids.
If you are changing any of the Zemismart default Preference settings, please let me know so that I set the working settings by default as well.
Update : while you are using temporarily the 'Device' driver for cleaning up the state variables, please also click on the "Get Info" button and copy/paste the fingerprint generated in the live logs.
Saving it as Device then going back to the ZemiSmart driver and restarting the Hubitat has removed the valve dirver left overs but the Show Advanced options * still fails to load. When you click the tab to "on" and save just goes back to off. This hasn't happened on any of the other same blinds.
PMinfofingerprint profileId:"0104", endpointId:"01", inClusters:"0000,0004,0005,EF00", outClusters:"0019,000A", model:"TS0601", manufacturer:"_TZE200_nv6nxo0c"
PMtraceZCL version:03
PMtraceSoftware Build Id:unknown
PMtraceModel:TS0601
PMtraceManufacturer:_TZE200_nv6nxo0c
PMdebuggetting info for unknown Zigbee device...
Yeah. But I noticed it still seems to think it is also a valve.
comment : Works with Tuya TS0001 TS0011 TS011F TS0601 shutoff valves; Tuya, GiEX, Saswell, Lidl irrigation valves
I might be able to fix it by deleting the valve driver and then repair the blind and it should only find the blind driver then reinstal the valve driver. I might be able to put all my irrigation valves as device first. Then back to valve after re-adding the driver.
Putting the valves to Device and deleting the Tuya zigbee valve driver, deleting the blinds and then re-pairing them (with the valve driver deleted) worked all found as a ZemiSmart Zigbee blind and all working properly. Then re-added the zigbee valve driver and changed the valves back to valve.
This is hubitat finding your Tuya zigbee valve driver instead of the ZemiSmart Blind driver when they are both installed.
This happens sometimes, or no driver is found. You can just do as he said, change the driver to Device, use the commands to delete all the states and attributes. Then change to the correct driver and run configure. Sometimes you have to reset and pair the device again depending on the driver.
I have had to do this once before but with Moes zigbee light switches. They found the wrong driver and would not function correctly even with the driver changed until I deleted them and the offending driver then reinstalled them before reinstalling the driver that was causing the issues.
I didn't try adding the fingerprint to the driver. I have one more blind motor to add which I haven't done yet so I might add the fingerprint and see if that fixes the issue.
Next time just change the device entry to the correct driver, then reset the device (do not delete it from HE). Then pair the device again. It will do a fresh pair and configure but using the same device entry already created with the driver you set it to. If it is changing the driver back by itself when pairing again, that is not how its supposed to work.
That does not work and the first thing I tried. It might work if the fingerprint is added to the driver but I haven't tried that yet. I have 2 more motors to add and have edited the driver but not joined these last 2 motors yet.
The fingerprint only matters for initial automatic driver selection. Once you change the driver manually, you should be able to just run a configure to fix it. With Zigbee though sometimes an incorrect driver will make some bad configs that are hard to undo, so at that point you need to factory reset the device (do not remove anything from HE) and then pair it again. Since the device is already in HE and the driver was manually set, it should not change back to the other incorrect driver, it will onboard and configure with the driver you set it to. At this point this is no different than if the driver was selected correctly at pairing. The other driver is no longer in play at all.
This happens commonly with zigbee devices (especially those supported with custom drivers), and that process is always the solution.
You should never have to delete some other random driver that is not even in play anymore to make a device work. What if it was selecting a system driver by default, you cannot delete those?
You can do your little rain dance if you want, but I am just trying to explain the correct way to handle it.
Sadly "should" and "does" are not the same. As you can see from the Hubitat comment ,
comment : Works with Tuya TS0001 TS0011 TS011F TS0601 shutoff valves; Tuya, GiEX, Saswell, Lidl irrigation valves
even after changing the driver to "Device" then back to the correct driver did not fix the problem. While it worked it still retained some of the properties of the incorrect driver even after a restart.
The only thing that fixed the problem was removing the offending valve driver and then readding the blind motor. Then it found the correct driver and was fine.
I have now added the correct finger print to the blind driver so hopefully the next blind motor I add will just find the correct driver from the start.
That is a state variable and would not be causing any problems with the functionality of the device. All you have to do is change to the "Device" driver and use the command button to clear the states, then change back to the correct driver.
