[ST EDGE] Zooz Edge Driver Channel

I am a newbie to all of this. I purchased all of my Zooz devices from TheSmartestHouse. I am mostly concerned with the ZEN23 switches. My first question is are the DHT’s referenced on the pages for the specific devices on TheSmartestHouse website considered to be Built In or Custom.
My second question is once I installed the switches and they worked, I never went back to check for updated drivers. Should I perform this task before the cutover?
I also purchased double relay switches(modules) from them, but, they are not Zooz so I will need to do further on them. Any input would be greatly appreciated. Most of my house is wired ZEN23 switches and my whole family is used to 'Alexa, turn on … Light! :grin:

The short answer is don’t do anything.

SmartThings will automatically migrate the device to the built-in Zwave Switch driver without losing any of the settings you changed when you originally installed it.

1 Like

Kevin, thank you for the quick response. Much appreciated.

After a few tries at exclude/reinclude my ZEN25 double outlet (Firmware 1.0), it came up with a “placeholder” device handler. I named it “ZEN25.” I was able to add “leftOutlet” (the only one I presently use) as a target device for a ZEN32 controller button, an Aeotec Minimote button, and as a target device for a few SmartLighting automations. The ZEN32 and Aeotec work great. This is all terrific, fully functional, great…

But there’s no unique name access to each outlet - I can’t figure out how to use Google Assistant to control them. If I try to use Google Assistant for the parent name, the device stops responding to any commands for a little while. Google Assistant “can’t help with ZEN25 Left Outlet.”

In the SmartThings Android app I have to select the device and find the correct side (“Left Outlet”) to control. Can “Left Outlet” become an editable, published name (e.g. “Tiffany Lamp”)? Can app on/off buttons be added for the left and right sides, like the Groovy setup?

Thanks very much!

(My SmartThings V2 hub is enrolled in Channel and Drivers Web UI )

Lack of access via voice integrations is a known issue with sub devices. Not sure how quickly it’ll be addressed but supposedly they’re working on it.

1 Like

As of now the only way to use both outlets with voice assistants is to create virtual switches.
Mariano has an awesome mirror device driver that requires 2 routines per switch to sync. There are other community created virtual edge drivers that show as contact sensors and work with Alexa routines as well. Just search “virtual edge”.

Thanks very much for these suggestions.
The bigger problem is that after just a few minutes the device goes offline and stays offline. I can bring it back only by unplugging it / plugging it in. While it’s offline it doesn’t respond to button presses…

Hi All,

Any update on getting the Z15 added to the Edge Driver?
It is the last DTH I currently have running .

2 Likes

Not sure if this will help but you could try excluding and re-including the device. Sometimes the drivers don’t add/configure properly.

Will zen34 support association to a dimmer like I see the old handler supports?

Just adding to the questions, any chance there will be Edge drivers for Zen 21 Ver 4.0 and
Zen 22 Ver 4.0?

Looking for a Zen31 driver. Zooz RGBW Dimmer. Any plans on creating this?

Any plans for the Zooz XS Tilt | Shock Sensor ZSE43?

2 Likes

To make sure I understand, some conflicting comments…

I have the official Zooz groovy DTH for my Zen 77 & Zen 30….

I don’t want to lose settings, so all I need to do is install the edge drivers to hub now & on 9/30 ST will automatically convert it for me?

1 Like

Sorry everyone for being MIA for a while. I had some life related stuff I had to deal with, but that’s over now so I’ll be able to dedicate my time to working on drivers for the remaining Zooz devices.

4 Likes

If the physical button on the device stops working and you haven’t disabled them through the settings then that sounds like a hardware problem because I don’t see how a driver could cause that to happen.

That being, @Terri_Baker suggestion of removing the device and joining it again is worth trying, but if that doesn’t work then you should contact Zooz support.

1 Like

I don’t have an ETA, but it’s on the list.

I originally wasn’t including that in my drivers because without the IDE there’s no way for the end user to get the device’s Device Network ID.

All my recent drivers that can be controlled through associations are display it on the device details screen using a custom capability so once I’ve finished creating drivers for their devices I plan on adding support for associations to the ZEN32, ZEN34, and probably some of the other drivers.

At some point they probably will be supported, but they’re at the bottom of the list because they’re already officially supported by the built-in drivers and as long as you let SmartThings migrate those devices instead of doing it yourself ahead of time you won’t lose any of the setting changes you made while using the custom DTH.

Zooz hasn’t mentioned that device so I’m not sure if it will be getting a driver, but I think someone created a custom driver for the Fibaro RGBW controller so try searching the forum for that.

I think there might be a few differences with the settings, but that device is close enough to the ZEN32 where it should be functional with that driver.

If someone knows of the driver I’m referring to then feel free to post the creator’s handle which will make it easier to find, but please DON’T POST THE LINK.

Yes, those are near the top of the list.

1 Like

Are they any faster now? When I used the custom DTH it would delay lights turning on and off by almost a few seconds. Using them as a generic z-wave switch immediately sped things up.

If a custom driver is installed with a matching fingerprint then ST is supposed to assign it during the migration and if there isn’t one then it will assign it a built-in driver with a matching fingerprint, but if it doesn’t find a driver with a matching fingerprint then it will assign a driver based on the supported command classes.

That’s how it’s supposed to work, but if SmartThings screws up and it assigns a built-in driver with an exact fingerprint match instead of a custom driver then you can easily change it to the custom driver after the migration.

Unfortunately if you’re using the custom features/capabilities of a custom Groovy DTH in Routines/Automations and the migration assigns it the wrong driver then there’s a chance those will break/disappear, but hopefully ST won’t botch the migration.

This is where things get messy with the automatic migration for devices using custom DTHs…

All Devices without a Driver (ZEN21, ZEN22, etc.):

  • WON’T LOSE custom settings, but you won’t be able to change them going forward.

  • Routines/Automations using custom capabilities or capabilities not supported by the built-in driver it gets assigned WILL BREAK

Simple Devices with custom Drivers (ZEN76, ZEN77, ZSE41, etc) that get installed before the device is automatically migrated:

  • WILL LOSE custom settings, but you can easily go into the settings and change them.

  • Routines/Automations using custom feature WON’T BREAK

Multichannel Devices and other devices that use child devices (ZEN30, ZEN32, etc.) and have a custom driver that gets installed before the device is automatically migrated:

  • WILL LOSE custom settings, but you can easily go into the settings and change them.

  • Routines/Automations that use the child devices created by the custom handler WILL BREAK.

  • It might be a lot easier (less frustrating) to manually remove and add these devices ahead of time instead of letting them get migrated automatically.

1 Like

I’m pretty sure the z-wave switch Groovy DTH supported local execution and that wasn’t possible for custom DTHs which might explain the slowness you were seeing.

Most, if not all, of my switch/dimmer drivers use the built-in handlers for the on/off/setLevel commands so the behavior and performance should be identical to the built-in drivers.

Routines/Automations that execute locally are almost always faster with drivers than with DTH, but they sometimes respond slower than DTHs when controlling them from the mobile app. At least that’s the behavior I’ve been seeing…