New Version 2026-04-04
- add
Auto reset time for input_select helpersoption in misc section to auto resetinput_select-helpers to first selection for dynamic scroll wheel mode after timeout (for the idea thanks to @Alberto11
)
Hi! I love this template, especially with the Instant mode and the minimum brightness so that the wheel doesn’t turn off the light.
I have one question/request: while I love that it doesn’t turn off the light with the wheel (with a minimum brightness >0 set, otherwise it does eventually turn off), I would like the abiity to turn on the light with the wheel. So that if it’s off, I don’t have to first click, then turn the wheel up for more brightness.
How should I go about it? Or can the option be added to the blueprint?
Thank you!
EDIT: For now, and since I only have one, I took control of the Automation/Blueprint and replaced
- if:
- condition: template
value_template: "{{ is_state(repeat.item, 'on') }}"
then:
- action: light.turn_on
...
with
- if:
- condition: template
# This allows the action if the light is already ON,
# OR if the light is OFF but you are turning the wheel RIGHT.
value_template: >-
{{ is_state(repeat.item, 'on') or
(is_state(repeat.item, 'off') and scroll_direction == 'right') }}
then:
- action: light.turn_on
target:
entity_id: "{{ repeat.item }}"
data:
brightness_step_pct: >-
{% if is_state(repeat.item, 'off') %}
{{ var_dim_step_pct }}
{% else %}
{{ iif(scroll_direction == 'right',
scroll_clicks * var_dim_step_pct,
-1*([scroll_clicks * var_dim_step_pct,
state_attr(repeat.item,
'brightness')*100/254
- var_min_pct]|min)) }}
{% endif %}
transition: "{{ var_light_transition_duration }}"
and it seems to work (haven’t thoroughly tested beyond the basics).
1 Like
@antonio1475 thanks for the feedback and idea
My original use case is different here: I have two lights added as scroll wheel target so I can dim both lights together, but sometimes I turn just one light on. Then I want only this light to change brightness while dimming of course.
To support your use case as well as my use case, here is
New Version 2026-04-06:
- add option
Dim turns lights onto Global light settings: allow scroll wheel (mode: dim) to turn lights on
1 Like
First of all thanks for this great blueprint.
When I tested the blueprint with single Kajplats bulb in the “typical” configuration (click - toggles, hold cycles color temp and scroll wheel dims in instant mode) then it worked nicely. But when I added two more bulbs (as my light consists of 3 bulbs), then things started getting weird with the on/off toggling. The bulbs or a subset of the 3 would only briefly turn on (basically pulsate on briefly). I tried grouping the lights and use the Toggle light action on the group, but the behavior was the same.
Any pointers on how to get the automation working on all 3 bulbs. The dimming and color temperature cycling when the lights are on, seems to work perfectly with the light group. At the moment the only reliable way to turn the lights on, is to use the “Dim turns lights on” setting. But then sometimes the turning off does not work either (it turns the lights off only briefly and then back on).
@r0mi please show your exact configuration, this seems very strange.
Under helpers you would create a new light group and then you would use this new light group as target entity for toggle light and dimming alone, no other changes are necessary. (Especially don’t use the group and single lights from it together!)
Yeah, sure, here’s my conf:
alias: Children room ceiling light remote control
description: ""
use_blueprint:
path: jhol-byte/Ikea_bilresa_scroll_wheel.yaml
input:
remote: 18159d489558ebd1f5db1b3c8d502674
click_action_ch1:
- action: light.toggle
metadata: {}
target:
entity_id: light.children_room_ceiling_light
data: {}
on_hold_action_ch1:
- action: script.light_color_temp_helper
metadata: {}
data:
min_color_temp: 2200
max_color_temp: 4000
color_temp_step: 300
light_transition_duration: 0.5
mode: cycle
target_light: light.children_room_ceiling_light
scroll_wheel_target_ch1:
- light.children_room_ceiling_light
scroll_wheel_mode_ext_ch1: instant
dim_step_pct: 15
dim_min_pct: 2
dim_turns_lights_on: true
One thing I’ve noticed is that every time I press a button on the Ikea remote, then I get 2-3 “identical” events with just a 1ms separation or so. The only differences in the events are timestamps and context.id values.
Is this normal for the Ikea remote to send multiple events for a single click or wheel rotation step? Maybe this is causing the behaviour.
hmm, try reloading the Matter integration, if this doesn’t help restart HA once, that’s for sure not expected behaviour
That was a good call. Restarting the Matter server indeed reduced the events to a single instance per click.
1 Like
Hey, thanks for the blueprint! Sorry to bother - the automation doesn’t trigger anymore when i click the central button. Matter still registers the click, only the automation doesn’t. I tried recreating the entity ids already, and it used to work two weeks ago. Thanks for your help in advance!
Try to duplicate the existing automation (3-dot menu), select your remote again and disable the old automation (if this still doesn’t work restart the Matter integration).
I think there needs to be some kind of filter on the event detection. The event entities are emitting when other properties change and not just when a button is pressed. To reproduce, simply change the friendly name of one of the entities (something tied to an obvious action, like toggling a light, works well to demonstrate).
I use NodeRED and the Ignore state change event when: Current state equals previous state option seems to filter out the events generated by changing the entity’s friendly name. I’ve also noticed this happening sporadically with my Bilresa two-button device - the entities will emit an event, but the actual value of the state hasn’t changed - but I haven’t been able to catch the event as it happens to see the event data and the NodeRED Ignore isn’t catching it. I have logging set up for that one now, but it hasn’t happened again yet to be able to catch the data.
how does this relate to my blueprint?
I’m using your blueprint and seeing this behavior. It seems to be reacting to any event being emitted, not just when a button is actually pushed - when the actual state value updates.
Yes, I know. It is somewhat a “feature” of the HA event handling, see my (old) issue for Bluetooth here:
I have no idea how to fix this in your own automation/blueprint though.
It looks like there might enough data in the event to work with. You already have a conditional check for unavailable, could another comparison be made there?
new_state.last_reported and new_state.last_updated seem to update with a property change, but new_state.last_changed seems to still match new_state.state. If one of the former matches one of the latter, it’s a true “button” event? Eg.
condition:
- condition: template
value_template: >-
{{ trigger.event.data.old_state.state != 'unavailable'
and trigger.event.data.new_state.state != 'unavailable'
and trigger.event.data.new_state.last_updated == trigger.event.data.new_state.last_changed
}}
Or just comparing new_state.state with old_state.state and if they don’t match, it’s a true “button” event? Eg.
condition:
- condition: template
value_template: >-
{{ trigger.event.data.old_state.state != 'unavailable'
and trigger.event.data.new_state.state != 'unavailable'
and trigger.event.data.new_state.state != trigger.event.data.old_state.state
}}