Open TUNER88 opened 6 months ago
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
Request is not stale, few more users (@to0b, @pimw1) are waiting for the support of the new device.
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
This device has raving reviews all over the internet; from a commercial point of view it would (imho) be wise to bring support for it with all bells&whistles attached.
If it was following the standard it should be working already out of the box.
@Smanar can you help with a DDF?
If it was following the standard it should be working already out of the box.
Yes, exactly, what is the problem with this device ? What is working or not ?
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
@TUNER88 , could you reply to the question of Smanar? :)
I would suspect the main lamp to work out of the box (as a Color Temperature Light); Color Capabilities on the first endpoint correctly indicates it only supports Color Temperature. The colour ring on the second endpoint should be exposed as an Enhanced Color Light. The only issue with both endpoints is the ZHA device type: Color Dimmable Light; if memory serves, we needed whitelisting in the legacy code to correct that. Creating a DDF for this would be pretty straightforward. My main concern is that neither endpoint seems to support PowerOn On/Off.
The real challenge will be the effects on the colour ring. I suspect they use the LUMI specific cluster for these. We would need some serious sniffing while the light is connected to the Aqara app to reverse engineer how to control these. Probably need some serious JavaScript hacking for that, as we needed for the Hue gradient lights.
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.
Bump
Could anyone reopen this?
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
Bump
What's the issue with the light? @Paule-Panter please see the question of Smanar
I can switch both endpoints on/off. Both endpoint are exposed as "Color dimmable light", but the first (main) endpoint has physically only 2colors (cw and ww). At the moment i can't switch/fade between this colours. The outer ring has physically individual adressable LEDs. It exposed as one "Color dimmable light", therefore it is only controlled as one light, so far.
The device types are from ZHA. In ZLL / ZB3 terms, the first endpoint (main light) is a Color Temperature Light; the second (ring light) an Enhanced Color Light. Note that the second endpoint only contains RGB LEDs; colour temperature is emulated using these.
Both light endpoints seem to provide the same functions (apart, obviously, from the colour):
ct
(from 153 to 370), second endpoint ct
(same range, but emulated using RGB LEDs) and xy
. No hs
, no colorloop. It doesn't report the gamut. Startup Color Temperature is non-functional.ct
.Created an initial DDF, but the lights
resource for the first endpoint somehow exposes state/xy
. The corresponding attributes are also being polled. I suspect this is the legacy code dealing with Color Dimmable Light.
Thanks for this huge information and the ddf. I'll try this after my holiday vacation.
I would like to read the 'RTFM' for the Lumi specific cluster with the crazy states, where can i find this?
BR Paule
I'll try this after my holiday vacation.
Best set DDF Mode to Strict in the Control panel when testing the DDF. Otherwise the legacy code is kicking in, applying messages from one endpoint to the other resource, or ignoring them.
EDIT Should no longer be needed after adding the non-public xy
to the resource for the first endpoint. Needs the legacy PR to suppress xy
from being reported by the API, though.
I would like to read the 'RTFM' for the Lumi specific cluster with the crazy states, where can i find this?
I don't think there is a manual describing the LUMI specific cluster, at least not in a language I can read.
Most of our knowledge has been obtained through reverse engineering: changing stuff in the Aqara app while sniffing the Zigbee traffic between the Aqara hub and the device. This knowledge is documented in GitHub issue, and summarised in general.xml
(use the Source, Luke).
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
Is there already an existing issue for this?
Product name
Aqara Ceiling Light T1M
Manufacturer
LUMI
Model identifier
lumi.light.acn032
Device type to add
Light
Node info
Endpoints and clusters
Basic
Further relevant clusters
On/Off
Level Control
Color Control
=======
Any other cluster of relevance/interest