Thanks for the hint. I improved the description a little bit.
Concerning scrolling speed I found this comment by @mocelet interesting IKEA Bilresa Scrollwheel (Matter) – Ultimate Light Controller (Atomic Edition) - #13 by mocelet
I wanted to add a media player play/pause to the button.
Other remote integration add it like this:
play:
icon: mdi:play
service: remote.send_command
service_data:
entity_id: remote.samsung_projector_lsp3_sp_lsp3blaxxh
command: KEY_PLAY
Im currently trying to get this working like this:
input:
click_action_ch1:
- device_id: d6ce0724f36ea8c41519b8ccee0bb816
entity_id: remote.samsung_projector_lsp3_sp_lsp3blaxxh
domain: remote.send_command
command: KEY_PLAY
(Indentation was not supported here)
But I get “Response error: 500” trying to save.
Maybe if support could be added to the “for media player”?
You have to find out the correct action call, e. g. by using the developer tools “Actions”, something along
action: remote.send_command
target:
entity_id: remote.your_remote
data:
hold_secs: 0.3
command: KEY_PLAY
But this has nothing to do with the blueprint, maybe you have better chance to get an answer if you post it as a new thread.
You’re right, I got it working like this, thank you!
click_action_ch1:
- action: remote.send_command
target:
entity_id: remote.samsung_projector_lsp3_sp_lsp3blaxxh
data:
hold_secs: 0.1
command: KEY_PAUSE
First of all thanks for the great work and sharing your blueprint. I want to use the scroll wheel to dim (up/down) three Zigbee lamps that have separate entities, but are also a light group helper. I have configured the single-click to switch the light group on, double-click to switch the light group off. This works perfectly fine.
The problems start with using the scroll wheel, in particular with lower and upper limits (I use it in “instant” mode). I know that the lamp shuts off when the percentage is 12% or lower, so I have set the lower scroll limit to 15%. Nevertheless, when I scroll quickly, it apparently “overshoots” into the region where the lamps shut down. A similar effect I see on the upper scroll level limit, that is 100% (not configurable) - when I scroll quickly, I get the lamps to full brightness, but dimming them down again with the opposite direction of the scroll wheel first does nothing for quite a while, then overshoots into the “down” region. It looks like also here the quick scrolling sets some internal level counter to far over 100%, and scrolling it back first does nothing until the 100% is reached from above, then quickly dims down.
Could you have a look into this behavior? I looks like the logic does not strictly enforce the lower and upper scroll limit when scrolling fast.
And one different feature that could help would be an option to add a little delay between firing the command to the lamps, when/if they are not so quick to respond. Something like 200 to 400ms between “scrolling clicks”. I have tried to achieve this with smaller change values per scroll click, but that doesn’t do the job.
I cannot reproduce your issue.
You can check in “Developer Tools / States” the brightness value (should be in range 0…255) in real-time while scrolling up/down:
or similar in “Developer Tools / Template”
{{ state_attr('light.globe_lampe', 'brightness'),
state_attr('automation.scrolltaster_sz', 'last_triggered'),
state_attr('automation.scrolltaster_sz', 'current')
}}
Expected result: brightness stops at 2.55 * Minimum Brightness dimming down and 255 dimming up. If your results are different please provide some more details.
Spook is not happy with the 2 : * script.light_color_hs_helper
script.light_color_temp_helper
even though they are not being used in my set up :
alias: Living Room - Bilresa Scroll Wheel
description: ""
use_blueprint:
path: jhol-byte/Ikea_bilresa_scroll_wheel.yaml
input:
remote: d27e96c83fc2342800d4254981742988
click_action_ch1:
- action: light.toggle
metadata: {}
target:
entity_id:
- light.living_room_lights
data: {}
scroll_wheel_target_ch1:
- light.living_room_lights
scroll_wheel_mode_ext_ch1: instant
click_action_ch2:
- action: light.toggle
metadata: {}
target:
entity_id: light.tense
data: {}
double_click_action_ch1:
- action: switch.toggle
metadata: {}
target:
entity_id: switch.adaptive_lighting_sleep_mode_living_room
data: {}
dim_step_pct: 20
scroll_wheel_target_ch2:
- light.tense
dim_min_pct: 1
volume_use_up_down_for_instant: false
These scripts are referenced in the blueprint itself. So either add them (see description) or ignore the Spook warning.
Update: 2026-03-22
- support
transitionduration for lights (can be changed under Global light settings) which makes the dimming and color effects more satisfying (
update the two helper scripts as well)
Brilliant work on this, thank you!
I am however finding that multiple click actions are very inconsistent, often triggering the single click event.
Is there something that you perhaps could do about this? Even perhaps to read multiple single click events Vs 'true’reported double-clicks which seems a bit erratic.
Being able to change the time between each click would be super handy. Unfortunately, I have tremors, so spacing them out a bit would help immensely.
First thanks for a great blueprint. I have a strange issue that you maybe able to point me to a fix. Dimming with the wheel works great with my Hue Color Ambience E27 bulbs but when I try to use it with a group of Hue white ambience GU10 spots, only anti-clockwise is working. I can reduce the brightness but then clockwise does not increase. Anticlockwise can also be used to increase (should it not be decrease??) colour temp, but then clockwise does not reduce it. All the bulbs are connected via Zigbee2MQTT. I have no idea why the different types of bulb behave differently, but the behaviour is consistent across 4 x GU10 spots while working with 2 x E27 bulbs. I am only using “instant” mode. Is there maybe a global setting that I need to tweak?
Just in case you hit the same issue as in #62, see my answer there. Try using the exact channel which is working with the “non-working” bulbs to double-check.
(for color temp the logic is that anti-clock wise makes the light warmer, compared to dimming which makes it darker, more cosy)
Thanks for the feedback @home2b. I played around with handling multiple single-clicks as double-click, but experience is worse than default behavior. Actually the default double-click doesn’t have to be super fast for my remote.
Unfortunately not working here. Click Button works, but scrolling not. Either for KNX Light Dimming or Sonos Volume, no reaction. In Event section of the matter device overview page of the scroll switch, i can see the events for scrolling in both directions. Whats also interestin is, that on the left under automations, there is nothing mentioned, altough i have 2 automations running with this device.
Did you enable the hidden sensor entities and check the following?
Thank you so much, this is awesome, thought I’d just try the Bilresa remote without big expectations and though it won’t work too well… With your blueprint it actually works like a charm. I love the idea with the on hold colour change and scrolling temp and brightness change by scrolling through with double click. Never had such an awesome remote for 5€ ![]()
When I was searching for blueprints I actually saw another nice addition from @mcinnes01 (IKEA E2490 BILRESA Scroll Wheel).
In addition to scrolling through the scrolling options by double click he made a auto reset function, that after a set duration the scroll behaviour returns to default. Just an idea, I added it myself and love it, since I only sometimes change temp/color but usually want to return to brightness always.
Again thanks for this awesome blueprint!
I made an updated version that allows it to be used with covers, allowing me to use it to open and close my blinds if anyone is interesting
I have it so it starts it opening and closing (by setting the step percentage change to 100) and clicking it stops it for convenient control
I enabled the hidden entities under Diagnosis and it worked. THank you. Great little device.
@Harry-George that’s the idea which I used in my user-defined example for cover as well. For me the experience is not very satisfying though. (If you use 100% step size and a stop button you might better go with simple start/stop button concept anyway). But here …
Another idea for covers is the following:
Let the cover go down/up as long as you scroll in the corresponding direction. To do so you need two additional helpers and one additional automation:
Steps:
-
define two timer helpers:
Left scroll cover1with duration of 2 seconds
Right scroll cover1with duration of 2 seconds
(unfortunately 2 seconds is the smallest value working here, meaning that you have a latency of 2 seconds before the cover stops)
-
define automation
Scroll control cover1(with a 5 % safety margin at both ends):
alias: Scroll control cover1
description: ""
triggers:
- trigger: state
entity_id:
- timer.left_scroll_cover1
to:
- active
id: left
- trigger: state
entity_id:
- timer.right_scroll_cover1
to:
- active
id: right
- trigger: state
entity_id:
- timer.left_scroll_cover1
- timer.right_scroll_cover1
to:
- idle
id: stop
conditions: []
actions:
- choose:
- conditions:
- condition: trigger
id:
- left
- condition: numeric_state
entity_id: cover.rollladen_sz
attribute: current_position
below: 95
sequence:
- action: cover.open_cover
metadata: {}
target:
entity_id: cover.rollladen_sz
data: {}
- conditions:
- condition: trigger
id:
- right
- condition: numeric_state
entity_id: cover.rollladen_sz
attribute: current_position
above: 5
sequence:
- action: cover.close_cover
metadata: {}
target:
entity_id: cover.rollladen_sz
data: {}
- conditions:
- condition: trigger
id:
- stop
sequence:
- action: cover.stop_cover
metadata: {}
target:
entity_id: cover.rollladen_sz
data: {}
mode: single
- define a user-defined scroll wheel action:
if:
- condition: template
value_template: "{{ scroll_direction == 'left' }}"
then:
- action: timer.start
metadata: {}
target:
entity_id: timer.left_scroll_cover1
data: {}
else:
- action: timer.start
metadata: {}
data: {}
target:
entity_id: timer.right_scroll_cover1


