Newer Hue Wall Switch Modules Not Working

[jamesonuk]

What happened?

This is splitting out what appears to be two separate issues from https://github.com/Koenkk/zigbee2mqtt/issues/19941 The OP in that thread (and others) are having issues adding the module to the group but there is also a discussion around changes in how the device work that appear to be in new devices and/or firmware.

We can definitely see that a RDM001 device on firmware 1.0.5 / 20210504 has the following state after being clicked but a newer RDM004 device on firmware 2.60.16 / 20220510 has the following

Both are configured the same way being bound to a group of lights

The newer device (appears that it may also affect older devices which had firmware updated via Hue hub) is then not working (leaving the lights in a state where they just can't be controlled any more)

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

2.1.3

Adapter firmware version

0x26780700

Adapter

Conbee II

Setup

Docker

Debug log

[2025-03-17 15:21:03] debug:    z2m: Received Zigbee message from 'Spare Room/Hue Wall Switch', type 'commandOn', cluster 'genOnOff', data '{}' from endpoint 1 with groupID 15
[2025-03-17 15:21:03] debug:    z2m: No converter available for '929003017102' with cluster 'genOnOff' and type 'commandOn' and data '{}'
[2025-03-17 15:21:03] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Spare Room/Hue Wall Switch', payload '{"battery":100,"device_mode":"single_rocker","last_seen":"2025-03-17T15:21:03.724Z","linkquality":255,"state":"ON"}'

[jamesonuk]

Having sniffed the traffic I am seeing this from the newer switch 34 times .... (But I presume that is just as a result of it being a broadcast message and having lots of routers) followed by (well they get intermixed but I guess again that is down to the network size and being broadcast).

for an older one I see

which I guess confirms that the two devices are most definitely working in different ways

https://github.com/Koenkk/zigbee-herdsman-converters/blob/089aee198634564762f156168d006686a05bc94d/src/devices/philips.ts#L2319-L2323 looks like the converter is setup for toggle but not for these on/off commands

[jamesonuk]

@Koenkk / @Nerivec I don't suppose you could just throw me a pointer as to whether I can read an attribute that isn't defined in Z2M.

As per https://github.com/zigpy/zha-device-handlers/issues/2764 there is attribute 0x0031 in the basic cluster (Called Philips - Configuration in Deconz) but that doesn't exist in Z2M so through the UI I can't read / write it. Just want to see what this is set to across the different devices

I can see appear to be parsing 0x00034 (https://github.com/Koenkk/zigbee-herdsman-converters/blob/66072f484fbb7076789c900b23bf392d9295b88f/src/converters/toZigbee.ts#L2330) which is obviously the switch type.

I am also right in thinking that the clusters tab is always complete? I see ZCL has an on/off config cluster (0x0007) and just wanted to check this doesn't show up because the device doesn't support it rather than it just not being in the Z2M config?

[Koenkk]

Could you check if the issue is fixed with the following external converter:

• save this as file next to configuration.yaml in the external_converters directory (create if it doesn't exist yet) as ext_converter.js (so external_converters/ext_converter.js)
• start z2m,
• in the frontend, check if the description of this device now ends with CUSTOM (this indicates the external converter has been loaded correctly)
• check if issue is fixed

[jamesonuk]

Could you check if the issue is fixed with the following [external converter]

I am not at home to check but the issue it two-fold. Currently we have one device that behaves in two different ways and not sure whether this is down to the device or the firmware (just trying to work out if RDM001 on 2.x firmware behaves the same as the RDM004 which ships with 2.x firmware). I think ultimately this might need the two split into two different converters.

When I started playing I was looking at a Deconz thread which says it now works like Hue dimmer which actually ignores the on/off commands and processes button presses from the Hue specific cluster

https://github.com/Koenkk/zigbee-herdsman-converters/blob/89ab46f435273bee930cec78e2f2d050e6fa5af8/src/devices/philips.ts#L2398-L2406

I think this is probably the same here. I think if you are processing it via Z2M then you want the actual button press which is already handled by fz.hue_wall_switch (I guess there is no harm in ignoring these regardless as if the RDM001 never sends them it has nothing to ignore)

The biggest pain for me is that the older models allowed me to bind them but if they are sending on/off messages (and appears to be just be in sequence) instead of toggle then that breaks that (which massively reduces their usability for me 😢 ) so looking at digging into how they work a little deeper as there is talk about this magic 0x000b value on 0x0031 attribute of genBasic (which is set for the dimmer and several other Hue switches) but I haven't actually been able to find anything to say what this magic value is meant to do....

There is also state on the switch (ON/OFF) which never seems to change so perhaps if that was synced this would solve the on/off working instead of a basic toggle.

I did see I can send a MQTT message to query attributes that aren't defined in the converter (and I think that I am sure that clusters are always complete so although there is a 0x0007 switch config cluster, this would show up in Z2M if the device supported it, regardless of the converter). When I did query something though I just saw an unsupported attribute value which I am sure is saying the device doesn't support it or whether it is saying Z2M doesn't know what to do with it as it isn't in the converter. (eg. it would be nice to see what this 0x0031 attribute is set to for different devices)

Going to do some playing around with both models and see what differences I see. Ideally I am hoping I can spot something in the Hue specific cluster that allows you to alter the on/off functionality to be a toggle. Without it these lose a lot of appeal.....

[rvanmaanen]

I'm currently not at home and can't check statusses or exact firmware versions, but two weeks ago I installed and configured 4 of these RDM004 models which all work fine. I did update them all to the latest firmware by connecting them to a Hue bridge first and I'm pretty sure that firmware is a lot newer than the one they were shipped with.

Think I updated them to this one: December 11, 2024 All Philips Hue accessories Software version 67.115.5, 2.77.35, 2.77.39

Bug fixes and stability improvements

Update: I didn't add them to a group or anything btw, just use them through Home Assistant

[jamesonuk]

Just tagging https://github.com/Koenkk/zigbee2mqtt/issues/25791 as that is kind of the same issue.

also https://github.com/dresden-elektronik/deconz-rest-plugin/issues/7490#issue-2055162469 where they have listed a few Hue specific attributes including this magical 0x0031 configuration attribute and a further 0x0051 enum that is apparently rw.

I am guessing Deconz have parsed all the available attributes and you can determine the types and r/rw but there is no way of knowing the enum value without already knowing them???? I guess all I can try here is setting it from 0 to 255 and seeing if anything changes and then try and work out what ?

[uschindler]

Hi, I am ZHA user but the same problem also appears there. I also bought one of the newer switches. Their shipped firmware and the newest one from @Koenkk's repository for those switches indeed no longer send "toggle" to the zigbee group but (depending on some internal state) either "on" or "off with effect" (and some 0.7 seconds delay). Because of the no longer sent toggle, the whole thing breaks if you have multiple switches bound to the group. It also breaks if you have one single switch bound to the group and toggle the light group using home assistant.

The main problem of that device is that the internal state "on/off" cannot be changed from outside and it also does not seem to update it internally from the real group status (possibly because it does not get the event from the group due to deep-sleep). This new behaviour "on/off-with-effect" vs "toggle" makes the switch almost unuseable in mixed multi-switch environments, because every switch has their own state.

Othe rpeople say that in the Hue Software they can make the switch behave correctly, but I have no idea how that's handled there. I have no Hue Coordinator so I can't sniff it.

Possibly there is some extra setting in the Phillips cluster that can set the on/of/toggle state with a different ID. Has anybody tried to try out other phillips/basic cluster setting ids to figure out how it reacts to other (not yet used) settings which me may not havce discovered yet? There must be a way to change the configuration of the switch so it send toggle events! From a "selling point of view" it might be nice to sell those switches as being able to fade the light off in 0.7 seconds (yes, looks really nice), but there should be the option to change them to simple toggle behaviour. I am sure Phillips has this somehow implemented, but nobody knows about any config option or they never documented it in change log how to change this in later firmwares or the RDM004 switch.

In the meantime I created an automation that I can post here that I use to manually toggle the switch if it receives the event about the button was pressed. The automation basically waits 500 ms and then sends a toggle event to the light group under the condition that for the last 1 s no state change happened on the light group. This brings both of two worlds: Switch works without coordinator and when the HASS coordinator is on and working it toggles the light if not done by the switch itsself. This adds a short delay of 500 ms for the problematic case (internal switch state does not fit the light group state), but when coordinator is off the lights can still be controlled.

Here is the automation. Be aware that the automation explicitely updates the light group entity before it checks for a change:

alias: "Licht: Fix state of Küchenzeile Hue Switch"
description: ""
triggers:
  - device_id: 2a276f0f34356e770e947d9e57579b77
    domain: zha
    type: remote_button_short_press
    subtype: turn_on
    trigger: device
conditions: []
actions:
  - delay:
      hours: 0
      minutes: 0
      seconds: 0
      milliseconds: 500
  - action: homeassistant.update_entity
    metadata: {}
    data:
      entity_id:
        - light.zigbee_coordinator_kuche_indirekte_beleuchtung
  - condition: or
    conditions:
      - condition: state
        entity_id: light.zigbee_coordinator_kuche_indirekte_beleuchtung
        for:
          hours: 0
          minutes: 0
          seconds: 1
        state: "off"
      - condition: state
        entity_id: light.zigbee_coordinator_kuche_indirekte_beleuchtung
        for:
          hours: 0
          minutes: 0
          seconds: 1
        state: "on"
  - action: homeassistant.toggle
    target:
      entity_id: light.zigbee_coordinator_kuche_indirekte_beleuchtung
    data: {}
mode: single

[uschindler]

Maybe I will configure the configuration option 0x51 as enum like the 0x34 type in my ZHA quirk. If I find something out (and what the default value is), I will report here.

Does anybody know what the option 0x31 config attribute is? It is a 16 bit integer/bitset, but I don't want to try out all possible combinations.

[jamesonuk]

Does anybody know what the option 0x31 config attribute is? It is a 16 bit integer/bitset, but I don't want to try out all possible combinations.

Real life keeps getting in the way but from what I can tell the config attribute is seemingly always set to 0x000b but no-one knows why... and it doesn't seem to affect anything when it is set from what I can see.

The other attribute (0x51) is listed as unknown on that Dresden thread but I did briefly try to read it without much luck.

The one thing I did start looking at is that as well as the ZCL on/off commands it sends a Hue specific message with the raw value of 0100003000210000 or 0100003002210100 (ISTR one was for on and the other for off, or is could have been that one was switch 1 and the other switch2).

I don't have a Hue hub either but I am starting to think that the Hue hub doesn't handle it, is just uses the manufacturer specific messages and ignores the ZCL ones (which I think you can setup in HA by binding the hue specific cluster to the coordinator and not the on/off cluster). I really want to change the actual ZCL messages as binding the switch to the lights directly makes a huge difference for usability and resilience.

Would be very interested in you get anywhere (also I have https://github.com/dresden-elektronik/deconz-rest-plugin/issues/7947 in my notes which might be helpful)

[uschindler]

It's weekend I have a bit of time to check out the options. My first step is to make the zigpy quirk to allow all the deconz-discovered settings changeable. I will report.

@Koenkk: Sorry for misusing this thread also for ZHA-related issues, but as this is hardware specific I think both Zigbee projects (and many others supporting "custom quirks") can investiagte how this switch can be get under control. It's a pity that Phillips has no documentation at all. IMHO the developers of custom clusters should be forced to document all settings of their devices to get zigbee certification.

Does anybody contact phillips with that question: "Why the hell does the device suddenly send on + off-with.effect instead of simple toggle events?"

[uschindler]

I'd wish there are other in-wall buttons without relais from Sonoff.

[uschindler]

Hi, I was not able to figure out anything useful:

• the tested RDM004 has firmware 0x02004d23 from the ZHA OTA provider or z2m, not sure where it came from. It was updated last week. This corresponds to version number 2.77.35
• config flag 0x0031 is 0 (zero) on my device, 0x0033, 0x0051 and 0xF109 are all None. If you set arbitrary value (which succeeds without error) you see no change in behaviour and when you get the value again it is switching back to None.
• I tried the "mode" enum 0x0034 and tried if there are new enum values on the newer device: My hope was that 0, 1, 2, 3 are the well-known values, but maybe they have extended the enum to 4, 5, 6 ,7 (corresponding to have same meaning than 0-3, just with toggle instead of on/off). Unfortunately this did not work, the device rejects any value outside the 0-3 range.

This is all a desaster. Does anybody know where to get a RDM001 device and is it possible to downgrade the firmware OTA?

[github-actions[bot]]

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

[jamesonuk]

Bump

[github-actions[bot]]

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

[HobboRobin]

I asume the Problem still exist. I have currently 4 RDM004 and want to control 1 Light but i cant toggle them because they send out on/off

And unfortunatly i have only 3 RDM001 :D