ZooZ ZEN21 Turns Off After 1 Hour

I have a particular Zooz ZEN21 v4 switch that turns off exactly 1 hour after being turned on. I have checked everywhere that I can to see if there’s a rule or automation in place to cause this and there is nothing I can find. In addition, I’ve updated the firmware on the device, unpaired, re-paired, factory defaulted the switch, and re-paired again and still the same thing happens where the switch will turn off after 1 hour on it’s own.

Is there anything I’m missing that could be causing this?

Whatever handler you’re using with it might be changing the auto off configuration parameter so try the custom handler.

The auto on/off settings will probably already show that they’re disabled so you might have to change one of the other settings to force the the sync code to execute.


I’m actually using your handler. I’ve gone in and manually toggled it to disabled and will see how it goes. I hope it fixes it, but I’m not too confident as I don’t have this issue on any of the other ZEN21s that I have with the same handler on default settings.

@krlaframboise I actually have another ZEN21 that’s doing the same thing as well. This one is more annoying since it’s a light that actually usually needs to stay on all the time. I’m starting to wonder if there’s something in the device handler that is causing this as that light switch has no automations on it at all. I even tried to switch to the default Z-Wave Switch handler, but no luck - I think because it was initially paired with your controller and picked up the parameters maybe?

Any help would be appreciated.

EDIT: Adding some screenshots…

Zooz site says that Parameter 3 should be set to 0 however it doesn’t show up as one of the parameters in Smartthings even though I changed one of the settings to force a sync like you said to try:

That handler was published over a year ago and this is the first time I’ve heard this complaint so it’s not the handler…

Open live logging, change both of those auto on/off settings to 1 minute in the mobile app, exit settings, wait 30 seconds, go back into the settings and disable them.

If that doesn’t work then post the live logging results.

@krlaframboise I wasn’t trying to blame your handler at all, I know you do great work with all the Zooz and other handlers. So, sorry if you thought that.

I think I might have figured it out though. Based on my last screenshot of what Smartthings is showing for the parameters, I went in and hit the Edit button on the IDE and completely erased configParam4’s value from 0 to “blank.” This resolved the issue on the light that kept turning itself off after exactly 1 hour.

Now as far as why having 0 in that value is still turning off the light after 1 hour…I have no idea. Not sure if it’s a Smartthings issue, firmware issue, or something else, but erasing that value did fix it.

1 Like

Sorry, there have been a lot of random issues with my handlers lately and I spent the entire day yesterday fighting with a driver so I was just a bit frustrated…

I guess it’s possible that my handler is causing the problem if ST recently changed anything related to the way setting defaults are handled which would explain why it wasn’t an issue in the past.

Did you try the steps I included in my last email?

Changing the settings from the IDE will mess things up and when you make a change to a setting in the mobile app there’s a delay before it syncs so after changing that value to something other than disabled you have to wait for it to sync before changing it back.

Param #3 and param #5 won’t show in the IDE because their not settings. The handler changes those behind the scenes depending on whether the auto on/off settings shown in the mobile app are set to disabled or a number. If you have live logging open you’ll be able to see whether or not it changed those parameters.

The problem is that the default on the device should be disabled and the handler won’t touch that param unless it changes so if it’s out of sync and you change it to enabled then it will be able to set it back to 0 when you change the setting back to disabled.

Being able to see the live logging results during inclusion if that doesn’t work would make it much easier for me to troubleshoot the problem…

@krlaframboise So you were right, I thought I had it fixed by manually changing those params in the IDE but the problem is back again for whatever reason even though I haven’t changed any settings since then. Here’s the output from the live logging pasted below.

To make sense of the logs, I first changed the handler from the default Z-wave Switch to your handler and then made the change to the settings as you suggested by waiting 30 seconds in between and backing out of the settings page.

I like to keep the device on the default Z-wave Switch handler since it processes local and takes remote presses a little quicker. Normally, I’d change back to the default Z-wave Switch handler, but in the interest of troubleshooting I’ve left your handler on the switch. I’m not sure if maybe this is the cause of my issues, but in any case the logs are pasted below.

 8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:53:11 PM: debug Auto Turn-Off Timer Enabled(#3) = 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:53:08 PM: debug Changing Auto Turn-Off Timer Enabled(#3) from 1 to 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:52:59 PM: debug updated()...
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:52:39 PM: debug refresh()...
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:51:21 PM: debug Auto Turn-Off Timer(#4) = 15
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:51:16 PM: debug Auto Turn-Off Timer Enabled(#3) = 1
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:51:13 PM: debug Changing Auto Turn-Off Timer(#4) from null to 15
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:51:13 PM: debug Changing Auto Turn-Off Timer Enabled(#3) from 0 to 1
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:51:06 PM: debug updated()...
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:56 PM: debug switch is on
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:55 PM: debug refresh()...
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:51 PM: debug Relay Behavior(#13) = 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:46 PM: debug Relay Control(#11) = 1
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:41 PM: debug 3-Way Switch Type(#12) = 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:36 PM: debug Scene Control(#9) = 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:32 PM: debug Behavior After Power Outage(#8) = 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:26 PM: debug Auto Turn-On Timer Enabled(#5) = 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:21 PM: debug Auto Turn-Off Timer Enabled(#3) = 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:16 PM: debug LED Indicator(#2) = 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:11 PM: debug Paddle Orientation(#1) = 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:06 PM: debug Lifeline Association: [1]
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:01 PM: debug updated()...
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:01 PM: debug Changing Relay Behavior(#13) from 0 to 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:01 PM: debug Changing Relay Control(#11) from 1 to 1
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:01 PM: debug Changing 3-Way Switch Type(#12) from 0 to 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:01 PM: debug Changing Scene Control(#9) from 0 to 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:01 PM: debug Changing Behavior After Power Outage(#8) from 0 to 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:01 PM: debug Changing Auto Turn-On Timer Enabled(#5) from 0 to 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:01 PM: debug Changing Auto Turn-Off Timer Enabled(#3) from 0 to 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:01 PM: debug Changing LED Indicator(#2) from 0 to 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:01 PM: debug Changing Paddle Orientation(#1) from 0 to 0
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:01 PM: debug configure()...
8747c1e4-7ced-4d0c-ace8-b209fcc7ce4e 9:50:01 PM: debug installed()... 

@krlaframboise I know you are probably busy, but did you get a chance to check this out? I followed your steps for changing a setting and then changing it back, but this particular switch is still turning off after 1 hour. It’s in a family member’s room and they are not as patient or understanding as me and they are starting to get annoyed. I’m hoping you might be able to figure out what’s going on so I don’t have to swap out the light switch.

EDIT: I also kept this switch using your handler the entire time, so switching handlers shouldn’t be part of the problem if it was one.


If you look at the top 2 lines you’ll see that the handler sent a command to the device to change parameter #3 to 0 and the device sent back a report confirming that the value = 0.

If it’s still turning off after an hour then either something changed that parameter back to 1 after you closed live logging or the device is ignoring that value.

If you change line 349 to below, save/publish, open live logging, and then swipe down on the device details screen in the mobile app it should request the value of parameter #3 and the logs will show if it’s still set to 0.

sendCommands([switchBinaryGetCmd(), configGetCmd(autoOffEnabledParam)])

Sorry for the extremely delayed response. I was sick for a week and then out of town so I didn’t get a chance to respond. I ended up just pulling the switch out for now and replacing it with a GE/Jasco switch that I had laying around. I didn’t get a chance to try to modify the handler like you suggested.

I may just have to be patient here I guess, it seems like Zooz is slowly starting to officially integrate most of their devices so that they have local control, hopefully they’ll get the official integration of the ZEN21s soon and we won’t have to worry about it anymore.

In any case, thanks for your help and time - sorry if I wasted it.

I hate to bring up this thread from 1 month ago, but I’m now having issues with the switch in a different room. I guess it wasn’t noticeable before since this switch never usually stayed on for more than 1 hour.

Here is the information.

Firmware: 4.04

Include device and it pairs with @krlaframboise’s Zooz ZEN21 On/Off Switch VER. 4.0.1 handler.

I then go in and change it to the generic Z-Wave Switch handler so I can get local control.

I’m not sure if this is something going on with the actual firmware of the device since I upgraded it to 4.04 within the past couple of months or if it’s me switching the handler to the generic Z-Wave Switch after the fact. The reason why I have @krlaframboise’s handler is because I do use the features in that handler on about 3-4 of the Zooz switches I have. The rest I just set to the generic Z-Wave Switch just so I can get the faster local control. I’m not sure if there is a way to disable the custom handler temporarily while including a device so it doesn’t even try to pair to the custom handler if that could be a cause.

Again, I’m not blaming anything in particular, I just want to figure it out. I’m starting to lean towards the firmware version of the switch since I upgraded that within the past 2 months and that is around the time my problems started.

I’m not sure if this is related, but the ZEN21-ZSEN27 switches/dimmers have to be removed and factory reset after the firmware is updated or the devices can have all sorts of problems.

I provided those instructions above so that we could see what parameter #3 was set to because if it reports 0 then auto off is disabled and the problem isn’t the handler.

The only way it could be the handler is if Zooz merged parameters #3 and #4 in the latest firmware without telling anyone and the manufacturers default value for param #4 was originally 1 hour. That’s highly unlikely because they wouldn’t merge the off params without also merging the on params so you’d most likely also be having issues with it automatically turning on.

If they did merge those parameters then the fix for that would be to remove “?: null” from lines 255 and 261.

If you didn’t upgrade the firmware for a specific reason then the simplest solutions is to ask Zooz for the production firmware so you can put it back.

You can prevent the custom handler from getting assigned by putting // in front of the fingerprint line near the top of the code.