Zigbee RGBW strip controller only showing colour temp but not color options

Hi. Hoping someone can help point me in the right direction.

I’ve moved fully over to HA, and love it but still learning the workings. Running in a container on my Synology NAS.

I’ve installed a Zigbee controller and moved across my Zigbee devices fine, with one exception: I’ve an Aurora RGBW tunable white strip controller but ZHA only seems to register the tunable white, and not the RGB (which has previously worked fine on the Aurora Aone hub that I’ve decommissioned).

My question is: where are the properties stored in relation to the RGB controller? Can I just update them and correct the properties so that it’ll then all work correctly, or is there something else that I need to do?

Welcome!

A search here for Aone, returned the two links below. Does seem like there are a couple different models of this controller that are similar but different, this can often cause documentation on various ‘open’ zigbee setups to be incorrect, as some implemented one but not all and or got model numbers confused. Not seeing any reference to ZHA implementation at this database, however that does not mean you cannot learn from the implementation on Zigbee2MQTT and copy that work into a ‘quirk’ that might work in ZHA. Search this forum for ZHA quirks, similar to last link below. Good hunting!

AU-A1ZBSCCX
AU-A1ZBSCD

1 Like

Thanks!

Found this relating to the RGBCXStrip50AU / au-a1zbscrgbcx on the mqtt github (Aurora RGBW LED strip Controller · Issue #13925 · Koenkk/zigbee2mqtt · GitHub).

Will keep following the thread, and see if I can figure out how to write a quirk…!

1 Like

So, looking at HA and the settings for the device I can see that the device has a color endpoint.

This box suggests that I might be able to change it manually just to see whether it’s working:

However, if I then click ‘Issue Zigbee Command’ then I receive an error:

Given that the input cluster already has an endpoint for color does this suggest that it’s a more fundamental issue than can be fixed by writing a custom quirk?

BTW, I found this on writing quirks that others may find helpful: zha-quirks · PyPI

Apologies for throwing some cold water your way. However, as I understand your setup and state, based on my experience, I would highly recommend 86’ing ZHA and installing one or two (second for testing) zigbee2mqtt docker containers with two zigbee coordinator dongles and a solid MQTT broker in docker. All completely independent from your Home Assistant core setup (however you have this running). Then in your test zigbee2mqtt instance experiment with ways to get you device running. These points based on many hours wasted :wink:

Good hunting!

Thanks again for your quick response! I’m running HA in a container on my Synology NAS. Very new to all this, and was initially expecting to have to get zigbee2mqtt up and running in a separate container before HA could talk to my adapter (SLZN-06); however, was very pleased when HA recognised it on the network straight away because then I didn’t have to go through the challenge of getting my two containers to talk to each other!

This is the only wrinkle that I have with any Zigbee kit that I have so part of me is thinking I’ll just live with it (dimming and white colour temperature work fine).

Might have a tinker with getting mqtt2 up today…

Yes, the concept of everything packaged inside Home Assistant is appealing. However, after running ZHA inside HA as well as Zigbee2MQTT in a seperate container along side the container running HA, I found better stability in both my zigbee setup via Zigbee2MQTT and core HA (especially after I removed ZHA from within HA). Not to mention the vastly larger number of devices supported in Zigbee2mqtt and much larger user and developer community for help and advice.

Synology added a bit of complexity to the puzzle due to getting USB devices mapped thru to the containers, get a good handle on doing that. Try to use the “/dev/serial/by-id/…” paths to your zigbee dongle/dongles, these do not change on USB reconfigs unlike them moving when referenced by the more used /dev/tty* mapping.

Get a solid MQTT broker running first in a container, I have had very good success with Mosquitto.

user@docker-01:~$ tio -L
/dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_5cf90e3b6229ec119a9a6d7840c9ce8d-if00-port0
/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
/dev/serial/by-id/usb-1a86_TubesZB_971207DO-if00-port0
user@docker-01:~$

https://hub.docker.com/_/eclipse-mosquitto

Great. Thanks. Yes, will explore Zigbee2MQTT. I’ve a network adapter, so thankfully not needing to worry too much about faffing with the USB into the Synology.

I figured it out. You need to turn off “Always prefer XY colour mode” when configuring ZHA:

image