+1. I’m waiting on ordering more switches until I’m confident the firmware is in a stable place
There isn’t an official post to my knowledge, but I’ve also been out of the forums for a bit dealing with some personal stuff.
We pulled this firmware because there was an issue with inductive loads and Trailing Edge which was causing the switch to overheat and, in some cases, melt the faceplates.
Our fear was that since Leading Edge (the default on the last production run), “worked” on inductive loads (in quotes because we still can’t endorse it) it gave people a false sense of security in the update.
In other words, if you put your switch on an inductive load (transformer, ballast, etc), it likely would work on Leading Edge (albeit some potential buzzing/flickering) – if you updated your switch and it switched over to Trailing Edge (in some cases you may not even know this was a feature) your switch could overheat.
–
So, we pulled it until we could figure out what was causing this and then how we could fix it (if possible). We just wrapped up the analysis, which I will share below. This is the full report and I won’t attempt at interpreting it as I know there are many of you who are much smarter than me and can probably explain it better:
–
Now that we know the root cause, we are taking greater steps to put warnings on the switches to prevent this from happening as well as changing the default parameters and exploring a solution for the temperature sensor (for overheating).
We are awaiting v2.15 that has these precautions built in before releasing anything. In addition, we are recommending that if you don’t have any issues with 2.14 currently that you don’t find the urge to update to 2.15 as these are more protective measures than anything.
The reason we’re recommending that approach is that these updates are more protective measures (ie: no new features), it’s getting hard for us to troubleshoot network problems stemming from updates and there’s no way to downgrade firmware with Zigbee. In other words, “if it ain’t broke, don’t fix it” on this firmware version.
–
Here’s my recommendation:
- If you already have 2.14 installed and it’s working great, keep that firmware version on your switch
- If you are < v2.14 on your switch, then if you can give us a couple weeks to sort out 2.15, we anticipate it to be ready then (we’re already testing it on the Z-Wave firmware)
–
All new switches being produced right now will be on 2.15.
Interesting analysis, and makes sense.
I know you said no new features, but kind of related to this fix, it would be nice if leading/trailing edge had its own parameter instead of looking up/trying to remember what other settings it’s linked to.
So theoretically, if you enable “full sine wave”, this should never be an issue, right? (Not looking for an official response, since I know it’s still not officially supported).
Like not calling it a 2-1 on/off switch?
I’m recommending on/off/on switch.
Yeah sorry for the confusion, that will be added to 2.15 and was one of the protective measures, my bad.
Here’s what 2.15 will have:
- On/Off default will be Leading Edge + Full Sine Wave
- Leading Edge will be the default again for everything
- You’ll have the ability via parameter or local change to change to Trailing Edge, but we will have warnings in our drivers stating Trailing Edge cannot be used with certain loads
In addition, one of the recommendations from the manufacturer was to add a temperature sensor inside that would shut the switch down if it got too hot. We are looking to see if we can leverage the MG21 (or MG24) temperature parameter and use that rather than having to revamp the PCB (although it’s unclear from this datasheet if this is just a test or if this is something included on the chip). We will if we have to, but it would be nice to catch a break for once and see if we can use the chips. There seems to be something related to temperature reading:
Page 48
In addition, one of the recommendations from the manufacturer was to add a temperature sensor inside that would shut the switch down if it got too hot. We are looking to see if we can leverage the MG21 (or MG24) temperature parameter and use that rather than having to revamp the PCB (although it’s unclear from this datasheet if this is just a test or if this is something included on the chip). We will if we have to, but it would be nice to catch a break for once and see if we can use the chips. There seems to be something related to temperature reading:
Definitely present on the chip. Here’s the register for reading it. I assume there’s also a higher level API for it.
So having an integrated sensor on the chip is nice, but assuming that works, what do you do if you detect an overheat condition? Can the switch be fully shut off or do you have the ability to reduce power by setting it to minimum dimming?
If there’s still power to the switch, it could be useful to use the LED to display some sort of error condition (Maybe some of the LEDs in Red, blinking a specific pattern…?)
It might make more sense from a user perspective to have a drop-down menu where you select the bulb type, and based on the user input it changes it from leading edge to trailing edge or vice-versa.
I’m traveling overseas and just got call from my wife that all my lights in bathroom start buzzing and behaving completely crazy - sometimes on randomly sometimes off.
Dimmer has LED lights on, so it is not dead
I hope that it is only LED driver issue and not wires connections due to some kind of stress due sharp edges
I’m coming back in Sat and check what is going on
But any idea is welcome. I never saw something like that
Interesting question. It will be interesting to see how this shakes out. If a switch is overheating to the point it is dangerous, I would not think you would want it providing any power. Dimming might be one thing for lights, but if the device is powering an improper load, simply dimming may not resolve the issue.
That is strange, just regular 120 AC bulbs? Maybe not liking trailing edge? If you change them to 3-way dumb switch mode (to change them to leading edge) I wonder if it would make a difference.
It is MR16 (LED option) with Juno cans.
I believe that 3 way dumb option made it work better before, but I did not want to hear clicks and it is not possible to get rid of that with this configuration
I thought that limiting max power will cut it….looks like it did not.
2.08 did not manifest same behavior
Came home and spent quite some time.
This is the most bizarre thing I saw. I have 5 LEDs connected to same dimmer (all MR16 with Juno cans):
- Buzzing sound (quite low frequency)
- Sometimes no LED is working, all over sudden one or two are firing up
What I did:
- Disconnected switch from line voltage and connected back - no change
- Replaced all LEDs with tungsten bulbs - buzzing sound gone, but same behavior - or no one woking, or one
- Performed reset for the switch - it went to on/off mode. Did not work from the beginning, at some point I got up yo 4 bulbs working, but buzzing.
- Changed to dimming - buzzing, and 1 or 2 builds responding. Temperature of the switch start to rise to the level I could smell burned plastic.
I checked voltage (do not have a scope at home) - voltage between line and neutral was 123V, between load and neutral (at max) was about 117V
It is a mystery for my why bulbs are not working
Replaced switch with Insteon dimmer - no problem whatsoever. Same with Zooz ZEN77 Rev3, Replaced all bulbs back with LED, no problem with ZEN77. I’ll keep ZEN77 for now, but it is scary if all blue 2in1 will start malfunction like that - I am in trouble - I have 22 dimmers with 2.14 firmware. It is not just $$, but a lot of time to replace them - I already create tons of automations…
Update:
I took 2 affected dimmers and placed them in other locations. Same behavior.
I am trying to salvage these dimmers, so I used one as on/off switch. When changed to “Single Pole- Full Sine Wave” buzzing stoped, but it is still not working if configured as a “dimmer”, so I am using it in “on/off” mode. BTW, when it is in “dimming mode”, dimmer is heating and after changing back to “on/off” mode it takes some time to switch to start working, so I am guessing there is some kind of temperature protection.
Another dimmer with same behavior I placed as 3 way companion dimmer (without load) and it is working ok (obviously )
My biggest concern now is the fact that I do not understand the root cause of the issue, and because of the same set-up (MR16 LED with Juno cans) for almost all dimmers, I am worried that will be the destiny of all dimmers at some point of time.
BTW, should I request replacement? I have these dimmers less than a month
I may be mistaken, but aren’t MR16s low voltage?
Yes, 12V.
Juno cans has magnetic transformer inside (from 120 to 12V).
I definitely thought about it, but I had Insteon dimmers for 13 years without issue and Zoom ZEN77 works just fine. 2in1 Blue was working fine with 2.08 as well. Buzzing started with 2.14, but I manage to fix it with max power limit (not exciting 150). Flickering still was there.
When I replaced MR16 LED with Halogen MR16, buzzing stoped (so root cause is not a magnetic transformer)
Are the halogen MR16 not also low voltage? I assume the transformer is in the can.
That’s your problem. From the product page:
This switch is to be used for lighting only (except ballasts/tube lights or any lights connected to a transformer). Not to be used for fans, outlets, ballasts (magnetic or electric), tube lights or any inductive/motorized loads