[ST EDGE] Zooz Edge Driver Channel


i just edited my previous post it is all routines in the Then section.

That makes sense, as I did not have this issue this morning on the first Zen16

1 Like

@nayelyz is this a known bug with the new version of the iOS app?

I just fired up an old Pixel and was able to edit the routines, so it is confirmed to be an iOS issue.


I haven’t switches my zen72’s over yet so haven’t tested. Can anyone tell me if there is dimming association before I manuallyove them?

I have 2 zen72 switches on a 3 way set up (1 only has power) so they are associated but it only has on/off association, not dimming.

The ZEN72 driver supports association group 2 (on/off) and group 3 (dimming)


I’m hoping to have the ZEN17 driver completed by tomorrow morning, but I figured it would probably be a good idea to post my implementation plan ahead of time in case anyone has suggestions or throws a wrench into my plan…

When the S1 and S2 Input Type Settings are set to Momentary, Toggle (any), Toggle (up/down), or Garage Door:

  • The driver will display the main switch on the dashboard and just the 3 switches (main/R1/R2) on the device details screen.

  • It will have the “Dashboard View” setting that allows you to see the Large tile on the dashboard with all 3 switches.

  • I’ve already finished this part of the driver.

  • It’s basically the same implementation as the ZEN16.

When the S1 or S2 Input Type setting is set to any of the other options (motion, contact, water, etc.):

  • The look/behavior will be the same as above, except there will also be a tile for each input (S1/S2)

  • The S1 and S2 tiles will be a custom capability that displays the Input Type and its value (Contact Closed, Motion Active, Water Wet, etc.). If only one of the input types is set to a sensor value then the other S# tile will show something like “N/A”.

  • The driver will support all of the capabilities that are available as input types (Motion Sensor, Contact Sensor, etc.), but only the selected input type’s corresponding capability will change with the state of the input. The other capabilities will always be set to their inactive state. (inactive, closed, dry, etc.)

  • Since the S1 and S2 tiles on the device details screen show the type of sensor and its value the actual capabilities won’t be shown there.

  • When selecting the device in a Routine you’ll see all of those capabilities.

  • I don’t plan on including the “Heat”, “CO”, or “CO2” input types, but I can easily add them later if requested.

  • The manual says you need to remove the device and join it again after changing the input type settings, which might still be required, but I won’t know for sure until I start testing that part of the driver…

1 Like

I had to re-add ZSE40 sensor 4 times. 1st Time no Motion and Lux report. 2nd time no Motion, Temp and Lux. 3rd time No battery report. The last time all the attributes reporting.

FYI. This sensor is running 17.09.and after I included the device the iOS app show a security warning.

Thanx for the hard work . Hope this info is useful.

I know some had issues with the on/off option missing in iOS and they should have reported it to Customer Support but I don’t have any more info.
I will ask about this, it seems it’s only affecting multicomponent devices…

1 Like

I like the style of the DTH for what it’s worth.

I’m running into some really inconsistent behavior with the new driver and my ZEN25 double plugs, which I’ve had installed and running the custom DTH for about 8 months now.

To test, I added the Zooz Multichannel Switch Edge driver to my hub. Next, I uninstalled all ZEN25 devices (via Z-wave exclusion) and removed the custom DTH in Graph. Once the DTH was gone, I reinstalled devices one by one to pick up the new Edge driver. After testing with the Edge driver, I uninstalled the devices again, removed the Edge driver from my hub, and then reinstalled the devices to pick up the standard (pre-Edge) SmartThings driver, which gives me a pair of devices (one Z-Wave Multi Metering Switch and one Child Metering Switch).

The device seems to install fine using the Edge driver, and it initially looks like it is working. However, after a while, it starts to become intermittently unresponsive. The usual symptom is that one outlet or the other stops responding for a bit and then eventually works again. Sometimes, if I’m executing a scene that is supposed to turn on or turn off both sides, only one or the other will actually change state.

I’ve also gotten into a situation several times where if I turn off both sides, neither will come back on via a scene until I go into the device panel and manually turn on the main on first. (I’ve tried to fix that in scenes by always turning on the main whenever I turn on either side, but that doesn’t seem to help in general.) The intermittent behavior plus the fact that I’ve reproduced this thing with the state of the main makes me wonder whether the problem is somehow related to order of operations.

These outlets have historically been reliable on the old custom DTH, and were also reliable after I fell back to the standard SmartThings driver, so it seems like the new Edge driver is somehow implicated in the instability. What can I do to help debug this?

Short answer, disable the metering reports to see if that solves the problem as a temporary solution and the next version I release will have a couple of minor changes which should solve the problem…

The hub kept dropping reports every time the main switch was used to control the ZEN20 and ZEN16 because too many messages were sent too close together which left some of outlets/relays showing the wrong state.

I had to include a workaround in the driver that checks the state of all the outlets/relays a few seconds after the main switch is used to control them and request a report for any that might be out of sync.

I just noticed that my ZEN25 driver used the hardware default value for the Power Reporting Frequency setting, which is 30 seconds, but my DTH used 5 minutes and the built-in driver uses 10 so I’m pretty sure that’s causing the problem.

I’ve never used scenes, but if they check the state of the switch and only send the on/off command if needed then a switch being in the wrong state would appear unresponsive until you performed an action that causes the state to get refreshed.

I know that Routines always send the on/off command so I’d be interested to see if you experience the same unresponsiveness if you used routines instead of scenes.

I’ll include that workaround for the ZEN25 and increase that setting’s default value in the next version, but I suspect your problem will go away if you disable all the metering reports you’re not using or at least change their frequency to reduce the number of messages.

FYI, the hardware automatically turns on both relays when you control it with the main switch so using the main switch and an outlet in the same scene or automation could make the syncing problems worse…

I also just noticed that the built-in driver doesn’t support the main endpoint which is another reason why the on/off reports aren’t getting dropped…


Was going to post a reply to kpronovici but you literally confirmed my theory. I have two Zen25’s which one of them was basically oversaturating my Z-Wave network and causing timeouts on all Z-Wave devices. My Z-Wave network came back to life when I unplugged the sucker. For now I’ve just upped the frequency which seems to have resolved the issue. .

Also just wanted to mention that it looks like one of my Zen25’s is missing the option to turn off reporting which is the last option in settings. (I have the one that has this setting uninstalled right now which I forget the exact name) plus there’s some “Untitled” labels on random numbers which I’m guessing one of them is to notate the firmware version. Unsure if I’m the only one seeing this.

Edit - Just installed the plug I mentioned above. The setting that’s missing is in fact the “Disable Reports” option.

That setting was added in the 2.0 firmware so if your device has a lower firmware version then you won’t see it.

I added the translation workaround for those custom capabilities and I thought I reloaded all the presentations so you shouldn’t be seeing any “untitled” labels.

If you’re using the iOS app then maybe they broke the workaround, but it’s possible I forgot to load the presentation so I just did that again.

I was thinking the same thing too. I registered my plugs the other day to obtain the firmware and the ZST10 usb stick will be in tomorrow.

You make a good point which I didn’t think about checking out my other phone which I have access to both an iPhone (work phone) and an Android phone. For me, it looks like the labels are not set on my Android while the iPhone is showing the proper labels. Reinstalled the SmartThings app on the Android with no luck. (dunno if that would effect anything but did it just in case)



Edit: Last post from me: Looks like the labels have reverted to the proper titles magically on my android and now I have more routines I can run against. Not sure if you did anything but I thank you for doing what you do.

Short answer, disable the metering reports to see if that solves the problem as a temporary solution and the next version I release will have a couple of minor changes which should solve the problem…

I disabled reports entirely (I’m not using them right now anyway) and that made a large difference in stability. It’s much more reliable now and there was only one time when a lamp did not go on when I expected it to. When I have a few minutes, I’ll upgrade the other outlets and confirm a similar improvement there.

I do have a few routines (triggered through an Aoetec Wallmote switch), but not for this particular outlet that I tested this morning. I’ll try that out once I convert the other outlets.

I’ve now migrated a few other of my ZEN25. Unlike the first one I migrated, these two are on V1 of the firmware, so I couldn’t disable reporting entirely. Instead, I disabled the wattage reporting threshold (set to 0) and set the reporting frequency to 600 for everything.

Behavior is much better than it was originally, but still intermittent. Sometimes, it works fine to turn on and off an outlet repeatedly (10+ times), waiting just long enough for the state to be reflected in the lamp before toggling. Other times, the request to change state seems to get lost and I need to make 1-2 other attempts before it takes effect. Rarely, a lost event seems to suddenly take effect a long time later.

I’ve tested from within the device panel itself, from a scene that turns one or several outlets on or off (triggered from the app), and also from my Aeotec Wallmote Quad, which I’m using to trigger a toggle event for an individual outlet. (I don’t have any other way to trigger a routine right now.) Behavior seems to be pretty consistent no matter which mechanism I am using. It’s just as likely that I’ll get a failure from within the device panel as when using the Wallmote switch or when executing a scene.

When testing in the device panel in the app, I have sometimes gotten a toast telling me about a network connectivity problem, around the same time I’ve experienced a failure. However, it only happens some of the time, and it’s not clear from the error whether it’s a wifi problem or a device network problem.

The Z-Wave network currently contains 3 ZEN25 outlets, 5 ZSE11 sensors (on battery), and 3 Wallmote switches (on battery). The battery devices should be pretty quiet in general. Z-Wave network repair doesn’t report any problems.

If there’s anything else I can do to help debug this behavior, let me know and I’ll dig in. The net result is now roughly as good as I had on the old custom DTH, but I’d like to help iron out some of the remaining wrinkles, if possible.

How far apart are the ZEN25s and how far are they from the hub?

Do most of your scenes/automations control more than 1 of those devices and/or both outlets together?

I added that check feature to the ZEN25 driver so the next release should solve the problem of the state not getting updated. The state not getting updated will cause those network errors your seeing. Unless they recently fixed an issue with the mobile app you’ll also see those errors if you drag down on the device details screen.

The ZEN17 driver is kicking my butt, but I hope to have it posted by late tonight…

1 Like

So I think I found a little glitch with the Zen 51 stock groovy device handler that I hope can be fixed with the Edge driver.

When the load control for the switch and Z-Wave are both turned off and it loses power it will shut off power to the load when power is restored. To get power back to the load you have to go in the settings and turn back on control to the switch and manually turn the load back on then disable the switch again.

If the device is ignoring the “On/Off Status After Power Failure” setting and not turning the load back on then that’s a firmware bug that can’t be fixed within the DTH or Driver…

It will still report on off status from the physical switch to the hub but the physical power to the load it is wired to will be off. I set Power status after power failure to, forced on. This did not effect the physical load. To restore power to the physical load you will have to enable the switch and manually turn it back on.

If this is a firmware issue I guess I’ll have to report it to Zooz. Unfortunately I don’t think you can update firmware through SmartThings.