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.
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.
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)
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.
Everything this person says is perfect, and exactly matches how “Dimming enabled + always on” would work in my suggested approach.
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.
This 100%. Let’s try to be polite and not make these folks regret the amazing level of transparency and engagement they’re giving.
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.
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.
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.
I was happy to see this as I read through your long post. 
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.
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.
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?
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.
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.
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?
FYI I believe @EricM_Inovelli said this behavior can be changed in driver. I can’t find the post at the moment.
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.
Can you help me understand this better? Taking a z-wave device offline (out of the mesh) is never recommended and is 99% of the reason this entire debacle started. There is no reason ever that any communicating device (z-wave/zigbee/wifi, etc.) should EVER be taken offline, it should instead be commanded off (level 0). From my perspective.
Almost, right now if you set the dimmer level to 0, the switch turns off and kills the power to the bulb, taking it offline.
This update should allow toggle down or setting dimmer level to 0 to turn off the LED bar (or to full bar at whatever brightness is in said parameter) and the smart bulb (level 0), while keeping both online and the mesh intact.