After DDF modification got duplicate clusters with 0xff endpoint

After modifiying a DDF for SMT402AD thermostat, replacing an invalid uuid by another on the Humidity sensor, replacing :

      "type": "$TYPE_HUMIDITY_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0405"

by

      "type": "$TYPE_HUMIDITY_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x19",
        "0x0405"

to be compliant with the binding parts of the DDF (25 in decimal equals to 0x19)

 "bindings": [
    {
      "bind": "unicast",
      "src.ep": 25,
      "cl": "0x0405"
    },
    {
      "bind": "unicast",
      "src.ep": 25,
      "cl": "0x0204"
    },
    {
      "bind": "unicast",
      "src.ep": 25,
      "cl": "0x0201"
    }
  ]

and after that I had to restart my RPi for other reason.

All return to normal, except that I got duplicates clusters, those that I think are correct with endpoint 0x19 and others with endpoint 0xffand when reading information in deCONZ-GUI both are updated :

07:53:54:663 f8:f0:05:ff:ff:70:7e:95-ff-0201/attr/manufacturername expression: Item.val = Attr.val --> Stelpro
07:53:54:664 f8:f0:05:ff:ff:70:7e:95-19-0201/attr/manufacturername expression: Item.val = Attr.val --> Stelpro
07:53:54:665 f8:f0:05:ff:ff:70:7e:95-ff-0402/attr/manufacturername expression: Item.val = Attr.val --> Stelpro
07:53:54:666 f8:f0:05:ff:ff:70:7e:95-ff-0405/attr/manufacturername expression: Item.val = Attr.val --> Stelpro
07:53:54:667 f8:f0:05:ff:ff:70:7e:95-19-0405/attr/manufacturername expression: Item.val = Attr.val --> Stelpro
07:53:54:668 f8:f0:05:ff:ff:70:7e:95-19-0402/attr/manufacturername expression: Item.val = Attr.val --> Stelpro
07:53:54:668 f8:f0:05:ff:ff:70:7e:95/attr/manufacturername expression: Item.val = Attr.val --> Stelpro
07:53:54:828 f8:f0:05:ff:ff:70:7e:95-ff-0201/attr/modelid expression: Item.val = Attr.val --> SMT402AD
07:53:54:829 f8:f0:05:ff:ff:70:7e:95-19-0201/attr/modelid expression: Item.val = Attr.val --> SMT402AD
07:53:54:830 f8:f0:05:ff:ff:70:7e:95-ff-0402/attr/modelid expression: Item.val = Attr.val --> SMT402AD
07:53:54:831 f8:f0:05:ff:ff:70:7e:95-ff-0405/attr/modelid expression: Item.val = Attr.val --> SMT402AD
07:53:54:832 f8:f0:05:ff:ff:70:7e:95-19-0405/attr/modelid expression: Item.val = Attr.val --> SMT402AD
07:53:54:833 f8:f0:05:ff:ff:70:7e:95-19-0402/attr/modelid expression: Item.val = Attr.val --> SMT402AD
07:53:54:834 f8:f0:05:ff:ff:70:7e:95/attr/modelid expression: Item.val = Attr.val --> SMT402AD

If I delete the Thermostat with 0xff endpoint it delte the device from deCONZ and I had to rejoin it.

Here is my DDF :

{
  "schema": "devcap1.schema.json",
  "manufacturername": "Stelpro",
  "modelid": "SMT402AD",
  "product": "SMT402AD",
  "sleeper": false,
  "status": "Silver",
  "path": "/devices/smt402ad.json",
  "subdevices": [
    {
      "type": "$TYPE_THERMOSTAT",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x19",
        "0x0201"
      ],
      "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/externalsensortemp",
          "description": "External sensor temperature used as Outdoor temperature on display.",
          "refresh.interval": 300,
          "read": {
            "at": "0x4001",
            "cl": "0x0201",
            "ep": 25,
            "fn": "zcl",
            "mf": "0x1185"
          },
          "write": {
            "at": "0x4001",
            "cl": "0x0201",
            "dt": "0x29",
            "ep": 25,
            "eval": "Item.val",
            "fn": "zcl",
            "mf": "0x1185"
          },
          "parse": {
            "at": "0x4001",
            "cl": "0x0201",
            "ep": 25,
            "eval": "Item.val = Attr.val;",
            "fn": "zcl",
            "mf": "0x1185"
          },
          "default": 0
        },
        {
          "name": "config/heatsetpoint",
          "default": 0
        },
        {
          "name": "config/mode"
        },
        {
          "name": "config/offset",
          "default": 0
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "config/unoccupiedheatsetpoint",
          "refresh.interval": 300,
          "read": {
            "at": "0x0014",
            "cl": "0x0201",
            "ep": 25,
            "fn": "zcl"
          },
          "write": {
            "at": "0x0014",
            "cl": "0x0201",
            "dt": "0x29",
            "ep": 25,
            "eval": "Item.val",
            "fn": "zcl",
            "mf": "0x1185"
          },
          "parse": {
            "at": "0x0014",
            "cl": "0x0201",
            "ep": 25,
            "eval": "Item.val = Attr.val;",
            "fn": "zcl"
          },
          "default": 17
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/on",
          "refresh.interval": 5
        },
        {
          "name": "state/temperature",
          "description": "The current temperature in °C (*100).",
          "parse": {
            "at": "0x0000",
            "cl": "0x0201",
            "ep": 25,
            "eval": "Item.val = Attr.val + R.item('config/offset').val",
            "fn": "zcl"
          },
          "default": 0
        },
        {
          "name": "state/valve",
          "description": "PI Heating Demand\nIf below 10, then device is Idle, else device is Heating.",
          "refresh.interval": 300,
          "read": {
            "at": "0x0008",
            "cl": "0x0201",
            "ep": 25,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0008",
            "cl": "0x0201",
            "ep": 25,
            "eval": "Item.val = Attr.val;",
            "fn": "zcl"
          },
          "default": 0
        }
      ]
    },
    {
      "type": "$TYPE_HUMIDITY_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x19",
        "0x0405"
      ],
      "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/offset",
          "default": 0
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/humidity",
          "description": "The current relative humidity in percent (*100).",
          "refresh.interval": 300,
          "read": {
            "at": "0x0000",
            "cl": "0x0405",
            "ep": 25,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0000",
            "cl": "0x0405",
            "ep": 25,
            "eval": "Item.val = Attr.val + R.item('config/offset').val",
            "fn": "zcl"
          },
          "default": 0
        },
        {
          "name": "state/lastupdated"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 25,
      "cl": "0x0405"
    },
    {
      "bind": "unicast",
      "src.ep": 25,
      "cl": "0x0204"
    },
    {
      "bind": "unicast",
      "src.ep": 25,
      "cl": "0x0201"
    }
  ]
}

And it create it again if you try to re-include the device ?
I have this issue some days ago, need to found the post.

Edit:

Exactly ! :-/
BTW I can live with it inside Phoscon/DECONZ environment, but in third party apps it’s source of confusion and unused pseudo-devices (like in Domoticz that I use) and sometimes errors. But it’s not the right place to discuss about this part.

Even when “playing” with DDF by adding and deleting sensor (like ZHATemperature, Cluster 0x402) the -ff device is still alive when the regular one has disapear :

Not sure you can live with it.
On the issue I have linked, it probably make the DDF not working.

And I realy have no clue where this false entry can be from …

You are sure you haven’t garbage in the database after deleting the sensor ?

And if you make a “hot reload” with “DDF” log enabled ?

Not sure about that at all … How can I check this ?

Here it is

12:57:25:925 update ddf SMT402AD index 0
12:57:25:985 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: attr/id
12:57:25:987 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: attr/lastannounced
12:57:25:988 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: attr/lastseen
12:57:25:989 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: attr/manufacturername
12:57:25:990 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: attr/modelid
12:57:25:992 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: attr/name
12:57:25:993 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: attr/swversion
12:57:25:994 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: attr/type
12:57:25:996 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: attr/uniqueid
12:57:25:997 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: config/externalsensortemp
12:57:25:998 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: config/heatsetpoint
12:57:25:999 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: config/mode
12:57:26:000 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: config/offset
12:57:26:001 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: config/on
12:57:26:002 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: config/reachable
12:57:26:003 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: config/unoccupiedheatsetpoint
12:57:26:004 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: state/lastupdated
12:57:26:005 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: state/on
12:57:26:006 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: state/temperature
12:57:26:008 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0201, has item: state/valve
12:57:26:011 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: attr/id
12:57:26:012 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: attr/lastannounced
12:57:26:013 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: attr/lastseen
12:57:26:014 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: attr/manufacturername
12:57:26:015 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: attr/modelid
12:57:26:016 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: attr/name
12:57:26:017 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: attr/swversion
12:57:26:018 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: attr/type
12:57:26:019 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: attr/uniqueid
12:57:26:021 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: config/offset
12:57:26:022 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: config/on
12:57:26:023 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: config/reachable
12:57:26:024 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: state/humidity
12:57:26:025 sub-device: f8:f0:05:ff:ff:70:7e:95-19-0405, has item: state/lastupdated
...
12:57:39:143 f8:f0:05:ff:ff:70:7e:95-19-0201/config/externalsensortemp expression: Item.val = Attr.val; --> 1720

and after that making a read on the basic cluster

13:01:23:857 f8:f0:05:ff:ff:70:7e:95-ff-0201/attr/manufacturername expression: Item.val = Attr.val --> Stelpro
13:01:23:859 f8:f0:05:ff:ff:70:7e:95-19-0201/attr/manufacturername expression: Item.val = Attr.val --> Stelpro
13:01:23:860 f8:f0:05:ff:ff:70:7e:95-ff-0402/attr/manufacturername expression: Item.val = Attr.val --> Stelpro
13:01:23:862 f8:f0:05:ff:ff:70:7e:95-ff-0405/attr/manufacturername expression: Item.val = Attr.val --> Stelpro
13:01:23:863 f8:f0:05:ff:ff:70:7e:95-19-0405/attr/manufacturername expression: Item.val = Attr.val --> Stelpro
13:01:23:864 f8:f0:05:ff:ff:70:7e:95/attr/manufacturername expression: Item.val = Attr.val --> Stelpro
13:01:23:923 f8:f0:05:ff:ff:70:7e:95-ff-0201/attr/modelid expression: Item.val = Attr.val --> SMT402AD
13:01:23:928 f8:f0:05:ff:ff:70:7e:95-19-0201/attr/modelid expression: Item.val = Attr.val --> SMT402AD
13:01:23:936 f8:f0:05:ff:ff:70:7e:95-ff-0402/attr/modelid expression: Item.val = Attr.val --> SMT402AD
13:01:23:941 f8:f0:05:ff:ff:70:7e:95-ff-0405/attr/modelid expression: Item.val = Attr.val --> SMT402AD
13:01:23:946 f8:f0:05:ff:ff:70:7e:95-19-0405/attr/modelid expression: Item.val = Attr.val --> SMT402AD
13:01:23:953 f8:f0:05:ff:ff:70:7e:95/attr/modelid expression: Item.val = Attr.val --> SMT402AD

It’s even keeping trace of the cluster 0x0402 that is no more in the DDF !!

Not sure about that at all … How can I check this ?

Can use a sql editor. On m y side I m using “SQLiteDatabaseBrowserPortable” without installation with the deconz datafile zll.db.
But you have too another problem (on the other post) the strange new field.
I think someone need to investigate.

So the “hot relaoad” work fine, only for the good entry.
But asking cluster trigger the bad one.

It’s even keeping trace of the cluster 0x0402 that is no more in the DDF !!

Yeah its for that I think there is perhaps something bad in your datatabase. You are sure you don’t have a “bad DDF” mix ?

What do you mean by a “bad DDF mix” ? I only have one DDF for that thermostat SMT402AD.
I tried to delete that thermostat in Deconz-GUI and it crashed. After restarting the -ff endpoints had disapeared … seemed to be good but after rejoining the thermostat and renaming it (I changed it from room) Deconz crashed again and the old thermostat, with the old name came again as a ghost … with the weird endpoints !

Each attempt to rename it crash Deconz, not immediately but after a while … May be during the automatic modification of outside temperature with a script. Stopped it and wait to be sure.

Well, Deconz sporadic crashes was due to attempts to write a config attributes by script on a no more existent sensor … corrected, then system seems to be stable for last night.

But l’m still not able to exoplain the re-appearence of the -FF endpoints. Will try again later to delete thermostat and rejoining it …

I can reproduce that on my side ?

I’d be interested to catch those crashes with a backtrace. Is that easily reproducable?

You can run it with a debugger like described here: v2.11.0-beta in docker - after mi button click "Segmentation fault (core dumped)" · Issue #4766 · dresden-elektronik/deconz-rest-plugin · GitHub

When the crash occurred, the command bt will give you the juicy parts…

Yes it can be reproductable, on my side when sending such a command

curl -H 'Content-Type: application/json' -X PUT -d '{"externalsensortemp": 509}' http://127.0.0.1/api/XXXXXXXXXX/sensors/18/config

Whrere XXXXXXXXXX is my API key and that the sensor idx (18 in this example) is a non existing sensor (I delete and rejoin a SMT0402AD thermostat recently trying to solve this -ff endpoint issue) then Deconz-GUI seems crashing.

Example when using existant sensor idx (18) and just after non existent sensor idx (37) :

pi@domoticz:/tmp/log $ curl -H 'Content-Type: application/json' -X PUT -d '{"externalsensortemp": 509}' http://127.0.0.1/api/XXXXXXXXXX/sensors/18/config
[{"success":{"/sensors/18/config/externalsensortemp":509}}]
pi@domoticz:/tmp/log $ curl -H 'Content-Type: application/json' -X PUT -d '{"externalsensortemp": 509}' http://127.0.0.1/api/XXXXXXXXXX/sensors/37/config
curl: (52) Empty reply from server

and crash & restart of Deconz-GUI

Version 2.15.03 21/04/2022
Firmware 26720700

I know it’s quite an “old” version but until I had to change I’ll keep it because of PR #6011 still not integrated (don’t want to recompile at each version change).

Lol right
I can confirm it on the version I had, nice crash ^^
But I have installed the last beta version and now I have

[
  {
    "error": {
      "address": "/sensors/99",
      "description": "resource, /sensors/99, not available",
      "type": 3
    }
  }
]

So I think it’s corrected now

1 Like

-FF Endpoint is back again. Trying to play with a recently received device and was surprise that I didn’t get the same result using REST-API or Domoticz-plugin :
REST-API via CURL curl -X GET -i 'http://192.168.2.xxx/api/xxxxxxxxxx/sensors/83' or PHOSCON gives me :

{
  "config": {
    "duration": 0,
    "on": true,
    "reachable": true
  },
  "etag": "3221c57d699f88a48a063d3f54b36e4c",
  "lastannounced": null,
  "lastseen": "2023-02-14T00:46Z",
  "manufacturername": "_TZE200_v6ossqfy",
  "modelid": "TS0601",
  "name": "Presence 83",
  "state": {
    "lastupdated": "2023-02-11T03:08:21.700",
    "presence": false
  },
  "swversion": "1.0.6",
  "type": "ZHAPresence",
  "uniqueid": "a4:c1:38:6c:b8:00:b3:88-ff-ef00"

and via Domoticz-Plugin :


As you can see the attributes are not the same, nor the values … and the EP is good in Domoticz but not in Phoscon/curl. All the attriubutes from Domoticz are compliant with the DDF. All from curl or Phoscon are not.

I looked in every tables in zll.db and didn’t find any trace of the -FF endpoint, just informations with the correct -01 endpoint.

It can’t be due to an old version like we thought initially :
image

How can we have to way of getting these different informations if both use REST-API ? May be @Smanar could give a light on this because he developped the Domoticz plugin ?

Lol, WTF ?
But domoticz and phoscon are using the same API, it’s not possible, it’s not because the api was updated at a moment and 1 request was done before and the second one after ?

And the last updated is not the same, this one with FF is 2 days before.

When you use the Domoticz frontend, the plugin make a GET on http://192.168.2.xxx/api/xxxxxxxxxx/sensors/ to get the complete sensor list

So you have perhaps a difference if you make a GET on
http://192.168.2.xxx/api/xxxxxxxxxx/sensors/ and searching the id 83 or making a GET on http://192.168.2.xxx/api/xxxxxxxxxx/sensors/83

You get it

curl -X GET -i 'http://192.168.2.146/api/xxxxxxxxxx/sensors/83'
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Content-Length: 377
ETag:"239e0ce3c3ceb46f1966c47c18135af1"

{"config":{"duration":0,"on":true,"reachable":true},"etag":"239e0ce3c3ceb46f1966c47c18135af1","lastannounced":null,"lastseen":"2023-02-14T10:45Z","manufacturername":"_TZE200_v6ossqfy","modelid":"TS0601","name":"Presence 83","state":{"lastupdated":"2023-02-11T03:08:21.700","presence":false},"swversion":"1.0.6","type":"ZHAPresence","uniqueid":"a4:c1:38:6c:b8:00:b3:88-ff-ef00"}

and

curl -X GET -i 'http://192.168.2.146/api/xxxxxxxxxx/sensors'
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Content-Length: 20742
ETag:"d98528aceb1b1f55178a24086d2aca1b"

{"1":{"config":{"configured":true,"on":true,"sunriseoffset":30,"sunsetoffset"
...
83":{"config":{"delay":0,"duration":0,"ledindication":true,"on":true,"reachable":true,"triggerdistance":null},"etag":"e4dff639c664c03bc9eb66e43c344d87","lastannounced":null,"lastseen":"2023-02-14T10:45Z","manufacturername":"_TZE200_v6ossqfy","modelid":"TS0601","name":"Presence 83","state":{"lastupdated":"2023-02-14T10:45:36.363","presence":true},"swversion":"1.0.6","type":"ZHAPresence","uniqueid":"a4:c1:38:6c:b8:00:b3:88-01-ef00"}}

Terrible ^^.

I deleted device one more time to get a DDF to work (I hope so!) then all is correct … but mystery is still unsolved and demonstration is done that some « ghost » -ff endpoint can still appears.

Another example today after restarting Deconz :
Via REST-API on sensor 76 directly (GET http://127.0.0.1/api/xxxxxxxxxx/sensors/76)

{
"config": {
"heatsetpoint": 1800,
"offset": 0,
"on": true,
"reachable": true,
"schedule": {},
"schedule_on": false
},
"etag": "81acaacc493410f4f620c6da95488efd",
"lastannounced": null,
"lastseen": "2023-02-17T14:04Z",
"manufacturername": "Stelpro",
"modelid": "0x534d5434303241440000000000301800203944000803000000dd590008ffff",
"name": "Thermostat SdD",
"state": {
"lastupdated": "2023-02-17T02:47:39.656",
"on": false,
"temperature": 2100
},
"swversion": "20000000 00000",
"type": "ZHAThermostat",
"uniqueid": "f8:f0:05:ff:ff:70:7e:95-ff-0201"
}

And with collecting for all sensors (GET http://127.0.0.1/api/xxxxxxxxxx/sensors/)

{
1: {
"config": {
"configured": true,
"on": true,
"sunriseoffset": 30,
"sunsetoffset": -30
},
"etag": "331c45cd19417e41d431c6ff66540016",
"manufacturername": "Philips",
"modelid": "PHDL00",
"name": "Daylight",
[...]
76: {
"config": {
"externalsensortemp": 30,
"heatsetpoint": 1800,
"mode": null,
"offset": 0,
"on": true,
"reachable": true
},
"etag": null,
"lastannounced": null,
"lastseen": "2023-02-17T14:07Z",
"manufacturername": "Stelpro",
"modelid": "0x534d5434303241440000000000301800203944000803000000dd590008ffff",
"name": "Thermostat SdD",
"state": {
"lastupdated": "2023-02-17T14:06:06.052",
"on": null,
"temperature": 1800,
"valve": 0
},
"type": "ZHAThermostat",
"uniqueid": "f8:f0:05:ff:ff:70:7e:95-19-0201"
},

What I did : Restart of DeConz (by mistake, closing the GUI). After restart I saw that the thermostat did not get the DDF loaded (one more time for a incorrect modelid) Changed it in DDF, save, hot reload. Seems fine but this morning saw that external temperature was not displayed. Looking in DeCONZ UI, DFF seems fine with externalsensortemp listed in attributes. But my script that updates the value usiong REST_API got an error …

And this -FF endpoint sensor does not exist in zll.db
image

I have some issue too with users that have already included a device with legacy code, and try to include it again using DDF, without deleting the old one.
No problem if they delete first the device created with legacy code.