It seems that all 6 of my devices have done that a few times in the past couple of days. Any chance you know what may cause that? I am turning on debug logging to see if I can catch anything else in the meantime.
I suggest turning off Debug logging unless specifically asked by a developer (or me). It generates a ton of data that is mostly meaningless except when troubleshooting a repeatable error. Leaving it on continuously overloads the hub and makes it very hard to read the other relevant info in the logs
If you want to see more than Info logs, Try playing with Trace logging instead of Debug
Did this ever get discussed further? I would love to see double, triple, quadruple, quintuple held events along with the press events. You can use it for color cycling as well as brightness control. Say you have a room with dumb lights and smart lights. You can have the single presses actuate the relay which controls the dumb lights, then the double presses control other smart lights, but double hold up could increase the brightness of the smart lights, and double hold down, could decrease. Of course this could be expanded to any number of actions.
Basically extending this table to include tap and hold, double tap and hold, triple tap and hold, etc over just tap x times and hold/release events.
Is it true that when using zigbee bindings with smart bulbs, the Blue 2-1 does not send any ramp rate to the bulbs when telling them to turn on/off? (as indicated in this thread for the Z-Wave switches)
If that’s true, please consider it a feature request! I would expect the ramp rate parameters to be applied to smart bulbs when using Zigbee bindings, too!
Thanks, I’m hopping there is a better way. Removing and adding back over 30 switches is a lot of work, not to mention I can only imagine I will have to re-do automations as well. There is gotta be another way
If you want to be extra safe, you can copy the entity names, but Zigbee should remember the device when it comes back in so your automations should be untouched. Also when you hit remove from the UI the switch goes back into pairing mode so you can just remove/readd pretty quickly. Definitely can appreciate that adds up across over 30 switches though.
I think the way zha works that it has to be re-added. During the interview it goes through the available options and adds the entity for it. I’m not aware of a way to do it other than this.
Like @chack mentioned though if you add it back with the same name it should be in all your automations. Maybe try it one one device and see how it goes. Let us know if it works the way we are thinking. Also, if you remove and readd (without factory reset) it should keep all its configuration settings (except for maybe bindings which may need to be redone).
I think this seems to be the case. On the flipside, if you don’t need it through the UI on the device page, you’ll still have access to the parameters through automations or managing them directly, it just takes a couple steps. If a parameter is removed you can disable/hide it on the device page, but that’s still a manual step.
This may or may not have already been requested but my eyes where going cross eyed searching for this particular feature request. Or maybe it’s possible and I just haven’t discovered the setting yet.
I would like to completely separate the switch (button presses) from the load control. I understand that you can put the switch into “smart bulb” mode which “sort of” accomplishes this. That said I would like to be able to press buttons on the switch without it effecting the load attached to the switch.
I am coming over from a 20+ year old Vantage lighting system and this is how every one of their dimmers worked. It is incredibly useful allowing independent control of the load from local button presses. I understand that this would create a situation where if communication with the hub failed then you would lose the ability to control the local load directly from the switch. This situation was avoided in the Vantage system dimmers by a fallback local control mode when it lost communication with the system controller (hub).
Is this something that can be accomplished in a future firmware update or at all?
That is exactly what the Smart Bulb Mode (if you want to switch to always put out 100%) or Disable Local Control will do. Why do you say “sort of”? What isn’t working as you would expect using one of those two modes?