Hue Dimmer Remote (connected via Hue Bridge + Hue Integration), December 2021 - Works w/RWL020 / 21 / 22

One general question to all using this blueprint : do you experience much delay for the lights to switch on / off compared to when they are directly controled by the hue app? (like annoying long :))

And second thing which I don’t find so cool: if I click on different buttoms of the hue remote too fast it won’t trigger the action (I guess the remote is locked by the first trigger until finished). Anything that I can do to improve that?

Hey there, @louloulepou ! Hope you’re well :slight_smile:

To answer your general question:

From my usage, the delay is < 1 second for both short and long presses; I would say between using the remote through this blueprint versus just the native Hue hub itself the delay is basically indistinguishable.

Here are some potential configuration differences that could be causing issues:

  • Using HomeAssistant versions Pre 2021.12
    • The 2021 December release introduced support for Hue API V2, which supports event-based messaging instead of the previous polling mechanism. This improves both performance of the Hue bridge as well as Home Assistant’s response to changes (e.g. dimmer remote button presses!)
  • Having a very large amount of devices on the Hue bridge
    • Pretty much self-explanatory. The bridge only has so many resources so if there are a ton of devices connected to it that could affect performance and user experience
  • Home Assistant server resource overload
    • Just like the Hue hub, whatever you’re running Home Assistant on could be bogged down by having too many processes, entities, etc., running on it at once.

For debugging this, I would just try disabling automations created with this blueprint and hooking up a scene/light in the Hue app. If it’s faster there then the issue can be narrowed down to most likely limited resources on Home Assistant. If it’s still slow there, then you’ll know it’s the Hue hub itself.


For the second part, take a look at the following from Hue V2 API:

There is a 1 second rate limit on the amount of event containers the Bridge will send. If the same property has changed twice within that timeframe, you only get the last state. If multiple resources have changed within that timeframe, then you will get multiple events grouped in a single container.

Reference (requires sign up/login): Hue V2 API section on events.

If triggering multiple events within < 1 second, only the last event will actually make it into Home Assistant. This could potentially cause an issue if attempting to run more events than the rate-limit will throttle. In this case there’s not much that can be done, since Home Assistant will be receiving events after the throttle.

Recommendation: if you need to support sub-second presses of different buttons, use a different method to connect the remote (e.g. manually connecting to a zigbee radio that’s directly connected to Home Assistant). Or, potentially a workaround involving a different approach via software.

On the software front: if you want to just have a repeat action with a single button, check out the blueprint addition from @lksnyder0 ; just be sure to not have long-press actions set up for a given button simultaneously! It also gets throttled due to the outline integration limitation… but it’s much easier to use than button-mashing!

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

1 Like

Hi there, thanks for your contribution!

I hope you’re alright with having it linked in the original post; if not, I’m happy to link or direct to your message.

I got some time to play around with it and works a treat! Great for the brightness controls.

Happy automating! :robot:

Hello!
Got a small problem with your blueprint: I’m using it with my Skyconnect Zigbee Bridge and it basically works, but only if the light is already turned on. If it’s turned off and I try to do anything it just gives an error:
Error: ValueError: Template error: int got invalid input 'None' when rendering template '{{ state_attr(light, 'brightness') | int }}' but no default was specified

Thank you :slight_smile:

Hey there, @NessD! Hope you’re well.

Happy to hear this blueprint is potentially compatible with the Skyconnect Zigbee bridge!

Please note for any users with the Skyconnect Zigbee bridge: this blueprint was made originally for and currently supports the native Hue Bridge V2 (V1 may also work but is untested).


As for the issue you’re seeing, this is likely since the attribute brightness doesn’t exist when a light’s state is off (as of 2023-02-19). An easy workaround is to define a default value that will take effect when the brightness attribute isn’t accessible on the light:

{{ state_attr(light, 'brightness') | default(128, true) }} # set to 50% brightness based on range of [0, 255]

Here we’re using the default jinja filter, which must have a boolean second parameter set to true if we’d like to create a default value based on a false-y input (None's truthiness in Python evaluates to False).
Additionally, we can see that the value output from the property brightness or default (which we are setting when the prop doesn’t exist) is also a number (so no need to cast to int)

  • Jinja defaults: docs
  • Info on template rules: docs

Hope this helps! Happy automating :grin:

Hi! Thank you for that!
I just realised I posted for the wrong Blueprint. But your solution still pointed me into the right direction. Thank you :smiley:

1 Like

Hi.
I got my self Hue starter kit that has bridge, dimmer(RWL022) and 2 lights.
Been trying to find way to get remote to work with HA but so far no luck.

I can see bridge, remote and light in Hue integration.
Remote shows only battery status but far as I have understood that is expected.

I have made simple automation with this blueprint(toggles light on/off with press of power button) but according to HA it newer gets triggered.

Any ideas where I have gone wrong?

Hey there @aki1987 , hope you’re doing well!

Yes, that’s (almost) all I’m seeing on my setup too. I have tested an RWL022 using the latest Home Assistant 2023.3 and it’s been working rock solid for me.

For troubleshooting:
Confirm that there is an automation on the Integration → Devices → {your_dimmer_name_here}:


(see highlighted part)

If you do have one automation (which is the automation using this blueprint), then check its actions and ensure that no conflicts are occurring.
For further debugging, you can check the last time the automation ran inside dev tools.

Please note that this integration is for the native Hue Bridge with Integration, which sounds like your setup, but is also good to confirm.


Hopeful it helps. Feel free to post back with your progress.

Happy automating! :rocket: :computer: :raised_hands:

I can see automation on remotes page.

Cant find any sing of life from logs.
For me it seems that for some reason HA wont notice or receive events from buttons.
But it gets battery status so connection should work.

Thanks for your response, @aki1987!

Can you check the developer tools and subscribe to the hue_event to see what events are coming through? Then reference the blueprint and see if the events are the same?

From Philips Hue - Home Assistant :

Hue remotes such as the Dimmer Switch are stateless devices, meaning that they do not have a on/off state like regular entities in Home Assistant. Instead, such devices emit the event hue_event when a button is pressed. You can test what events come in using the event developer tools in Home Assistant and subscribe to the hue_event

Best of luck!

Well no hue_event gets triggered. With * I see other events that should happen.
So now question is why nothing triggers.

Quick Googling didn’t yield anything useful. Have to dig more tomorrow.
If you have some good tips about setting up Hue it would be much appreciated.

Hmm, I would verify that the remote is connected to the Hue hub and can control lights on its own first.

There might be all sorts of things that could be done but establishing connectivity directly with the Hue hub will help you isolate where issues are occurring.

I might go about troubleshooting as follows: Hue hub? → networking? → Home Assistant Hue integration?

What I have tested so far.
I can control Hue lights from HA and with remote.
So I think its safe to say remote and bridge are talking together. And that HA and bridge are also talking together.
I also did notice that when remote got too far from hub and pressed button remote light went red. Home assistant noticed that remote had connectivity issues at that same time.
HA records events when light status/brightness changes.
Tried to reset remote settings from Hue app but nothing changed in HA except remote name.

I am very knew to HA so this could be a very stupid question but whenever i am going to save a new automation using this blueprint i get he following error: Message malformed: expected str for dictionary value @ data[‘subtype’]

Anyone know what this is ?

use_blueprint:
  path: lksnyder0/hue-remote-dimmer-january-2022.yaml
  input:
    dimmer_device: c386611d42b977398906eab25fa3c37d
    on_short_action:
      - type: toggle
        device_id: 73d5f372d85a3d2bebcafc6f41fd06b0
        entity_id: switch.under_counter_lights
        domain: switch
alias: UnderCounterLightSwitch

Hey @aki1987, hope you’re doing well!
Thanks for sharing your troubleshooting journey. I’m hopeful we’ll be able to resolve the issues you’re facing :grin:

Couple things:

  1. I would try removing the dimmer accessory from Hue, verify it’s removed in Home Assistant, and then add it back via Hue app and see it get picked up again by Home Assistant. After a restart, that might help. If it’s still not working, you’d probably want to consider learning more about the API and/or if you have backups just re-adding the Hue integration on Home Assistant. There aren’t really any guarantees from my end for either so please do so at your discretion.
  2. Just something I noticed when comparing our screenshots and what my actual config is: my Zigbee Connectivity sensor isn’t present for my dimmer anymore. I’m not sure if this has anything to do with connectivity method (guessing it doesn’t) but wanted to throw it out there in case it’s useful.

Would be great to know how things turn out.
Best of luck and happy automating! :robot::rocket::tada:

Hello @Ryanklingert and welcome to HA! Thank you for trying out this blueprint.
I see you’re using the one which allows for long-press :raised_hands:t2:

Thanks for sharing your automation config; to be honest I’m not sure what the appropriate YAML schema is for this and I didn’t validate what you wrote, but I was able to use the UI to generate an automation that uses a toggle action on a switch and is based on a device id:

- id: '1680373212530'
  alias: Test 1234
  description: ''
  use_blueprint:
    path: lksnyder0/hue-remote-dimmer-january-2022.yaml
    input:
      dimmer_device: 845a5ea127778a7acb53b6da4c4a248f
      on_short_action:
      - service: switch.toggle
        data: {}
        target:
          device_id: 44c33aa6fdb94fe8a222e63064c8cf8d

There are some differences between the automations. I’m unsure of the YAML schema but most likely a data dictionary needs to be added hence the error for attempting to locate the 'subtype' key. It’s possible that just having an empty dictionary would avoid this issue.

It’s also possible that providing both device_id and entity_id would be two different options, and in this case I think device_id is still taking precedence. It could cause undefined behavior to have both, but I’m not 100% sure.


I’m not sure if it’s what you’re already doing and this misses the mark, but I’d recommend using the UI to generate this automation. That would provide the guard rails in generating the correct YAML under the hood.

As an added “bonus” to using the UI editor, you can disable actions for specific automations. What this meant for me when the long press repeat blueprint was added is that I only needed to override the repeat actions on the new automation, and could use the old automation’s actions and simply disable the hold actions for that original automation. This allows me to

  1. reduce how much code was written initially
  2. reduce how much code will be written and have both options easily toggle-able. If I want to go back I can simply re-enable the functionality for the original automation for hold actions and disable the long press actions as needed without needing to create/edit existing automations

Hopeful it’s helpful. Once again welcome to Home Assistant and happy automating!

:robot::handshake::house_with_garden:

Hi.
Hue devices where new so nothing to revert to.
But following your post I now get “hue_event” in HA.

Removing and adding remote to Hue helped.
Apparently in Hue starter kits there some something in out of the box setup thats not good for HA.
For other note that when I added remote back to Hue I selected at end of adding remote “Configure in other app”.

Thanks codes for ideas. Now I can get to doing setups :grin:

1 Like

Rad, great to hear :star_struck:!
Will take this info into account and add it to the initial post so others can easily reference as well.

I’m guessing the remote came pre-paired to the Hub?
Speculating here but this initial pairing could be the cause of the issue… some info may be missing when paired this way which Home Assistant needs to listen to the events.

Yes all devices where pre-paired in starter kit I bought.
Must be something to do with their factory settings so might truly come handy for some others who buy kits.

Hi, I don’t really understand, yesterday I was able in automation to have a different action on each switch but today after rebooting my hue bridge, nothing work anymore! Probably an unfortunate update!
So I look, for something to help me, and I found your blueprint, but unfortunately, when I try to save my automation I’ve got this error message : “Message malformed: expected str for dictionary value @ data[‘subtype’]” looks like my dimmer is RWL021.
Did someone have a suggestion to edit the blueprint or find an other solution.
Thanks