DDF for Aqara Tunable White Bulb - lumi.light.aqcn02 (ZNLDP12LM))

DDF-Library
1

This one works fine for me.

{
  "schema": "devcap1.schema.json",
  "manufacturername": "$MF_LUMI",
  "modelid": "lumi.light.aqcn02",
  "product": "lumi.light.aqcn02",
  "sleeper": false,
  "status": "Gold",
  "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": "state/alert",
          "description": "The currently active alert effect.",
          "default": "none"
        },
        {
          "name": "state/on",
          "description": "True when device is on; false when off.",
          "refresh.interval": 5
        },
        {
          "name": "state/reachable",
          "default": true
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0006",
      "report": [
        {
          "at": "0x0000",
          "dt": "0x10",
          "min": 1,
          "max": 300
        }
      ]
    },
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0008",
      "report": [
        {
          "at": "0x0000",
          "dt": "0x20",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    },
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0300",
      "report": [
        {
          "at": "0x0007",
          "dt": "0x21",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        },
        {
          "at": "0x0003",
          "dt": "0x21",
          "min": 1,
          "max": 300,
          "change": "0x0000000A"
        },
        {
          "at": "0x0004",
          "dt": "0x21",
          "min": 1,
          "max": 300,
          "change": "0x0000000A"
        },
        {
          "at": "0x0008",
          "dt": "0x30",
          "min": 1,
          "max": 300
        }
      ]
    }
  ]
}
1 Like
2

BTW: Is there a way to contribute DDF files without having to GIT clone/update/pull-to-master?

3

I think if you do it trough github.com, via the website, a lot is taken care of already.

4

You mean just add a device request and copy/paste the working ddf for review?

5

I’ll reply Monday with some screens on how to do it.

1 Like
6

You can ask for a dev make the PR for you.
But better to make the PR yourself if you have a github account, if you have only 1 file, it’s realy fast and the file will be under your name, for me it’s important, even it’s just 1 file, it’s nice to see other name than the classic 4/5 devs, Github is a community, and you are the “owner” of the file.

7

I understand, but the problem is that I - like most end users - have no clue about DDF files, I just generated one from an existing device. And although it seems to work OK, I have no idea if all settings are actually correct.

If DDF should become the main method of device support, IMO there has to be a simple and user-friendly way to upload them. For example submit them directly from the Phoscon web UI to a deconz library for review/approval by an expert (they could also verify/merge different manufacturer Ids, check dependencies etc.)? That way many devices could be converted and added with minimal effort on both sides.

Just my thoughts… :slight_smile:

8

Yeah I m agree with you, but It mean some work on deconz webserver site for me, there is so much thing to do first and I realy have no clue what they are doing ATM.

We will see with the Mimixx tutorial, but the benefit of Github if you are not sure of you, the PR can be see by other users before validation and edition is easy (you will see later with github, but you can edit the PR in 30s just with a browser)

About this DDF (for later when you will submit it):

  • Can remove the line “path”
  • Set the status at least to “Silver”, bronze will be never tested by other user, it s only when you are rely not sure.
  • Can remove line “description”
  • Can remove the binding for cluster 0x0102, it’s a binding for covering, I don’t think your device have/need it.
9

Wrote a wiki page for it:

1 Like
10

@iisworks Great that it was fine for you! :slight_smile: Was a small write up. If i missed anything, let me know :slight_smile:

11

@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.

12

If you’ve checked carefully, that’s already there. I used a seperate account to avoid exactly that :wink:

13

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 ?

14

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).

15

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.

16

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”
}

17

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.

18

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. :slight_smile:

Maybe this zigbee2mqtt commit holds a clue:

19

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.

20

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.