Testing: binding

[Koenkk]

This issue is used to gather feedback on the binding feature.

Notes

• Documentation is available here
• Dev branch is required (edge for Hassio users)
• IKEA TRADFRI remote control (E1524) cannot be bound to other devices, this is a limitation of the device. A workaround for this is to sniff the group the E1524 is sending commands to (documentation), and add the device you want to bind to this group (documentation)

TODO

• Binding to a group doesn't seem to be working

[niekvlessert]

I'm pretty new to this world, but I can help testing. Would this be a valid testing environment? Insert the CC2531 USB stick in my iMac, forward the USB port to Virtualbox, install zigbee2mqtt in a Linux VM and test. So I can keep my stable & slow RPI 1B the same.

Another question; how would I pair the Ikea remote so that I can try using it and zigbee2mqtt at the same time? Now I factory default the Ikea lamp, then it'll connect to zigbee2mqtt automatically, but when I then pair the remote, the connection with zigbee2mqtt is gone.

[Koenkk]

@niekvlessert the tradfri button can be paired to zigbee2mqtt by resseting it and keeping it close to the coordinator.

[niekvlessert]

I've got my VM setup running, running zigbee2mqtt dev version on a VM with forwarded USB port on my iMac. Since the bulb pairs fine with this it looks ok. I couldn't pair the Ikea remote, it gave: 'PM Device with modelID 'TRADFRI remote control' is not supported.'

So I found: #102 (comment)

I added the settings to devices.js, but I couldn't find the handleReady in lib/zigbee.js, I guess this info is dated? Any tips?

[Koenkk]

@niekvlessert thats not needed, once paired you will be able to bind it

[martinrosenauer]

@Koenkk, should we be able to pair the (5 button) Trådfri Remote now ? (I'm also getting the 'PM Device with modelID 'TRADFRI remote control' is not supported.' after resetting it as also @niekvlessert get).

[Koenkk]

Yes, but the unsupported message doesnt mean you cannot use binding

[martinrosenauer]

@Koenkk, ok, so is it the same that happens when I "pair" the remote with a bulb? (e.g. holding the reset button inside it pressed for 15-20 secs next to the bulb)

[Koenkk]

@martinrosenauer yes

[niekvlessert]

It works!

• Factory default the remote
• Pair with zigbee2mqtt, ignore the 'Not supported'
• Factory default the bulb
• Let it pair with zigbee2mqtt
• Pair the remote with the bulb
• Now my mosquitto_pub -t 'zigbee2mqtt/0x000b57fffecb610d/set' -m '{"color_temp":200}' still works but the remote also works. :)

Interesting; I can't change the color temperature with the remote anymore, off/on and intensity work fine.

[ookyn]

Hi,
Same results as @niekvlessert here :
I can manage all features with mqtt and the remote, except for color (rgb bulb) with the remote .

[JumpmanJunior]

I'm using an IKEA remote and RGB bulb. But it does not work for me.

• The bulb is paired with zigbee2mqtt.
• The remote is also paired with zigbee2mqtt. I have received the "Not supported" error message
• I bind the remote to the bulb: zigbee2mqtt/bridge/bind/REMOTE BULB
• I get the following messages in the log:

2019-1-5 03:55:08 - warn: Cannot handle MQTT message on 'zigbee2mqtt/bridge/bind/REMOTE' with data 'BULB'
2019-1-5 03:55:11 - info: Successfully bound cluster '5' from 0x000d6ffffe1d7895' to '0x000d6ffffe1df5f5'
2019-1-5 03:55:13 - info: Successfully bound cluster '6' from 0x000d6ffffe1d7895' to '0x000d6ffffe1df5f5'
2019-1-5 03:55:15 - info: Successfully bound cluster '8' from 0x000d6ffffe1d7895' to '0x000d6ffffe1df5f5'
2019-1-5 03:55:15 - warn: Don't know how to setup reporting for '5', skipping..
2019-1-5 03:55:15 - info: Configured reporting for cluster '6' of device '0x000d6ffffe1df5f5'
2019-1-5 03:55:15 - info: Configured reporting for cluster '8' of device '0x000d6ffffe1df5f5'

• So it seems that everything worked. I assume that the cluster 5 message relates to the not working colour changing feature reported by @niekvlessert and @ookyn.
• But for me the remote is not working at all. I can still control the bulb via zigbee2mqtt.
• Unbinding seems also to work:

2019-1-5 04:11:24 - warn: Cannot handle MQTT message on 'zigbee2mqtt/bridge/unbind/xUfo' with data 'xIkea'
2019-1-5 04:11:28 - info: Successfully unbound cluster '5' from 0x000d6ffffe1d7895' to '0x000d6ffffe1df5f5'
2019-1-5 04:11:30 - info: Successfully unbound cluster '6' from 0x000d6ffffe1d7895' to '0x000d6ffffe1df5f5'
2019-1-5 04:11:32 - info: Successfully unbound cluster '8' from 0x000d6ffffe1d7895' to '0x000d6ffffe1df5f5'

[niekvlessert]

Ah, you use the binding, interesting. I just paired with the remote itself with the bulb.

[BudBundi]

I try to bind a "Xiaomi Aqara single key wireless wall switch (single click)" with a "GL-C-008 - Gledopto Zigbee LED controller RGB + CCT / RGBW / WWCW / Dimmer"
but only get the message
zigbee2mqtt:error 2019-1-7 16:41:06 Failed to bind cluster '5' from 0x00158d0002523a2f' to '0x00124b00199f0348' (Error: Timed out after 10000 ms)

Startup messages

zigbee2mqtt:info 2019-1-7 16:32:07 Logging to directory: '/app/data/log/2019-01-07.15-32-07'
zigbee2mqtt:info 2019-1-7 16:32:11 Starting zigbee2mqtt version 1.0.1 (commit #932a66a)
zigbee2mqtt:info 2019-1-7 16:32:11 Starting zigbee-shepherd
zigbee2mqtt:info 2019-1-7 16:32:15 zigbee-shepherd started
zigbee2mqtt:info 2019-1-7 16:32:15 Coordinator firmware version: '20181024'
zigbee2mqtt:info 2019-1-7 16:32:15 Currently 7 devices are joined:
zigbee2mqtt:info 2019-1-7 16:32:15 Bewegungsmelder_Unten (0x00158d0002b95d67): RTCGQ11LM - Xiaomi Aqara human body movement and illuminance sensor (EndDevice)
zigbee2mqtt:info 2019-1-7 16:32:15 Bewegungsmelder_Oben (0x00158d0002b6d069): RTCGQ11LM - Xiaomi Aqara human body movement and illuminance sensor (EndDevice)
zigbee2mqtt:info 2019-1-7 16:32:15 Raumsensor_Stube (0x00158d0002c8cfe2): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice)
zigbee2mqtt:info 2019-1-7 16:32:15 Raumsensor_Ankleide (0x00158d0002c8d2c3): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice)
zigbee2mqtt:info 2019-1-7 16:32:15 Raumsensor_Badezimmer (0x00158d0002c8d155): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice)
zigbee2mqtt:info 2019-1-7 16:32:15 Licht_Badezimmer (0x00124b00199f0348): GL-C-008 - Gledopto Zigbee LED controller RGB + CCT / RGBW / WWCW / Dimmer (Router)
zigbee2mqtt:info 2019-1-7 16:32:15 Schalter_Badezimmer (0x00158d0002523a2f): WXKG03LM - Xiaomi Aqara single key wireless wall switch (EndDevice)
zigbee2mqtt:info 2019-1-7 16:32:15 Zigbee: disabling joining new devices.
zigbee2mqtt:info 2019-1-7 16:32:15 Connecting to MQTT server at mqtt://mosquitto
zigbee2mqtt:info 2019-1-7 16:32:16 zigbee-shepherd ready
zigbee2mqtt:info 2019-1-7 16:32:16 Connected to MQTT server
zigbee2mqtt:info 2019-1-7 16:32:16 MQTT publish: topic 'zigbee2mqtt/bridge/state', payload 'online'

Is it not possible to bind the Xiaomi Switch? Or is there another problem?
Platform is Docker on a Raspberry Pi 3b+
Image is koenkk/zigbee2mqtt:arm32v6-dev@sha256:aa87c8e89569ecd6646658b2802e8c28170e062882fd70b56501f235cb07ba9b

[Koenkk]

@BudBundi Xiaomi defines don't follow the ZCL specification, therefore they are (probably) not able to control other devices.

Something you can also try is to wake the device up while the configuring takes place (just press the button a few times when you start zigbee2mqtt)

[trekker25]

would be awesome if it could be used for groups!
Not sure if this is even possible?

As a backup would be great to have a remote that can turn on / off a couple of groups i'm going to realize next month.

[Koenkk]

@trekker25 I didn't have any success with the TRADFRI dimmer, however results may vary per device.

[JumpmanJunior]

I have now tried to bind the Philips dimmer switch with an Ikea RGB bulb. I did the same as described in my post with the Tradfri remote and I also have received the same result. According to the log it works except for cluster 5 but the remote is not working. The remote still sends its events to zigbee2mqtt but is not controlling the bulb.

2019-1-11 03:44:31 - warn: Cannot handle MQTT message on 'zigbee2mqtt/bridge/bind/xDimmer' with data 'xIkea'
2019-1-11 03:44:32 - info: Successfully bound cluster '5' from 0x0017880104e680f9' to '0x000d6ffffe1df5f5'
2019-1-11 03:44:32 - info: Successfully bound cluster '6' from 0x0017880104e680f9' to '0x000d6ffffe1df5f5'
2019-1-11 03:44:33 - info: Successfully bound cluster '8' from 0x0017880104e680f9' to '0x000d6ffffe1df5f5'
2019-1-11 03:44:33 - warn: Don't know how to setup reporting for '5', skipping..
2019-1-11 03:44:33 - info: Configured reporting for cluster '6' of device '0x000d6ffffe1df5f5'
2019-1-11 03:44:33 - info: Configured reporting for cluster '8' of device '0x000d6ffffe1df5f5'
2019-1-11 03:44:49 - info: MQTT publish: topic 'zigbee2mqtt/xDimmer', payload '{"battery":100,"linkquality":23,"action":"off","last_seen":"2019-01-11T02:44:49.119Z"}'

[Koenkk]

@JumpmanJunior can you do some zigbee sniffing and post the results of the on/off commands send by the remote? https://github.com/Koenkk/zigbee2mqtt/blob/dev/docs/how_tos/how_to_sniff_zigbee_traffic.md

[JumpmanJunior]

Yes, the attached dump contains the binding procedure, pressing some buttons on the remote (which has no effect on the bulb) and the unbinding procedure.

[Koenkk]

@JumpmanJunior do you know how this remote is normally used, can it be paired directly to a bulb?

[JumpmanJunior]

Yes, the remote can be paired directly to a bulb. That is even the default if you buy it in a set with a bulb.

In order to exclude a problem with the bulb I have now tried to bind the Philips dimmer switch to a Philips bulb (instead of the Ikea bulb I used before). But the results are the same, it is not working.

[Koenkk]

@JumpmanJunior in the log I see that the remote reports that the binding is OK, however ZCL Onoff is still send to 0x0000. Perhaps it can only be bound to one device, by default zigbee2mqtt will bind it to the coordinator.

• Can you replace https://github.com/Koenkk/zigbee-shepherd-converters/blob/master/devices.js#L725 and https://github.com/Koenkk/zigbee-shepherd-converters/blob/master/devices.js#L726 with unbind
• Start zigbee2mqtt and verify that it logs Successfully configured...
• Put return after https://github.com/Koenkk/zigbee-shepherd-converters/blob/master/devices.js#L722
• Bind it to the bulb again.

[JumpmanJunior]

OK, this worked. Now the remote is controlling the bulb. But I was not receiving the button presses in zigbee2mqtt anymore. I was still able to control the bulb directly via zigbee2mqtt. But I was not receiving status updates from the bulb when executing a change with the remote. After executing the unbind command (with reverted code) it immediately stopped controlling the bulb and the button presses where showing up in zigbee2mqtt again.

I also tried the same with the Tradfri remote which was integrated via the coordinator_group but I had no success with this one. But there is also no "Successfully configured" message for this remote.

[Koenkk]

@JumpmanJunior it seems that this remote can only be bound to one devices, so either to coordinator or he bulb. About the TRADFRI remote, it doesn't allow to be bound (also experienced this). What you can do is add the bulbs to the same group as the one of the TRADFRI remote.

[f-bader]

Hi, binding worked as long as I woke up the TRADFRI wireless dimmer (ICTC-G-1) before sending the MQTT message
But I receive an error about reporting for one cluster

2019-1-25 19:28:12 - info: Successfully bound cluster '6' from 0x000b57fffe9292a7' to '0x0017880110348471'
2019-1-25 19:28:12 - info: Successfully bound cluster '8' from 0x000b57fffe9292a7' to '0x0017880110348471'
2019-1-25 19:28:12 - info: Configured reporting for cluster '8' of device '0x0017880110348471'
2019-1-25 19:28:42 - error: Failed to setup reporting for cluster '6' of device '0x0017880110348471'

[f-bader]

One thing thats a bit annoying is that when I use the dimmer the state change of the target is not published. Only the state change of the dimmer.
This makes the integration in home assistant a bit tricky

[Koenkk]

@f-bader that's because the reporting setup fails (see your log). cluster 6 is the on/off cluster, Does changing brightness trigger a state update?

[martin-g-it]

Thanks, that did it! Didn;t notice that extra step.. :-).

[Morphy99]

I'm moving over to a new coordinator running source routing fw and on a different channel to accommodate a device I have that only supports certain channels. Whilst trying to bind some IKEA bulbs and remotes that I've moved over, I'm having some issues where they appear to bind OK according to the logs however if I stop Z2M to test they control the bulbs, they don't.
Oddly I have moved over a Hue bulb and this seems to bind and control just fine with the IKEA remote.

The bulb in question is LED1623G12 and the remote the E1524. Both are updated to the latest OTA. I was binding them by this process:
Create a group then add the bulb to the group.
Unbind the remote from the default group.
Bind the remote to the group ticking OnOff & LevelCtrl.

This worked previously with my other Z2M instance and coordinator although I did it some release revisions ago.
I've tried binding direct to the bulb instead of using a group but this has never worked for me.

[Anjerlaan]

The IKEA remote must be bound to a group, it is not possible to a device.

By default the 1524 remote is bind to the default group (901)...if you press a button, you would see messages ending with 901.

You first have to unbind the remote from the default group...Read the manual how to do...
Don't forget to wake-up the device by pressing a button Just before the unbind command is send.

Then create a group, add bulb(s)
And bind the remote to the group. Also here wake-up the device Just before the bind command

[Anjerlaan]

Maybe try the new_api and web front-end of version1.16.2
Then you can visually do all these steps.
Read the manual for this

[Morphy99]

@Anjerlaan thanks, I've unbound from the default group to start with, sorry I left that out of process in my post!
Also, am waking it up, the process all appears successful according to the logs. I'm also using the web gui to do it but I did try to bind with mqtt publish in HA just to see if that would work, no joy.

I don't understand why it's not working now as the same process has worked fine with my old coordinator and it also appears to work with a hue bulb on the new coordinator. So I'm guessing it's something to do with the IKEA LED1623G12 bulb. I might try putting it back on the old network to see if I can still bind it with that, seems a PITA just to prove it works on something I don't want it to anymore!

[Morphy99]

I managed to get these two remotes to work now! I removed them, created a new group with a different name and voila it works.

[Gerard-Oedzes]

Good evening everyone,

I hope there is someone who can help me a little further with binding a HUE remote.

I did a clean install of Ubuntu Server 20.04.1 on an Intel NUC 7i5BNK today.
I have provided my Texas Instruments LAUNCHXL-CC26X2R1 with the latest firmware. (CC26X2R1_20201026)

After installing Mosquitto followed the full guide to installing Zigbee2Mqtt and everything seems to work great!

before the complete integration in Domoticz I first wanted to perform a test, apart from Domoticz I would also like to use a remote control for dimming a group.

I have now added 2 HUE GU10 spots and a HUE remote control.
I made a group of the 2 GU10 spots called: Zolder.

'homeassistant: true
permit_join: true
mqtt:
base_topic: zigbee2mqtt
server: 'mqtt://localhost'
serial:
port: /dev/ttyACM0
advanced:
pan_id: 6768
elapsed: true
devices:
'0x0017880104272078':
friendly_name: zolder plafondspot 1
'0x001788010427dcf2':
friendly_name: zolder plafondspot 2
'0x0017880106342a20':
friendly_name: remote_control
groups:
'1':
friendly_name: zolder
retain: false
transition: 2
optimistic: true
devices:
- '0x0017880104272078'
- '0x001788010427dcf2'
frontend:
port: 8080
host: 192.168.178.17
experimental:
new_api: true`

In the frontend panel I selected my remote control and added the group under binding.

But somehow I don't get this work...

Am I missing something?

[WarmCatUK]

Ikea motion detector (E1525/E1745) is able to bind directly to a bulb, but unable to control it; it is unable to be bound to a group.

[loewexy]

I bound an IKEA remote E1524 to an LED1545G12 light bulb via a group. On/Off and Dimming does work, however the color temperature can not be changed. Is there a way to enable this?

[martin-g-it]

Same here... On/Off and Dimming works like a charm (with groups). Changing the color temperature simply doesn;t work.
Z2M is running on the latest version..

Also tried to update some bulbs/spotlights with OTA since this seems to help out in some situations as referenced in this issue, but got the 'Image is truncated' error (mentioned in #2921). Unfortunately wasn't able to resolve this by adding ikea_ota_use_test_url: true to the advanced: section of my config file...

[doctor64]

@loewexy @martin-g-it Actually, E1524 does not switch color temperature. If I remember correctly, this two buttons send command Set Next/Prev Scene. Unfortunately, z2m does not (yet?) support scenes, but this functionality can be implemented on higher level - I, for example implement this in OpenHab. Of course this solution have drawback what it require working server with OpenHab/any other home automation software. I'm think details will be out of topic here, contact me if you are interested

[loewexy]

There is a seperate Bug report for this Issue I just found #1232 . I know that this can be done in OpenHab but this seems to be the not so elegant solution.

[mgg1010]

I've just tried binding a Sonoff sensor (SNZB-3) with a Moes/Tuya switch MS-104Z - and I get binding failed. I can see that the two devices don't have clusters in common - but now I'm wondering if the device DB is correct

The Sensor has this initial configuration fragment in devices.js:

    fingerprint: [
        {type: 'EndDevice', manufacturerName: 'eWeLink', modelID: '66666', endpoints: [
            {ID: 1, profileID: 260, deviceID: 1026, inputClusters: [0, 3, 1280, 1], outputClusters: [3]},
        ]},
    ],
    zigbeeModel: ['MS01', 'MSO1'],
    model: 'SNZB-03',

Outputcluster 3 is "identity". Output cluster 6 is "onoff". I am puzzled how a motion sensor doesn't
have onoff as an output cluster at all?

Could someone explain a bit more:

• How reliable is the devices.js database in general? I guess if it's been crowdsourced to some extent, it may
  have gaps?

• How is a binding decision made? Do the devices need the same clusters or ?

Thanks

Martin

[mgg1010]

Another note: the config fragment above is mostly Tuya specific - how do other devices get their outputclusters?

[sjorge]

@mgg1010 that is sadly correct. My Hue/Xiaomi/SONOFF (no longer have the SONOFF) also only have msOccupancy, which a bulb can do nothing with(1).

Some of the IKEA ones do however have genOnOff so you can bind those directly.

1. My hue actually also has a genOnOff but it never outputs anything on that.

[mgg1010]

Ah, and this is built-into the firmware of the device, and hence not fixable?

And I guess when a new device is added, it's relatively easy to see the low-level messages being sent
and hence devices.js should be right.

re: IKEA - I've read that the Tradfri sensor only sends to groups...

It would all be easier if the hardware people just got it right for a change.

I suppose this means we have to live with making sure our servers are reliable!

[sjorge]

It's a mix bag of doing what the zigbee spec allows and what is easy I guess.

There is a bit more on PIR Configuration... but that's beside the point, the spec offers a (niceish) way to report if a room/area/... is occupied or not based on PIR/Ultrsonic/Ultrasonic+PIR/physical (you want to have a video camera and do analysis on the video to detect occupancy? Though luck, you either lie and say it is PIR or extend the spec with your own stuff... fun)

There is much I could find on having device A control device B, the (old) ikea approuch was just to be a client for genOnOff and send on with timeout of X to a group (you can create a single device group if you want too)... which is a pretty creative way to solve it.

Hue/SONOFF/... seem to just follow the spec and say... motion => means someone is there... so we'll expose a msOccupancy sensor and toggle it true/false...

There is a reason each manufacturer has a bridge the are trying to push :)

/me adds the idea of using a z2m extension to fix this to the massive backlog of things to write... someday.

tl;dr: the spec is pretty OK, but... is not all encompassing. Either do what is spec compliant, add your own extension, be creative. Or well, have your bridge deal with it. (Seems most go for a mix of a, b and c)

[Gerard-Oedzes]

Is it true that Philips HUE LWG004 GU10 cannot be bound to a HUE Dimmer remote?

[deltaphi]

I have a Paulmann YourLED RGB 500.49 Zigbee controller for an LED strip and a matching Paulmann Gent 500.67 remote. Both are connected to Zigbee2MQTT via a Conbee 2 stick. Control of the LED Controller through Home Assistant works like a charm. The Gent also shows up in Home Assistant and I can receive commands from it. To make full use of the remote and the LED Controller, I wanted to bind them.

My first attempt was to bind the Remote to the LED Controller directly. Zigbee2MQTT reported success, but the LED Controller did not react to any button press on the remote.

My second attempt after reading through this thread was to create a group with only the LED controller in it and to then bind the remote to the group. This now works and I have full control over the LED controller from both Home Assistant and the remote.

What does not work: The "On/"Off" state is not synced from the Remote to Home Assistant, but not the other way around. Meaning: If I turn on the LED strip via Home Assistant, the Remote still thinks it is off. I have to press the "On/Off" button on the remote twice to actually send a { "status": "OFF" } message.

[heggink]

Since 1.19.1, groups/binding functionality is gone for me. I have 4 E1743's and one E1524. AT first I thought it was related to the latest firmware 2.3.075 but then I noticed that no bindings seem to work anymore except for one of my E1743's. Any unbind/bind seems to result in the device using group 0 :-(:
Received Zigbee message from 'wk_remote', type 'commandToggle', cluster 'genOnOff', data '{}' from endpoint 1 with groupID 0
Anyone any ideas? Factory resetting does not make a difference. Retsrating z2m, unpairing and repairing. I am lost...

[vide]

@heggink have you tried going back to a previous, working zigbee2mqtt version?

[heggink]

@vide I have not since I had no idea that I had this issue. I mostly use the remotes as a backup (in case my pi dies). It was only when I tried to repurpose one of the remotes when I noticed that, out of 5, only one still had a working group association. The weird thing is that I have 2 remotes with the same FW, one works, one does not. I have one remote with older FW without an indication to upgrade and I have one with the latest FW, all are E1743's. Then I have one E1524 that refuses to bind and lost it's bindings to the default bind group (which is not supposed to happen at all).
At least all the remotes still work so I can capture the messages and build automation for it but then it's all dependent on a running raspberry pi so no fall back scenario.

[grafalex82]

Hi All,

I am diving into a binding topics from a device creator prospective. Trying to understand a fact that during Lonsonho 2 gang switch pairing Z2M configures 2 bindings from the device to the coordinator (see lonsonho.js, line 164)

            await reporting.bind(device.getEndpoint(1), coordinatorEndpoint, ['genOnOff']);
            await reporting.bind(device.getEndpoint(2), coordinatorEndpoint, ['genOnOff']);

What is this for? Xiaomi switches and relays do not make any bindings.

[sjorge]

The clusters can have input and output clusters.

e.g. a switch button's output to a relays input to control it, without the coordinator being involved for example

But a lot of the times we bind the output cluster(s) on the device's enpoint to the coordinator so we can actually get the events they generate.

[grafalex82]

Thank you for the answer. I am a little bit confused, though.

Let's compare two functionally similar relay switches - Xiaomi LLKZMK11LM, and Lonsonho QS-Zigbee-S04-2C-LN. Both devices have only input clusters (if not counting genOTA and getTime). Both devices report back to the server the current state of the switch.

So why Lonsonho requires binding its clusters to the coordinator, while Xiaomi one does not? In other words what would stop binding Lonsonho clusters? Will it continue reporting its state?

[heggink]

@vide I have not since I had no idea that I had this issue. I mostly use the remotes as a backup (in case my pi dies). It was only when I tried to repurpose one of the remotes when I noticed that, out of 5, only one still had a working group association. The weird thing is that I have 2 remotes with the same FW, one works, one does not. I have one remote with older FW without an indication to upgrade and I have one with the latest FW, all are E1743's. Then I have one E1524 that refuses to bind and lost it's bindings to the default bind group (which is not supposed to happen at all).
At least all the remotes still work so I can capture the messages and build automation for it but then it's all dependent on a running raspberry pi so no fall back scenario.

So it turns out that the binding function in the remotes has changed from group based to device based: I can now bind both the E1524 (dimmer) and the E1743 (switch) to (multiple) individual devices (at the same time), just not to a group. Whilst not as handy as a group, still functional and very workable for me!

[martin-g-it]

Have you first removed the binding from the default group 901?

…

Op 11 jun. 2021 om 09:21 heeft heggink ***@***.***> het volgende geschreven:  @vide I have not since I had no idea that I had this issue. I mostly use the remotes as a backup (in case my pi dies). It was only when I tried to repurpose one of the remotes when I noticed that, out of 5, only one still had a working group association. The weird thing is that I have 2 remotes with the same FW, one works, one does not. I have one remote with older FW without an indication to upgrade and I have one with the latest FW, all are E1743's. Then I have one E1524 that refuses to bind and lost it's bindings to the default bind group (which is not supposed to happen at all). At least all the remotes still work so I can capture the messages and build automation for it but then it's all dependent on a running raspberry pi so no fall back scenario. So it turns out that the binding function in the remotes has changed from group based to device based: I can now bind both the E1524 (dimmer) and the E1743 (switch) to (multiple) individual devices (at the same time), just not to a group. Whilst not as handy as a group, still functional and very workable for me! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[heggink]

It was no longer bound to 901 and I was not able to rebind it to 901. With the previous firmware, I think it was bound to 901 by default with no way to unbind.

[helljol]

Hi Guys,

First thanks for this great software.

I'm using the lastest version (also tried with dev branch) and i was not able to get a E1743 working to control LED1837R5 light.
I can successfully bind the dimmer/switch to the light group or to individual light but nothing happen. Log show the action happen correctly but it seems it does not get send to the light.

Is there something I'm missing here or something broken ?

[mhl66]

Same here for E1743 with deconz control software ("bind panel"). No effect after turning off coordinator, thus: no bind in effect.