[Problem]: Hue wall switch binding issue

[rhvs]

What happened?

The Hue wall switch binds succesfully to a lamp, however it doesn't operate the lamp as expected (nothing happens).

What did you expect to happen?

I expected that (as I did before with the Hue dimmer switches) after binding, I would be able to operate the light directly.

How to reproduce it (minimal and precise)

Zigbee2MQTT version

1.22.2

Adapter firmware version

20211217

Adapter

Slaesh's CC2652RB stick

Debug log

[Tonio16]

Hello

Did you try without the coordinator in the binding list, like for the 324131092621?
https://www.zigbee2mqtt.io/devices/324131092621.html#philips-324131092621

Antoine

[leoluk]

Unbinding the coordinator doesn't seem to do anything :/

Sniffer shows that binding a light get a "Success" reply and unbinding twice returns "No Entry" the second time - so it does update its binding table, but never sends any commands.

The device simply doesn't seem to support binding.

Related threads:

• Support Signify/Philips Hue wall switch module (RDM001) zigbee-herdsman-converters#2393
• Hue wall switch module. dresden-elektronik/deconz-rest-plugin#4566
• [Device Support Request] Philips Hue Wall Switch Module zigpy/zha-device-handlers#858

[rhvs]

Not sure if it's related, but a dimmer switch has two endpoint (attached screenshots of the dimmer switch clusters and wall switch (1 endpoint). When binding the dimmer switch, the second endpoint is used.

[Koenkk]

Could you check if this issue has been fixed with the following external converter:

const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const extend = require('zigbee-herdsman-converters/lib/extend');
const e = exposes.presets;
const ea = exposes.access;
const tuya = require('../lib/tuya');

const definition = {
    zigbeeModel: ['RDM001', '9290030171'],
    model: '929003017102',
    vendor: 'Philips',
    description: 'Hue wall switch module CUSTOM',
    fromZigbee: [fz.battery, fz.hue_wall_switch_device_mode, fz.hue_wall_switch],
    exposes: [e.battery(), e.action(['left_press', 'left_press_release', 'right_press', 'right_press_release']),
        exposes.enum('device_mode', ea.ALL, ['single_rocker', 'single_push_button', 'dual_rocker', 'dual_push_button'])],
    toZigbee: [tz.hue_wall_switch_device_mode],
    configure: async (device, coordinatorEndpoint, logger) => {
        // const endpoint = device.getEndpoint(1);
        // await reporting.bind(endpoint, coordinatorEndpoint, ['genPowerCfg', 'genOnOff', 'manuSpecificPhilips']);
        // await reporting.batteryPercentageRemaining(endpoint);
        // const options = {manufacturerCode: 0x100B, disableDefaultResponse: true};
        // await endpoint.write('genBasic', {0x0034: {value: 0, type: 48}}, options);
    },
};

module.exports = definition;

• save this as file next to configuration.yaml as ext_converter.js
• add it to configuration.yaml:

external_converters:
  - ext_converter.js

• start z2m, go to the frontend, verify that the description of the device ends with CUSTOM (this means that external converter has been loaded correctly)
• now factory reset the hue wall switch (repair it)
• try to bind it.
• does it work now?

[WernerRH21]

CC2652P Stick with firmware 20211217
I use mqtt server adapter in ioBroker to collect datapoints, but there is no usable to work with.

[leoluk]

@Koenkk

Thanks! So, this is interesting.

Added the external converter, paired the switch and confirmed that it loads the CUSTOM converter.

The device continues to ignore the binding config - it maintains a binding table and I can bind/unbind things, it just doesn't do anything. However, when looking with a sniffer, you can see that it actually does send OnOff broadcasts regardless of binds, but to a hardcoded group 0xd31d (I haven't tested whether this happens only with the custom converter):

And indeed, creating a group with that ID and adding lights to it works perfectly! Even dimming works (with single_push_button).

When setting mode to dual_rocker, both channels work, but use the same group ID (not terribly useful). Presumably, the Hue bridge uses vendor-specific commands to properly configure these as well as things like scenes.

Switching lights on/off via the switch also won't update the entity status in z2m, presumably because it doesn't know anything about the "binding" and hasn't set up the right reportings. For my use case, this is the only thing that's missing. Manually configuring reportings on the two Surface Light TW in the group fixes status:

Worth trying to remove the custom converter? What is the commented-out code supposed to do originally (other than configuring battery status reporting, which indeed doesn't work)?

(actually switched from zha to z2m so I can try this - I'm definitely keeping z2m, it's so smooth - thanks!)

[Koenkk]

@leoluk

Worth trying to remove the custom converter? What is the commented-out code supposed to do originally (other than configuring battery status reporting, which indeed doesn't work)?

Yes please check if this doesn't change the binding behaviour.

[leoluk]

@Koenkk - you were right

Can confirm that without the custom converter, it's back to sending key presses to the coordinator after a reset and no longer sends anything to the group:

(different NWK since this is a spare)

[Koenkk]

@leoluk can you switch back to the external converter and remove the comments line-by-line to see what statement is stopping the switch from sending commands to the group? (#10740 (comment))

[leoluk]

@Koenkk Binding the reporting endpoints makes the difference. With this config, it still sends group commands:

  configure: async (device, coordinatorEndpoint, logger) => {
      const endpoint = device.getEndpoint(1);
      //await reporting.bind(endpoint, coordinatorEndpoint, ['genPowerCfg', 'genOnOff', 'manuSpecificPhilips']);
      await reporting.batteryPercentageRemaining(endpoint);
      const options = {manufacturerCode: 0x100B, disableDefaultResponse: true};
      await endpoint.write('genBasic', {0x0034: {value: 0, type: 48}}, options);
  },

[Koenkk]

@leoluk can you find out which cluster? Start with await reporting.bind(endpoint, coordinatorEndpoint, ['genPowerCfg']);

[kegelmeier]

Anyhow, I can support here?

Also trying to bind the Hue Wall Switch with a Hue Light Group with success, however, no effect while pressing.

[cyrille74500]

same problem....

[trollix]

Hello, same problem. I can Bind, but no effect when action

[Daanoz]

From the other thread, it looks like the group address changes on each reset, anyone knows an easy way to get the last known group address, or do we need a sniffer for it?

dresden-elektronik/deconz-rest-plugin#4566 (comment)

[Daanoz]

Right, so I hooked up to one a group, and the switch can indeed turn on an off a group.

Ended up with these reports in the convertor
await reporting.bind(endpoint, coordinatorEndpoint, ['genPowerCfg', 'genOnOff'/*, 'manuSpecificPhilips'*/]);

After removing the device from the network, resetting and rejoining. The following messages can be observer in debug mode on the logging when pressing a button:

The 15204 group id is the group that's gets toggled in this case, but it changes on every reset of the switch. There is also no difference between switch 1 and 2; both seem to trigger the same message towards the 15204 group id.

Does it help if I try to do a sniff when it's connected to a Hue bridge? I don't have a setup yet to do that, but I think I can get that arranged.

[Daanoz]

So, I started sniffing on the Hue Bridge. Some key take away's:

• The Hue bridge doesn't use binding as far as I can tell, If I simply unplug the bridge the switch stops working. All messages from the switch also have as destination the bridge.
• There is a difference in payload for the p1 port and the p2 port, but not if it's connecting or disconnecting.

Action	Sequence
Connect P1	0100003000210000 -> 50ms -> 0100003002210100
Disconnect P1	0100003000210000 -> 50ms -> 0100003002210100
Connect P2	0200003000210000 -> 50ms -> 0200003002210100
Disconnect P2	0200003000210000 -> 50ms -> 0200003002210100

Payload doesn't change between single rocker and dual rocker mode; except that in single rocker mode the p2 port simply doesn't do anything.

As the bridge doesn't do binding, will it even ever work?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[leoluk]

Still relevant

[martijn-brant]

Are there any updates to this? I would like to remove ControllerX from my setup and just have these Hue modules talk natively via bindings.

[leoluk]

The modified binding should still work - when the cluster isn't bound to the controller, it sends OnOff commands to a random group. Not sure how to figure out the ID though other than checking with a sniffer.

[moritz31]

have the same problem with ioBroker and zigbee .... @leoluk is there an easy way to find out the groupId, which is random and need to be found first

[JBS5]

Any updates on the direct binding possibilities of the Hue Wall Switch?

[bavo]

<-Edit> Nvm, doesn't work for me either. (Had some automation running in HA that toggles the light)

[steve41200]

It always doesn't work for me. Have u the directbinding AND the coordinator ? or just the directbinding ? I try in the hue to bind with checkbox On/off Le ven. 18 nov. 2022 à 11:02, bavo ***@***.***> a écrit :

…

I can confirm this working for me on the Sonoff CC2652 stick - zigbee2mqtt version: 1.28.2 - Coordinator type: zStack3x0 - Coordinator revision 20220219 Wall switch has a direct binding to a group of 3 hue spots — Reply to this email directly, view it on GitHub <#10740 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOKQLH46FTMJGAX5KOOTNPLWI5H2LANCNFSM5LZWV6ZA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bavo]

See my edit, I was tricked by my Home Assistant setup into thinking this worked. It does not .... 😞

[martijn-brant]

I've had the PSU of my NUC running HA/Z2M get fried and I couldn't switch my lights off until I replaced it. This is of course a big flaw in my HA setup, being reliant on Zigbee, Z2M and some kind of switching logic (appdaemon in my case).

This ^^^

I have a large number of hue lights and while HA is pretty stable, I worry about being on the road for work and the fam unable to control lighting particularly in the remote area we're in. It's further complicated by the fact that I have the bulbs set to return to prior state in the event of a power loss as those happen regularly out here.

I'm actually a Deconz/Phoscon user with a Conbee II stick and I ended up here while researching this issue.

I was ultimately able to solve this in a simple manner by using an alternate version of the Phoscon software that they keep available via a link on the help page of the current application.

It allowed me to bind the hue switch directly to a group of lights. Using the newer hue switch, by default the top button is an on/off toggle and the brightness buttons work as well. The bottom button is not used. I tested the above with HA shut down.

With HA up, the above events are reported under deconz_events so I can see the actions there and handle them properly (accidental trigger in daylight, shutdown after time without activity, etc).

The remaining button actions are also available for regular HA use (bottom button, long press on all the buttons).

So with some quick training of the fam, I'm in business. I was subscribed to this thread and an update today reminded me to circle back and share my journey through this.

Are you referring the hue wall magnet mounted switch or do you mean the in-wall switches? We're talking about the inwalls that have two contact, nothing more.

[rhdny]

I was speaking of the on-wall vs the in-wall as evidenced by my description of the buttons.

The tool I referenced above supports the in-wall as well. I haven't bought one as the in-wall has less functionality for my use case and is also battery dependent. If it had neutral support, I'd likely get some.

I'm traveling a lot but if possible, I may get an in-wall to confirm the above outcome. Will circle back here if so.

[bjornarfjelldal]

This is awesome dedication, @Koenkk! Thanks a lot for your efforts. While you now have the device, is it possible to also investigate why it, in many cases, depletes the battery in a manner of days, as in #12545 and at least another issue number which I can't find at the moment, as well as https://community.home-assistant.io/t/battery-drain-philips-hue-wall-switch-modules/518501.

They are supposed to last 5 years, not 5 days.. :)

[Koenkk]

As written earlier in this thread, it is possible to make this device send toggle commands to Zigbee groups. To enable this some fixes where required. These are available in the latest-dev branch now. I documented how to accomplish the group binding: https://github.com/Koenkk/zigbee2mqtt.io/blob/develop/docs/devices/929003017102.md#directly-control-zigbee-groups

Changes will be available in the dev branch in a few hours from now. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html)

Note: this will probably break the battery reporting, something in the frontend needs to be fixed first (since genPowerCfg shouldn't be unbound). I will fix this later and update the docs.

@bjornarfjelldal regarding battery, please create a new issue for this (to not clutter this topic)

[martijn-brant]

As written earlier in this thread, it is possible to make this device send toggle commands to Zigbee groups. To enable this some fixes where required. These are available in the latest-dev branch now. I documented how to accomplish the group binding: https://github.com/Koenkk/zigbee2mqtt.io/blob/develop/docs/devices/929003017102.md#directly-control-zigbee-groups

To clarify.. this only works for one of the input/side of switch, right?

[Koenkk]

@martijn-brant yes, I've updated the docs with this.

Note: this will probably break the battery reporting, something in the frontend needs to be fixed first (since genPowerCfg shouldn't be unbound). I will fix this later and update the docs.

This will be fixed after nurikk/zigbee2mqtt-frontend#1754 is merged (already updated the docs)

I guess that after merging this issue can be closed.

[Koenkk]

nurikk/zigbee2mqtt-frontend#1754 is merged now, so I assume I can close this now.

[burpy]

I migrated from the Philips Hue bridge and a DECONZ Stick with Phoscon to Zigbee2MQTT on a Raspberry with a Zigbee 3.0 Sonoff USB Dongle.

It works very well with the Hue wall switch module and the workaround above to bind the Hue wall switch module with a group of lamps. As you mentioned the binding does not work with two outputs if I use two inputs in the wall switch mondule. Is there a change to get it work in future? At the moment this is the only reason to keep my Philips Hue Bridge alive.

This would be great!

[JBS5]

The current docs (https://www.zigbee2mqtt.io/devices/929003017102.html#directly-control-zigbee-groups) tells me to add the Hue Wall Switch to the created group, but in the past it was neccessary to create a group with the Group ID which was triggered by the Hue Wall Switch.

When adding the Hue Wall Switch to the created group, I get an error (even after waking up the device by pressing it one or multiple times).

Does anyone recognize this?

[marazmarci]

The current docs (https://www.zigbee2mqtt.io/devices/929003017102.html#directly-control-zigbee-groups) tells me to add the Hue Wall Switch to the created group, but in the past it was neccessary to create a group with the Group ID which was triggered by the Hue Wall Switch.

When adding the Hue Wall Switch to the created group, I get an error (even after waking up the device by pressing it one or multiple times).

Does anyone recognize this?

Yes, the same happens for me, but if after this you check what group ID the device sends commands to, you'll see that it is now the group you tried to add the device to 🙂

Please confirm that it works also for you like this, and then I'll update the documentation!

[JBS5]

The current docs (https://www.zigbee2mqtt.io/devices/929003017102.html#directly-control-zigbee-groups) tells me to add the Hue Wall Switch to the created group, but in the past it was neccessary to create a group with the Group ID which was triggered by the Hue Wall Switch.
When adding the Hue Wall Switch to the created group, I get an error (even after waking up the device by pressing it one or multiple times).

Does anyone recognize this?

Yes, the same happens for me, but if after this you check what group ID the device sends commands to, you'll see that it is now the group you tried to add the device to 🙂

Please confirm that it works also for you like this, and then I'll update the documentation!

Yes, you are right. I do see the groupID of the created group (15) in the log when I trigger the Hue Wall Switch by pressing the button.
But, not all the time, when I press e.g. 10 times, I see ~6-8x the log message like below. Not sure why, yet.

debug 2024-02-01 12:48:10: Received Zigbee message from 'Wandschakelaar WC boven', type 'commandToggle', cluster 'genOnOff', data '{}' from endpoint 1 with groupID 15
info  2024-02-01 12:48:10: MQTT publish: topic 'zigbee2mqtt/Wandschakelaar WC boven', payload '{"action":"toggle","action_group":15,"battery":100,"device_mode":null,"linkquality":75}'
info  2024-02-01 12:48:10: MQTT publish: topic 'zigbee2mqtt/Wandschakelaar WC boven', payload '{"action":"","battery":100,"device_mode":null,"linkquality":75}'
info  2024-02-01 12:48:10: MQTT publish: topic 'zigbee2mqtt/Wandschakelaar WC boven/action', payload 'toggle'

[daniel-langeland]

I can not get the module to add to a group, no matter what I do it always sends commands to groupID 0.
I have tried repairing, restarting, even tried one older model of the Switch module but same results.

Some info on my setup:
Zigbee2MQTT version
1.36.0-dev commit: 85c00b8
Coordinator type
zStack3x0
Coordinator revision
20230507
Coordinator IEEE Address
0x00124b002e0e1a5d
Frontend version
0.6.161
zigbee_herdsman_converters_version
19.11.1
zigbee_herdsman_version
0.40.3

The log message:
Received Zigbee message from 'Switch soverom', type 'commandHueNotification', cluster 'manuSpecificPhilips', data '{"button":1,"time":0,"type":0,"unknown1":3145728,"unknown2":0}' from endpoint 1 with groupID 0

Any idea what I am missing?

[daniel-langeland]

I can not get the module to add to a group, no matter what I do it always sends commands to groupID 0. I have tried repairing, restarting, even tried one older model of the Switch module but same results.

Some info on my setup: Zigbee2MQTT version 1.36.0-dev commit: 85c00b8 Coordinator type zStack3x0 Coordinator revision 20230507 Coordinator IEEE Address 0x00124b002e0e1a5d Frontend version 0.6.161 zigbee_herdsman_converters_version 19.11.1 zigbee_herdsman_version 0.40.3

The log message: Received Zigbee message from 'Switch soverom', type 'commandHueNotification', cluster 'manuSpecificPhilips', data '{"button":1,"time":0,"type":0,"unknown1":3145728,"unknown2":0}' from endpoint 1 with groupID 0

Any idea what I am missing?

Figured it out. I was checking the logs before I had gone through the bind procedure. After binding its all working!

[hvorragend]

Is it possible that something has been changed in the RDM001 with version 1.36.1? I had to remove all my wall switches and reset them several times. The first attempt only worked for a short time. After the second reset, it is stable.

I have noticed the error that all events are sent twice in direct succession.

[sanderlv]

Hi, I am not sure if I am hitting the same issue but after updating to 1.36.1 I have an issue which looks like the above. I described it here:
https://community.home-assistant.io/t/z2m-rdm001-not-working-anymore-after-update-to-1-36-1-1-929003017102

Now my lights do not work anymore :-(

Any help/guidance greatly appreciated...