Lidl 14149505L/14149506L_2 (TS0505B _TZ3210_iystcadi): brightness-only commands ignored in color (hs) mode since 2.10

Open
  • Is something wrong?
#33,627 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
66/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
backend, devtools

Research direction

Start with tuya.tz.led_control in src/lib/tuya.ts and trace how brightness-only messages are handled when the color mode is hs; the issue identifies the numeric value being missed in that branch. Check the definitions that also use this converter and add coverage for the reported brightness-only command. Done when the affected light changes brightness in color mode and white/color temperature behavior remains intact.

Written by the indexing model from the issue text.

Description

problem
What happened?

When the Lidl Livarno Lux light bar is in color mode (color_mode: hs), sending only a brightness value
has no effect: Z2M reports the new brightness but the light itself does not change.
Brightness only changes when color and brightness are sent together. White / color_temp mode works.
This worked in 2.9.2.

History, as far as I can tell from the zhc commits:

  • #31835, #31905, #31958: TS0505B_2 colour fixes after 2.10
  • #32204 (zhc 0b947d2b, Jul 2026): definition switched to toZigbee: [tz.on_off, tuya.tz.led_control], and brightness in hs mode has been broken since then
  • zhc PR #13336: _TZ3210_iystcadi moved to lidl.ts with the same converters
  • The bug is still present on current master (checked 2026-11-06, after #13657)
Cause

In tuya.tz.led_control (src/lib/tuya.ts), a brightness-only message in hs mode falls through to the
colour branch. There the brightness of the message is never used:

const zclData = {
    brightness: globalStore.getValue(entity, "brightness") || 100,
    ...
};
if (utils.isObject(value)) {
    ...
    if (typeof value === "number") {   // never true inside isObject(value)
        zclData.brightness = value;
    }
}

For key === "brightness", value is a number, so the device always gets the old stored brightness.
tuya.tz.led_control is also used by two definitions in tuya.ts, so they are probably affected too.

Workaround (confirmed working)

An external converter that keeps the current definition but handles hs mode the pre-2.10 way
(tuyaMoveToHueAndSaturationBrightness2, hue in degrees, saturation/brightness scaled to 0–1000,
brightness taken from meta.message.brightness or state) and delegates everything else to
tuya.tz.led_control. With it, brightness changes in colour mode work again. Converter attached.

Minimal fix suggestion: in the hs branch, apply a numeric brightness outside the isObject(value) check, e.g.
if (key === "brightness" && utils.isNumber(value)) zclData.brightness = Number(value);
(I did not test whether the light accepts command 0x06 with the correct brightness, only the legacy 0xE1 command.)

What did you expect to happen?

Brightness slider works in colour mode, as in 2.9.2.

How to reproduce it (minimal and precise)
  1. {"color": {"h": 0, "s": 100}, "brightness": 254} → light is bright red
  2. {"brightness": 30} → Z2M state shows 30, light stays at full brightness
  3. With the external converter, step 2 dims the light as expected
Zigbee2MQTT version

2.14.3

Adapter firmware version

EmberZNet 8.1.1

Adapter

SONOFF Dongle Plus MG24 (ember)

Setup

Home Assistant OS, Zigbee2MQTT app on Proxmox VM

Device database.db entry

{"id":43,"type":"Router","ieeeAddr":"0x60a423fffe4a45bc","nwkAddr":51140,"manufId":4098,"manufName":"_TZ3210_iystcadi","powerSource":"Mains (single phase)","modelId":"TS0505B","epList":[1,242],"endpoints":{"1":{"profId":260,"epId":1,"devId":269,"inClusterList":[0,3,4,5,6,4096,8,768,61184],"outClusterList":[25,10],"clusters":{"genBasic":{"attributes":{"modelId":"TS0505B","manufacturerName":"_TZ3210_iystcadi","powerSource":1,"zclVersion":3,"appVersion":68,"stackVersion":0,"hwVersion":1,"dateCode":""}},"lightingColorCtrl":{"attributes":{"colorCapabilities":29}}},"binds":[],"configuredReportings":[],"meta":{}},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[],"outClusterList":[33],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":68,"stackVersion":0,"hwVersion":1,"dateCode":"","zclVersion":3,"interviewCompleted":true,"interviewState":"SUCCESSFUL","meta":{"configured":"0.0.0"},"lastSeen":1793984858364}

Debug log

With the external converter (works):
z2m: MQTT publish: topic 'zigbee2mqtt/light.livingroom_lightbar', payload '{"brightness":30,"color":{"h":0,"hue":0,"s":100,"saturation":100},"color_mode":"hs",...}'

Notes

lidl_lightbar.mjs.txt

Dominant language
TypeScript
Stars
15.8k
Forks
2.1k
Avg merge
1d 6h
Merged PRs (30d)
38

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Koenkk/zigbee2mqtt

All issues in Koenkk/zigbee2mqtt

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.