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).
Bad luck, need to start from scratch but if the device is a buggy one it’s easier because when you drag and drop the good type from right to left, you will have the attribute according to the type and only them.
Does this look OK for a tunable white bulb? If so then I will do the same for aqara:
Yep the json is perfect, the DDF too for me.
Just a comment, ATM we have issue on some color temperature device https://forum.phoscon.de/t/device-values-are-not-read-out/2389 with legacy code, can be corrected using DDF.
For the binding part you are making a bind on the cluster 0x0300 on the attribute 0x0007 only, it the more important, it s the ct value.
But if you have issue to set the temperature, I think there is something to improve here, but if you don’t have issue on your side, let them as it for the moment (the previous issue appear after a deconz reboot)
But does it really matter the api includes too much states
Depend of third app, but can cause issue, you have xy in the json, so third app can think the device support color.
But we will have a new deconz soon, with lot of improvement on this part, for me your DDF is fine, the problem is from deconz.
Edit:
Ops, you forget to set value for min et max
"min": 0,
"max": 0
Defaut value are 1/300 for usefull light attributes, needed regulary.
{
"at": "0x0007",
"dt": "0x21",
"min": 1,
"max": 300,
"change": "0x0005"
},
{
"at": "0x0000",
"dt": "0x20",
"min": 1,
"max": 300,
"change": "0x00000001"
}
Attribute on cluster 0x0006 don’t have “change”
So this is OK?
“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”: 1,
“max”: 300,
“change”: “0x00000001”
}
]
},
{
“bind”: “unicast”,
“src.ep”: 1,
“cl”: “0x0300”,
“report”: [
{
“at”: “0x0007”,
“dt”: “0x21”,
“min”: 1,
“max”: 300,
“change”: “0x0005”
}
]
The Cluster 0x0006 haven’t “change” because the value is just “on” or “off”, but it need too “min” and “max”. The “change” is the difference value that trigger a report.
Ah, ok. Like this?
Perfect for me.
The only problem we can have is with the color stuff (colorcapabilities, ctmin, ctmax) like on the previous link, but if you don’t have issue, nothing more to say.
Well, that was quite a journey!
@Smanar Thanks for your guidance, much appreciated!
I created 2 other PRs for similar TW bulbs, based on the same DDF:
Lol, np, thx for you for the time you spend on the project.
Just for information (according to the previous issue I have linked). If you have issue it’s possible to lock value for ctmin/ctmax/colorcapabilities.
As the DDF is only for this device, you can set the value direclty in the editor, and check the checkbox to make it fixed. Like that, no need to update/check the value using zigbee request, and less issues.