Missing features / enhancement proposal for Manage Zigbee Device / Bindings

[lopezio]

Hi All,

First of all I hope this is the right place for this - as opposed to the homeassistant/core repository. Please comment if I'm wrong, I'll resubmit.

I would like here to point out a few missing features and unclear UX elements in the "Manage Zigbee Device" / "Bindings" Screen. The Bindings are an important feature of the Zigbee protocol, as recognized by providing this panel in the first place.

However:

• Current Bindings of a device are not shown
• Unbinding is a "blind" thing. It works, but I have to know (or check with zha_toolkit) which bindings are currently active and whether they are active for a device or a group.
• Layout is misleading (Clusters choice is below Groups, but should be available both for IEEE and for Group bindings)
• Destination Endpoints are currently not selectable when creating / removing a binding

The current bindings of a device seem to be retrievable, at least using the zha-toolkit with the action zha_toolkit.binds_get. Could this be built in this panel, too? Possibly with mention of the fact that the device should be waken up when clicking. They also could be cached like the rest upon registration. But maybe it should be clear that they might be outdated. Also, when creating a new bind, they could immediately be re-fetched to see if the binding succeeded.

I am adding a mockup of what I would expect (at least one verison of it, of course many other ideas are possible...). Please apologize for the ugly design. The trash icon could also be replaced by a "break link" icon. And also the lists are just a proposal to visualize.

Kudos to all and Thanx for HA and ZHA!

[skilly00]

I'd love to see this done as well. it would make binding a lot easier to get into for people. Many times people bind groups and the members not understanding how that can cause a lot of traffic that overloads your network and this would make it easy to see/fix after reading troubleshooting docs.

[dmulcahey]

This is an area we are 100% looking to improve. I think we need to ditch the dialog completely and redesign everything as a page. Thoughts?

[smarthome-24]

Hello everyone, I think ZHA direct binding is very important because it ensures that lights can be switched on even if HA or its automation is not available. For example, when we carry out an update or are working on the automation. A rudimentary functionality should be available under all circumstances.

I think it would be good if the suggestion could be implemented in this or a similar way, because I find it really difficult to see whether all the bindings have been adopted as I intended. And if you haven't worked on it for a while, it would be much easier to continue with the work you have done so far.

Thanks

[lopezio]

Hi @dmulcahey , Hi all who watch this thread. I think your idea to give bindings more room with an own page/view is quite the right direction. I've been thinking about this idea, while experimenting with bindings in my very heterogeneous setup (IKEA, Tuya, Aqara, NOUS, Sonoff, Paul Neuhaus...). Please apologize in advance for this DLDR post, but, hey, You asked for it ;-). Here are my thoughts...

-> An important note: With a little help from our favorite AI-enemies, I had my draft formatted a bit nicer and more readable (the tables, adding examples, and title formatting). Every detail was verified, and the text content is 100% authored by me. I think it is very important to be always explicit and transparent on these matters, nowadays.... <-

Ideal Vision for a Bindings Map

In an ideal scenario, a second network map would display bindings graphically, allowing users to visually understand the relationships between devices. However, even if that remains aspirational, it cannot live without a tabular view (as the network panel would need, too), because it can get very difficult to visualize with many devices.

Current Challenges in Multi-Vendor Binding with ZHA

Given that one of (Z)HA’s missions is to support multi-vendor deployments and automations, the UX for handling binding must also offer a resilient and user-friendly way to handle the challenges associated with multi-vendor bindings. After experimenting with bindings in various scenarios, I’ve identified some issues, for example (and I'm quite sure it's not all...):

• Binding Limitations: Some devices only allow one binding (per cluster? 2bt...).
• Binding Restrictions: Some devices only support binding during the pairing phase.
• Unadvertised Clusters: Certain devices, like some remotes, do not advertise all of their supported clusters (e.g., Cluster 0x0300 for Color Control), though they can still use those clusters if/when bound.
• Device Wake Requirements: Many remotes and sensors require being woken up to respond to binding requests or queries. This can't be stressed enough...
• Error Messaging: Frequently, a binding command reports an error, even when it succeeds.
• Side-wish: Scenes Cluster Support: Some devices support the Scenes Cluster, which is great, but a whole new chapter for itself (and again, a feature that duplicates the HA-Scenes feature, so that might open a new discussion on how to honour it there...)

To manage these issues effectively, the UI should incorporate resilient tools and notices to help troubleshoot and verify bindings. For instance:

• Always try to reload the bindings table immediately after binding
• There should be both manual and background ways (not too-intrusive and as seldom as possible) to reload and cache binding tables
• Prompt users to check setup and notify them if the device must be woken up.
• Cache successful bindings and display a confidence level icon for each binding to indicate reliability.

Ideas of UI Components for Binding Management

Mainly, tables could facilitate binding management:

Current Bindings Table

Toolbar:

• [x] Show / hide default (coordinator) bindings
• Usual Filters for source and destination devices

Binding Name (optional)	Source Device	Source Endpoint	Cluster	Target (Device/Group)	Target Endpoint	Actions
Living Room Remote	Living Room Remote	1	OnOff (0x0006) [link]	Living Room Lights Group	1	Unbind Reload
Cellar Remote	Remote 2	1	OnOff (0x0006) [link]	Cellar Lamp	1	Unbind Reload
Garden Remote	Remote 3	1	Level Control (0x0008) [link]	Multi Powerplug	2	Unbind Reload
Thermostat Temp	Living Room Thermostat	1	Temperature Measurement (0x0402) [link]	Living Room Sensor	1	Unbind Reload
Color Control	Living Room Remote	1	Color Control (0x0300) [link]	Living Room RGB Light Group	1	Unbind Reload

This table format could provide an organized view with essential actions, icons, and filters to help users manage bindings... (the links would be info-links that show some docs about that binding, at least for the ones that have been standardized...)

Device-Centric Bindings Table

Another idea could organize bindings by source device, with each device’s bindings displayed in a sub-table for easy overview. Maybe it makes even more sense than flat bindings, and would help group them in a more intuitive way:

Source Device	Bindings
Living Room Remote	Cluster Target Device/Group Target Endpoint Actions OnOff (0x0006) [link] Living Room Lights Group 1 Unbind Reload Color Control (0x0300) [link] Living Room RGB Light Group 1 Unbind Reload
Remote 2	Cluster Target Device/Group Target Endpoint Actions OnOff (0x0006) [link] Cellar Lamp 1 Unbind Reload
Remote 3	Cluster Target Device/Group Target Endpoint Actions Level Control (0x0008) [link] Multi Powerplug 2 Unbind Reload
Living Room Thermostat	Cluster Target Device/Group Target Endpoint Actions Temperature Measurement (0x0402) [link] Living Room Sensor 1 Unbind Reload

Edit: I also think it is very important in the context of bindings to see (in a small font size, below the friendly name and of course icon), both the unfriendly-name and the IEEE of each device.

Enhancements on Device/Automation Pages/Lists (Binding Awareness)

Devices involved in bindings should display a notice or alert on their device panel - linking to the bindings page - so users are aware of existing bindings when creating automations. This should also be clearly visible in device lists. I've been also thinking that in theory, bindings should even be handled as "shadow automations" added to the automations page (well-distinguished and with different handlers and a clear graphical distinction), but that's probably too much...

New Binding Creation Dialog

A Create New Binding dialog could allow multiple bindings to be created at once with interactive feedback:

1. Select Source Device: Choose the device initiating the binding.
2. Choose Clusters: Display the device’s advertised clusters first, followed by other standard clusters.
3. Select Target Devices: Choose target devices and specify target endpoints. Important note: Here it should be possible to:
   • Select one or more devices
   • Select one or more groups
   • Offer the User to auto-create a Group made of the selected devices (thus, give them the group), and then assign it to the source
4. Binding Feedback: Show status updates during binding, including prompts to wake up devices and success/failure messages (e.g., "Please wake up the device… Try 1… Success").

Summary...

This is a rough outline to ignite discussion. Incrementally improving the current panel-based UI, while adding missing features and solving bugs might be still the best first step: If the whole binding thing gets more accessible to more users, we will get more ideas and more experiences and expectations to make it better...

All the Best, and many great thanks for what we already have!