After DDF modification got duplicate clusters with 0xff endpoint

Advice
12

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

13

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
14

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

image
image686×601 22.7 KB

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.

image
image997×704 59.4 KB

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 ?

15

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

16

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"}}
17

Terrible ^^.

18

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.

19

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

20

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.

21

I undestand, and it’s not a problem when the device is in integration/test of a new/modified DDF. But when the device is already used by some automation it could be a challenge that we don’t have a way to just delete a sensor with -FF endpoint for instance.

22

My comment was not a working mode ^^.
There is clearly a problem (and a mystery) for me too.

1 Like
23

Another occurrence of it : Fix extra config/battery for ts0202 devices by Monofin · Pull Request #6599 · dresden-elektronik/deconz-rest-plugin · GitHub

24

Another occurence : Tuya Soil Sensor · Issue #6731 · dresden-elektronik/deconz-rest-plugin · GitHub and this one had never been picked up by legacy code before having DDF.

25

Ha yes righ, it’s a temperature sensor, and end device, so without the DDF it could not be included before the DDF installation.

26

@manup @de_employees

27

Another case of FF endpoint : LiXee ZLinky_TIC DDF File

28

Got another one, for a no more existing sensor :

    "32": {
        "config": {
            "on": true,
            "reachable": false
        },
        "etag": "523ca834cfae0bd9ea79d5d7b44e7538",
        "lastannounced": null,
        "lastseen": "2023-02-17T03:00Z",
        "manufacturername": "sengled",
        "modelid": "E1C-NB7",
        "name": "Puissance ventilo projecteur",
        "state": {
            "current": 0,
            "lastupdated": "2023-02-17T03:01:00.106",
            "power": 0,
            "voltage": 0
        },
        "swversion": "0.1.10",
        "type": "ZHAPower",
        "uniqueid": "b0:ce:18:14:03:6b:cf:99-ff-0b04"
    },

And that is still in DB (only into sensors table) with

{"lastupdated":"2023-02-17T03:01:00.106","power":0}
29

It’s your network ?
Let me guess, you have a bind for the cluster 0x0b04 in the bind table and not device in the DDF core ?

30

Ye it is. And it’s quite the opposite deconz-rest-plugin/devices/sengled/e1c-nb7.json at master · dresden-elektronik/deconz-rest-plugin · GitHub

0x0b04 in core DDF but no bind ! Uneeded because this cluster is unused in core, because it doesn’t exist in the device
image

And a device that have been deleted for a while …

31

And it have added power+current+tension that are not present in the DDF …