This is almost politician-level false.
They can/are completely integrated and track each other. No matter what trigger controls my switch or light, they follow each other and the end user is completely unaware of any smarts whatsoever.
Yes it does take some proper setup.
Both good points. I totally forgot about energy stats. I’m guessing the bypass is still less of a code violation/safety risk than running the outlets on a dimmer, though.
No question!
In a neutral configuration, it does not need a load. You can use it as you’re suggesting, a scene controller. If it’s a non-neutral, then it needs a load as part of powering the switch voodoo.
I didn’t realize they can be completely integrated. That is great. I would like to get some color and warmth changing Philips hue bulbs soon to go in some inovelli red series switches.
What I meant was more if you have either the choice of doing only a smart switch vs a smart bulb. The switch is the more integrated solution and physically tied to the house? I haven’t really used smart bulbs so sorry for the dumb politics!
Hey no issues at all! I will say that using different technologies (zwave and hue/zigbee) will not be AS integrated as sticking with one solution (zwave), but they can be made to work pretty well together.
Ilumin Ilumin, wherefore art thou Ilumin…
Just throwing my $0.02 in here in regards to what I would like out of smart bulb mode after using it for a couple months.
From my understanding, it seems like the following settings are planned:
If this isn’t true, please help me understand what is planned better. If it is true, is it also true that within “always on” the LEDs will still reflect on/off/dim level while still always delivering 100% power? I think that would be ideal.
In my head, the “always on” setting would allow you to still change the brightness slider (locally or remotely) and that would only change the LED gradient. The dimmer would still output 100% power. Then, you could still use Disable Local Control to determine if you want the dimmer to change this brightness through holding the up/down button or if you want it controlled exclusively through scenes. Same for on/off through single tapping the dimmer buttons. With keeping this setting to the dimmer brightness slider itself, users could decide to leave it alone or change it depending on use case.
My only “complaint” about the “current” (1.52) way smart bulb mode works is that I can’t control the LED bar height. Like, if my bulbs are dimmed or off I want that reflected in the LED bar. I can turn them off via webcore when the lights turn off, but I can’t set it to what it would be for % brightness, so they’re just always on at full brightness all the time.
Nailed it and yes that is exactly as planned.
I think for On/Off mode, the device will still simulate dimming (I can set the brightness to 1%, and it will still report 1%, and the LED strip would indicate 1%), but the load will still output 100%. Basically, the dimmer behaves as it normally would, except the physical load output is either off (when brightness is 0) or 100% (when brightness is anything but 0)
That is my understanding (and expectation) as well.
The way I would describe it is that the internal dimmer level setting works the same for all modes. Everything about the switch still looks and acts like a dimmer… except for the LOAD output terminal.
In all modes, the LED bar height will reflect the relative internal setting of the dimming level value. If you send a zwave setLevel command it will adjust the LED bar accordingly. And if you poll the switch it will report its current setLevel value. Likewise for holding the paddle up or down, it will adjust the internal level value and also the LED bar height as well as sending the dimming value out via zwave.
In other words, the only difference between the three SBM modes is how the LOAD terminal is powered:
SBM “disabled” = LOAD terminal is dimmed according to the setLevel value
SBM “on/off” = LOAD is ON except when the setLevel is 0 the LOAD is OFF
SBM “always on” = LOAD is always ON regardless of the setLevel value
That is not what I’m seeing. The LED bar height still adjusts up or down with setLevel commands even though the LOAD stays at 100% output.
I guess I hadn’t tried that since I updated the firmware. I remember that changing the level made the bulbs flicker. So I’m guessing the upcoming “on/off” will be like it functions now and the “always on” will just allow the LED to reflect the on/off without actually changing the load? I.e., lights stay on when switch (and LED) are off?