nayelyz
(OOO - Please contact @AlejandroPadilla or @Ivan_Luis_Falleau)
2176
Hi, @Diegocampy
Drivers in the beta channel and the default channel have the same configuration, so, there’s not a problem if you have the beta one, the date changes based on when it was packaged, not if there were changes in the code.
Also, something important to consider about LAN drivers is that they don’t support driver switching because, during the discovery and onboarding of the device, there is some info collected and saved in the data store which isn’t transferred among drivers for security reasons. Hue is a great example of this. The driver stores the API key from the Link Button process in the driver’s datastore.
So, if you were using the driver in beta and then changed to the one in “default”, it could have caused issues.
Thanks for the reply. No, honestly I did the opposite, I had the default drive, but I wasn’t sure the hue devices worked with that, so I tried changing it . After the change it didn’t work anymore. Then I reinstalled the drive and the beta overwrote the default. If as you say it’s not a problem, I’ll keep the beta drive
They may not support it (and it makes sense that they don’t), but the UI still allows it, at least on Android. It would be good if this ability was removed from the UIs.
2 Likes
nayelyz
(OOO - Please contact @AlejandroPadilla or @Ivan_Luis_Falleau)
2179
I understand, I will open a report to see what the team can do about it.
Nobody As I said in this message I changed to do some tests, I didn’t have problem now.
I reinstalled the drive manually and now I have beta instead of stable, but that shouldn’t change, everything works
As a belated follow up, the API does expose the routing for Zigbee and Z-Wave devices, but I’ve only encountered it for the legacy DTH devices. So that isn’t terribly helpful. Especially when you only have one.
Install @Mariano_Colmenarejo “ZigBee Thing Mc” driver and temporarily switch your device to that driver and it will show your clusters when you open the device tile.
To Search for specific drivers, check the quick browse lists in the community – created wiki. they are divided by device class, so there’s one for sensors.
Thanks. I had taken a look at the Wiki, and even commented in that thread you linked previously. I thought I would ask some of the other users who have these sensors as well what they have ended up doing.
Is there a better place for this question than this thread where the user has previously discussed them? I like the idea of the combined thread for zwave driver requests, but the requests there go unanswered and get buried sometimes.
The Request threads are to make it easy for the community developers who are voluntarily creating custom edge drivers. Looking through it, I would say that over 90% of the requests have been answered, although once in a while the answer is that it’s a challenging device, and no one seems to be working on a driver for it.
Other alternatives are:
write to smartthings support and ask them what to do, although, if it’s an older device, they’ll probably just tell you it’s not supported
check the author thread for the old DTH that the device was using and see if there are any recent comments about what people are doing with it. Again, sometimes the responses that no one‘s found an alternative yet.
I wish there was a better answer, but I don’t have one. From the beginning, smartthings has put its own proprietary architecture layer over the top of the independent third-party standards, so there have always been some devices which worked with other Z wave hubs but don’t work with smartthings. As an engineer, I find that really annoying, but it is what it is.
I see a pull request has been created to put the ‘synthetic events’ back in the stock drivers. Those are the ones that initialise the device attributes with non-null values which in turn keeps the mobile apps happy. They presumably were removed because they would have fired during automatic migration, but the trade-off was they were not there in fresh device installations, hence the mobile apps stomping their little feet about not having the device status and refusing to do anything, while the rest of the SmartThings tools wondered what the fuss was.
Anyway that seems to be a significant milestone being reached.
Would appreciate the support of the HKZW-DWS01. I have a lot of them in use that worked perfectly up until the Edge migration.
The sensors all pair fine but go offline after a few hours. Once I open/close them, they come back online, but continue to go offline once a few hours have passed.
Thank you!
I’m not sure if they are supportable on Edge. Other smart home platforms have mentioned that they ignore changes to their wakeup period, which is set to 24hrs or something pretty long.
I don’t have one to test with. If someone wants to send me one I can see what I can do.
Thanks for the info! The wake-up default appears to be only when the magnet moves away from the sensor, which is consistent with the behavior I’m experiencing.
Let me know how to send a sensor to you. Appreciate your insights and willingness to assist!
