Lidl HG06106C / TS0505A (_TZ3000_dbou1ap4): RGB commands acknowledged but bulb stays yellowish; channel_change produces blue
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
- Ambito
- backend-api-design
Direzione di ricerca
Start by checking the device definition and color handling for model TS0505A (_TZ3000_dbou1ap4) in Zigbee2MQTT and the possibly related converter report linked in the issue. Compare the normal color command with the working channel_change effect; the issue does not name specific source files or tests. Done means the bulb displays the requested red and blue colors with normal color commands.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
What happened?
My Lidl HG06106C RGB bulb (Zigbee model TS0505A, manufacturer _TZ3000_dbou1ap4) does not display the requested RGB colors when controlled through Zigbee2MQTT.
On/off, brightness and color temperature control work. However, normal color commands result in yellowish/white light instead of the requested color.
Both a red hex color command and a direct XY command for blue were tested. Zigbee2MQTT publishes the requested XY values, but the visible light remains yellowish.
The debug log shows that Zigbee2MQTT sends lightingColorCtrl.moveToColor and the device returns a default response with statusCode 0.
Publishing {"effect":"channel_change"} makes the bulb visibly display blue. Sending a normal red color command afterwards makes it return to yellowish light.
Additional notes:
The same bulb previously displayed different colors correctly when connected to the Lidl gateway. I cannot identify a particular Zigbee2MQTT update as the cause.
Device interview completed successfully.
Color changes were tested both through the Zigbee2MQTT frontend and through direct MQTT commands using Home Assistant.
The channel_change effect produces visible blue light, but sending a normal color command afterwards returns the bulb to yellowish light.
Possibly related report:
https://github.com/Koenkk/zigbee-herdsman-converters/issues/11872
I can provide additional debug logs or perform targeted tests if needed.
What did you expect to happen?
The bulb should display the requested RGB color: red when sending #FF0000 and blue when sending the tested blue XY coordinates.
Normal color commands should work without having to trigger an effect first.
How to reproduce it (minimal and precise)
With the bulb paired to Zigbee2MQTT and switched on:
-
Publish the following MQTT message:
Topic: zigbee2mqtt/Stehlampe/set
Payload: {"color":{"hex":"#FF0000"}} -
Observe that the bulb remains yellowish instead of turning red.
-
Publish:
Topic: zigbee2mqtt/Stehlampe/set
Payload: {"effect":"channel_change"} -
Observe that the bulb displays blue.
-
Publish the red command from step 1 again.
-
Observe that the bulb returns to yellowish light instead of displaying red.
An additional test with the following payload also failed to produce blue:
{"color":{"x":0.1355,"y":0.0399}}
Zigbee2MQTT version
2.14.3 (unknown)
Adapter firmware version
{"maintrel":1,"majorrel":2,"minorrel":7,"product":1,"revision":20240705,"transportrev":2}
Adapter
ZStack3x0
Setup
os: #1 SMP PREEMPT_DYNAMIC Tue Oct 27 13:48:56 UTC 2026 - 6.18.58-haos - x64
node: v24.22.1
ha: true
Device database.db entry
No response
Debug log
[12.11.2026, 03:16:15] z2m:mqtt: Received MQTT message on 'zigbee2mqtt/Stehlampe/set' with data '{"color":{"hex":"#FF0000"}}'
[12.11.2026, 03:16:15] z2m: Skipping state because of Home Assistant
[12.11.2026, 03:16:15] z2m: Publishing 'set' 'color' to 'Stehlampe'
[12.11.2026, 03:16:15] zh:controller:endpoint: ZCL command 0x588e81fffeca0475/1 lightingColorCtrl.moveToColor({"transtime":0,"colorx":45914,"colory":19615,"optionsMask":0,"optionsOverride":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false})
[12.11.2026, 03:16:15] zh:zstack: sendZclFrameToEndpointInternal 0x588e81fffeca0475:30983/1 (0,0,1)
[12.11.2026, 03:16:15] zh:zstack:znp: --> SREQ: AF - dataRequest - {"dstaddr":30983,"destendpoint":1,"srcendpoint":1,"clusterid":768,"transid":2,"options":0,"radius":30,"len":11,"data":{"type":"Buffer","data":[1,49,7,90,179,159,76,0,0,0,0]}}
[12.11.2026, 03:16:15] zh:zstack:znp: <-- SRSP: AF - dataRequest - {"status":0}
[12.11.2026, 03:16:15] zh:zstack:znp: <-- AREQ: AF - dataConfirm - {"status":0,"endpoint":1,"transid":2}
[12.11.2026, 03:16:15] zh:zstack:znp: <-- AREQ: ZDO - srcRtgInd
[12.11.2026, 03:16:15] zh:zstack:znp: <-- AREQ: AF - incomingMsg - {"groupid":0,"clusterid":768,"srcaddr":30983,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":120,"securityuse":0,"timestamp":11906206,"transseqnumber":0,"len":5,"data":{"type":"Buffer","data":[8,49,11,7,0]}}
[12.11.2026, 03:16:15] zh:controller: Received payload: clusterID=768, address=30983, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=120, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":49,"commandIdentifier":11},"payload":{"cmdId":7,"statusCode":0},"command":{"name":"defaultRsp","ID":11}}
[12.11.2026, 03:16:15] zhc:light: Missing colorTempPhysicalMin and/or colorTempPhysicalMax for endpoint 0x588e81fffeca0475!
[12.11.2026, 03:16:15] z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Stehlampe', payload '{"brightness":200,"color":{"x":0.7006,"y":0.2993},"color_mode":"xy","color_temp":160,"linkquality":120,"state":"ON"}'
Notes
Last health check
time: Thu Nov 12 2026 03:21:05 GMT+0100 (Mitteleuropäische Normalzeit)
os.load_average: 0, 0.01, 0
os.memory_percent: 50.2521
process.memory_percent: 6.511
process.uptime_sec: 5779
- Lingua principale
- TypeScript
- Stelle
- 15.8k
- Fork
- 2.1k
- Merge medio
- 1g 6h
- PR unite (30g)
- 38
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Koenkk/zigbee2mqtt
-
[Feature request]: OTA for generated definitions of devices with an OTA client clusterForse già presa @jabla l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 80/100
Koenkk/zigbee2mqtt#33684 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
new device support
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
Koenkk/zigbee2mqtt#33674 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
[Feature request]: Support espzb adapter (ESP Zigbee SDK v2, ESP32-S31)Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
Koenkk/zigbee2mqtt#33668 ·
I maintainer di solito rispondono entro 1 giorno
-
problem
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 76/100
Koenkk/zigbee2mqtt#33645 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
Koenkk/zigbee2mqtt#33613 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Koenkk/zigbee2mqtt
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
devswha/herdr-web-ui#3875 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
-
area: runtime chore cli consistency dependencies developer-experience difficulty: easy discovery documentation enhancement good first issue help wanted hygiene json-output packaging priority: P3 tests version
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
discovery:other factory-active task-identify-harness-labels-done task-identify-issue-type-done
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
vercel/ai#25068 · 4 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
create-strapi-app doesn't await writing license.txt, so a failed write skips its error handlingApertaflag: invalid template issue: bug severity: low source: cli status: pending reproduction version: 5
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
strapi/strapi#28637 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni