Smart Bulb Mode Optimization Thread

Switches Firmware Discussion
, ,
1

Disclaimer: I’m not an electrician nor an engineer so if you see something wrong in my explanation below or as I’m going through and responding, please feel free to correct me. I won’t be offended, I promise! My role is to collect the input from this thread and package it up nicely so that the everyday person (like myself) can understand it and use it easily. I’ll try my best to ask for clarity if I don’t understand.

Purpose
The purpose of this thread is to discuss smart bulb mode on our switches. If I’m being honest, this feature has taken on a mind of it’s own and even I don’t understand everything it can/can’t do. I’ll outline below the history of Smart Bulb Mode, the way in which we approached it and then at the end we’ll track the changes we’ve made (and will continue to make based on feedback) so at the end of the day, we can perfect this feature as it’s a major selling point and need in the industry.

Vocabulary
Before we dive into the history, approach and game-plan moving forward, it’s important to understand the vernacular used as it can be confusing and I will admit, I’m the primary culprit who made everyone confused as I didn’t quite understand the technology or terms being thrown around (here’s my public apology – sorry).

image
image1996×1270 517 KB

Disable Relay
This was used a lot in our marketing, but I regret daily ever using this phrase as I found out later, it’s the wrong phrase to use and I get reminded almost daily here lol. I’m going to do my best to not use this phrase moving forward. However, for explanation and historical purposes, here’s what was meant by this phrase – the switch has two ways to disable the internal relay (again, I realize now that the dimmer does not have a relay so this term is incorrect): local (at the switch) and remote (via Z-Wave and your hub).

The way this phrase was used was that smart bulbs could now be controlled by disabling the internal relay from turning off (and thus keeping 100% power to the bulbs).

Disable Local & Remote Control
These are the new phrases I’m trying to push as they are a more accurate depiction of what’s going on. Alternatively, enabling local & remote protection can be used interchangeably here, but for simplicity sake, I’m just going to use the above phrase (disable local and remote control).

  • Disable Local Control = removing the ability to control the load of the switch at the actual switch
  • Disable Remote Control = removing the ability to control the load of the switch remotely (via Z-Wave commands and your Hub)

Scene Control
Scene control means the Z-Wave Central Scene Command is used to control another smart product. An example would be: Double Tap the smart switch and your smart lights turn on purple at 75%. This is commonly used on our switches with non-Z-Wave bulbs.

Associations
Associations are used to communicate Z-Wave product to Z-Wave product. It is a one-way street in that only Product A can talk to Product B (B cannot talk back to A via Association). There is a limit to how many devices Product A can control via Associations and currently our switches only support up to 5 other products. In addition, in order for Associations to work, the same security level needs to be applied across the products (No Security, S0, or S2).

History of, "Smart Bulb Mode"
Ok, so now that we have the vernacular out of the way, let’s talk a bit about the history and how we approached what is now called, “Smart Bulb Mode”.

Problem
The problem with putting smart bulbs on smart switches (or dumb switches) is that the bulbs require constant power to them in order for them to communicate with the hub/gateway they’re attached to.

Remember my disclaimer here: Traditional switches have a line attached to them (120V) and a load that goes to the light bulb and when you toggle the switch, there is a connection that either opens or closes which turns on or off the light. In smart switches, there is a relay that opens and closes, which turns on and off the load it’s connected to. It was my mistake in thinking relays are in every type of switch and why I referred to disabling local control as disabling the relay.

Either way (dimmer or on/off), there needs to be a way to keep electricity to the load to power the smart bulb.

Solution (Our Approach)
The solution has evolved (and still is evolving) to this problem over the years and while it started out, “simple”, we’ve come to realize there’s a lot to take on here. It’s not as simple as just allowing a way to keep constant power to the light/load (that was so Inovelli circa 2017), but rather now there is an LED bar, 3-Way scenarios, non-neutral scenarios, etc. Below is how we’ve tackled what’s now referred to as, “Smart Bulb Mode”:

2017 - July 17, 2020
We didn’t call it SBM back then nor had a specific feature to enable this quickly. How we approached making smart bulbs work on your switch was to do the following:

  • Install your switch and turn the power on to the load (and to 100% for dimmers)
  • Disable local control at the switch (Gen 1 switches could do this with a tap sequence on the paddle, Gen 2 switches do this by pressing the config button 8x)
  • If you had a Z-Wave bulb, use Associations (Groups 2 & 4 for On/Off and Dimming control – NOTE: On/Off switches did not include Group 4) and if you had a non-Z-Wave bulb, use Scene Control (Various taps = change dim level of the bulb and/or color)

That was it! The premise was simply to allow full power to your smart bulb and use either Associations or Scene Control to control your smart bulb. This worked (and still does quite frankly) for 99% of use cases and the average user.

But you guys (and girls) aren’t average users and challenged us with different scenarios!

Limitations (Firmware/Hardware)
As mentioned above, SBM is much more complicated than just providing power to the load/light. With the addition of the LED bar on our switches, 3-Way setups, limited Z-Wave 500 Series space, and trying to translate this across languages and cultures, it’s been a real challenge to try to keep up.

Before we go into the modifications we’ve made, it’s important to understand the limitations from a hardware and firmware standpoint.

LED Bar (Dimmer)
Starting with Gen 2 (Black/Red Series) we added an LED bar that will track the dim level of your dumb bulbs. When you disable local control, the LED bar no longer showed you the level at which your light bulb is at.

3-Way (or Multi-Way) Setups w/a Dumb (Existing) Switch
I’m not sure if this is a hardware or firmware issue, but as of right now, if you enable local protection and use a dumb switch on the end of a multi-switch setup, operating the dumb switch will override the local protection on the Inovelli.

Local vs Cloud Processing
If your hub does not support local processing, the speed at which commands are sent can vary and user experience can suffer. In other words, trying to mimic the way a dumb bulb works with your smart switch will be very difficult as it takes time for the cloud to process.

Mixed Protocols
Similar to the above limitation, mixing protocols can be difficult as you are sending a Z-Wave Command to the hub to process and then converting that to a different language (ZigBee, WiFi, etc).

Limited Z-Wave Space & Certification Woes
Since most switches (aside from the Fan/Light) run on the 500 Series chipset, they only have a limited amount of space. So we have to make decisions as a company on what features we keep in vs take out for our production runs. Every time we make a change and produce it, we have to get it re-certified ($$$$$). In addition, our larger B2B customers do not require all the fancy features, but do need some of the features less used by power users, so we have to weigh that in our decision.

Keeping all this in mind, what we tried to do with SBM is to provide the best user experience we could to mimic using a dumb bulb on your smart switch, all the while keeping it easy for the average user.

Present Day, “Smart Bulb Mode” Implementation
So, with the limitations in mind above, we created SBM to work the following way when parameter 52 (SBM) is enabled:

  • Switch delivers 100% power output to your light/load
  • Local Control is disabled (so no one at the physical switch can turn off the light/load)
  • Remote Control remains enabled

We kept remote control enabled for safety reasons. If you’re away from your house and there is an issue, we want there to be a way for you to turn off the switch. If you would like remote control disabled, you can still select this via a separate parameter.

Wishlist & Enhancements
Below will be a running list of ideas on how to improve SBM. I’ll capture everything and then cross them off when we implement them. If we cannot implement them or we come to the conclusion it wouldn’t make sense, I will cross them off and provide an explanation as to why. Please do not be offended if your idea is crossed off – we promise we’ll discuss it in the open before making a decision.

  • LED Bar Tracking: Have the LED bar track the level at which your smart bulb(s) are at

    • Q1: What if there are multiple bulbs at different levels?
    • Q2: Associations – can this already be accomplished via Associations (Group 3)? I’ve seen mixed reviews across the forums, but I haven’t personally tested myself.
    • Q3: Non-Z-Wave Bulb Tracking – what’s the current best way to accomplish this?

  • 3-Way Compatibility: SBM should work in a 3-Way setting with a dumb switch or aux switch. Currently this is supported with an aux switch and Z-Wave bulb only via Associations.

  • Security Level Choices: This is now needed due to SmartThings not allowing the choice of security levels when including (to be clear you never could choose, but the work-around no longer works).

I’m sure I’m missing something and I’ve taken about 6hrs to write this out, so I feel like I’ve exhausted this topic in my mind for today. Please comment below and I’m looking forward to the discussion!

3 Likes
3

Here is how I envision Smart-bulb mode:

Load output is locked at 100%, and cannot be changed by local or zwave commands. Switch will still simulate brightness levels, and will still send commands to associated devices. This should be similar to hard-wiring the bulb to be always connected to power (although pulling the air-gap will still cut power to the bulb). You can change the dimming level all you want, and LED bar will reflect the change, but the load will always be at 100%

On button press:

  • Pressing ON button will cause no change in the actual load output (always 100%)
  • Pressing ON button will scale the dimmer’s internal “Level” value based on the value in Parameter 9 (default level). The scaling duration will be based on the ramp rate
  • Pressing ON button will scale LED strip to appropriate level based on the dimmer’s internal “level”
  • Pressing ON button will send Basic Set command with value from internal “Level” to devices in association group 2
  • Pressing ON button will send Multi-level Set command with value from internal “Level” and duration as defined in Parameter 4 (Ramp Rate) to devices in association group 3

On button Hold:

  • Holding ON button will cause no change in the actual load output (always 100%)
  • Holding the ON button will send multilevel Start command and duration as defined in Parameter 2 (Dimming Speed) to devices in association group 4
  • Holding the ON button will cause its internal “level” value to scale up as if it were increasing brightness
  • Holding the ON button will cause the LED strip to scale up as if it were increasing brightness
  • Releasing the ON button will send multilevel Stop command to devices in association group 4
  • Releasing the ON button will send Multilevel Set command with brightness equal to internal “level” on the dimmer, and a duration of 0 to devices in Association group 3 (this will cause associated devices to “sync up” their brightness levels)

Off Button Press:

  • Pressing OFF button will cause no change in the actual load output
  • Pressing OFF button will cause internal dimmer’s “level” to scale down to 0 with duration based on ramp rate
  • Pressing OFF button will cause LED strip to scale to 0 based on internal “level”
  • Pressing OFF button will send Basic Set command with value 0x00 to devices in association group 2
  • Pressing OFF button will send Multi-level Set command with value 0x00 and duration value as defined in Parameter 4 (Ramp Rate) to devices in association group 3

Off Button Hold:

  • Holding the OFF button will have no effect on load output
  • Holding the OFF button will send multilevel Start command and duration as defined in Parameter 2 (Dimming Speed) to devices in association group 4
  • Holding the OFF button will cause its internal “level” value to scale down as if it were decreasing brightness
  • Holding the OFF button will cause the LED strip to scale down as if it were decreasing brightness
  • Releasing the ON button will send multilevel Stop command to devices in association group 4
  • Releasing the ON button will send Multilevel Set command with brightness equal to internal “level” on the dimmer, and a duration of 0 to devices in Association group 3 (this will cause associated devices to “sync up” their brightness levels)

Basic Set Command Received by dimmer:

  • Basic Set 0x00:
    • No change to load output (still at 100%)
    • Internal “level” value set to 0
    • LED strip turns off
  • Basic Set 0x01 - 0x63, 0xFF:
    • No change to load output
    • Internal “level” value set to value received
    • LED strip is set to value received

Multi-Level Set Command Received by dimmer:

  • Multi-level Set 0x00:
    • No change to load output
    • Internal “level” value scales down to 0 based on duration value received in command
    • LED strip scales down to 0 based on duration value received in command
    • If permitted by Parameter 12 (Association Behavior), forward the command to devices in Association group 3
      • Use Duration value that was received in the Multi-level set command.
      • If no Duration value received or if duration value = 0xFF, use value from Parameter 3
  • Multi-level Set 0x01 - 0x63, 0xFF:
    • No change to load output
    • Internal “level” value scales to received value based on duration received in command
    • LED strip scales to received value based on duration received in command
    • If permitted by Parameter 12 (Association Behavior), forward the command to devices in Association group 3
      • Use Duration value that was received in the Multi-level set command.
      • If no Duration value received or if duration value = 0xFF, use value from Parameter 3

Multilevel Start/Stop commands:

  • No change to load output
  • Scale internal “level” based on duration value received
  • Scale LED scrip based on duration value received
  • If permitted by Parameter 12 (Association Behavior), forward the command to devices in Association group 4
    • Use Duration value that was received in the Multi-level Start command.
    • If no Duration value received or if duration value = 0xFF, use value from Parameter 1 (Dimming Speed)
  • After multi-level stop command is received, send a multi-level set command to devices in Association group 3 in order to force everything back in sync

Most of this functionality seems to exist in beta firmware 1.52. The only thing I really see that is missing is the ability for the dimmer to send duration values as part of the multi-level switch command, and the fact that sending a value of 0 via zwave will cut power to the smart bulbs. Based on the information above, the questions about LED bar tracking can be answered:

The bulbs are all synced up by the switch when you press the buttons on the switch or change the switch brightness via zwave. If you control the smart bulb directly, it will temporarily be out of sync until the next time you control the switch. This is similar to how the virtual 3-way setup works. You just need to send commands to the switch, and let the switch forward them to associated devices.

Other than the lack of duration values and sending brightness of 0 via zwave cuts power to the bulb, then yes, Associations are the way to go if your smart bulbs are zwave.

The benefit to this method is you can read the “level” of the dimmer. The dimmer would still send a multi-level report to the hub when its internal “level” changes, even though the load is still outputting 100%. A user could set up an automation to send a value to their non-wave devices when the “level” of the dimmer changes. This could be accomplished even without the use of scenes.

3 Likes
4

THIS. Those of us who understand (and install) home automation, Z-wave and Zigbee protocols, thought this was the way it was going to be from Day 1, hence why we were raving about the arrival of the Red Dimmers when they were announced. Unfortunately this was not the way it was implemented.

And since the dim level is being sent to the hub of your choice, it’s then up to the hub to “distribute” the intended dim level to the various bulbs the user decides. Heck, you could even mix and match bulb technologies on different electrical circuits because the hub could do the necessary commands whether it’s a Z-wave bulb, Zigbee bulb, or another z-wave dimmer on a different circuit controlling a dumb bulb.

Like I’ve said in the past, you do THIS… and I will buy dozens and recommend to anyone that this is the ultimate dimmer to solve almost all smart home use cases.

What SBM should do is basically turn the Red Dimmer into a Z-wave remote dimmer. It dims, sends the multi-level reports, but doesn’t do anything to the local load. Basically doing the same thing many of us accomplish today by buying a Z-wave remote dimmer like the Eaton 9542 and hard-wiring the light socket where the smart-bulb is to be always on.

I’m dumbfounded why the Inovelli team doesn’t get this concept? If it can’t be technically done then simply tell us.

1 Like
5

I agree with 99% of everything @jtronicus and @TC1 said. If this were how it was first implemented then I would 100% agree. However since we’ve had “SBM v1.47” for over 6 months now, I’ve made use of the way it controls the load 0% or 100%. Basically everything is the same except that it turns off the load if the internal SetLevel is 0. Any other level the load is 100%. Perhaps the long term solution would include a separate parameter for this. But I think it could be mimicked if Parameter 5 (Minimum Level) was allowed to be set to 99 (or 100) so the Minimum load output was always 100% unless it was set to 0 then the load would be off.

In Summary, I agree SBM should have a mode or setting that keeps the load output 100% all the time. But since we’ve had the 0%/100% off/on capability for over six months now I don’t want to see that go completely away. Instead of making it a separate new parameter, my suggestion is to allow setting the existing Parameter5 Minimum Level=99 which would force the load to always be 100% except when off (mimicking SBM v1.47 behaviour). Alternatively it could be a new parameter (“disable dimming”) if you prefer to implement it that way.

Yeah, I’m a bit baffled how this got so complicated. Maybe there are internal hardware/firmware reasons that make it more complicated than it should be? Or maybe its just a language barrier? However, the concept is really quite simple:

The existing Red Series Dimmer basically already has all the functionatliy in it. The only thing needed for SBM was a setting to lock the load at 100% (unless airgap is pulled) while still performing all the other existing dimming functions (sending button-Held/Released events, Level status reporting, Led Bar level tracking, etc). Nothing else needed to change.

Related to this, and due to how SBM was implemented in v1.47 (and used for over 6 months now) I would like the long-term solution to retain a “disable dimming” function which would basically retain how SBM works now in v1.47-v1.51 but be renamed more closely to what it does. As mentioned previously, this might be as simple as allowing Parameter 5 the full range of 1-99 where 99 is effectively “dimming disabled” (its currently restricted to 1-45). Or, it could just be a new parameter to enable/disable load dimming (while still acting like a dimmer in all other ways)

6

If it would be possible for scenes to be utilized when an aux switch is multi tapped, held up/down, etc, that would be awesome.

1 Like
7

Everything this person says is perfect, and exactly matches how “Dimming enabled + always on” would work in my suggested approach.

8

Just to be that guy, but it is pretty clear that the Inovelli guys are trying to understand the details of what everyone is asking for. I don’t think they are talking around it or withholding information, they are truly trying to get a better picture of what you guys are expecting.

As an independent 3rd party who has just been reading along with all these messages, I was having a similarly difficult time parsing all of what is being asked for in these threads. So it’s not just them.

2 Likes
9

This 100%. Let’s try to be polite and not make these folks regret the amazing level of transparency and engagement they’re giving.

10

Just to be that guy… that’s the problem. They are paying too much attention to individuals on the forums that are asking for features to compensate for the limitations of their chosen platform. I too read through some of those threads and my head spins trying to decipher what these folks are asking for.

Myself, along with others, are trying to approach the issue from a professional point of view. In other words, this how Z-wave works, this is how Zigbee works, this is what would solve that problem while adhering to standard practices across any Z-wave compliant platform.

Yeah, I’ll get flamed for saying the above, so be it.

My only motivation is to get the best Z-wave dimmer possible that can be applied in the widest possible use-cases (not one-off requests from individuals). That’s what sells product in the quantities necessary to make a profit and stay in business.

1 Like
11

Sounds like there’s just a bunch of guys here trying to make a better product. This guy included.

Thanks everyone for the feedback and for breaking it down for us - very helpful!

@EricM_Inovelli & @JasonL_Inovelli - let’s talk about this early next week.

2 Likes
13

You just proved the point of my subsequent post, that if they keep trying to solve for one-off use cases then the product will never get released/finalized. The 500 series Z-wave chips this product is built around has limited memory and hence functionality. It’s literally impossible to solve every possible use-case, so you solve the ones that have the broadest impact, and hence financial return.

If they make a Z-wave remote/accessory dimmer that has the option to handle a local load then they have solved the majority of use cases I’ve seen in my 20+ years of doing home automation.

14

I was happy to see this as I read through your long post. :slight_smile: I was like, “this is how it basically works right now!” LOL.

So The BasicSet and SwitchMultiLevelSet 0x00 are adjustments we are planning. Duration with the multilevel commands is something that sounds doable as well.

I believe this is already possible with 1.52. We just need to adjust the BasicSet and SwitchMultiLevelSet as mentioned above.

15

If so then that’s great news! Unfortunately I don’t have a set up in my lab that can handle flashing the two different firmware targets. Yet another project to add to the to-do list, but I look forward to testing this out and buying more Red Dimmers if successful.

Appreciate the feedback.

16

Yeah, I think for folks are trying to keep the bulbs in sync with the switches (using associationGroup 3), then basicSet 0x00 and multiSet 0x00 would be important.

Personally, I don’t use Smart Bulb Mode since I can replicate the exact same behavior by disabling local control and keeping remote control enabled. Just want to ensure that if remote control is enabled and Smart Bulb Mode is disabled, I can still turn off the switch via zwave (i.e. the changes you’re looking to make would only apply to Smart Bulb Mode).

Actually, is that all Smart Bulb Mode currently does? Disable local control and enable remote control?

17

I would suggest the following target behavior…

When SBM is on, the switch/dimmer’s relay is always at 100%. The dimmer’s switch_multilevel exists purely virtually, affecting z-wave associations but not the actual power flow.

For times when you actually want to kill the power, that could be done two ways. One would be by pulling the airgap switch. The other would be with a configuration parameter. With the switch_multilevel being totally decoupled from the load control, you ideally need a way to still override the load control. And a config param would be it.

Result is any control to the smart bulb should go to the switch. In the hub you basically just hide the smart bulb, and always send control commands to the switch.

18

I have been away for a loooooong time and just look at all the excitement I’ve missed. I am so pleased to see so much development in this area (and the configurable button delays…)!

My $0.02… as a Hubitat user, I would want to sync my dimmer switch driving some assortment of smart bulbs (be they ZWave, ZigBee, WiFi, Thread, ACN, DMX…) to a hubitat “group” device. This gives a layer of abstraction that nicely aligns with what the dimmer switch is capable of communicating both to the user and the controller. It is a convenient 1:1 in that the dimmer switch logically controls the group and the group then drives the lights contained within it. I even could imagine using the LED bar to optionally give a “hint” of the color chosen for the group or perhaps time of day for the circadian rhythm folks.

19

Late to the thread, but I have been one of the most vocal individuals on this feature and this is 99.99% effective at killing my needs on this issue.

Only because I can NEVER be 100% satisfied (of course), something has to keep me coming back to these forums!

Edit: The z-wave command to level 0 turning the switch off (If I understand it correctly) is unfortunate. When I set the switch into SBM, I never EVER want the power to be cut unless I yank the air gap.

MAYBE allowing a specific scene or something (like enabling manual control via 8 config clicks then toggle down, which already does that) that only I know could cut the power, but for now if I automate any switch to off (bedtime) then it cuts power to the bulb and my mesh is screwed. Right?

20

FYI I believe @EricM_Inovelli said this behavior can be changed in driver. I can’t find the post at the moment.

1 Like
21

Found it:

I’ll cede to the others above describing the need, but sacrificing a safety feature in a smoke/CO2 incident (actually I think the OPPOSITE is safer, where I enable ALL lights to 100% when there is smoke detected, as I did in STHM actions for smoke) in order to enable automations to turn off the switch without turning off the load is an easy choice for me.