How to Bind?

Configuration Zigbee
28

FYI, the ZHA docs now finally have some information explain basic concept for binding and unbinding:

https://www.home-assistant.io/integrations/zha#binding-and-unbinding

It would be great if you guys could help improve/extend the ZHA docs by submitting PRs similar to this:

https://github.com/home-assistant/home-assistant.io/pull/16336

For changing the existing docs and submitting a new PR with improvements check out zha.markdown:

https://github.com/home-assistant/home-assistant.io/blob/current/source/_integrations/zha.markdown

Adding more information about bindings limitations could be a good start in improving the ZHA docs.

4 Likes
29

I have the 2 button IKEA square remote (on/off/dimming). I manage to bind it to an IKEA on/off power outlet. But I have no luck to bind it to an IKEA dimmable lamp. I have createda group with the single lamp and binding the group. Then reconfigure booth the remote and the lamp.

image
image526×619 17 KB

I have tried all different combinations of having OnOff and LevelControl bound or not bounded…

Anyone succeeded with this IKEA devices?

30

@zamb, group bindings have been disabled for IKEA switch since software update 2.3.0.75

How to tell the software version

How to bind to many devices

1 Like
31

Again it would be great if you guys could help extend and improve the ZHA documentation on this topic:

https://www.home-assistant.io/integrations/zha#binding-and-unbinding

https://github.com/home-assistant/home-assistant.io/blob/97731860f5401dadef45cf37755281f8a25dc064/source/_integrations/zha.markdown

32

How did you manage to bind the remote to the outlet? I’ve tried everything but I just can’t can get it to work. Thanks!

33

ZHA-Toolkit offers several services with regards to binding.

Without that, in HA/ZHA, you can perform certain bindings.

One-to-one bindings are recommended as long as you have no more than 3/4 devices to bind onto the same command.
If you do not know it yet: you actually configure the “remote” when you want make these one-to-one bindings by telling it which other devices to send the command to.

You can also bind using groups: in that case you configure bind the remote’s cluster to a group, and you need to configure the lights to the same group.

To bind, you go to the entity, click on ⋮ next to Reconfigure, where you click on Manage the Zigbee device (or similar). Then you have a horizontal tab list and the middle one is Bindings. You can the devices to bind to from the list fo devices and (un)bind the device, or the group to be bound.

When you go to the Zigbee Integration, you also have access to the groups in the center tab. There you can create groups and also add or remove devices from a group.

zha-toolkit is “low-level” but allows you to read the bindings that exist on a device, remove all or some of them and make more bindings than ZHA proposes. Of course, I recommend doing it using the internal features if you can.

Personnally I have a remote and a light in group number 2 because there were some limitationd on the remote as far as I remember (so I use a group even with less than 1 device listening).

34

Thanks for the clear description. The problem is that the above doesn’t work for many people. I used deconz/conbee II before and bound several remotes to groups. But attempting the same with ZHA and a Sonoff zbdongle-E, the same remote and the same lights in the group, it fails. I realize the remote needs to be awake for adding bindings. At the last attempt yesterday, pressing bind resulted in a wait cursor but nothing else. So somehow deconz manages to do something that zha can’t.

35

You are right, the remote needs to be awake to do the binding.

What you can do is to configure the binding in ZHA and then immediately press on a button on the remote which will wake it up.

I do not know what Domoticz’ method is, but here are a few ways I think it can be done:

  • On network association the remote may be awake for a longer time, allowing the coordinator to configure the device. During that period, the coordinator could assign a unique group to the remote and use it later to configure devices that should act on this remote’s commands;
  • There might not be a direct binding. Instead, the coordinator receives all the commands and then generates new ones to control the “slaves” (lights).
  • The system could remember that the remote still needs to be configured and repeat the command at a later time when the remote wakes up. That is a bit trickier as the remote would also sleep immediately after packet confirmation. Until the remote confirms it’s configured, the system could use the method described above.

With ZHA-Toolkit, several commands already use the “TRIES” parameters which results in commands being repeated until they succeed. Amongst the bind services, this currently is implemented on binds_get and binds_remove_all only. I added an “zha-toolkit issue” as a reminder.

In the mean time, just press the remote’s button just after sending the binding configuration.

Zigbee messages are held on the parent router for about 6 seconds.

36

Has anyone been able to successfully bind the Phillips hue dimmer switch via a bulb via zha? I’ve tried everything I can find, including the zha toolkit, and it hue won’t take for me.

37

I suggest that you verify the binding and reporting configurations on your devices.

There are essentially two zigbee only methods to link your devices (without intervention of code running on HA to transfer the command).

  1. Button notifies group, Light listens to group;
  2. Button sends direct to light.

In the first case, you bind the button’s sending cluster to a group, and the light’s receiving cluster to a group. There is no guarantee that the command sent by the button is received by the light.

In the second case, the button is configured to send to the light directly. The light has to acknowledge to the button that the command was received. The button repeats the command a few times in case the acknowledgement is not received. So that gives some guarantee. However, that method is recommended for 3/4 devices maximum.

Whatever method you used to configure the devices (HA or ZHA or ZHA-Toolkit), you can check the configuration on the devices using zha_toolkit.binds_get .

In some cases use zha_toolkit.conf_report_read when attributes need to be communicated to the other device (but for button bindings that is not useful).

In the binds_get results you should see that the relevant cluster(s) on the remote is(are) bound to the group or expected IEEE address.
When using the group method, you should check that the relevant cluster(s) on the receiving device is(are) bound to the relevant group.

Based on those results, it can be determined if the light(s) should react to the buttons or not according to the configuration that is set. If the configuration is not ok, then it can be seen which binding(s) are missing so that they can be configured using one of the available means. In zha-toolkit, this is zha_toolkit.bind_ieee

zha_toolkit.bind_group also exists, but is not documented, it is available though and the target group id must be provided in command_data

1 Like
38

After many hours of trial and error I finally figured this out.
I have a Philips Hue Dimmer Switch (RWL021) and a Hue Light strip which I wanted to bind together.
Thanks to this thread I found the ZHA toolkit, which is how I got this to work. Another major hint was that people wrote that the dimmer can control only 1 thing at the time. A thing can either be a group or a device.

Firstly, I used zha_toolkit.binds_get to find out how my dimmer was connected from the get-go.
The important bit of the reply can be found in the cluster-ids. Command:

service: zha_toolkit.binds_get
data: 
  ieee: 00:17:88:01:08:71:b5:ae

Reply (or well, the important bit):

result:
  "0":
    src: 00:17:88:01:08:71:b5:ae
    src_ep: 1
    cluster_id: "0x0008"
    dst:
      addrmode: 3
      dst_ieee: 00:12:4b:00:1c:dc:60:19
      dst_ep: 2
  "1":
    src: 00:17:88:01:08:71:b5:ae
    src_ep: 1
    cluster_id: "0x0006"
    dst:
      addrmode: 3
      dst_ieee: 00:12:4b:00:1c:dc:60:19
      dst_ep: 2
  "2":
    src: 00:17:88:01:08:71:b5:ae
    src_ep: 1
    cluster_id: "0x0005"
    dst:
      addrmode: 3
      dst_ieee: 00:12:4b:00:1c:dc:60:19
      dst_ep: 2
  "3":
    src: 00:17:88:01:08:71:b5:ae
    src_ep: 2
    cluster_id: "0x0001"
    dst:
      addrmode: 3
      dst_ieee: 00:12:4b:00:1c:dc:60:19
      dst_ep: 1
  "4":
    src: 00:17:88:01:08:71:b5:ae
    src_ep: 2
    cluster_id: "0x000F"
    dst:
      addrmode: 3
      dst_ieee: 00:12:4b:00:1c:dc:60:19
      dst_ep: 1
  "5":
    src: 00:17:88:01:08:71:b5:ae
    src_ep: 2
    cluster_id: "0xFC00"
    dst:
      addrmode: 3
      dst_ieee: 00:12:4b:00:1c:dc:60:19
      dst_ep: 1

Browsing to the device and choosing “Manage Zigbee Device” you can find out what each cluster_id does.
The important ones for me here are 0x0006 (On/Off) and 0x0008 (LevelControl). The first cluster tells the ‘thing’ to turn on or off, while the second tells it to dim. By default, HA binds these to the Zigbee Controller, in my case the ieee number is 00:12:4b:00:1c:dc:60:19. (BTW, the ieee number can be found under Zigbee Info in Device Info:

image
image395×607 25.9 KB

Knowing all this, I used ZHA toolkit to firstly remove these bindings (but only those, not everything!)

service: zha_toolkit.binds_remove_all
data: 
  ieee: 00:17:88:01:08:71:b5:ae
  command_data: 00:12:4b:00:1c:dc:60:19
  cluster: [0x0006, 0x0008]
  tries: 100

00:17:88:01:08:71:b5:ae is the ieee number of the dimmer, 00:12:4b:00:1c:dc:60:19 is the coordinator. Don’t forget to wake your device here.

After that, I run the bind command to link the dimmer and the light together:

service: zha_toolkit.bind_ieee
data: 
  ieee: 00:17:88:01:08:71:b5:ae
  command_data: 00:17:88:01:06:d2:2f:80
  tries: 100

This then re-creates the bindings with clusters 0x0006 and 0x0008, but now they are pointed at the light instead of the Zigbee controller. To check, you can re-run the first service call zha_toolkit.binds_get.

Hope this helps!

2 Likes
39

Good work.

Juste one note regarding:

You can actually also keep the bindings pointing to the controller so that home assitant receives these commands as well so that you can observe when commands were sent and you can use them for something else.

However, this also uses up space in the device’s binding table which can only hold that many entries. When that is the case, you could still use Zigbee groups and notify the group instead of individual devices. The Zigbee controller would need to be a member of these groups (for the relevant clusters).

Howeer groups are less reliable than device-to-device bindings because the latter has a higher guarantee of message delivery.

1 Like
40

If i bind the motion sensor ato the tradfri light bulb, is it still possible to set the light intensity/color temp depending to the daytime (night less, day more) vis HA?

41

Do you have any advice for an existing setup where I just checked and realised I multiple no name groups showing in my ZHA Groups list. I added all my switches and remotes way in the past and now can’t figure out how to match a no name group to a specific switch or remote!

42

Is there a process for identifying what is the limit of bindable entities for any given ‘sending’ device?

If the device limit is either = 1 or > 1 seems to imply a big difference in how a user might need to configure their ZHA groups to ensure the devices are bound AND HA is able to listen to all events.

If the limit = 1 I think I would need to add my coordinator to all ZHA groups to ensure HA is listening to all devices events.
If the limit is > 1 I don’t need to do this as I can separately bind the device to my coordinator and ZHA group.
If the limit is > 4 I probably don’t need to use ZHA groups at all (as long I’m controlling no more than 3/4 ‘receiving’ devices?).

43

Hi
The number of available bindings is dependent on the device. When your bind request does not fit anymore (in the cluster), the device should respond with an error.

The ZB specification mentions the optionnal parameter Config_Max_Bind for a device, which is set by the device application and not available through a zigbee request.

I’ld expect that you can generally configure up 4 bindings per cluster, but I’ve seen more.

Also not that some devices keep their binding tables even after leaving a network or even after sending a reset command. That can be “annoying” - zha-toolkit allows you to clear a binding table for a cluster using binds_remove_all

1 Like
44

I think you can ignore them. In my groups list there is a “Devices” column on the far right - all the no name groups are 0. If you click on a group name where the number of devices is > 0 you should get a list of the devices in it.

image
image1361×907 52.7 KB

45

Hmm, in my circumstance they all have one device in them, turns out it’s the zigbee coordinator in each instance.

46

switched from zigbee2mqtt today to zha. Trying to prepare the system for updating the usb dongle.
In connection with this, I would also like to start tying the ikea remote to certain lamps so that I avoid problems if the home assistant is down. I’ve tried to read on etc. but no guide seems to tell how to proceed, now the ones I find are 1-2 years old and refer to things I can’t find. Does anyone have a good guide on how to do this?

47

I think that I’ve successfully bound an Aqara Opple remote to a Samotech SM309 dimmer module using the ZHA UI but am not experiencing the expected behaviour.

This is a screenshot of what is returned by the ZHA toolkit binds_get service for the Aqara remote (04:cf:8c:df:3c:7c:6b:c5):

  result:
    "0":
      src: 04:cf:8c:df:3c:7c:6b:c5
      src_ep: 1
      cluster_id: "0xFCC0"
      dst:
        addrmode: 3
        dst_ieee: 94:de:b8:ff:fe:97:7e:4f
        dst_ep: 1
    "1":
      src: 04:cf:8c:df:3c:7c:6b:c5
      src_ep: 1
      cluster_id: "0x0008"
      dst:
        addrmode: 3
        dst_ieee: 94:de:b8:ff:fe:97:7e:4f
        dst_ep: 1
    "2":
      src: 04:cf:8c:df:3c:7c:6b:c5
      src_ep: 1
      cluster_id: "0x0006"
      dst:
        addrmode: 3
        dst_ieee: 90:35:ea:ff:fe:64:19:d5
        dst_ep: 1
    "3":
      src: 04:cf:8c:df:3c:7c:6b:c5
      src_ep: 1
      cluster_id: "0x0008"
      dst:
        addrmode: 3
        dst_ieee: 90:35:ea:ff:fe:64:19:d5
        dst_ep: 1

94:de:b8:ff:fe:97:7e:4f is my zigbee coordinator and 90:35:ea:ff:fe:64:19:d5 is the target Samotech module. I’ve confirmed that 0x0006 is the OnOff endpoint and 0x0008 is the LevelControl endpoint by looking under the Clusters section of Manage Zigbee Device of both devices.

Curious, I looked up 0xFCC0 and it’s listed as OppleCluster with a single attribute of mode.

I can see the remote clicks registering in the logbook on the device’s page and I expected the remote to now be able to turn on the module (and attached light bulb) but this did not happen.

This is a screenshot of the Aqara remote:

Screenshot 2023-10-31 at 09.39.03
Screenshot 2023-10-31 at 09.39.03528×684 31.8 KB