Optionally Hide Groups

[konistehrad]

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:

rooms:
  desk_light_isolation:
    name: Desk Light Isolation Group
    hidden: true

which will prevent the group from being exported into BiFrost. Thanks!

[konistehrad]

(As a note, I'm working on this PR now, I just wanted to use this issue as a tracking issue for the branch)

[konistehrad]

Just a heads up config.rooms appears to have always lower case keys, which will fail to match group friendly names with capitalization.

[chrivers]

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 :)

[chrivers]

And i agree with the mechanism, btw. Seems fine to put a flag in the rooms config

[chrivers]

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?

[konistehrad]

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 #20 (comment) plays into the idea of group friendly name prefixing)

[chrivers]

@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 :)