Hello,
I recently tried an Edge driver for one of my zwave devices (iBlinds) and wanted to revert back to the DTH I was previously using for it. However when re-adding the device it keeps adding back using the Edge driver.
I have uninstalled the Edge driver from my hub, unenrolled from the beta channel, and rebooted the hub several times. I have also logged into the CLI (first time user) and uninstalled, and deleted the driver from there and CLI confirms no drivers found. Checking my hub in the app in the āDriversā section shows no channels or drivers present. Still when I re-add my device it re-adds using the Edge driver and if I go back to the āDriversā section in my hub the Edge driver reappears.
Is this a known issue or is there another process to revert back to DTH after trying an Edge driver? The Edge driver is missing functionality that I had with the DTH and I made the assumption that I could revert back after trying it. Apologies if this is incorrectly catagorized.
I donāt know anything about iBlinds but I can see three fingerprints for them in the production Z-Wave Window Treatment driver which seems a likely reason why you get the Edge driver.
ST seem pretty keen on parity with the DTHs. What have they missed?
Is your iblinds the version 2 or 3? The version 2 is notoriously problematic for using non-standard communication of state and battery data. There are community DTHās that did a good job of dealing with those problems. I doubt the standard Edge driver was programmed to handle the special logic needed for this one (now outdated) device.
Actually my iBlinds are v3.1 which I believe adds a few more parameters to the v3.
I tried the beta channel āZwave Window Treatmentā driver solely for local execution of routines and didnāt take into consideration that all params might not be available with that driver. Unfortunately one of those params was of particular importance and remapped āopenā state tilt level.
I figured I could just delete the driver and revert back to the DTH, but now whatever I do with reinclusion of the blinds they always come back with the Edge driver. My hub is a 2nd gen with .043 firmware and checking the blinds on the IDE obviously shows no network ID thus not allowing for change of device type back to DTH either.
As mentioned, I was curious if this might be a known issue or if others might be stuck in a similar predicament. Fairly frustrating not to be able to revert back to what I had before, and at this point, beta testing of Edge drivers seems to be just that: ābetaā and a bit half-bakedā¦ or could be just me I guess.
Yes, on my intial attempt to revert back I performed these steps in this order:
Deleted/Excluded the device through the SmartThings app
Deleted the Z-Wave Window Treatment driver from the Drivers section of my hub in the SmartThings app
Initiated Unenroll from the Beta Channel in the SmartThings app and completed unenroll from the subsequent page
Rebooted the hub
Initiated Inclusion/Add Device in the SmartThings app and performed pairing sequence on the device
The blinds added back but with the Edge driver.
After two more attempts of deleting the driver in the SmartThings app and rebooting hub and re-adding device, I read the usage details on CLI, logged in, and followed instructions on driver removal from there. CLI confirms āno drivers foundā
Re-added the blinds following the Inclusion/Add Device sequence in the SmartThings app and device adds back with Edge drivers. At this point I posted to the Community for assistance.
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
8
If you have a DTH installed with the correct fingerprints it should then pick up the DTH if there are no edge drivers found. Check if the DTH published and that it contains the correct fingerprints.
In response to RBoy:
Yes, that was my expectation but itās not picking it up. IDE shows the DTH listed and published. As far as fingerprinting Iām assuming whatās coded in the DTH, correctly corresponds to my device.
In response to orangebucket:
The DTH Iām using is linked from iBlinds support site,
Has the following in the header,
āV3.06+ - Added Parameters 7 - 11 - Chance H 6/11/21ā
and is hosted at:
Two thoughts,
I have 4 other iBlinds devices which are v3 which are using a previous DTH. With the v3.1 device I was directed to the above mentioned DTH by iBlinds because it supported a new parameter allowing for correct remapping of open state and instructed to add it as a custom DTH. With my 4 previous blinds no additional DTH was necessary and I used what was already existing in the SmartThings device repo.
Regardless of any of this, if the Edge driver is deleted from the hub shouldnāt it be āgoneā? Why would the device keep adding back with a driver thatās apparently been deleted? Is there a local or cloud ācacheā somewhere where it still needs to be cleared from?
Weird, and again, fairly frustrating.
Ah right, now I understand. I note that the updated version has the same metadata as the stock DTH so I wonder if that is now a source of confusion. Having a custom DTH with the same metadata as a stock DTH may have worked OK previously but it was never a good idea and now the stock DTH has been migrated to Edge it may be positively harmful.
I think SmartThings have done the best they can in migrating the DTH to Edge based on the latest version committed. Presumably there are reasons the later version has apparently not been committed.
Just to be clear, the stock DTH is basically past tense. Any devices currently using it will keep doing so but if you try and pair them again they will pick up the Edge driver.
It may be that tweaking the custom DTH by changing its name: slightly is enough to let the custom DTH be used.
That was the trick orangebucket, thank you!
I tweaked the name and the device added back with the DTH. I also changed the name back, updated, and everything still appears to be functioning as before.
As an end user this was quite frustrating. Along with a lack of ābackendā understanding, I probably didnāt inform myself enough with the whole Edge driver process or the current state of migration, but I was under the assumption that a device could be reverted back to DTH for now regardless of migration status. That doesnāt appear to be the case and is good to know going forward.
Oh wellā¦ On a side note, hopefully vendors can timely align with SmartThings during the transition but thatās probably asking too much.
Thanks for your assistance!
I am tagging @nayelyz from Developer Support here in case there is something to be learned here or she sees something the rest of us missed. It may also be that one of the reasons you got unlucky is that she didnāt see the thread first.
Nayely, the situation here is that a manufacturer has an āofficialā DTH in the ST repo, but also has an update to that DTH in circulation as a custom DTH. The stock DTH has been converted to Edge as part of the Z-Wave Window Treatment and the devices are fingerprinted in the default/production channel.
The end result seems to be that adding devices results in the Edge driver being installed and used despite there being the custom DTH in place.
Tweaking the name of the custom DTH seems to allow it to be picked up.
Yes, the device being paired with the production driver by default is expected (announcement for others reference).
Iām not sure why having a custom DTH with the same as the stock one would prevent its recognition but remember that in Groovy many things depended on the DTHs name (presentation, deviceType, etc.) so, a good practice is having different names for each version to avoid this kind of issue.
I will check with the team if thereās a special restriction about DTHs names but youāre right on track with this workaround.
So, is there a preference included in the stock DTH, the one published in the SmartThings Public repo that isnāt included in the driver?
Hi nayelyz,
Iām not sure I 100% understand your question but yes, I believe that driver is missing the following param described on iBlinds support site:
Param: 10
Name: Remap 99
Description:
Remap value 99 (ON) ā Some Z-Wave controllers send 0x63 (99), instead of 0XFF(255) for ON, and this causes the blind to tilt to the endpoint when we really want it to turn ON 50%
In my attempt to revert back to DTH, I also reset the device and the blinds would not recognize āopenā state as 50% and the Remap setting was no longer there with the Edge driver. So basically the blinds would tilt all the way up as āopenā state. Iām not sure what changed with their devices but I have four other iBlinds (v3) which did not require this Remap. Only my latest blind (v3.1) required this and it happened to be the one I tried the Edge driver on.
Iāll admit I had not read the announcement you linked which now gives me more insight on the driver migration process. Probably typical of an end user, but Iām of a set-it-and-forget-it mindset and this particular situation was quite the āpickleā
Appreciate the info and assistance.
Nayely, I do understand the question so Iāll clarify.
The stock DTH recognises the version 3 and 3.1 devices and handles five Z-Wave parameters (numbers 1 to 6 - I know that is six but one of the numbers isnāt used). As far as I can see all those are available in the driver. @theparkdude would have to say if they work properly but Iād like to think that as the devices have been added to the production channel they are believed by ST to be OK.
According to the iBlinds support site, later versions of the firmware for both the 3.0 and 3.1 devices have four more parameters, numbers 7 to 10. Those are not in the DTH in the ST repo, they are in an update from last November in the third party repo mentioned earlier in the thread (along with an additional parameter 11) and are the reason the custom DTH is still needed by @theparkdude for one of the devices.
ah ok, got it.
The migration is based on the original DTH as the devices included there were certified by the manufacturer. So, iBlinds should contact ST in case they want to add those parameters to the existing driver.
So, @theparkdude, I suggest you contact their support team so theyāre aware (in case they arenāt yet) of the requirement of the update of the official driver.
Now that I have a hind-sight view I realize exactly what happened. Good to know going forward as my home is well immersed in SmartThings with many other devices.
Thanks again to orangebucket for his excellent sleuthing, appreciate the effort!
First my apologies for my ignorance as a new ST convert from Wink. I want to use a custom device handler from RBoy for my GoControl (GC) Garage Opener (GD00Z-4). I have the handler published in the IDE and have been successful with their DHās for my Honeywell thermostat and Schlage Connect lock but the GoControl always gets added to my hub (Aeotec) under the Edge driver and not the custom DH. Since it is under the Edge platform I am unable to reassign the Type as there is no Device Network ID listed in IDE. Any guidance or help you could provide in getting the GC to add under DTH so I can use the RBoy DH would be greatly appreciated.