Zooz ZEN32 and ZEN35 - Control and Track all in one

Blueprints Exchange
,
164

agreed, I have many Zooz Zen30 (double switch) and the Zen32/35 are easily 2x as bright on the lowest setting than the Zen30 is on the highest. Very annoying even on the lowest setting

165

@TheZackCodec Merged. Everyone please open any bug reports based on the latest version. All my devices worked fine.

166

@rwalker Glad to hear you had no issues! I tried to test each feature as i added them and retest them as i added in each new one. Hopefully it goes smoothly with everyone else.

I’ll probably open another PR shortly. I went back through the advanced switch parameters to see what else might be useful to add, and I’ve got a few new things working on my branch.

We probably want to avoid cluttering the blueprint with too many options, but I really think the “Disable LED Flash On Setting Change” parameter (Param 38 on the ZEN35 and Param 23 on the ZEN32) is a highly valuable addition. Because this blueprint handles so many setting changes, the switches will normally flash for a couple of seconds every time an automation updates a color. Disabling this makes the color transitions faster and looks way cleaner.

I also added an option to “Disable LED Flash On Button Press” (Param 39 on the ZEN35 and Param 27 on the ZEN32). This might be more of a subjective preference, but I think a lot of users will appreciate the option to have the indicator immediately snap to the tracked entity’s color instead of blinking first. I’ll send a reminder here once I’ve submitted one.

1 Like
167

Hopefully you find the option to override as red at night useful then. At night when less things are going on I’m fine with just overriding everything as dim red so I’m not blinded.

I also thought about night overrides per button or per (on/off/unavilable) but I’m trying to strike a balance between configurable but not overwhelming. I find the red override works good enough and you only have to do it in bedrooms where it is bothersome not all the switches as a whole.

I have some more ideas but I want to try them out before I open them up to public scrutiny.

2 Likes
168

I found these Zen32/35 LED brightness pretty overwhelming for bedroom use. I’ve been researching customization options and have been coming up to speed on blueprints. I just used this one for a new HA Zen32 setup in a vacation home. After install HA came up with an OTA update for 08/2026 Firmware 3.30. The new firmware supports 10 levels of LED brightness used in Parameters 11-15. Exactly what was needed. I’m new to HA Blueprints. Will this one be updated for the latest firmware changes? Or is this something that the blueprint users typically handle for their own installations?

169

You beat me to asking this same question. This blueprint has been great but wondering on the new updated changes as well as some others that @TheZackCodec suggested. Thanks for your work on this @rwalker

170

The blueprint has been updated to v2026.9.3. I was using v2026.7.0. Perhaps I imported it before 09-03-2026 and started setup later? I’ve reimported the blueprint, but my first Zen32 automation still shows v2026.7.0. I started a new automation for a different Zen32 using the v2026.9.3 blueprint. It has a setting added for either auto-sensing or forcing the firmware version, so that the automation includes either 3 LED brightness levels (0-2) or 10 (1-10). I’ve run it it both ways and have not been able to enable the 10 levels of brightness.

I am new to Blueprints so I may be missing something obvious that I am doing wrong. The automation is awesome, but I’d really like to make use of the extra brightness levels for dimming the Zen32’s in bedrooms. Thanks to @rwalker for creating this one!

171

Just to get the low-hanging fruit out of the way here, your Z32s are all confirmed to have the latest Zooz firmware successfully installed? The appropriate firmware file varies by Z32 generation, but it looks like the latest f/w file for each gen includes the new brightness levels.

Simply re-importing the blueprint should do the trick, but maybe a HA restart is worth considering.

172

Thank you for the input. Yes, all 3x of the installed Zen32’s have the updated firmware onboard. These are new switches I’m installing to a new HA hub in a second home. I have experience with the Zen32/35 switch from my home set up where I added these a few months ago without use of a blueprint. For this new HA system, I used the JS UI Z-wave control panel to verify that 10 LED levels were now available after the latest firmware update.

Looking at the first Zen32 switch I automated using this blueprint, it turned out it was successfully updated to the current blueprint. However, the blueprint code for confirming current firmware automatically, or by manually selecting the firmware version, doesn’t work on my HA instance because the Zen32 switch label and firmware settings don’t match. So, the 3 default LED brightness menu setting offerings (low, medium, bright) weren’t changing for me. Until I opened up the blueprint in an editor, I was also assuming the new blueprint would offer 10 menu brightness levels. But the updated blueprint kept 3 LED brightness menu options, now mapped to levels 3, 6, and 10.

173

Hey all, thanks to Roy for this excellent blueprint which I’ve used for a while on my Zen35. I decided to add some more flexibility and functionality. At least half the code is new or re-written

If you are interested, check out the thread…

What’s new

Brightness work properly, and has more options. The original blueprint provided Low / Medium / Bright. There was also a bug that could send 0 and would be rejected by newer firmware. My version uses the device’s own 1–10 scale, auto-detects firmware (ZEN35 1.40+, ZEN32 800LR 3.30+ get the fine scale), and remaps older firmware to its 3 levels automatically — every value validated before it’s written.

Global Defaults. Set color / behavior / brightness for on / off / unavailable once, for all buttons. You can easily set a value override on any button, otherwise it inherits the global value automatically. No more setting the same value five times.

Conditional Override (replaces Night Time). The old fixed night-schedule is gone. In its place: supply your own triggers and condition — time, sun, an entity, numeric, or any template HA supports — and set override color / behavior / brightness per button. So you can dim every LED after sunset while each keeps its own color, which the single global night value couldn’t do.

Big-button LED Control Mode. The relay/dimmer button’s LED can now be blueprint-driven (full color/brightness/override tracking of any entity, the new default) or left to the device firmware (instant on/off). The original silently gave you only the firmware behavior.

Cleaner UI. Each button split into an Actions panel (presses) and an LED Settings panel (what the LED shows). Corrected ZEN32 (relay) / ZEN35 (dimmer) terminology throughout.

Two upstream bugs fixed.

  1. Hold and Released button actions were firing for the wrong event (swapped Z-Wave scene key codes)

  2. a climate entity in cooling mode never registered as “on” (cold → cool). Both confirmed against the Z-Wave JS source. So, it if a Thermostat’s LED stayed dark while cooling. If a button’s LED is set to track a thermostat, the LED lit up when heating but not when cooling, because the “on” list had cold instead of Home Assistant’s actual cool mode. Now cooling turns the LED on like heating does. Affects you only if a button tracks a climate / thermostat entity.