If the Blue 2-1 switch is programed in Smart Bulb mode, how does the switch behave if the hub (in my case Home Assistant) is unavailable (down, updating, offline, no network/WiFi, etc.)? Does the 2-1 switch default to a “regular” switch mode? Assuming can’t use Zigbee binding. Or is Zigbee binding the only way to really do this? Thanks
If the switch is in Smart Bulb mode, the load is always on. So if you are not using Zigbee binding (or Zwave associations with the Reds depending on what the load is), the only way to control the load would be through scenes. If the hub is offline, so will your ability to use scenes, which means the load would stay in whatever the state was when the hub went offline would be my expectation.
1 Like
Thanks chack. Not what I hoped. Trying to mimic the way (human expectation) that you use a Shelly 1 with a dumb switch. In smart (Hub) mode, the relay is always on (power to load), no matter the physical switch position. The light load is then controlled by the Hub. But, if the relay detects a hub signal loss if the Hub goes offline, it reverts the relay to the state driven by the physical switch. “Behaves like a normal switch”. This is done by the ESP8266 in the relay checking for connectivity. I think it would be better if the 2-1 behaved this way. The switch still behaves like the user expectation no matter what the Hub’s condition.
Is binding/association the only way around this?
1 Like
For clarity, if the hub goes offline, you’d like to be able to physically cut the load from the switch?
You’d still be able to pull the air gap to cut power (to the switch and load), or you can manually change the setting for smart bulb mode from the switch through a series of button presses, etc so that it will cut power when off, etc, though that isn’t generally recommended with smart bulbs.
I may be misunderstanding your goal here, but I think both of those would have you covered in the scenario you describe? There is the caveat that it wouldn’t automatically change switch parameters though as binding or association could potentially be at play and the user would still want Smart Bulb Mode to be enabled.
To throw another similar option out there…you can also Disable Local Control from the switch so the touches on the paddle aren’t going to actually control the load. You can still use scenes from the hub in this state, but it won’t be as quick as binding/association is. If the hub goes down you can Reenable Local Control on the switch and then just hit on/off to control the load.
1 Like
@chack I think it’s the opposite from what you described. The OP would like to use the switch with a Shelly, where the smart bulb mode is turned on so the Shelly is constantly powered. The Shelly is then controlled by the hub.
But if the hub goes offline, the OP would like the SWITCH to sense that and respond by turning off the SBM so that the paddle can now make and break the power connection to the Shelly.
Unfortunately, it doesn’t work like that. The switch does not have the capability to monitor the hub for it’s online/offline state, nor does the switch have the ability to change its own parameters.
So, from my understanding, binding is the solution. Which, from a speed standpoint, you might want anyway.
1 Like
Bry, @chack
Exactly as Bry described it. Thanks. Mostly, trying to deal with human expectations (with switches) in the presence of a system failure. The default is always, a switch behaves like a switch. You never want users (non automation folks, significant others, guests or visitors) have to do anything different to make a switch/light work. No mode changes, no pulling the air gap.
I obviously don’t know the switch firmware, but the EFR32MG21 obviously communicates with the hub. Is it not possible to have a “deadman switch” code to disengage the relay control on the loss of the zigbee/z-wave control signal. This is as simple as the ESP8266 code is for checking for the Home Assistant interface connectivity.
if: condition: api.connected: then:
Not a mode change, just a toggle of the relay control. Just food for thought.
In the absence of that, will go work with zigbee binding. Just wish there were more Zigbee bulbs options that did not require a mortgage payment (Philips!). Will look at EcoSmart, but not a lot of options there. Mostly interested in CCT white for adaptive/circadian lighting.
@EricM_Inovelli – is this possible? If so, can we add it to the GitHub wishlist for v2 firmware?
I agree, this would be a good feature to have. My only concern would be false positives or something, but aside from that, I definitely see the benefit (no one wants to leave a cheat sheet on the wall to reprogram the switch lol).
1 Like
Cloud outage or high latency would be annoying.
1 Like
Thanks Eric and team.
Most hubs (Home Assistant, Hubitat) are local and SmartThings will be soon, with their next major release with Matter. Matter and Thread will also drive significantly more local control. Maybe even Amazon and Google might get there!!
For it to work reliably, the API interface with the EFR32MG21 needs to have a good handshake and appropriate parameters.
As I’m new to your forum, do I need to put a request on GitHub or will one of the wizards be better able to articulate it?
Thanks again for a great interaction. This is a great community you have here.
I can add it to our beta Github as a feature request.
I’m a little confused here, are you looking to control bulbs? Or are you looking to control a Shelly?
If it’s bulbs you’re looking to control, you 1000% want zigbee bulbs with binding. There are literally tons of zigbee bulb options out there that do tunable white and colour. Ikea, Sengled, Ecosmart, gledopto, smartthings and I’m just scratching the surface.
If it’s human expectations you’re looking to manage, binding is an absolute must! Running commands through a hub to change protocols to turn on bulbs adds a very noticeable and annoying delay. I guarantee this will get user complaints. I had a zwave switch controlling 6 WiFi bulbs in my office. I was ok with the delay and got used to it, but had family in for a visit so threw a spare bed in there. The very next morning a comment was made about it taking forever for the lights to turn on and the delay is really only 1-2s at it’s absolute worst.
This office now has a blue switch with 6 sengled colour and tunable white zigbee bulbs connected through binding. It’s as fast as hardwired bulbs, including when dimming. And works when the hub is off. FYI, those bulbs are currently $76 USD on amazon for a pack of 6 making them about $12/bulb.
MRobi
What I’m ultimately trying to do here, is Adaptive CCT Lighting. Sometimes called Circadian Lighting. Mostly care about good quality CCT lighting. Any RGB, RGBW, RGBCCT will be limited. The lighting control will be the Adaptive Lighting integration in Home Assistant. Therefore, using BOTH smart lights and smart switches.
Beyond the technology the UI for all users (homeowner, visitors, babysitters, guests, etc.) is critical. A switch needs to behave like a switch (<500mS) when turned off or on by anyone. Similar experience with a dimmer.
Beyond the “normal” use cases, also need to consider how any of these technologies, but in this discussion, the switch, will perform under abnormal or “fail” conditions. The one being discussed here is "how does the switch behave in Smart Bulb Mode, when communication is lost with the automation hub (personally, will only consider local control). My suggestion, is that it needs to behave like a local regular switch, turns the light on and off. A deeper layer on that use case would be, how does the Smart Mode reengage, when communication is reestablished, considering how the switch might have changed state during that time?
The Shelly part of the discussion was only relative to how the ESP8266 code handles a similar situation. Some DYI’er use a Shelly 1 behind a regular dumb wall switch to make it work with smart bulbs. The Shelly is coded so that the relay is always on (power to load), no matter that physical state of the switch. The automation controls the bulb - dimming, color, etc. But if the Shelly switch looses communication with the automation hub, it toggles the relay to behavior and control of a dumb switch. That was from the user experience, the user can still turn the light on and off (but not color or dimming).
From a UI experience you do not want to have cheat sheets or an “automation manual” for all your automation for any of your users.
Changing subjects (slightly) - Bulbs. By the way, ilumin by Inovelli was one of the best, but it’s Z-Wave and can’t get it anymore. My focus is on Zigbee, CCT (tunable white, 2700K-6500K), multiple types (A19 E26, B11 E12, BR30, PAR30 E26, & Filament) and Power-On state (if you are having smart light bulbs in bedrooms, then this is a must-have so it doesn’t wake anyone up during a power outage and restoration):
My experience and investigation, so far:-
Philips Hue:- Biggest selection of bulb types, reliable, large ecosystem and power on, but dim and expensive,
EcoSmart: Only two types that meet the criteria, inexpensive, but no Power-On state.
Novastella: bright and white color accurate. No Power On State and can’t dim very low.
Sengled: inexpensive, white color not very accurate - warm color, orange-ish white,
Ikea: Inexpensive, but their whole TRÅDFRI system is a bit of a nightmare. White temperature tops out at 4000K. Their whole smart system (is about to see a major change next month [DIRIGERA] - will see,
Innr: limited selection and RBGW
Gledopto: limited options and RGBCCT
Smartthings: not CCT
Sylvania Smart: dim
Feit is bailing out LIFX, so maybe something in the future there. As long as it’s not Wi-Fi.
I expect a lot of new offerings and changes in the coming months. New house planned for completion in January! But will probably have to mix and match from multiple vendors. Want to stay away from disco lights - RGB, RGBW, RGBCCT.
But, definitely will pursue the Zigbee biding approach.
Input, corrections and suggestions welcome!
Sorry for the long response, but you asked!!!
1 Like
Some thoughts:
I have, essentially, the same goals as you: switches always behave like switches + circadian lighting.
I’ve gone the Hue route because of the bulb selection (are they dim? Their newer tunable whites get to 1100lumen/75watt equiv) and reliability. Cost matters, but is less important for these types of home upgrades for me.
To solve the UX, I’m doing all binding with smart switches. I currently have a mixture of zwave switches associated with zwave bulbs (work fine) and zwave switches controlling hue bulbs via my hub (not ideal for when my server needs to go down for maintenance/something breaks). Therefore, I’ll be replacing all the zwave switches with Blues to bind to all of my hue bulbs.
Now, this will definitely solve the goals of circadian lighting plus reliable, hardwired-like switch behavior, but has one downside that your suggestion solves: when you operate a bound light at the switch, the only thing the switch can tell the bulb is to turn on to x brightness. It can’t tell it the correct color temperature. Therefore, there is a slight delay between the bulb turning on and it shifting color temperature to the right temp. This doesn’t bother me a lot, but it’s not ideal.
Your solution would allow the switch to still use the hub to call the “turn on to the correct color temperature” service instead of direct binding, which solve the above problem. It keeps the reliability because of that fallback to automatically re-enable the relay to operate in “dumb mode”. Great thinking here.
I, too, am very suspicious about this actually being able to work reliably in practice, even if it’s technically possible with the existing hardware. Hope this ends up going somewhere to at least test this hypothesis and see what is possible here!
Thanks for sharing and the clarification on CCT temperature control.
Do you only use the Hue hub or is there another hub in your automation? Being avoiding the Hue hub because of the ecosystem expense, but as you suggested, the broad selection, reliability and UX trumps the expense. Buy once, cry once.
Adding good clear user experience scene control "override " will also be a challenge. Considering another system physical integration, rather than having to remember or explain the button press permutations.
Then you absolutely want zigbee bulbs via association. I also use the Adaptive Lighting add-on. My only gripe with it is that the addon does not stage the bulbs, so when you turn it on it flashes at the previous brightness and colour temp and then changes to where it should be.
This is actually a non-issue when you’re using binding since the switch speaks directly to the lights. I wanted to test this before I responded to be completely sure I was correct.
My coordinator is currently unplugged and Home Assistant is shut off. My blue series switch that’s here in my office is still directly turning on/off and dimming the 6 bulbs I have binded to it./
This delay has nothing to do with the bulbs or with the switch. It’s due to the addon not supporting staging. There’s a few open Feature Requests in the Adaptive Lighting addon’s github repo requesting this.
Disabling SBM and cutting the power to the bulbs will not solve this issue, if anything it will make it significantly worse. Cutting power to zigbee/zwave bulbs can wreak havoc on a mesh network possibly crippling any other device that used the bulb as a repeater. When power is restored to the bulb, it then has to re-join the network which certainly isn’t instant. Only once the bulb has re-joined the network will the color command be able to be sent.
Another thing to point out, most bulbs can have their power-on state changed. Most of us set this state to “off” or “previous” when power is restored simply because we don’t want every light in the house turning on when there’s a power bump at 3am. Disabling SBM when a bulb is set like this would allow for the switch to turn the bulb off, but it would not be able to turn it back on.
1 Like
This delay has nothing to do with the bulbs or with the switch. It’s due to the addon not supporting staging. There’s a few open Feature Requests in the Adaptive Lighting addon’s github repo requesting this.
Absolutely- it’s an issue that could be solved with prestaging the color temp (though I didn’t think Hue supports that yet, which is what I use) and is not an issue with the bulb or switch. Sorry- I didn’t mean to imply it was.
Disabling SBM and cutting the power to the bulbs will not solve this issue, if anything it will make it significantly worse.
I should have been more clear on what I think this solves. This “fallback” should happen very, very, extremely rarely: only in the case that I may need to take my hub (HA on unraid) down for server upgrades/fixes/crashes. The idea being that even though it’s a terrible way to control lights (to fallback to cutting power on a smart bulb), it’s much better than not being able to control the lights at all. To your point, having this behavior occur regularly would be havoc for the mesh, which is why I’d be concerned about how reliable a feature like this could be (that is, to not enable to the relay automatically due to a false positive of thinking the hub is down).
Another thing to point out, most bulbs can have their power-on state changed. Most of us set this state to “off” or “previous” when power is restored simply because we don’t want every light in the house turning on when there’s a power bump at 3am.
This is a great point that I wasn’t thinking of: I also have my lights set to this right now so, to your point, this “feature” would be useless unless I change them and then risk the 3am lights on due to a brief blackout.
When using zigbee bulbs and binding, the switch will still directly control the bulbs on/off/dim even when the hub is down. I also tested with the coordinator unplugged and the switch still controlled the bulbs through binding (this one admittedly shocked me and I wasn’t sure it would work, but it did).
So add another level of rarity in that it will only be useful for those looking to use non-zigbee bulbs with their zigbee switch and control them while the hub is rebooting.
I still think the possibility of causing harm to the mesh network will be significantly higher than the extremely rare scenario that this would solve. Picture the switch is off and for some reason or another drops off the network. This feature disables SBM and cuts power to the bulbs. Now instead of 1 device dropping off the network you’ve got 10. Your entire zigbee network starts to fail because other devices were connecting through some of those bulbs and suddenly you’re at 15, 20, 25 devices dropped off the network.
MRobi,
Thanks for doing this. Great to know. A part two to that situation, what happens when you restore the HA/coordinator? How does the switch respond? No need to do any magic resets? And how do the bulbs respond on CCT or color? Just curious. Obviously there is no CCT/color control when the hub (HA/coordinator) is off. May have a solution here, without having to mess with the switch relay. Thanks
My comment on “Dim” was in comparison to competitive products for the same rated lumens (800) and to a light meter at 1 meter. CRI is another key factor I’m trying to get a better method of assessment. In some areas of the house kitchen, bathroom - make-up/dressing (not me!!). But most of these factors only become noticeable if there is a large difference in CRI or you mix multiple vendors in the same area.