feat: add bulk editing support

[deviantintegral]

I recently installed ~20 Philips Hue Downlights and 10 Inovelli switches to control them. There were many settings I wanted to make sure were the same for each device, such as power-on behaviour and LED behaviour for the switches.

At first I was just going to hack up a script to do this over mqtt directly, but I realized this was a good opportunity to see if I AI could implement this well.

Here's the flow:

1. Select one or more devices on the device list.
2. The app filters through all exposes definitions that have the same name and data type. This means you can bulk edit attributes on devices even if they are of different manufacturers or models.
3. The list shows if the values are currently the same across all of the selected devices or not - great for double-checking power on behaviour.

The new checkboxes:

The top of the bulk settings page:

These settings aren't in sync:

And then, correcting them, where we get a log showing how many calls were made:

Before I do anything more (as this totally solved my immediate needs!), is this a feature you'd be interested in accepting?

Implementation Notes

My colleague has been working on a tool for AI-assisted development that I used as a part of this. It totally worked! I only spent about 10 minutes going through it's definition loop and it took about 30 to execute. I only made some minor changes after. In the interest of transparency, I have those files in this branch.

If you want to look at the PR contents at this stage, I'd suggest:

• .ai/task-manager/archive/01--bulk-device-settings/plan-01--bulk-device-settings.md - the plan I iterated on to create this.
• The new functions in src/utils.ts - are the assumptions around determining what can be shown as exposed features correct?

Otherwise, I've only done a very cursory review of the code, so feel free to kick it back to me if you're open to the feature in general. I'm also glad to rebase it with none of the .ai directory too. Thanks!

[Nerivec]

Interesting! I'm sure some would like to see this.

I only glanced at the main code, so, preliminary observations:

• I think a modal is better suited than a page, that eliminates the need for storing more stuff in the zustand store as well. The modal package used is "no cost unless shown", so should not affect performance.
• For the common features, I did something on this for groups recently, checks are different, but might be able to re-use some of the logic (see https://github.com/Nerivec/zigbee2mqtt-windfront/pull/405/changes).
• Did you check that this works for composite? I see stuff being flatten, if the hierarchy is lost, it won't use proper payloads in commands.
• I see a lot of loops, could be a performance problem for large network / multi-instance (could be looking at 100+ device selection based on networks I've seen that use few device models). Same problem for the Zigbee network, would need some kind of throttling otherwise it's a guaranteed crash on a lot of setups (this would be similar to HA Group, so same issues).