There could be hope then one day that this is sorted. Tbh bought 25 thread/matter devices to test this new thingie but it’s such a downgrade from zigbee that there’s currently no reason to switching. It’s a bit off topic but doesn’t matter also support device-to-device communication so something similar to zigbee touchlink is possible but just not supported in HA yet.
I hope they fix both the 500ms issue and the “short_release” then so this blueprint get to shine. It works with the hardware limitations Ikea sets so good work @stone13 and I’m not blaming you here. Just dissapointed with the switches that could be great if done properly.
It does, they’re called Matter bindings. The problem is there are no wireless remotes with binding support and IKEA didn’t implement Matter bindings in any of the BILRESA, at least not yet. Who knows if a future firmware update will surprise us.
By the way! I tested the scroll wheel in a IKEA store like you mentioned, they were indeed using Zigbee Touchlink instead of Matter and have to say the scroll experience didn’t feel natural either. It felt like I didn’t have precise and quick control over the brightness and something was “off”, I believe it’s because there’s also a delay and it won’t stop right when you stop scrolling but a bit later and they use long transitions to cover up that delay.
The classic start / stop dimming with long press and release feels more instant, but that would fit the BILRESA dual button, not the scroll wheel of course. Also, Home Assistant does not support sending the required commands (Move / Stop) to Matter lights, that’s why blueprints have to rely on auto-repeating increments which is not the best experience (although some have clever workarounds).
For the events needed for the scroll wheel, yes, there is even a PR that implements them. The PR is promising and generated a good discussion but it’s been stuck for some time because it needs to introduce a breaking change but they want people to have time to migrate and that requires more changes.
As for commands for native dimming with other buttons, that’s more complicated since the Light entity of HA has never had the notion of start / stop dimming and right now there’s no tool to facilitate sending your own Matter commands like happens, for instance, with Zigbee2MQTT or the ZHA Toolkit.
Thanks for making this. I am getting the same double press for when i scroll the wheel on v1.0.4 as well. Then the wheel stops responging for a bit. i can try again about 5 seconds later and it starts responding to commands again. Always double presses though with the scroll wheel.
Many Thanks for this Blueprint! Now my Bilresa works how i wanted it to do. Best Blueprint for my purposes so far. Additional german explanation much appreciated! !-)
Hi @stone13, thanks a lot for creating this blueprint — it’s really useful and has been very helpful.
I think I may have found another ghost-trigger case in v1.0.4.
My light turned on during the night without any input from the Bilresa remote. The automation was triggered by sensor.bilresa_scroll_wheel_current_switch_position_1.
Entity history shows that at that exact moment the sensor changed from 0 to unavailable, and later back to 0.
From the YAML it looks like the scroll sensors use state triggers, while the condition only filters trigger.from_state against unknown/unavailable, not trigger.to_state.
So a transition like 0 -> unavailable may still be treated as a valid scroll action and turn on the light.
Would it make sense to also ignore trigger.to_state.state in ['unknown', 'unavailable'] for the scroll triggers?
The current template only filters out the event when the device reconnects (e.g., jumping from unavailable → 0), but it completely misses the event when the device drops off the network (jumping from 0 → unavailable). Since the from_state in that moment is 0, the condition evaluates to true and triggers the ghost light. This perfectly explains the behavior you saw during the night (likely a short drop in the Thread mesh).
I have just updated the Blueprint V1.0.5 and included your suggested fix to check both the from_state and the to_state.
The new global condition now looks like this:
YAML{{ trigger.from_state is defined and trigger.to_state is defined and trigger.from_state.state not in ['unknown', 'unavailable'] and trigger.to_state.state not in ['unknown', 'unavailable'] }}
Thank you so much for the deep dive and the excellent debugging! This makes the blueprint more robust for everyone. Feel free to re-import the latest version.
Thanks for the kind words @Caprica ! I’m really glad to hear that you find the blueprint easy to understand and use.
Regarding your questions:
1. The “Preset” Scroll Option: This doesn’t trigger external Home Assistant scenes. It simply toggles between the extreme values you define in the “FINE TUNING” section of the blueprint UI. Scrolling up sets the light to your defined Bright/Cold values (e.g., for working), and scrolling down sets it to your Dim/Warm values (e.g., for a cozy evening).
2. Specific Colors & Effects (Lifx/Tapo): Right now, the blueprint is designed to be a standalone, plug-and-play controller for standard light behaviors without needing to map external scripts or scenes. The colors (like “Red”) are hardcoded in the YAML.
To trigger specific device effects like the Aurora Borealis or set a very specific blue hue, you would currently need to open the YAML file of the blueprint manually. You can easily find the set_red or set_white blocks in the actions: section and replace the standard light.turn_on action with the specific service call for your Lifx/Tapo effect or scene.
I might consider adding support for custom actions or scene selectors in a future update, but for now, a quick tweak of the YAML is the fastest way to get your specific effects running!
Thanks for reporting this! That is a very interesting observation.
What you are describing sounds like the Matter integration might be generating a multi_press_2 (double press) event concurrently when you use the scroll wheel. If the blueprint tries to run the scroll loop and a double-press action at the exact same time, it could overload the device or the network, causing that 5-second “freeze” you are experiencing.
Interestingly, I haven’t been able to reproduce this exact behavior on my own setup yet. Because of that, I want to hold off on releasing a quick “blind fix” (which would involve blocking all clicks while scrolling) until I can thoroughly test it on my end to ensure it doesn’t break other functionalities.
I am definitely keeping a very close eye on this! If I can replicate the issue or if it becomes a broader problem after recent HA Core updates, I will certainly implement a safeguard in a future version.
Thanks again for the detailed feedback, it really helps to understand how the blueprint behaves across different setups!
So I wasn’t clear enough. The issue is for every single step of rotation of the scroll wheel, the light responds with two visible level changes. So if I tie it to a 10 step lighting raise, spin the wheel one step, then the light responds with 10 step raise, followed by another 10 step raise.