@Mimiix as you have a better english than me ^^, can you add as the user don’t have right on the official github the procedure will create a fork under his name, and later all change on his own fork will be automatically synchronised with the PR (till it will be merged), so easy to correct it.
As you have right on the github, it s a little different for them.
If you’ve checked carefully, that’s already there. I used a seperate account to avoid exactly that 
It’s to be sure no one will ask what is a “fork” and how to edit the PR later.
@iisworks I m reading again your DDF, it s a color temperature light, so you do’nt miss state/ct and state/bri ?
Not sure what you mean, but I see the color temp settings in my 3rd party app with the DDF. Like I said I just generated the DDF (I only removed the window cover binding 0x0102 as you suggested).
I don’t know your device, but on the DDF you don’t create state/ct and state/bri, there is only state/on. So I can understand the on/off is working but for other it’s strange.
You can see how look the final json created by the DDF in phoscon / help / API Information / light / device_id
I m almost sure you have more fields. If the device have the cluster, even the auto-generated feature will add them, but I don’t know the device, and the clusters it use, so I can be wrong.
I see this in the api when using the DDF:
{
“1”: {
“etag”: “1fc20cf97b02428f44fb72a43ca4f02d”,
“hascolor”: true,
“lastannounced”: null,
“lastseen”: “2022-09-06T05:47Z”,
“manufacturername”: “LUMI”,
“modelid”: “lumi.light.aqcn02”,
“name”: “Bulb 1”,
“state”: {
“alert”: “none”,
“colormode”: “hs”,
“effect”: “none”,
“lift”: 0,
“on”: false,
“open”: false,
“reachable”: true,
“xy”: [
0.4355,
0.4079
]
},
“swversion”: “1.23”,
“type”: “Color temperature light”,
“uniqueid”: “00:15:8d:00:05:20:f4:43-01”
}
Lol ok, so I have finally make a search in deconz github, and this device is just an horror
So much problem with it. And there is already some hack in the legacy code for it.
So first need to remove :
“lift”: 0,
“open”: false,
This device don’t support X and Y ?
If yes need to remove too
“xy”: [
0.4355,
0.4079
]
and if it’s a temperature color device, need to add state/ct. I can’t understand how you can use it without this field on your third app ?
After a DDF edition you can use “hot reload” on the menu in the DDF editor, it will update the device json.
But it seems to work both in legacy mode as with the DDF, or does the legacy code override stuff from DDF?
It is indeed a dimmable temp color device (cold white - warm white). I have no clue about X/Y. 
Maybe this zigbee2mqtt commit holds a clue:
Update looks like you are right. Existing bulbs work fine with the ne DDF, but when I add a new bulb using the DDF, it does not actually control everything OK (on/off works, “Dimlevel” does not).
I think this PR should be dropped, because I also have no idea how to fix the DDF.
Can proceed step by step, try first with adding and removing fields like I m saying on previous post, we will see later the missing one.
does the legacy code override stuff from DDF?
It’s the reverse, a DDF enabled (with gold status for exemple) will be able to override the legacy code, but your device can be added before the DDF was enabled.
Yesterday I tried to use an Ikea tunable white bulb DDF and replace the manufacturername and modelid of the Aqara, but that did not work either. It messed up the existing 9 bulbs though, so I am probably going to replace the Aqara bulbs with those Ikea TW bulbs (€10). Not worth the DDF hassle IMO.
Or is there a generic DDF available for dimmable tunable white bulbs that could/should work? I don’t mind testing a DDF, but also don’t want to do it just by trial & error and hoping for the best.
I don’t understand what you are doing.
You don’t want to finish the first DDF ?
You have a new device that don’t work natively on deconz ?
I would like to, but I have no clue what to edit exactly. I don’t even really understand what “items” vs. “bindings” are, and what to change. I would need something to copy/paste I’m afraid. 
I see this in deconz, does that provide a clue?
About the Ikea bulb: I meant I connected one of those Ikea bulbs (TRADFRIbulbE27WSglobeopal1055lm) to deconz just fine, I then saved a DDF from it, and tried to use that as base DDF for the Aqara/Lumi (replacing manufacturername + modelid with the Lumi/Aqara’s).
@Smanar Thanks you for your patience!
I may just have found a working combination by cutting/pasting bits and pieces from the Ikea TW Bulb DDF! Can you check if you see anything strange? It seems it works now: I can add a new Aqara/Lumi bulb, turn it on/off, dim it and set the color temp now.
I re-opened the Aqara PR (and also opened a PR for 2 new Ikea lights DDFs).
{
"schema": "devcap1.schema.json",
"manufacturername": "$MF_LUMI",
"modelid": "lumi.light.aqcn02",
"product": "lumi.light.aqcn02",
"sleeper": false,
"status": "Gold",
"path": "",
"subdevices": [
{
"type": "$TYPE_COLOR_TEMPERATURE_LIGHT",
"restapi": "/lights",
"uuid": [
"$address.ext",
"0x01"
],
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/colorcapabilities",
"refresh.interval": 84000
},
{
"name": "config/ctmax",
"refresh.interval": 84000
},
{
"name": "config/ctmin",
"refresh.interval": 84000
},
{
"name": "state/alert",
"default": "none"
},
{
"name": "state/bri",
"refresh.interval": 5
},
{
"name": "state/colormode"
},
{
"name": "state/ct",
"refresh.interval": 5
},
{
"name": "state/on",
"refresh.interval": 5
},
{
"name": "state/reachable"
}
]
}
],
"bindings": [
{
"bind": "unicast",
"src.ep": 1,
"dst.ep": 1,
"cl": "0x0006",
"report": [
{
"at": "0x0000",
"dt": "0x10",
"min": 1,
"max": 1800
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"dst.ep": 1,
"cl": "0x0008",
"report": [
{
"at": "0x0000",
"dt": "0x20",
"min": 5,
"max": 1800,
"change": "0x00000001"
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"dst.ep": 1,
"cl": "0x0300",
"report": [
{
"at": "0x0007",
"dt": "0x21",
"min": 5,
"max": 1800,
"change": "0x00000001"
},
{
"at": "0x0003",
"dt": "0x21",
"min": 5,
"max": 1795,
"change": "0x0000000A"
},
{
"at": "0x0004",
"dt": "0x21",
"min": 5,
"max": 1795,
"change": "0x0000000A"
},
{
"at": "0x0008",
"dt": "0x30",
"min": 1,
"max": 1800
}
]
}
]
}
The api returns:
{
“colorcapabilities”: 0,
“ctmax”: 65279,
“ctmin”: 0,
“etag”: “0ee9f2b195593b366e5b2007de55c566”,
“hascolor”: true,
“lastannounced”: null,
“lastseen”: “2022-09-08T18:42Z”,
“manufacturername”: “LUMI”,
“modelid”: “lumi.light.aqcn02”,
“name”: “Color temperature light 14”,
“state”: {
“alert”: “none”,
“bri”: 148,
“colormode”: “ct”,
“ct”: 327,
“effect”: “none”,
“lift”: 0,
“on”: false,
“open”: false,
“reachable”: true,
“xy”: [
0.4355,
0.4079
]
},
“swversion”: “1.23”,
“type”: “Color temperature light”,
“uniqueid”: “00:15:8d:00:05:20:eb:66-01”
}
So you are on the model “lumi.light.aqcn02” ?
You can remove state/xy as the device don’t support color
You can remove state/lift and state/open as its for covering
Can remove in bind the attribute 0x0003 and 0x0004 as they are for X and Y (for the cluster 0x0300)
Can you please let me know exactly what to remove? Ddf is in the previous post, but I don’t see these in the DDF:
Update: I got rid of all except for this:
You can remove state/lift and state/open as its for covering
Where in the DDF do they come from? I just tried removing all kinds of stuff, but the additional States remain on lumi.light.aqcn02:
{
“colorcapabilities”: 0,
“ctmax”: 65279,
“ctmin”: 0,
“etag”: “323b74b21e38c3b91f7375b31ead962f”,
“hascolor”: true,
“lastannounced”: “2022-09-09T18:51:49Z”,
“lastseen”: “2022-09-09T18:52Z”,
“manufacturername”: “LUMI”,
“modelid”: “lumi.light.aqcn02”,
“name”: “Color temperature light 14”,
“state”: {
“alert”: “none”,
“bri”: 66,
“colormode”: “ct”,
“ct”: 500,
“effect”: “none”,
“lift”: 0,
“on”: true,
“open”: false,
“reachable”: true,
“xy”: [
0.5267,
0.4173
]
},
“swversion”: “1.23”,
“type”: “Color temperature light”,
“uniqueid”: “00:15:8d:00:05:20:eb:66-01”
}
Is there a sample DDF for Tunable Dimmable LED with all required fields?
I also looked at this DDF as an example for lumi.light.aqcn02, but with those bindings it still gives the same api output (it works fine though):
At this step, I think using the editor is easier for you, and as you can use the GUI.
“state” field are purple
“config” field are green
All of them can be add/removed https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/DDF-cheat-sheet
Just, remove them, save the DDF and make a hot reload.
With luck deconz will update the device json, but IDK if it will remove unused field (in this situation, need to re-include the device)
Where in the DDF do they come from?
Not your fault, when you make “edit DDF” deconz try to make a DDF according to cluster present on the device, and this one have useless one
That’s what confuses me, these states are not in the DDF when I open it on the Arara bulb (I re-included it before checking the api)?
It would really help if there was a generic DDF for some zigbee bulb types (dimmable/tunable white/color) that we could use as template.
I will try to start from scratch without DDF today and use the editor to create a new one.
That’s what confuses me, these states are not in the DDF when I open it on the Arara bulb
Ha yes, not normal, what is your deconz version ? On older version the legacy code is faster than the DDF one, so it can happen.
But not normal if you make a complete re inclusion with a DDF enabled.
Hard to find DDF for that, as the support is native generaly for this kind of stuff, except for buggy model like this one. There is some in the “ikea” folder, perhaps https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/ikea/e14_ws_opal_400lm_light.json
I also just bought another generic bulb (linkin), and I created a df from scratch.
It worked in deconz, but when I clicked “Edit DDF” the file is empty.
Does this look OK for a tunable white bulb? If so then I will do the same for aqara:
{
“colorcapabilities”: 16,
“ctmax”: 370,
“ctmin”: 153,
“etag”: “5c4ad0209de62b77984d7a4ee3fd08ee”,
“hascolor”: true,
“lastannounced”: “2022-09-10T06:54:14Z”,
“lastseen”: “2022-09-10T07:52Z”,
“manufacturername”: “lk”,
“modelid”: “ZBT-CCTLight-D0106”,
“name”: “Linkind”,
“state”: {
“alert”: “none”,
“bri”: 66,
“colormode”: “ct”,
“ct”: 370,
“on”: false,
“reachable”: true
},
“swversion”: “2.2”,
“type”: “Color temperature light”,
“uniqueid”: “ec:1b:bd:ff:fe:b1:96:5f-01”
}
Relevant part of DDF:
"subdevices": [
{
"type": "$TYPE_COLOR_TEMPERATURE_LIGHT",
"restapi": "/lights",
"uuid": [
"$address.ext",
"0x01"
],
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/ctmax",
"refresh.interval": 84000
},
{
"name": "config/ctmin",
"refresh.interval": 84000
},
{
"name": "state/alert",
"default": "none"
},
{
"name": "state/bri",
"refresh.interval": 5
},
{
"name": "state/colormode"
},
{
"name": "state/ct",
"refresh.interval": 5
},
{
"name": "state/on",
"refresh.interval": 5
},
{
"name": "state/reachable"
}
]
}
],
"bindings": [
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0006",
"report": [
{
"at": "0x0000",
"dt": "0x10",
"min": 0,
"max": 0
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0008",
"report": [
{
"at": "0x0000",
"dt": "0x20",
"min": 0,
"max": 0
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0300",
"report": [
{
"at": "0x0007",
"dt": "0x21",
"min": 0,
"max": 0
}
]
}
]
}
Update The DDF section mentioned above also seems to work fine for the Aqara, but it still exposes Lift and XY on the Aqara, even when I pair it again. For both the Linkind and Lkea that same DDF bit works just fine, with an api response as pasted above.
{
“ctmax”: 65279,
“ctmin”: 0,
“etag”: “ab60c67d314acdb802c92b0d1cd9ab3d”,
“hascolor”: true,
“lastannounced”: null,
“lastseen”: “2022-09-10T09:52Z”,
“manufacturername”: “LUMI”,
“modelid”: “lumi.light.aqcn02”,
“name”: “Lumi”,
“state”: {
“alert”: “none”,
“bri”: 139,
“colormode”: “ct”,
“ct”: 327,
“effect”: “none”,
“lift”: 0,
“on”: false,
“open”: false,
“reachable”: true,
“xy”: [
0.4355,
0.4079
]
},
“swversion”: “1.23”,
“type”: “Color temperature light”,
“uniqueid”: “00:15:8d:00:05:20:eb:66-01”
}
But does it really matter the api includes too much states, it doesn’t seem to bother my 3rd party application (Homey) and everything seems to be working as expected.
BTW: I am replacing my Aqara bulbs with more Linkind bulbs anyway ( Linkind 9W A19 Bulb, Dimmable & Tunable (ZL1000100-CCT-US-V1A02) Zigbee compatibility).