IKEA STYRBAR (Z2M) — Two-light controller with colour matching
Suggested category: Blueprints Exchange
Suggested tags: zigbee automation mqtt zigbee2mqtt ikea
This blueprint turns an IKEA STYRBAR (E2313) into a two-light controller via Zigbee2MQTT, where the second light inherits the brightness and colour of the first instead of coming on at whatever it was last set to.
It grew out of a simple annoyance: switching on a desk lamp and a ceiling light from the same remote and having them land on completely different colours and brightness levels. Everything the blueprint does follows from fixing that.
| Gesture | Action |
|---|---|
| Left arrow, short press | Toggles the left light |
| Right arrow, short press | Toggles the right light |
| Up, short press | Brightens every light that is currently on |
| Down, short press | Dims every light that is currently on |
| Up, hold | Sets a warm colour temperature on the lights that are on |
| Down, hold | Sets a cool colour temperature on the lights that are on |
Import Blueprint
Source and README: GitHub - pqpxo/ha-blueprints: Custom Home Assistant blueprints · GitHub
What makes it different
Matched turn-on. Switch one light on while the other is already on and it comes up at the other light’s brightness and colour, whether that is an RGB colour or a colour temperature. With both lights off, it comes on at a brightness you configure.
Independent brightness stepping. Up and down adjust each light that is on relative to its own current level, rather than forcing both to a shared value. Lights that are off are left alone rather than being switched on by the brightness command.
Live colour sync (optional). While both lights are on, changing the colour of either one from anywhere, a dashboard, a voice assistant or another automation, mirrors it to the other. Turn it off if you want the two set independently.
Mixed capabilities are safe. If one light does colour and the other only does colour temperature, colour is copied when the receiving light supports it and quietly falls back to matching brightness alone when it does not. Nothing errors, nothing needs configuring.
Requirements
- Home Assistant 2024.10 or newer (the blueprint uses input sections)
- Zigbee2MQTT, with the MQTT integration set up in Home Assistant
- Two light entities, ideally both colour capable
This is an MQTT blueprint rather than a device-trigger one, so you enter your remote’s Z2M friendly name and base topic rather than picking a device from a list. That also means it works regardless of whether the STYRBAR is exposed as a device with triggers on your setup.
Configuration
Controller: the Z2M friendly name of the remote, and the base MQTT topic (defaults to zigbee2mqtt).
Lights: the light toggled by the left arrow and the one toggled by the right arrow.
Behaviour: brightness step per press (default 20%), brightness used when both lights are off (default 100%), warm and cool colour temperature values (default 2000K and 6666K), a switch for the live colour sync, and a transition time.
Two implementation notes
These are in the post because they cost me an evening, and they may save someone else the same evening.
Colour is sent as a separate command. Plenty of Zigbee bulbs silently discard a colour that arrives in the same command that switches them on, especially with a transition attached. The blueprint switches the light on with brightness only, waits for it to report on, waits a further 300ms, then sends the colour on its own with no transition. It then reads back what the light reports and retries up to three times if the colour did not take.
Never store supported_color_modes in a template variable. It is a list of StrEnum members. Put it through a variable and it renders as text like [<ColorMode.HS: 'hs'>], which cannot be parsed back into a list, so it silently becomes a string and every membership test against it fails. Jinja’s string filter does not help, because soft_str returns StrEnum values untouched. Worst of all, it only affects some integrations, so a setup can work in one direction and fail in the other with identical logic. The capability checks in this blueprint are deliberately computed inline for that reason.
Other Z2M remotes
The action strings are hardcoded to the STYRBAR set:
on, off, arrow_left_click, arrow_right_click,
brightness_move_up, brightness_move_down
Any Z2M four-button remote that publishes the same strings will work as-is. For anything else, listen on zigbee2mqtt/YOUR_DEVICE and edit those strings in the choose conditions. If there is interest I am happy to expose them as inputs so it covers any Z2M remote without editing YAML.
FAQ
Why does holding up or down set a colour temperature instead of ramping the brightness?
The STYRBAR sends brightness_move_up and brightness_move_down on hold, so a hold cannot do both. Given the short presses already handle brightness, the hold was more useful as a quick warm and cool preset. A ramping variant is easy to swap in if people prefer it.
Can the two lights be different colours?
Yes, turn off the colour sync option. With it on they are locked together while both are on.
Why mode: parallel?
A colour sync run and a button press can overlap, and restart would have them cancelling each other.
The colour is not matching. What should I check?
Open the automation trace for that button press and look at the variables step. copy_colour or copy_temp should be true. If both are false, the source light’s color_mode is outside the expected set, or the target does not report a compatible mode. If they are true and the trace shows all three retry attempts running, the commands are leaving HA and something is undoing them, with Adaptive Lighting being the usual suspect.
The sync seems to run constantly.
Two runs per colour change is correct, the real one and the echo that matches nothing and stops. A continuous stream means a bulb is reporting back a value it cannot reproduce, so widen the tolerances in the sync branch conditions.
Feedback and issues welcome, either here or on the repo. If you are using it with a different remote or a mixed pair of bulbs I would be interested to hear how it behaves.