Trailing edge dimming issues with Blue FW 2.14

dan.strother · May 5, 2023, 6:21pm

I’ve seen a number of comments recently about strange dimming issues with the new trailing edge update in FW 2.14, so I broke out my oscilloscope to look at the waveforms. There is definitely a limitation with the trailing edge dimming implementation in the latest firmware.

(EDIT: the asymmetric trailing-edge dimming waveform seen here is apparently deliberate, and is necessary due to limitations in the current switch hardware - see discussion below this post)

My test setup is a single switch powering a 50W incandescent bulb (a purely resistive load that won’t distort the output waveforms). The switch is on the latest 2.14 firmware. Neutral is connected to the switch. I’m using Home Assistant with zigbee2mqtt for configuration.

Here is what the output looks like at 100% brightness in trailing edge mode:

The waveform is very asymmetric - the bottom half looks fine, but the top half is cut off at about 70% of max.

Here is a video of the waveform, as the switch ramps from off to 100% and back down:

It behaves correctly up until about 70% brightness, then the top half stops growing. This is wrong - the top half should behave identically to the bottom.

Not all bulbs seem to be bothered by the weird trailing edge waveform. Incandescents will always be dimmer. My test bulbs (Satco S29431) don’t seem to mind, and still reach 100% brightness (measured with a lux meter). But I could definitely imagine that other LED bulbs would be confused by this waveform (at best, they might just be dimmer - at worst, they might flicker badly).

This bug likely also explains the reports of switch failures when powering non-approved magnetic ballasts with FW 2.14. This waveform is doubly bad with transformers - the asymmetric nature of it may cause saturation of the transformer core, resulting in higher current draw - and the abrupt cutting of current in the top half of the waveform could result in large voltage spikes.

And one more minor observation: the bottom half of the waveform never reaches 100% either (it is still cut off a little). With a neutral connection, I’d expect a dimmer to go to full 100% duty cycle. I’m not sure how many bulbs will actually care about this (my Satcos don’t care), but I imagine at least a few won’t be able to reach true 100% brightness with this slightly truncated waveform.

For comparison, here is what it looks like in leading edge mode (forced by setting the switchType to “3-Way Dumb Switch”):

These leading edge waveforms look fine - exactly what I’d expect from a non-neutral dimmer.

I also tested the full sine wave mode, and it does indeed produce a genuine 100% duty cycle sine wave:

Surprisingly, you don’t get this full sine output in the switch’s default config. You have to set both outputMode = “On/Off” and switchType = “Single-Pole Full Sine Wave”. If you leave switchType at “Single Pole”, you’ll get the buggy trailing edge waveform. It would be better if the switch produced a full sine wave whenever possible. I’m not sure there is any reason to actually have a separate full sine wave mode - it should just be implicit when switchType = “Single Pole” and outputMode = “On/Off” and you have a neutral.

Here’s my list of recommended changes based on this testing:

fix the top half of the trailing edge waveform (most important)
make the switch go into true sine wave mode by default - so even if people do use it with a non-approved load, it stands a higher chance of working reliably
add an explicit option for selecting between trailing and leading edge dimming, so people can select the best mode for their specific bulbs (relying on the 3-way mode to force leading edge is a bit of a hack, and has the downside of producing relay click noises)
if possible, improve the trailing edge mode so that it can actually reach 100% duty cycle (i.e. the output should look identical to the full sine wave mode when set to 100% brightness)

EricM_Inovelli · May 9, 2023, 6:41pm

I spoke with the engineer on the wave form difference when the switch goes to 70% or above and the engineer said:

"If you’re using an LED light bulb, it’s going to get a nice sinusoidal wave,
Due to limited hardware conditions, if we do not limit the output of positive half cycle, then our switch is not compatible with LED bulbs.

With capacitive loads Trailing edge, which do not limit positive half-cycle output, we will fail to detect zero-crossing signals and AUX signals, which will result in invalid AUX and bulb flickering"

So the waveform is designed the way it is for better compatibility with certain LED bulbs and so that there is not interference when detecting aux switch button presses when the level is above 70%.

We are working on a configuration option to “Disable trailing edge output” so users with bulbs that perform better in leading edge mode can revert their output back.

Currently to disable trailing edge the only option is to change to dumb switch mode or to unplug the neutral on the back of the switch.

dan.strother · May 10, 2023, 12:41am

Hmm… that’s very interesting - thanks for sharing their response. My apologies for assuming that this was a bug and not a deliberate engineering trade-off!

I had been assuming that there was also a zero-crossing detector on the input to the switch that could take advantage of the neutral connection (when present) - but if there is only a non-neutral style zero-crossing detector, then I can see how that would be limiting.

It would be nice to fix this limitation in a future hardware revision (or at least fix it in future derivative products, like the mmwave switches), so that trailing-edge dimming can be fully functional. (It may be that 3-way aux setups will never fully support trailing-edge, even with hardware revisions - but single-pole should be completely doable)

Given the limitations of trailing-edge dimming with the current hardware, it seems better to have leading-edge dimming be the default mode (once that configuration option is added). That way, firmware updates wouldn’t cause any unpleasant surprises for existing users, and new users would get a better out-of-the-box experience with better bulb compatibility. Power users would still be able to opt-in to trailing-edge dimming, so they can see if their bulbs benefit from it.

So, of the 4 points I listed, #1 and #4 aren’t possible due to current hardware limitations, and #3 is being worked on.

I still think #2 should also be addressed: when outputMode = “On/Off”, you should either get the full sine wave - or, in cases where full sine wave isn’t possible (non-neutral and 3-way setups), it should fall back to the cleaner leading-edge dimming waveform. You should never get the trailing-edge waveform in “On/Off” mode. With this change, there shouldn’t be any need to explicitly change switchType to “Single-Pole Full Sine Wave”, so that option could be deprecated.

dan.strother · May 11, 2023, 8:14pm

Looks like I missed Smart Bulb Mode. SBM should also behave like this - producing the full sine wave when possible, then falling back to the leading-edge dimming waveform otherwise.

Crucially, outputMode shouldn’t change what waveform you get in SBM - you should still get full sine wave when possible, even if outputMode = “Dimmer”.

Right now, in SBM, the switch generates a waveform as-if it wasn’t in SBM mode (just locked at 100% brightness).

Here is the full table of all possible smartBulbMode + outputMode + switchType configurations and their resulting waveforms, as observed with FW 2.14 and a neutral connection:

smartBulbMode	outputMode	Single Pole	3-Way Dumb	3-Way Aux	Full Sine
SBM Off	On/Off	trailing	leading	trailing	full sine
SBM Off	Dimmer	trailing	leading	trailing	trailing
SBM On	On/Off	trailing	leading	trailing	full sine
SBM On	Dimmer	trailing	leading	trailing	trailing

This is what I'd like to see:

smartBulbMode	outputMode	Single Pole	3-Way Dumb	3-Way Aux	Full Sine
SBM Off	On/Off	full sine	leading	leading	full sine
SBM Off	Dimmer	edgeMode	leading	edgeMode	full sine (ignore dimming)
SBM On	On/Off	full sine	leading	leading	full sine
SBM On	Dimmer	full sine	leading	leading	full sine

Entries with edgeMode would use leading-edge or trailing-edge dimming, based on the setting of the upcoming configuration option.

Adopting this table would result in using the safest/most-compatible waveform in all cases. Trailing-edge would only ever be used in dumb bulb dimming applications when the user has explicitly opted into it (via the new edgeMode option).

grooves12 · May 12, 2023, 8:48pm

If I am reading that right, doesn’t that mean having a clean trailing edge wave would be possible if it was made a distinct option. The issues with “certain LED bulbs” sound like it would be those designed for leading edge dimming, so switching the option would eliminate the need to mess with the trailing edge wave and wouldn’t the same be true for the AUX, since it seems to only apply to capacitive loads?

PJF · May 13, 2023, 12:51am

Does it really matter if it’s not symmetric unless you try driving a load that you should not be?

I see it being off, but I just don’t see how it matters for LED or incandescent bulbs.

wardwolfram33 · July 17, 2023, 10:22pm

Any update to disable the trailing edge feature?

I have 5 lights in my livingroom where small to medium brightness pulsing takes place every 10-30 seconds. I run these lights at 10% brightness. I am pretty sure this started with the 2.14 FW.

Thanks in advance,

wardwolfram33 · August 1, 2023, 7:27pm

Any updates to disabling the trailing edge feature?