Cannot provide clean power to smart bulbs via LZW31-SN

Inovelli friends,

I’m finally getting around to experimenting with smart bulb control using an LZW31-SN (Red Series Dimmer). I am going to use a ZigBee smart bulb just to keep things interesting. So I followed the multitude of posts here and the instructions on the support site to disable both Local (paddle) and ZWave control using the dropdown in the Hubitat device page. I “Saved Preferences” twice just in case that old (rumored to exist) bug might still be lurking.

I think I might be missing something. Now that local and remote control is disabled I expected the power to always be on at full so that the smart bulb would be receiving continuous power. That’s not the case however. The dimmer remains at however it used to be set. So for example if I set the dimmer to 55% then disable local and ZWave control, the output will be fixed at 55%. The same goes for 0%. If I turn the switch off then disable local and ZWave control I get no power to my connected smart bulb. (Curious for later testing: I also wonder if there is something going on at “100%” where since it is a phase control dimmer the AC waveform is still being effected even in some tiny way.)

I understand that I can wire (hack?) around this to bypass the problem but that would interrupt power monitoring and prevent use of the air gap. I would prefer to use the safer and more stock approach.

A few particulars:

  • Hubitat is running the latest firmware (
  • LZW31-SN dimmers throughout my home are running firmware 1.43
  • The driver I am using is the official Inovelli driver from GitHub dated 2020-05-13
  • I have non-neutral and neutral situations in which I would like to test smart bulb functionality. I’m not sure if one vs the other will better/worse support this.

I don’t use smart bulbs like you’re doing, but I thought you are supposed to set power at 99% (fully on) on the dimmer and disable local relay by tapping config button 8x. Thus will provide continuous power to the bulb.

Latest driver for dimmer is 02JUN20

Unless you have an Oscope to show the power going to the bulb is dirty, I would it’s not dirty.

I think that disabling control and disabling the relay are two separate functions. Disabling local or remote control disables being able to do switch functions. Disabling the relay provides the continuous power as @harjms pointed out.

@Bry The way I read the docs and some threads here — toggling both of those settings on the device page is equivalent to the 8 button press routine.

@harjms In an attempt at this just prior to my original post I was unsuccessful. I set the dimmer to full using the device page and then I used the two advanced settings to disable local and Zwave control. I still got a flickering bulb which looks cyclic like an interrupted AC waveform and not some sort of ZigBee glitch. I tested the same bulb installed in a non dimmed socket I use for testing and it works perfectly without issue (that’s how I paired it with the hub initially too which worked without issue on the first attempt).

@rpulivella - Have you tried doing this locally vice remotely? Don’t attempt doing it via device page. Physically press the buttons to 100% (99% really). Confirm bulb doesn’t flicker. Disable local relay via config button.

@Eric_Inovelli should confirm one way or the other. I know that discussions about disabling the relay are among his favorite! :joy:


@harjms I did just attempt the physical button method and got a very different result… I don’t think I can post videos here but you should see this rave color strobe I have here… ugh! To be clear this method still was unsuccessful and I got yet another variation of failure where this go around I cannot even drive the bulb at all much less get stable enough output to see the cyclic flicker/artifacting I experienced the first time around.

@Bry here’s hoping the Erics can sort this out! It seems simple enough and I’ve followed the various versions of the documentation but still no luck.

You should’ve added some quotes around “disabling the relay”.


Nope, I’m not gettin’ lumped into that camp!


LOL! I honestly sit up at night waiting for the next, “disable local internal relay” conversation!

Yes, this was the latest dilemma we found with our manufacturer and we’re addressing in a new firmware update.

The problem was in a 3-Way scenario (with a dumb switch), there were issues of bulbs shutting off at random and what we found was that some bulbs needed to be maxed valued at 80-85%. This fixed the shutoff issue.

However, this presented a new problem with smart bulbs. Since the firmware maxed out bulbs at 80-85%, it did not provide full power to smart bulbs and some experienced the flashing/strobing issue. We noticed this on Hue.

So, we went back to the manufacturer and proposed a solution to where the value of the bulbs will be set for 100% if not in a 3-Way setting with a dumb switch (since you can’t really use smart bulbs in a 3-Way with a dumb switch anyway).

They then said, “sorry, there’s not enough memory left on the chip” – so we proposed removing a couple of features (invert switch locally and one other thing that no one uses) and they said that will work. So, we should be having a new release next week. The engineer said he needed 1wk and that was last Wednesday.

Perfect lol


Does this mean that all of my dimmers are internally maxed at 80–85%? A setting of 99% on the device page — no matter what other settings/parameters have been adjusted — leads to 80–85% output? Or is this only in effect when certain other settings are enabled/disabled? All Inovelli dimmers in my home are running firmware 1.43 at the moment.

This makes complete sense and is an effective solution. It’s almost like introducing a special case “switch type” for smart bulbs.

I am shocked at how much you’ve been able to pack into/achieve using an 8051. That’s a very constrained architecture especially when there’s a full wireless stack to run! I’ll bet you’re looking forward to building switch/dimmer products with the 700 series as you get a lot more from the Cortex M4 than that 8051. Either way it sounds like you’ve worked out a solution with your engineer?

Wonder what that “one other thing that no one uses” is…?

I’m looking forward to it!

Yes, this is how I interpreted it from the manufacturer – @EricM_Inovelli – can you confirm this?

No, it’s permanently in effect now regardless of any other settings.

Yeah, our Fan/Light switch is running on the 700 Series, which is exciting :slight_smile:

Yes, we worked out a solution – they should have something for us early next week!

I just said this bc I couldn’t remember lol. I think we suggested, “default level z-wave” (ie: setting the default level on for zwave). But remember, these are just if you need to configure this via the configuration button. These settings will not be lost if you have a hub that will allow you to change parameters.

Unfortunately v1.45 did not fix the smart bulb problem I described here. See my post in the v1.45 thread for more.

I guess I just want to say that with 1.45 my switches set at 99% (nothing set for max value in settings) and disable local control enabled, I get a clean 124V in and 124V out, and my zigbee bulbs run happily using solely scene control via ABC Manager.

Not sure how/why/what is up here, but you should be able to replicate my setup without issue.

  1. Confirm settings for max value is 99 or default.
  2. Enable remote control so you actually can control the dimmer level temporarily.
  3. Dim up to 99%
  4. Make sure no automations or whatever are controlling the level of the switch. Hide from interfaces so it just lives at 99% forever.

That Should get you what you are looking for.

I don’t think this is the case. Perhaps firmware/software were revised down, but I get full line voltage on the load side at 99% dim.

I have a brief update to my struggle to report. I still am waiting for my Z Wave USB sticks to arrive from DigiKey. Until that time I only can update target0 aka the .otz file. I’ve now tested with several different load types in a non-neutral configuration and cannot get stable output from load less than ~50W much above 60% on the dimmer. This by extension would includes any smart bulb since the wall dimmer level has to be set to 99 to pass along clean power.

What seems to happen (and this is especially noticeable with smart bulbs) is that the wall dimmer goes into a reset loop. This sends any smart bulbs into a rave panic, conventional LED bulbs into a fast strobing flicker, and incandescent bulbs into a smoother pulsed effect. Above that 50W threshold or below 60% works normally with conventional loads so far but of course this does not help when trying to use smart bulbs which require clean line voltage.

I had hoped that in my non-neutral circuits (I sadly have a few) I could use smart bulbs with Red Series dimmers to enable better performance and features but perhaps I’m discovering otherwise?

Has anyone else had success in non-neutral situations with smart bulbs running v1.45 (or any other firmware)? What tricks were required to get it working and what is the overall wattage on that circuit?

Can someone confirm that with a neutral, smart bulbs work as expected without issue?

Definitely had this happen (on v1.45) with a non-smart 15w LED fixture with the dimmer wired to neutral. Had a very “club-ish” feel… :slight_smile:

I finally have some updates to report! My ZWave Stick finally arrived from DigiKey. As I’m a Mac user I had to dig up a Windows 10 virtual machine from the ashes. Take took a little bit of extra work but I did get the ZWave developer tools installed and working on the VM. I managed to update all my Inovelli devices to current 1.45 firmware and update all the Holtek target1 firmwares too.

In all my testing I can report the following:

  • With a neutral present and the driver in Hubitat configured appropriately, smart bulbs and low wattage non-smart LED bulbs work perfectly without any issues. This is a notable improvement over previous tests. Right now I am up to a few hours of run time in this configuration without any issues at all.
  • Without a neutral the situation is worse for smart bulbs with 1.45. All I get this go around is a dimmer with its LED bar blinking red at a constant rate. I no longer see a rave mode from the light source and the dimmer appears to be very upset otherwise.
  • Without a neutral non-smart LED bulbs still exhibit instability in the same way as previous firmware versions. The “75% threshold” seems to still hold true where at 70% most loads are stable and dim without issue. At 75% or more, with loads approximately 50W or less, the dimmer will reset as though power was lost. I suspect that is what is happening as when the dimmer becomes functional again it will obey the “State After Power Restored” value as set on the device page. In addition (and this is particularly related to smart bulbs) if that “State After Power Restored” value is set to 75% or more the dimmer will go into a reset loop where every time it reboot itself and raises up to that value it restarts the reset loop again.

Hoping someone else either can confirm my results or tell me what I can do differently to overcome these issues?


Try 1.47 and sit there and make sure it works for both updates. The .bin has been especially troublesome not completing for a lot of us. See the 1.47 thread.

Mine are all neutral so I can’t help on the particular issue. But it seems like the .bin might not be applying properly. I’d work to exclude from your hub, reset the switch (20+s config button until red) use the z-wave stick to update it on it’s own z-wave network (instead of being a secondary controller) and then do some testing.

Edit: Also since you have hubitat @bcopeland now has an updated driver to push both the .otz and .bin to the switches in the future. For this iteration to get it working I’d do it in it’s own little network.

@kreene1987 I updated all switches with both targets using a ZWave Stick and PC Controller prior to posting my last update. Just a few days ago I updated again to 1.47 all around. There have been several noticeable improvements but I have not yet tested smart bulb functionality. That’s coming soon…

@EricM_Inovelli I am thrilled to see the inclusion of a specific Smart Bulb Mode. I cannot wait to try it later this week!