ZHA - Philips Hue Dimmer Switch (individual buttons with long presses)

Blueprints Exchange
,
2

Any idea if this is limited to certain models or firmware versions? My zha_event only shows “on,” “off_with_effect,” and “step” as valid commands. My device shows 0x420045b6 as firmware, RWL020 as model with zhaquirks.philips.rwl021.PhilipsRWL021 stated. I don’t have a Hue hub so perhaps I am behind on firmware that added more granularity to buttons? My device is model 324131092621.

Blueprint looks really handy, but definitely won’t work for my situation as-is, so worth noting at least even if we can’t figure out the disparity as I am sure others are in the same boat.

3

Hi mstanislav,

I have to admit that I am not 100% certain if it’s firmware or model related. I don’t use, and haven’t used a hue hub for years, but do notice that all my remotes are model RWL021, and an example of a single “on” button press generates the following 3 ZHA events:

Event 2 fired 10:58 AM:
{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "...",
        "unique_id": "...",
        "device_id": "...",
        "endpoint_id": 2,
        "cluster_id": 64512,
        "command": "on_short_release",
        "args": {
            "button": "on",
            "press_type": "short_release",
            "command_id": 0,
            "args": [
                1,
                3145728,
                2,
                33,
                1,
                0
            ]
        }
    },
    "origin": "LOCAL",
    "time_fired": "2021-01-01T09:58:19.456110+00:00",
    "context": {
        "id": "39e17b5046512f489fb2a71c99583ac4",
        "parent_id": null,
        "user_id": null
    }
}
Event 1 fired 10:58 AM:
{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "...",
        "unique_id": "...",
        "device_id": "...",
        "endpoint_id": 2,
        "cluster_id": 64512,
        "command": "on_press",
        "args": {
            "button": "on",
            "press_type": "press",
            "command_id": 0,
            "args": [
                1,
                3145728,
                0,
                33,
                0,
                0
            ]
        }
    },
    "origin": "LOCAL",
    "time_fired": "2021-01-01T09:58:18.451999+00:00",
    "context": {
        "id": "44b32ed320ee30bdd72e0d05e516dec2",
        "parent_id": null,
        "user_id": null
    }
}
Event 0 fired 10:58 AM:
{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "...",
        "unique_id": "...",
        "device_id": "...",
        "endpoint_id": 1,
        "cluster_id": 6,
        "command": "on",
        "args": []
    },
    "origin": "LOCAL",
    "time_fired": "2021-01-01T09:58:18.169953+00:00",
    "context": {
        "id": "a82f27c1662a86c1633ea51b0147a294",
        "parent_id": null,
        "user_id": null
    }
}

So it maybe that this blueprint is limited to RWL021 models and the RWL020 only sends one zha_event on a single press, if so, I will adjust the title of blueprint, but am willing to look at this with you and see if we can get it to work with the RWL020 as well. Would you be able to post the (developer tools > events) events that get generated by all the button presses on your dimmer?

Edit: we share the same firmware by the way, so that won’t be the issue.

4

Not sure if you’ve seen the Blueprint ZHA - Philips Hue Dimmer Switch (RWL020, RWL021) but it uses the button commands that I have. It appears that people with the RWL021 (which I believe is the EU release vs RWL020 for the US) use it as well and that from other threads the only difference should be the button labels/packaging, not functionality.

I am using “normal” ZHA support in HA on 2020.12.0 with a HUSBZB-1 for the radio. It’s interesting we have the same firmware, I would have bet that was our difference – or the difference from people using the RWL021 in the other thread… now I am very confused :slight_smile:

Off, Dim Down, Dim Up, and On. I do not see any events for hold, hold+release, double tap, etc.

{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "...",
        "unique_id": "...",
        "device_id": "...",
        "endpoint_id": 1,
        "cluster_id": 6,
        "command": "off_with_effect",
        "args": [
            0,
            0
        ]
    },
    "origin": "LOCAL",
    "time_fired": "2021-01-01T15:32:50.372079+00:00",
    "context": {
        "id": "9cf6c6624b9447c4c8c894ebac894939",
        "parent_id": null,
        "user_id": null
    }
}

{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "...",
        "unique_id": "...",
        "device_id": "...",
        "endpoint_id": 1,
        "cluster_id": 8,
        "command": "step",
        "args": [
            1,
            30,
            9
        ]
    },
    "origin": "LOCAL",
    "time_fired": "2021-01-01T15:32:49.327342+00:00",
    "context": {
        "id": "cdb59a9928232e61ad9067648630c8c2",
        "parent_id": null,
        "user_id": null
    }
}

{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "...",
        "unique_id": "...",
        "device_id": "...",
        "endpoint_id": 1,
        "cluster_id": 8,
        "command": "step",
        "args": [
            0,
            30,
            9
        ]
    },
    "origin": "LOCAL",
    "time_fired": "2021-01-01T15:32:48.204006+00:00",
    "context": {
        "id": "95d88562dfd915e7daee85f8fcb1756e",
        "parent_id": null,
        "user_id": null
    }
}

{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "...",
        "unique_id": "...",
        "device_id": "...",
        "endpoint_id": 1,
        "cluster_id": 6,
        "command": "on",
        "args": []
    },
    "origin": "LOCAL",
    "time_fired": "2021-01-01T15:32:46.852426+00:00",
    "context": {
        "id": "5ca85e505194189830c366d3500d2f75",
        "parent_id": null,
        "user_id": null
    }
}

Here is a Zigbee Device Signature for one of my remotes

{
  "node_descriptor": "NodeDescriptor(byte1=2, byte2=64, mac_capability_flags=128, manufacturer_code=4107, maximum_buffer_size=71, maximum_incoming_transfer_size=45, server_mask=0, maximum_outgoing_transfer_size=45, descriptor_capability_field=0)",
  "endpoints": {
    "1": {
      "profile_id": 49246,
      "device_type": "0x0830",
      "in_clusters": [
        "0x0000"
      ],
      "out_clusters": [
        "0x0000",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0008"
      ]
    },
    "2": {
      "profile_id": 260,
      "device_type": "0x000c",
      "in_clusters": [
        "0x0000",
        "0x0001",
        "0x0003",
        "0x000f",
        "0xfc00"
      ],
      "out_clusters": [
        "0x0019"
      ]
    }
  },
  "manufacturer": "Philips",
  "model": "RWL020",
  "class": "zhaquirks.philips.rwl021.PhilipsRWL021"
}
5

I am starting to worry that this might require insight beyond my skill level :thinking:…
I had done some (minor) looking around too and indeed also reached the conclusion that the only difference between our devices is the US vs EU model.

I just last week migrated from deconz to native “normal” (for as far as I can tell) ZHA. However, I do use a ConbeeII as my radio. I’m puzzled why the zha events would be different from radio to radio, but that is the only explanation I can think of. I am sure there are more skilled persons that might have a better answer however…

I do notice the “args” are different in your events from mine, maybe the key as to what type of event we’re dealing with is hidden within those.

6

So good (and bad?) news :slight_smile:

I had bought a new dimmer remote a few weeks back to go with my 2+ year old ones and despite the Zigbee signature details being the same, showing the same firmware, showing the same quirks… this “new” device has your zha_event structure whereas my “old” three devices do not. The model number on the back is the exact same, too.

What I can’t figure out is I would generally assume the stock would have been rotated out over this many years such that a new device is more likely to have firmware updated past the last time I had a Hub (probably close to three years). But in the other thread that person said they updated their remote and now see the less featureful zha_event.

Not sure where that leaves us all told except, there’s clearly a firmware-dependent difference (which is good we eliminated Zigbee radio/HA stuff? I am not clear what firmware that actually is, except to guess it’s very old.

7

A commenter on Upgrading Hue dimmer with ZHA OTA just recently used not-yet-integrated zigpy functionality to do an OTA update for their Hue dimmer remote. I just pinged them to sort out if after that update, what zha_event data they are seeing. May help confirm the current working theory that old firmware had more event meta data being received. TBD!

8

OK, so based on some feedback about this event data being related to ZHA quirks functionality, I did a “Remove” in the Zigbee control panel on one of my “old” remotes and did the ‘Setup’ button on my remote. When the device was re-added, I am now seeing the extra button meta data! Will perform the same on my last two “old” remotes, but it seems like because they were added before some quirks functionality was updated, I never received that support in Home Assistant. So anyone reading this, go ahead and follow the same process and you should end up with a much more functional remote in HA :slight_smile:

@mannerisms on the actual topic of your Blueprint :wink: have you thought about adding support for off_double_press and on_double_press? They are a bit weird since there is no blocking on the initiating press events to go through too, but maybe if you wanted to quickly turn off a bunch of groups of lights it may not matter that “extra” presses occur on a group from what would be the “single” events that would precede the action on the double?

9

Thanks for figuring all this out mstanislav! very valuable information I had no idea about.
I had initially added the double press events, but like you pointed out, found that they conflicted with the single press events and not reliably activate the scene I had set to the double press event. Thus ended up removing it, but could add it again with that caveat.

1 Like
10

Thanks for the blueprint. As a little request it could be good to note the names of the buttons in the input fields, e.g. Button 1 (on), Button 2 (up), Button 3 (down), Button 4 (off) instead of just 1, 2, 3 and 4. I sometimes like to make adaptations on the sofa and not always remember the order of the buttons :wink:

11

Thanks for the input, modified the blueprint according to your suggestion!

1 Like
12

I added the double press action to the blueprint. Thanks for the input!

13

Awesome! Works well for my use case, which is:

  • Light Group 1: Single (On/Up/Down/Off)
  • Light Group 2: Hold (On/Up/Down/Off)
  • Light Group 1+2+3+4 Double (On/Off)

Group 3/4 are mostly ran by schedule, but if I want to get “all lights” on/off fast this works really well. I am probably going to forego the Up/Down on the ‘double’ since in my situation I have a mixture of bulbs+LED strips and synchronizing brightness wouldn’t be something I can use right now – but hope someone else can. Certainly they will be glad to know how much extra functionality is sitting in a $25USD remote :wink: Nice job, and thank you!

1 Like
14

Awesome!

Happy to hear that it was of value to you!

15

Is it possible to have the on button cycle through the color temperatures, the same way it does by default when it’s paired via a Hue Bridge?

16

That should be possible through a script, than the action for the top button would be to call the script. I have not uses a hue bridge in years, and am not familiar with this function, but cycling through a list of color temperatures / scenes, should not be impossible. I can look into scripting that out if I have a some spare time… (not much of that available lately)

18

Is it possible to get this blueprint working with the Hue Bridge? Have most switches set up with individual automations, but this blueprint won’t recognise any switches in my setup apparently…

19

Hi @wolfster,

This blueprint listens specifically to zha events, although I can’t say with 100% certainty, I think this blueprint could be adjusted to include hue_events, or better yet, a similar blueprint should be feasible for hue event. I however do not use the hue bridge for any battery devices, so am not in a position to verify this quickly.

1 Like
20

Recently updated to home assistant 2021.4 and the update broke this blueprint. The error is:

Template variable error: 'dict object' has no attribute 'event' when rendering '{{ trigger.event.data.command }}'

Any clue about how to fix it? Couldn’t find anything in the changelog yet.

EDIT:

Apparently I’m having the same behaviour that [mstanislav] experienced on this thread. I’m trying to repair my dimmer to make it work with the additional event data. Is the recent update related with this problem?

21

Sorry, can’t say with any degree of certainty if it’s related. For me the update has caused no problems and thus can’t recreate the error.

23

Works perfect for me, rhanks! I use the double press for a broadcast to media players, but I would like to add a condition based on time to prevent broadcasting late in the evening. I know how conditions work in HA but I wonder if I’m able to add it myself and where in a blueprint automation.