Adding DDF for IDlock 150

[brujoand]

So after creating #5739 I wanted to try to add support for showing the state of the door (open/closed) in addition to the lockstatus for this device. I have no idea what I'm doing so please throw all the feedback at me.

This PR is functionally working, but only by trial and error, and has one flaw. config/lock works as expected but status/lockstatus does not. I'm assuming this is because I don't understand how to supply a proper enum return value. I did try to create lockstatus.js to work around this, but to no avail.

I also have no idea what the bindings are for, but they were suggested by the DDF editor so I kept them. Could someone please elaborate on what this achieves?

C++ support was added for this lock with #3827, and to test this I changed my config to allow bronze DDFs. With that setup I could lock and unlock the app through the rest API, but I don't know if that's due to my DDF being fantastic, or to the existing C++ functionality. I would assume only the DDF are used in this case.

This is the output currently get from the api:

{
  "config": {
    "battery": 85,
    "lock": false,
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "9d25f84a732ef1eae547866c427fab84",
  "lastannounced": null,
  "lastseen": "2022-02-09T17:22Z",
  "manufacturername": "Datek",
  "modelid": "ID Lock 150",
  "name": "Hoveddøra",
  "state": {
    "lastupdated": "2022-02-09T12:03:09.619",
    "lockstate": "unlocked",
    "open": false
  },
  "swversion": "0.7",
  "type": "ZHADoorLock",
  "uniqueid": "68:0a:e2:ff:fe:6b:b8:26-01-0101"
}

Where config/battery config/lock and status/open work as expected while status/lockstatus does not.

[Smanar]

Without binding/report, values will be updated only when you will read them in deconz.
With the combo bind/report, the device will report itself the changes. On your DDF you have

      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0101",
      "report": [
        {
          "at": "0x0003",
          "dt": "0x10",
          "mf": "0x1337",
          "min": 300,
          "max": 2700

It mean you have a bind from the cluster 0x0101, EP¨0x01 from the device to the gateway on EP 0x01. that for the attribute 0x0003. DT is the attribute type, min and max are delay between 2 reports.

ATM on code we are using as value for the attribute 0x0000

        rq.attributeId = 0x0000; // Current Lock Position
        rq.minInterval = 1;
        rq.maxInterval = 300;

And for the 0x0003

       rq2.attributeId = 0x0003; // Door state
        rq2.minInterval = 1;
        rq2.maxInterval = 300;

"mf": "0x1337",
I think too you can let (and it's better) the value maufacture number empty. From my memory this device don't use it for his request.

This PR is functionally working, but only by trial and error, and has one flaw. config/lock works as expected but status/lockstatus does not. I'm assuming this is because I don't understand how to supply a proper enum return value. I did try to create lockstatus.js to work around this, but to no avail.

Here you have made more work than me ^^
Have you tried just with a "eval": "Item.val = Attr.val" to be sure all working before displaying the good string ?

BTW, state/open is working ?

I think too it's better to remove
"refresh.interval": 172,

As the device will use report, no need to poll it.

[brujoand]

Thanks for the feedback, now the bindings make complete sense!

I'll try using the same intervals as the c++ code then and give it a go without the explicit mf code.

Have you tried just with a "eval": "Item.val = Attr.val" to be sure all working before displaying the good string ?

This is a bit funky. Because if I restart deCONZ then config/lock and status/lockstatus are not returned by the API. When I check the DDF editor they do not have the 'Public item' checkbox cheked. If I check the box and hot reload they appar in the API.

If I started deCONZ with no javascript file and no expression for status/lockstate then it will show 2 as value. If I lock the door it does change to 3. But when I unlocked the door again it still stays as 3. Even after restarting deCONZ it's now stuck as 3. I also tried changing the bindings intervall to min: 1 and max: 300, and remove the refresh interval, but that did not change this behaviour. So something weird is going on with this one. Any tips on debugging that?

Edit: And I forgot to mention, the 'status/open' works perfectly.

[Smanar]

This is a bit funky. Because if I restart deCONZ then config/lock and status/lockstatus are not returned by the API. When I check the DDF editor they do not have the 'Public item' checkbox cheked. If I check the box and hot reload they appar in the API.

Nice catch, I will ask to other devs if they have idea
Perhpas because this attribute is not here https://github.com/dresden-elektronik/deconz-rest-plugin/tree/master/devices/generic/items

          "name": "state/lockstate",
          "read": {
            "at": "0x0000",
            "cl": "0x0101",
            "ep": 1,
            "fn": "zcl",
            "mf": "0x1337"
          },
          "parse": {
            "at": "0x0000",
            "cl": "0x0101",
            "ep": 1,
            "fn": "zcl",
            "mf": "0x1337",
            "script": "lockstatus.js"
          }
        },

BTW, you still have the mf here, I think you can remove all "mf": "0x1337"
And how have you set the dt in the bind ?

And there is something strange on DT

• attribute 0x0000 dt = 0x30 = enum 8
• attribute 0x0003 dt = 0x10 = bool

And both are enum8, so it's strange 0x0003 is working ....

Have you tried to read the value in deconz ? when you read the value in deconz it need to update the filed in the API too in same time (this procedure works without bind/report, usefull to test the first part) and with the same value ofc.

and it's a long story, but for easy setting, it s esaier to set the status to "gold" for your tests, to be sure the DDF is always loaded.

[brujoand]

Okay, got all the mf parts removed here now.

The datatypes are still a huge mystery to me. So I know that the devices will return an enum for both of these fields. So when I used on javascript or expression I just got numbers.

Now in the parse function I could produce whatever datatype I want. So for the lockstate it made sense to create a string which matches the standard lock state values. But I would much rather have just used the enum, but I didn't understand how to do that. For the door state I would ideally have created a new state/doorstate similar to state/lockstate, but just to get this working I used state/open instead.

Now, the thing that isn't making sense to me right now is that both lockstate and doorstate are grey when I try to read them in the cluster in deCONZ. But still these values get updated when I call the API. All except state/lockstate.

So I guess I'm asking, should I go about returning an enum in this case? Deconz seems to be able to fill in the "locked/unlocked" values in the UI, can I instruct the API to do the same thing? I'm also on the discord channel with the same nick btw if I'm not making sense right now. I find it's a bit hard to describe what's going on here as it's not clear to me how read and parse relate to eachother and to the bindings. For instance is the parse function used by the bindings?

[Smanar]

Now in the parse function I could produce whatever datatype I want

??? you can't select a data type in parse / read ?
It's you job to convert value > bool or value > string.

But NVM, will see later for the correction, for the moment having a value is nice ^^.

Now, the thing that isn't making sense to me right now is that both lockstate and doorstate are grey when I try to read them in the cluster in deCONZ

Ha yes, have already see this issue on another doorlock, never use the "read" button, because it ask for all attributes in same time, and the doorlock is not able to do that, and one time the attribute is disabled not possible to asking it a second time. Better to ask the attribute one by one.

It's the parse part that is used with binding.

To resume

state/lockstate, attribute 0x0000 > locked to 3 ?
state/open, attribute 0x0003 > work perfectly

right ?

I don't check for config/lock because this one is special (can be updated by the API itself)

So for state/lockstate, as this value is used at 2 places, can be the problem but it s strange the value can move, you have set "Item.val = Attr.val" for test ?

And why the value 3 ?

not full locked = 0
locked = 1
unlocked = 2

This is a bit funky. Because if I restart deCONZ then config/lock and status/lockstatus are not returned by the API. When I check the DDF editor they do not have the 'Public item' checkbox cheked. If I check the box and hot reload they appar in the API.

The issue can be from the missing file in devices/generic/items

Try with adding for exemple config_lock_item.json

{
	"schema": "resourceitem1.schema.json",
	"id": "config/lock",
	"datatype": "Bool",
	"access": "RW",
	"public": true,
	"description": "Locks or unlocks the door lock."
}

[brujoand]

??? you can't select a data type in parse / read ?
It's you job to convert value > bool or value > string.

Yes, that's what I mean. When parsing the value I can return whatever datatype I want. This is confusing as it's not clear from the UI what this variable is used for.

It's the parse part that is used with binding.

This is helpfull, so I it doesn't matter what the datatype of the attribute on the devices is, it matters how it is parsed. But is the parse function also used for reads?

I don't check for config/lock because this one is special (can be updated by the API itself)

Does this mean that I shouldn't do any parsing for this one?

Try with adding for exemple config_lock_item.json

There is already an entry for config_locked_item.json should that be used instead or would that break with the expectations of the device type in deconz?

[brujoand]

oh, and as for this one

So for state/lockstate, as this value is used at 2 places, can be the problem but it s strange the value can move, you have set "Item.val = Attr.val" for test ?

It doesn't matter what I set it to. If i use my javascript it will stay as 'unlocked' for ever, if I use 'Item.val = Attr.val' it will stay as '2' forever. No change if I lock the door, or change the expression.

[Smanar]

Yes, that's what I mean. When parsing the value I can return whatever datatype I want. This is confusing as it's not clear from the UI what this variable is used for.

Ha ok, on my side when I say type, was zigbee type, the "dt" field used in the zigbee request ( thoses types https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/general.xml#L5 ), , not the returned value type by the API.

But is the parse function also used for reads?

If I m right, the read part is for the poll stuff, using the field "interval"

Does this mean that I shouldn't do any parsing for this one?

You need too, but this one use the API stuff, it's a long story, but to resume, it's updated first by the api, after the request is done, and the value is updated again according to device return, so you can have "strange result" with this one.

There is already an entry for config_locked_item.json should that be used instead or would that break with the expectations of the device type in deconz?

This one is for TRV, it's the childlock, better to use a new one.

It doesn't matter what I set it to. If i use my javascript it will stay as 'unlocked' for ever, if I use 'Item.val = Attr.val' it will stay as '2' forever. No change if I lock the door, or change the expression.

Have you tried to read the value in deconz ? when values are not disabled (if you don't read all attribute in same time using the "read" button)

If it update the value in same time > binding issue.
If the value is 2 too, heee ....

[brujoand]

Ha ok, on my side when I say type, was zigbee type, the "dt" field used in the zigbee request ( thoses types https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/general.xml#L5 ), , not the returned value type by the API.

Okay, so the data types in the bindings are for the data sent by the zigbee devices then. So in my case both lockstate and doorstate should be enum8.

This one is for TRV, it's the childlock, better to use a new one.

Ah, right. New one it is.

Have you tried to read the value in deconz ? when values are not disabled (if you don't read all attribute in same time using the "read" button)

How can I do that? I only see the one read option next to the list of attributes.

[Smanar]

Okay, so the data types in the bindings are for the data sent by the zigbee devices then. So in my case both lockstate and doorstate should be enum8.

For me yes, but it seem it don't make a big difference for the moment.

How can I do that? I only see the one read option next to the list of attributes.

Easy, just double clic on the attribute you want to read (this one need to be enabled) then "read" button on the new popup. Just don't use the "read" button above the attribute table.

If the attribute is still disabled after that, I think we have a problem, it will be like the attribute not existing at all (or making a bad request to read it)

[Smanar]

Hello, some improvement ^^ ?

[brujoand]

Easy, just double clic on the attribute you want to read (this one need to be enabled) then "read" button on the new popup. Just don't use the "read" button above the attribute table.

Impossible as the attribute is grey, even after making sure the attribute is marked as 'public'

I have to admit that considering the amount of time I've spent trying to figure out how deconz and the DDFs work versus the progress I've made I'll probably not be pursuing this any further. Thanks for your help though.

[ZeppDK]

@brujoand what did your last DDF look like? and what works/dosnt?
im trying to get another lock to work, and would be great with some sort of starting point.

[brujoand]

@ZeppDK I actually ended up migrating everything to zigbee2mqtt instead so I don't have any copies other than what's in this PR.

I did get lock/unlock to work I think. Or it might have been the existing support that did that. There wasn't really any way to tell. But I know for certain I was able to expose the open/closed state. But yeah. That's about it.