Open konistehrad opened 2 weeks ago
(As a note, I'm working on this PR now, I just wanted to use this issue as a tracking issue for the branch)
Just a heads up config.rooms
appears to have always lower case keys, which will fail to match group friendly names with capitalization.
Are things lowercased in the config parser? I didn't explicitly choose that.
A pull request sounds good! Start with lowercase support, and we can debug from there :)
And i agree with the mechanism, btw. Seems fine to put a flag in the rooms config
By the way, we already have a group_prefix
mechanism available, if you are willing to rename the rooms you want bifrost to handle?
If group_prefix
is used, any rooms not named with the prefix will be ignored by bifrost.
Is that a viable strategy for you?
I did see that. So right now the Zigbee net is controlled by two things:
1) HomeKit via Home Assistant, which doesn't really mess with the Zigbee Groups 2) NodeRed graphs, which I was afraid of modifying the Zigbee Group names explicitly because they do in fact use them.
That said, I'll run some tests, maybe I can do it without issue. Thanks!
(Also I think my comment here https://github.com/chrivers/bifrost/issues/20#issuecomment-2312971183 plays into the idea of group friendly name prefixing)
@konistehrad As we discussed, I think we agree that a more broad, blacklist-based aproach is the way to go.
We can keep this issue open, until we land that upcoming PR :)
Tuya controllers (such as the ERS-10TZBVK-AA) support binding but in a roundabout way: they will broadcast brightness up/brightness down/toggle commands on the first Group they're added to. So if you want to control a single bulb with the controller directly, you create a group containing only the knob and the bulb. Unfortunately, this means the net ends up with "isolation" groups to support these bindings, that shouldn't necessarily be exposed to Bifrost. I propose we add a boolean to the rooms config like so:
which will prevent the group from being exported into BiFrost. Thanks!