Try switching the driver to plain "Device" (it'll be an option, though it sounds kinda odd), then Save.
Near the top of the page, there'll then be options to "Clear all States", "Clear Child Devices" and things like -- select the ones related to clearing states and child devices, then refresh the page by doing a browser refresh -- the states and child devices should then be gone.
Then switch back to the Z51 driver and set up those corresponding preferences -- you should be good-to-go from there.
The "Device" driver trick is always a nice way to help ensure a clean plate when switching drivers like that.
You might also be seeing "ZEN52" in the device name that got defaulted from the pairing. That you can just change to anything you want. It just defaults to the name of the driver the system selected at pairing and has no impact on anything else.
I did the device driver and deleted the child devices then changed it back to your driver. No more children and it seems to work just fine. The Data field under Device Details still shows data that matches my other ZEN52s:
That deviceID is for the ZEN52. Can you turn on debug logging and then run configure.
It will request the ID numbers from the device again, you should get a "fingerprint" log, show me that.
Did you by chance use Swap Apps at all with a ZEN52 or something? Otherwise if you are certain this is a ZEN51 it looks like possibly the ZEN52 firmware got installed on it somehow.
No swap apps used. I got the ZEN51 a few days ago and installed as i usually do. I was thinking the same thing about the firmware. This is what I got after the configure. If it's not what you need, let me know.
Summary
[dev:2443] 2024-06-25 12:02:46.191 PM[debug] Dining Room Overhead: assocReports - Association Reports (#8) = 1
[dev:2443] 2024-06-25 12:02:45.449 PM[debug] Dining Room Overhead: offTimer - Auto Turn-Off Timer (#2) = 1
[dev:2443] 2024-06-25 12:02:44.985 PM[debug] Dining Room Overhead: switchType - External Switch Type (#7) = 2
[dev:2443] 2024-06-25 12:02:44.596 PM[debug] Dining Room Overhead: loadControl - Smart Bulb Mode - Load Control (#6) = 0
[dev:2443] 2024-06-25 12:02:44.184 PM[debug] Dining Room Overhead: powerFailure - Behavior After Power Failure (#4) = 0
[dev:2443] 2024-06-25 12:02:42.966 PM[debug] Dining Room Overhead: offTimer - Auto Turn-Off Timer (#2) = 1
[dev:2443] 2024-06-25 12:02:42.652 PM[debug] Dining Room Overhead: Changing assocReports - Association Reports (#8) from 1 to 0
[dev:2443] 2024-06-25 12:02:42.645 PM[debug] Dining Room Overhead: Changing impulseDuration - Impulse Duration for 3-way [seconds] (#11) from null to 10
[dev:2443] 2024-06-25 12:02:42.639 PM[debug] Dining Room Overhead: Changing relayType - Relay Type Behavior (#9) from null to 0
[dev:2443] 2024-06-25 12:02:42.632 PM[debug] Dining Room Overhead: Changing switchType - External Switch Type (#7) from 2 to 0
[dev:2443] 2024-06-25 12:02:42.626 PM[debug] Dining Room Overhead: Changing loadControl - Smart Bulb Mode - Load Control (#6) from 0 to 1
[dev:2443] 2024-06-25 12:02:42.619 PM[debug] Dining Room Overhead: Changing powerFailure - Behavior After Power Failure (#4) from 0 to 2
[dev:2443] 2024-06-25 12:02:42.613 PM[debug] Dining Room Overhead: Changing timerUnits - Time Units (#10) from null to 1
[dev:2443] 2024-06-25 12:02:42.602 PM[debug] Dining Room Overhead: Changing offTimer - Auto Turn-Off Timer (#2) from 1 to 0
[dev:2443] 2024-06-25 12:02:42.596 PM[debug] Dining Room Overhead: Changing ledIndicator - LED Indicator (On when On) (#1) from null to 1
[dev:2443] 2024-06-25 12:02:42.589 PM[debug] Dining Room Overhead: executeConfigureCmds...
[dev:2443] 2024-06-25 12:02:39.650 PM[debug] Dining Room Overhead: switch is turned off [NOT CHANGED]
[dev:2443] 2024-06-25 12:02:38.449 PM[info] Dining Room Overhead: Logging Level is: Debug (3) for 30 Minutes
[dev:2443] 2024-06-25 12:02:38.367 PM[warn] Dining Room Overhead: configure...
Looking for logs like this, the fingerprint specifically.
If you are stuck with "Pending Changes" the driver wont do a full re-sync unfortunately, so that could be the issue, or if you do not have the most current driver installed.
Either way, I suspect it wont change anything and you should contact Zooz and ask what to do. Ask them if you should try to just flash the current ZEN51 firmware on it, which I think should work.
Zooz is sending me a new one. They asked me to try and update the firmware (Which didn’t work) and to send them a picture of the device to make sure it was actually a ZEN51 (it was).
@bill.d Bill glad to hear it’s (mostly) working for you. But I’m still a bit confused about the wiring schematic.
Since there’s just one switched circuit (per closet), do you really need a dual relay? I thought you were saying you used RM to infer the door status, so I was imaging a single relay. But maybe I’m missing it here.
Would the below schematic (from Zooz ZEN51 manual) not work for our use-case case to both activate the light and monitor the door? Again, I may not be understanding so appreciate any guidance.
The issue is that the switch status can be changed by physical or digital means. If the light is turned off via Hubitat the switch reports off, even if the door (and physical switch) is open. The 2nd switch allows you to monitor the door as long as you don't do anything digitally to change it.
The switch is tied to the relay and you cannot de-couple it. I think he possibly wanted to be able to get the door contact status separate from the light state, there is an old post about it somewhere if this is the case I am thinking about. If you want the door contact to always turn on the light it should be fine with the ZEN51. You should even be able to turn the light off with rules even if door is left open. You would want to set the switch to on/off mode so that if the light is turned off while door is open, closing the door would always trigger Off (even if already off), and opening the door always triggers the relay ON.
EDIT: Yes in the case of door left open and turning the light off with a rule, you then lose visibility if the door is still open or not, if that matters to you. I think even once the door is closed you will not get another event so there is no way to tell if it ever got closed or not.
Ah this is what I was missing. Makes total sense duh.
Yes. This. Exactly. Me too.
I'm going to go the ZEN52 route so that I can activate the light and monitor door close/open separately.
Just still unsure about the wiring since there's only once switch in the circuit. I'm guessing you did something like this below (grounds omitted for clarity), just not sure about the OUT1/OUT2 wiring. Also, I. think @bill.d, you said you wired both S1 and S2 to the switch, but it just looks odd this way, so double-checking (can you tell I'm not an electrician?). Thanks again guys.
Hi again, my Zooz Zen 16 v2, running firmware 2.1 controls a contactor for my pool pump. I installed it a couple of weeks back. I unplugged the power supply, the pump stopped. When I plug it back in, the pump does not restart. The device reports it is on. The preference is set to all relays restore last state. Any ideas?
Thanks, John
The driver reports the last state that was sent to it. If the power is removed and restored and the device does not send any messages out how would the driver know the state of it (or even that it lost power)?
For the issue with it not restoring, you should post that on the Zooz forms or send them a support email.
I've just started using your advanced drivers for my Zen17, which I use to open/close my doggy door. I wanted the auto turn-off feature for the relays, but it appears to be turning off the main switch as well. I would like the main switch to stay on, and just the relays to auto-off. Is that possible?
[EDIT] Nvrmnd....the problem was me. Everything's working fine now.
For anyone that follows that wants to use a ZEN52 to automate a closet light with in-jamb ball-switch, the circuit design in post 92 above works perfectly — thank you @bill.d and @jtp10181.
Curious if there’s a reasonably elegant way of changing the second child device to a contact sensor rather than a switch? Would work better for automations and dashboards. Easy to use a virtual contact sensor to achieve the same end, but was hoping to avoid adding more devices (even virtual ones).
Jeff, thanks again for these awesome drivers! Nicely done!!
