Buzzing sound from under-cabinet transformer

Full sine wave mode

1 Like

Thank you!

Strange, though…I don’t see that option

Did you configure after updating? What is your version of z2m? I’m on 1.30.3

Same version As you. I took the screenshot after upgrading the firmware.

Try configure one more time

Ok, I did the reconfigure and it succeeded, but I still don’t see the option for Single Full Wave. I restarted the Z2M add-on but that didn’t help.

This is the About section of Z2M showing my version and stuff in case that’s the issue?

Ah ha. I’m running a custom converter. The updates for the 2.14 firmware were merged after the 1.30.3 release. You can either use Z2M Edge or wait for the May release.

Ahhhh ok I thought I was going crazy!

I’ll look into Z2M Edge this weekend to see if I can at least test that setting to see if that fixes it. thanks!!

1 Like

One of my switches was faulty so I had to get a replacement from Inovelli. I’m finally ready to test it with the lights that were causing the buzzing sound!

Except that I can’t upgrade its firmware to 2.14 because apparently Inovelli has pulled it or something? It should be located here according to the logs in Z2M: https://files.inovelli.com/firmware/VZM31-SN/Beta/2.14/VZM31-SN_2.14.ota. Anyone have any insight into when a new version will be made available?

That said, I do see the option for this switch to put it into “Single-Pole Full Sine Wave”…so I did that. But now the switch doesn’t work at all - the LED turned off and the switch doesn’t turn the lights on or off.

It seems that now the switch is dead…I tried a factory reset (hold config and top paddle for 20 seconds) and get nothing…

Is this the 2nd switch you have tried using with that transformer that has failed?

No, the first one seemed to have been DOA. So while I was waiting for the replacement, I took the switch that I was going to use for these under cabinet lights/transformer and moved it to the other lights since I didn’t want to listen to the buzzing sound.

The problem you are facing is that you are trying to use a switch that is not designed nor rated for inductive (transformer) loads. You need either a true on/off switch or a dimmer that is specifically compatible with your transformer.

1 Like

Yeah, Blue dimmer switches shouldn’t be used with magnetic/inductive loads… But this latest issue sounds like it could be an unrelated firmware bug:

(EDIT: @mamber confirms in a later post that the switch firmware does behave correctly in this scenario, so my theory here is unlikely to be the explanation for this failure)

This suggests to me that the switch firmware might not be validating/range-checking its configuration parameters before using them. So, if you use a new driver with an old switch firmware, you run the risk of sending an invalid config to the switch by enabling options that are only supported by newer firmware.

Z2M at least doesn’t tailor its config page to the current firmware version that is actually on the switch - it just assumes that you’re on the latest it supports (2.14 at present) - so it can show you options that aren’t actually supported by a switch running older firmware.

This should be harmless - the switch should just reject/ignore any configuration that it doesn’t support. It certainly shouldn’t brick itself.

Does the switch show any signs of life? Does the LED notification bar on it do anything?

Can you use the Quick Tap Sequences to get back to the default Single-pole On/Off mode?:

Are you sure you’re doing the factory reset correctly? It is a little tricky - the order you press/release the buttons matters. Quoting Bry’s instructions from another thread:

1 Like

ah ok. i didn’t realize inductive == transformer.

Does the switch show any signs of life? Does the LED notification bar on it do anything?

Nope… nothing lights up at all.

Agree this sounds like some sort of bug with the firmware/z2m/something that bricked it, even though it shouldn’t be used with a transformer (considering it worked fine prior to that setting). I’m in touch with inovelli support and hopefully they’ll work with me to get a replacement/credit for the next time i need a switch (since I clearly won’t be trying this location again).

thanks all for your help

Correct. The firmware ignores parameters that it doesn’t support. It’s highly unlikely that’s what ‘bricked’ his switch.

More likely it was caused by using it with a load it is not designed for.

1 Like

It does ignore completely new parameters (in my experience, Z2M returns an error if you try to change a parameter that the firmware doesn’t support) - but what does it do if you try to set an existing/supported parameter to a new/unsupported value?

For example: say you have a switch running FW 2.08 and you try to set switchType to “Single-Pole Full Sine Wave”, what happens? switchType is an existing parameter that FW 2.08 supports, but you’d be trying to set it to a value outside of the range that 2.08 supports.

I’m not saying this is definitely what happened (sorry if my previous post made it sound like a definitive diagnosis) - But it does look suspicious to me (as someone that has written, reviewed, and debugged a lot of embedded firmware). It should be easy enough to test - though with the risk of bricking a switch, I’ll leave that testing up to someone that has the hardware required to manually reflash the switch if it does fail.

@smenzer , do you recall what firmware version your switch was on before it failed? And what date code is on the sticker on the front of the switch?

It ignores it.

The firmware does a range check. If you try to set it outside the range, the previously set value remains unchanged. HOWEVER, that is what the firmware does. The hub UI may think its changed and get out of sync with what the device is actually configured for. A ‘refresh’ (hubitat) or ‘inventory’ (is that the right term for HA?) may be needed to get them back in sync.

And I’m not saying this definitely didn’t happen. It is possible that the firmware doesn’t always check ranges correctly for all parameters. But I have tested this particular parameter (#22) as well as many others and it ignores values out of range. And even if it failed the range check properly its highly unlikely to ‘brick’ the whole device. A factory reset should always be possible after any potential parameter misconfiguration

Using the dimmer with an unsupported load is the much more likely cause of failure

It was 2.09 I believe.

Excellent - thank you for testing and confirming!

My notion here was that perhaps an assertion statement was firing inside the firmware, rendering it completely unresponsive. Alternatively, the switchType parameter could have affected how the switch receives power (this would most likely only apply in non-neutral setups, where an improper dimming waveform would starve the switch for power).

Based on your post, I agree.

The Full Sine-Wave mode was only added in 2.10, so my theory could still apply if you were on an earlier firmware version - but it now seems unlikely to be the explanation (sorry!).

(Was 2.09 actually shipped on anything or released to the public? I don’t see it listed in the firmware changelog, or even mentioned anywhere else on the forum. My switches from the latest production batch came with 2.11 on them)