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.
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.
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.
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).
- Button notifies group, Light listens to group;
- 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
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:
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
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
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?
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!
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?).
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
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.
Hmm, in my circumstance they all have one device in them, turns out it’s the zigbee coordinator in each instance.
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?
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:
As cluster 6 is not bound to the coordinator, it would be “surprising” that you seen the cluster 6 commands sent by the Aqara device - “surprising” because I’ve also seen an Aqara device send data to a coordinator without binding as far as I could see.
According to https://www.samotech.co.uk/products/zigbee-dimmer-sm309-s/, the receiving module has an On/Off cluster, but no 0x0008 Level Control cluster (it’s 0x0b08 according to the documentation) so level commands from 0x0008 will not be interpreted.
Check if you get any of the on-off commands.
@le_top sorry for the delayed reply, I had been testing out scenarios and have been able to confirm that even when it appears that the remote is no longer bound to any devices, it still appears to be speaking to the coordinator! Below is an example of one of my tests.
As a reminder, my Aqara opple remote is 04:cf:8c:df:3c:7c:6b:c5, the coordinator is 94:de:b8:ff:fe:97:7e:4f and the Samotech relay module is 90:35:ea:ff:fe:64:19:d5.
(Also, I believe the cluster info on the Samotech website is a typo as the device manual says Level Control is 0x0008 and that is also what I see in the Bindings section under the device’s Manage Zigbee Device.)
- Run ZHA toolkit
binds_remove_allservice call:
event_type: binds_remove_done
data:
zha_toolkit_version: v1.1.5
zigpy_version: 0.59.0
zigpy_rf_version: 0.36.8
ieee_org:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
ieee: 04:cf:8c:df:3c:7c:6b:c5
command: binds_remove_all
command_data: null
start_time: "2023-11-04T17:35:13.240688+00:00"
errors: []
params:
dir: 0
tries: 100
expect_reply: true
args: []
event_done: binds_remove_done
read_before_write: true
read_after_write: true
replies:
- - 0
- 8
- 0
- - SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 1
ClusterId: 1
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
- SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 1
ClusterId: 64704
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
- - 0
- 8
- 2
- - SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 1
ClusterId: 8
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
- SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 1
ClusterId: 6
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
- - 0
- 8
- 4
- - SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 4
ClusterId: 6
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
- SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 5
ClusterId: 6
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
- - 0
- 8
- 6
- - SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 6
ClusterId: 6
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
- SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 1
ClusterId: 6
DstAddress:
addrmode: 3
nwk: null
ieee:
- 213
- 25
- 100
- 254
- 255
- 234
- 53
- 144
endpoint: 1
- - 0
- - 0
- - 0
- - 0
- - 0
- - 0
- - 0
- - 0
success: true
result:
removed:
- src: 04:cf:8c:df:3c:7c:6b:c5
src_ep: 1
cluster_id: "0x0001"
dst:
addrmode: 3
dst_ieee: 94:de:b8:ff:fe:97:7e:4f
dst_ep: 1
- 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
- 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
- src: 04:cf:8c:df:3c:7c:6b:c5
src_ep: 1
cluster_id: "0x0006"
dst:
addrmode: 3
dst_ieee: 94:de:b8:ff:fe:97:7e:4f
dst_ep: 1
- src: 04:cf:8c:df:3c:7c:6b:c5
src_ep: 4
cluster_id: "0x0006"
dst:
addrmode: 3
dst_ieee: 94:de:b8:ff:fe:97:7e:4f
dst_ep: 1
- src: 04:cf:8c:df:3c:7c:6b:c5
src_ep: 5
cluster_id: "0x0006"
dst:
addrmode: 3
dst_ieee: 94:de:b8:ff:fe:97:7e:4f
dst_ep: 1
- src: 04:cf:8c:df:3c:7c:6b:c5
src_ep: 6
cluster_id: "0x0006"
dst:
addrmode: 3
dst_ieee: 94:de:b8:ff:fe:97:7e:4f
dst_ep: 1
- 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
skipped: []
origin: LOCAL
time_fired: "2023-11-04T17:35:38.202882+00:00"
context:
id: 01HEDPF4PTW9A7P9HEE9S87E72
parent_id: null
user_id: null
- Run ZHA toolkit
binds_getservice call:
event_type: binds_get_done
data:
zha_toolkit_version: v1.1.5
zigpy_version: 0.59.0
zigpy_rf_version: 0.36.8
ieee_org:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
ieee: 04:cf:8c:df:3c:7c:6b:c5
command: binds_get
command_data: null
start_time: "2023-11-04T17:36:22.900228+00:00"
errors: []
params:
dir: 0
tries: 100
expect_reply: true
args: []
event_done: binds_get_done
read_before_write: true
read_after_write: true
replies:
- - 0
- 0
- 0
- []
success: true
result: {}
origin: LOCAL
time_fired: "2023-11-04T17:36:40.104896+00:00"
context:
id: 01HEDPH15835F2SGCCAE6K9NRG
parent_id: null
user_id: null
- Me clicking the remote buttons immediately after:
I have an automation that uses the remote button press to toggle the relay module (and connected dumb lights) and when I reactivated it the automation continued to perform as normal!
…and after a short while I tried the get_binds service again and it now looks like this, everything that had appeared to have been removed is magically back!
event_type: binds_get_done
data:
zha_toolkit_version: v1.1.5
zigpy_version: 0.59.0
zigpy_rf_version: 0.36.8
ieee_org:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
ieee: 04:cf:8c:df:3c:7c:6b:c5
command: binds_get
command_data: null
start_time: "2023-11-04T18:41:10.542941+00:00"
errors: []
params:
dir: 0
tries: 100
expect_reply: true
args: []
event_done: binds_get_done
read_before_write: true
read_after_write: true
replies:
- - 0
- 7
- 0
- - SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 3
ClusterId: 6
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
- SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 4
ClusterId: 6
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
- - 0
- 7
- 2
- - SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 5
ClusterId: 6
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
- SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 6
ClusterId: 6
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
- - 0
- 7
- 4
- - SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 1
ClusterId: 1
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
- SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 1
ClusterId: 64704
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
- - 0
- 7
- 6
- - SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 1
ClusterId: 768
DstAddress:
addrmode: 3
nwk: null
ieee:
- 79
- 126
- 151
- 254
- 255
- 184
- 222
- 148
endpoint: 1
success: true
result:
"0":
src: 04:cf:8c:df:3c:7c:6b:c5
src_ep: 3
cluster_id: "0x0006"
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: 4
cluster_id: "0x0006"
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: 5
cluster_id: "0x0006"
dst:
addrmode: 3
dst_ieee: 94:de:b8:ff:fe:97:7e:4f
dst_ep: 1
"3":
src: 04:cf:8c:df:3c:7c:6b:c5
src_ep: 6
cluster_id: "0x0006"
dst:
addrmode: 3
dst_ieee: 94:de:b8:ff:fe:97:7e:4f
dst_ep: 1
"4":
src: 04:cf:8c:df:3c:7c:6b:c5
src_ep: 1
cluster_id: "0x0001"
dst:
addrmode: 3
dst_ieee: 94:de:b8:ff:fe:97:7e:4f
dst_ep: 1
"5":
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
"6":
src: 04:cf:8c:df:3c:7c:6b:c5
src_ep: 1
cluster_id: "0x0300"
dst:
addrmode: 3
dst_ieee: 94:de:b8:ff:fe:97:7e:4f
dst_ep: 1
origin: LOCAL
time_fired: "2023-11-04T18:42:46.834043+00:00"
context:
id: 01HEDTA2XJ55Z4A9BM5NXZ777Q
parent_id: null
user_id: null
EDIT
…and one more update. I removed all bindings again and this time used the ZHA toolkit bind_ieee service and specifically selected target and destination endpoint 1 for the remote and relay module. Running the binds_get service I now see this returned but pressing the button on the remote doesn’t toggle the lights at all!
event_type: binds_get_done
data:
zha_toolkit_version: v1.1.5
zigpy_version: 0.59.0
zigpy_rf_version: 0.36.8
ieee_org:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
ieee: 04:cf:8c:df:3c:7c:6b:c5
command: binds_get
command_data: null
start_time: "2023-11-04T21:15:56.373167+00:00"
errors: []
params:
dir: 0
tries: 100
expect_reply: true
args: []
event_done: binds_get_done
read_before_write: true
read_after_write: true
replies:
- - 0
- 2
- 0
- - SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 1
ClusterId: 6
DstAddress:
addrmode: 3
nwk: null
ieee:
- 213
- 25
- 100
- 254
- 255
- 234
- 53
- 144
endpoint: 1
- SrcAddress:
- 197
- 107
- 124
- 60
- 223
- 140
- 207
- 4
SrcEndpoint: 1
ClusterId: 8
DstAddress:
addrmode: 3
nwk: null
ieee:
- 213
- 25
- 100
- 254
- 255
- 234
- 53
- 144
endpoint: 1
success: true
result:
"0":
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
"1":
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
origin: LOCAL
time_fired: "2023-11-04T21:16:03.672814+00:00"
context:
id: 01HEE32R6RX7MQP1XRP08CZQ87
parent_id: null
user_id: null
Hi,
I’m trying to understand how binding works in my situation. I hope someone can confirm what I understand.
I’ve installed an ECO-DIM.07 dimmer. It dims the connected (non-zigbee) bulbs. I can also control it from HA via zigbee. I have some Zigbee bulbs in the same room. Obviously, those are not connected to this dimmer. But I want them to “follow” the dimmer, so I can basically control the light level in the whole room with a single dimmer.
I’ve achieved this with an automation, that triggers on changes in the level. This has the downside that there’s a small delay and that it will not work if HA should be down for some reason.
I think in theory I could use Zigbee binding to solve this. However, when I try to bind the dimmer to any of the bulbs or a group, it doesn’t work. When I look at the clusters of the dimmer, this is what I see:
There’s only a LevelControl cluster of type “in”. My assumption is that this means that the device can only receive level control commands, but not send them. Is that right? I guess that would mean that I’m out of luck with this device, unless it can be added with a firmware update?
1 Like
You say it doesn’t work - do you mean binding the lights to a group doesn’t work, or the bind works, but the dimmer switch doesn’t control all the lights?
I managed to bind a button to an (ikea) blind. I had to repeat the process several times, but it eventually worked. I detailed the whole process here. If it’s a binding problem this might help?
Regarding the LevelControl, I looked at my Zigbee Button (that controls the blind) and mine is “Type: out”, not “in” like yours, so that could be a problem as you suspect? I can’t find any documentation that explains what the “Type” means, but I agree it makes no sense for a button to only accept commands coming “in”!
Hi @cokelid, thanks for your reply. Yes, I can add the bulbs to a group and control the group from HA. But I can’t get the dimmer to control the group. I did read your detailed steps, that was helpful indeed.
I agree that it doesn’t make sense for a button to only accept commands coming “in”. However, my dimmer is not only a button. It is a electronic dimmer as well, that can dim physically connected “dumb” LED bulbs. That works fine: I can now dim those bulbs by turning the physical knob as well as by using a Lovelace card. So there is a good use for incoming commands in this case. However, it would be even better if the dimmer could also send outgoing commands. I’ll contact the manufacturer, maybe they can confirm whether this is possible now or with a future firmware update.