Lights Delayed When First Turned On (VZM36 + VZM31-SN)

Hello everyone!

I’ve been using five VZM36 canopy modules, each bound to its own VZM31-SN (2-in-1 switch), for about a year now. I only recently noticed an odd issue…when turning the light on for the first time of the day, there’s a noticeable delay of about 3 seconds before it actually turns on. This happens across all five modules.

Strangely, if I turn the light off and then back on, it responds instantly. However, after being off for roughly 10 minutes or so, the delay returns when turning it on again. It almost feels like the switch or module is going into a sleep mode, but since both are mains powered, I’m not sure if thats the case.

I’ve already tried setting all parameters to zero in an attempt to fix it, but no luck. That said, since the light turns on instantly when cycling it off and on, I’m not sure if the settings would even make a difference in this behavior.

Is this expected behavior, or is there a way to eliminate the delay entirely? It’s a little awkward when guests use the switch and nothing seems to happen for a few seconds. It’s surprising how long 3 seconds can feel in moments like that! :sweat_smile:

Thanks for any help!

This sounds a lot like a problem I was having with the same setup, and even with VZM31 switches bound to Hue bulbs.

What fixed it for me was to add the receiving device to a Zigbee group, and bind the VZM31 to that group. Since I made that change, response has been instant.

I don’t know why that became necessary, but it has fixed the issue every time I’ve tried it across my network.

I think that’s what I’m doing based on Inovelli’s setup instructions inside of Zigbee2Mqtt. I’ll take a look and make sure I didn’t screw it up :slight_smile:. Appreciate the reply!

Maybe this will help. I find the binding instructions a bit lacking when it comes to the VZM36 + VZM31-SN. My hub is HomeSeer HS4 using Zigbee2MQTT via their Zigbee Plus plugin.

I have two different setups. The first is one switch controlling one module. The second is two switches controlling one module.

Setup 1 (one switch /one module):
No groups are necessary in this scenario.
Binding the dimmer (Switch) to the canopy module (Canopy):
Switch endpoint 2 (EP2) bound to Canopy endpoint 1 (EP1) LevelCtrl + OnOff
Switch EP3 bound to Canopy EP2 LevelCtrl + OnOff


Binding the module to the switch:
Canopy EP1 bound to Switch EP2 LevelCtrol + OnOff
Canopy EP2 bound to Switch EP3 LevelCtrl + OnOff

I originally only bound the switch to the module, but this did not keep the state of the switch in sync with the module if the module was controlled via the hub. Binding in both directions solved that for me.

Setup 2 (two switches /one module):
Groups are necessary in this scenario.
Group 1 Canopy Light group:
Canopy EP1 + both switches EP2 and EP1.

Group 2 Canopy Fan group:
Canopy EP2 + both switches EP3.

Bindings:
Both switches are bound the same. I’m only showing one of the switches. Repeat for additional switches in 3-way, 4-way, etc.
Switch EP2 bound to Canopy Light Group LevelCtrl + OnOff.
Switch EP3 bound to Canopy Fan Group LevelCtrl + OnOff.

Binding the Canopy Module to the groups:
Canopy EP1 bound to Canopy Light Group LevelCtrl + OnOff.
Canopy EP2 bound to Canopy Fan Group LevelCtrl + OnOff.

Just like the first setup without groups, the switch(es) and the canopy both need to be bound to the groups. I guess I would refer to this as 2-way binding.
The part that was surprising to me was adding the Switches EP1 to the Canopy Light Group. This was necessary to keep the LED notification bars in sync when controlled by the hub or the other switch.

1 Like

Wow, this an extremely detailed response, thank you! I never thought you could bind two ways… that might fix my issue. I’ll do the same then report back.

1 Like

Looks like the 2-way binding fixed the issue as I haven’t had a problem for the last couple of days. Fantastic! Appreciate your help!

1 Like

Glad I was able to help!