search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.9k stars 501 forks source link

Yale YRD226 ZigBee keypad door lock #3750

Closed zeiphon closed 3 years ago

zeiphon commented 3 years ago

Device

This is a new issues as requested by @Smanar here: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/579#issuecomment-729018037 for Yale lock YRD226.

Using ZigBee module: AYR202-ZB-HA V261 , Model: YRMZB2

I believe the Yale integration guide will probably still apply, found here: http://maxicom.net/public/Yale%20Locks%20ZigBee%20HA%20Integrators%20Guide%20RevC.pdf (source: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/579#issuecomment-459896727 )

It looks like these locks should support PIN management (setting/retrieval etc) via ZigBee but I don't see this capability reflected in the clusters, unless I'm missing something?

Thanks!

Screenshots

node

basic_cluster power_cluster identity_cluster alarms_cluster time_cluster door_cluster poll_cluster diagnostics_cluster

brientim commented 3 years ago

@Smanar thank you for the very quick reply and notification is a good outcome. I am not seeing this in V2.11 so I am hoping this will be pushed in the next beta release.

wvuyk commented 3 years ago

following as I want to be able to implement this in my plugin. Is there going to be a way to be requesting multiple logs apart from the notification? The logs give more information, like the user? Will this be available in the next beta?

Smanar commented 3 years ago

For the moment this is just for the one that make try, it s on the issue https://github.com/dresden-elektronik/deconz-rest-plugin/issues/4253 , on another branch, totally wip.

I will give more explanation (and more clearly, sorry) when I will make the PR, but for ATM somes users have asked for PIN management, so I m waiting for somes returns to continu.

Smanar commented 3 years ago

So you need to instal deconz on an Unix machine to test the code, take a look here https://github.com/dresden-elektronik/deconz-rest-plugin#install-deconz-development-package-optional-linux-only

sudo apt install deconz-dev
git clone --branch doorlock_v2 https://github.com/Smanar/deconz-rest-plugin.git
cd deconz-rest-plugin
qmake && make -j2
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins

To test : door state And log during "GET PIN" command

burken- commented 3 years ago

Info-log for Set, Get and Clear pin-commands. Haven't compiled and installed your branch yet so these logs are from Longshot release with my additions to general.xml.

Set PIN Code 20:33:49:410 Door lock debug 0x680AE2FFFE6BB91F, data 0x00000005 20:33:49:414 Door lock debug 0x680AE2FFFE6BB91F, data 0x00000021

Get PIN Code 20:32:54:780 Door lock debug 0x680AE2FFFE6BB91F, data 0x00000006

Clear PIN Code 20:35:05:260 Door lock debug 0x680AE2FFFE6BB91F, data 0x00000007 20:35:07:697 Door lock debug 0x680AE2FFFE6BB91F, data 0x00000021

Smanar commented 3 years ago

Yes, but I need log with my branch, I have added more debug to code, it s to be sure I take the good way.

burken- commented 3 years ago

Apperently I'm missing something... when using "libde_rest_plugin.so" built from the doorlock_v2-branch together with the general.xml file from that branch all devices shows without name and log output shows basically nothing when running commands.

screenshot1

Smanar commented 3 years ago

Ha ? will make try on my side, you have compiled on the same machine than deconz is running ?

Edit: effectively, there is a problem, IDK why, but all compilation failed on my side even on master.

Smanar commented 3 years ago

Ok, have corrected the "restart" problem. If you still have this problem, I think the bug is from the xml file, but better to keep the one your are using, yours is tested and working, not mine.

You can update the code with

cd deconz-rest-plugin
git pull
qmake && make -j2
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins

But keep your xml file.

burken- commented 3 years ago

Sorry for the delay, been an outdoor day today :)

Door state working fine in the api

"state": {
                "doorstate": "closed",
                "lastupdated": "2021-04-24T19:28:02.014",
                "lockstate": "unlocked",
                "notification": null,
                "pin": null
            }

Logs from different commands

Set pin code: 20:41:33:517 Door lock debug 0x680AE2FFFE6BB91F, command 0x05, payload 00 Followed by a "Programming Event Notification" 20:41:36:084 Door lock debug 0x680AE2FFFE6BB91F, command 0x21, payload 0102030004313233340001FFFFFFFF0431323334

Get pin code 20:46:03:152 Door lock debug 0x680AE2FFFE6BB91F, command 0x06, payload 030001000431323334 20:46:03:153 Door lock debug 1

Clear pin code 20:48:13:318 Door lock debug 0x680AE2FFFE6BB91F, command 0x07, payload 00 Followed by a "Programming Event Notification" 20:48:15:755 Door lock debug 0x680AE2FFFE6BB91F, command 0x21, payload 01030300000000FFFFFFFF00

Smanar commented 3 years ago

What are you caling a "Programming Event Notification" ?

I have updated the code, I think now it will update the field "pin" when you make a "Get pin code "request, but I have so much problem so convert qstring<>json.

burken- commented 3 years ago

This log row seems to refer to command 0x21 20:48:15:755 Door lock debug 0x680AE2FFFE6BB91F, command 0x21, payload 01030300000000FFFFFFFF00

According to the zigbee cluster library that command is "Programming event notification". I don't know more, just noticed that set and clear-commands were followed by these rows in the log. The lock makes a sound after setting or clearing pin, probably refers to that.

Smanar commented 3 years ago

Ha yes, right, can add it to code, but not sure It will be usefull to use for API.

BTW, I need your help, I have some problem to test code. On the last version online, can you make this test

burken- commented 3 years ago

No, ignore the Programming-event. I just didn't reflect over what it was when I sent the logs the first time. It adds no functionality.

First command using GUI 18:11:04:679 Door lock debug 0x680AE2FFFE6BB91F, command 0x06, payload 030001000431323334 18:11:04:680 Door lock debug : Json error 1

PIN returned in Json (as escaped json)

    "state": {
        "doorstate": "closed",
        "lastupdated": "2021-04-25T16:11:04.680",
        "lockstate": "unlocked",
        "notification": "source:keypad,code:Unlock,pin:0",
        "pin": "\"3\":{\"id\":3,\"status\":1,\"type\":0,\"code\":1234}"
    }

Second time calling Get PIN from GUI
18:12:17:464 Door lock debug 0x680AE2FFFE6BB91F, command 0x06, payload 030001000431323334 18:12:17:465 Door lock debug : Json error 1

Smanar commented 3 years ago

Nice, thx. I think it will be ok now, can you remake the same test ?

Now you will have "pin": "{\"3\":{\"id\":3,\"status\":1,\"type\":0,\"code\":1234}}"

And one more debug line with the string escaped.

burken- commented 3 years ago

This is what I get now

First attempt from GUI 21:16:29:852 Door lock debug 0x680AE2FFFE6BB91F, command 0x06, payload 030001000431323334 21:16:29:852 [Door lock] - Read PIN command received, User ID: 3, code: 1234, Status: 1, Type 0 21:16:29:853 Door lock debug : data "3":{"id":3,"status":1,"type":0,"code":1234} 21:16:29:853 Door lock debug : Json error 1 21:16:29:854 Door lock error: illegal value at offset: 1 (in characters) 21:16:44:817 Door lock debug 0x680AE2FFFE6BB91F, command 0x0A, payload 00003002

Api response

    "state": {
        "doorstate": "closed",
        "lastupdated": "2021-04-25T19:16:44.818",
        "lockstate": "unlocked",
        "notification": "source:keypad,code:Unlock,pin:0",
        "pin": "{\"3\":{\"id\":3,\"status\":1,\"type\":0,\"code\":1234}}"
    }

Second attempt from GUI 21:18:05:674 Door lock debug 0x680AE2FFFE6BB91F, command 0x06, payload 030001000431323334 21:18:05:675 [Door lock] - Read PIN command received, User ID: 3, code: 1234, Status: 1, Type 0 21:18:05:676 Door lock debug : data {"3":{"id":3,"status":1,"type":0,"code":1234}} 21:18:05:676 [ERROR] - Door lock debug 3 >

Smanar commented 3 years ago

Ok so I have improved the code, It works on a "simulation code" but I have realy no clue how it will happen on real hardware. So now the "pin" will be an array of object. If the actual user ID is new it will be added on "pin" else the value is updated.

The "pin" value is still a string, so with escaped char.

Smanar commented 3 years ago

Ok so new changes the code (if it works) Now the "pin" visible in the API will be a dictionnary. Everytime you ask for a pin using the gui, it will be added to the json

Now need to ask how make a "clean" command to ask for PIN using the API.

zeiphon commented 3 years ago

Just a query here - shouldn't the "code" value be a string, since it isn't actually a single integer? e.g. if not a string, I suspect it would fail for codes beginning with zero: 0123 -> 123

Smanar commented 3 years ago

Good question, depend on request, it seem for this one the code value is numeric. But code is the code event, the real code is "pin".

Have modified the code to use "0000" format for pin

brientim commented 3 years ago

The pin code can be up to 8 characters and the lock can store 250 codes depending on the model.

Smanar commented 3 years ago

Ok, so I have take a look again in the documentation.

So the "code" is a 100% Qstring, and lenght can move, no problem, the code can handle it. But in the event notification

"notification": "source:keypad,code:Unlock,pin:0",

Code is a code event, and I was wrong, Pin is not the pin code, it s a numeric value < 255

7.3.2.17.27.4 PIN
The PIN that is associated with the User ID who performed the event.

I think it s from your 250 codes.

Smanar commented 3 years ago

If someone can test the last code ? Have added a command to Get pin.

/*! PUT, POST /api/<apikey>/sensors/<id>/state/pin
    \return REQ_READY_SEND
            REQ_NOT_HANDLED
 */

with body {"get":0}

Every new discover UserID will be added to the json.

burken- commented 3 years ago

I've tested the Get pin-command with the following result:

PUT /api/{apikey}/sensors/{id}/state/pin {"get":3}

[
    {
        "error": {
            "address": "/sensors/7/state/pin",
            "description": "method, PUT, not available for resource, /sensors/7/state/pin",
            "type": 4
        }
    }
]

And POST /api/{apikey}/sensors/{id}/state/pin {"get":3}

[
    {
        "error": {
            "address": "/sensors/7/state/pin",
            "description": "parametre problems",
            "type": 7
        }
    }
]

Debug log when calling api using POST (after already calling the api a couple of times before for other users)

21:06:44:628 Door lock debug 0x680AE2FFFE6BB91F, command  0x06, payload 030001000431323334
21:06:44:629 [Door lock] - Read PIN command received, User ID: 3, code: 1234, Status: 1, Type 0
21:06:44:629 Door lock debug : data [{"code":"XXXXXXXXXX","id":2,"status":1,"type":0},{"code":"XXXXXXXXXX","id":1,"status":1,"type":0},{"code":"1234","id":3,"status":1,"type":0}]

When calling /api/{apikey}/sensors/{id} it returns json with a pin-property containing an array of pin-objects (one for each user we have called the "POST ...state/pin" for)

    "state": {
        "doorstate": "closed",
        "lastupdated": "2021-04-30T19:11:59.026",
        "lockstate": "unlocked",
        "notification": "source:manual,code:Manual Unlock,pin:0",
        "pin": [
            {
                "code": "XXXXXXXXXX",
                "id": 2,
                "status": 1,
                "type": 0
            },
            {
                "code": "XXXXXXXXXX",
                "id": 1,
                "status": 1,
                "type": 0
            },
            {
                "code": "1234",
                "id": 3,
                "status": 1,
                "type": 0
            }
        ]
    }

From a REST point of view it would be cleaner if the call was actually a GET. E.g. /api/{apikey}/sensors/{sensorid}/state/pin/{userid}

And then in the future be able to use POST (or PUT) /api/{apikey}/sensors/{sensorid}/state/pin with body {"userid": X, "pin": "YYYYYY"} to set pin for user

And DELETE /api/{apikey}/sensors/{sensorid}/state/pin/{userid} to clear pin for user

Smanar commented 3 years ago

Right. Have updated the code again to be used with PUT, GET, DELETE and /api/{apikey}/sensors/{sensorid}/state/pin/{userid}

For the PUT the body need to be {"type": X, "status":Y, "code":"YYYYYY"}

burken- commented 3 years ago

I tried the latest code but I don't seem to manage to get through with these calls. Tried PUT and GET with the following results:

PUT /api/{apikey}/sensors/7/state/pin/3 Body: {"type": 0, "status":1, "code":"1234"}

Response:

[
    {
        "error": {
            "address": "/sensors/7/state/pin/3",
            "description": "method, PUT, not available for resource, /sensors/7/state/pin/3",
            "type": 4
        }
    }
]

GET /api/{apikey}/sensors/7/state/pin/3

Response:

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

Seems like it stops earlier on a generic "resource not found"-response.

Smanar commented 3 years ago

My bad have updated the code again, I think this one will work but not sure for the method

/api/{apikey}/sensors/{sensorid}/state/pin/{userid}

Is only for GET and DELETE

For the PUT the body need to be {"id":4,"type": X, "status":Y, "code":"YYYYYY"}

and the url only /api/{apikey}/sensors/{sensorid}/state/pin

But for me it s stupid, the json contain a list, so the url need to be only ...../state/pin, but not possible adding a body to a GET request.

That s not relay good, it s mix a "zigbee command" and "json command", IDK if it will be better to have a command to retreive the fulll list using json + 1 command to fill the json with making zigbee command, but the delete and the put command will be the same ....

burken- commented 3 years ago

I've tested GET, PUT and DELETE again. It partially works :)

PUT .../state/pin with body e.g. {"id":4,"type": 0, "status":1, "code":"1234"} Good: Creates/updates and updates a user successfully. No biggie: Gives 3-4 sound notifications from lock. When doing the same from GUI it notify once. Bad: Returns 400 Bad request with body:

[
    {
        "error": {
            "address": "/sensors/7/state/pin",
            "description": "parametre problems",
            "type": 7
        }
    }
]

DELETE .../state/pin/{userId} Same as for put, successfully deletes the user, gives too many sound notifications and returns 400 Bad request with same error message as for PUT

GET .../state/pin/{userId} Returns 404 Not found with message "resource, /sensors/7/state/pin/2, not available"

Smanar commented 3 years ago

Edit:

Have found a problem, can remake a try pls ?

burken- commented 3 years ago

PUT command now returns this. The trailing "7" seems to be the sensor id instead of the user id but apart from that all seems fine. Sometimes gives multiple sound notifications.

[
    {
        "success": "/sensors/7/state/pin put user 7"
    }
]

DELETE returns the following. Sometimes gives multiple sound notifications

[
    {
        "success": "/sensors/7/state/pin d user 7"
    }
]

GET still returns 404 Not found

Info logs when calling PUT and DELETE on two separate occations:

PUT command first attempt
22:20:19:024 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
22:20:19:032 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
22:20:20:999 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 0102030004313233340001FFFFFFFF0431323334
22:20:22:768 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 0004030004313233340001FFFFFFFF0431323334
22:20:24:535 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 0004030004313233340001FFFFFFFF0431323334

DELETE command first attempt
22:20:52:325 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
22:20:54:756 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 01030300000000FFFFFFFF00

PUT command second attempt
22:21:25:709 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
22:21:27:752 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 0102030004313233340001FFFFFFFF0431323334

DELETE command second attempt
22:21:59:106 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
22:22:01:191 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
22:22:01:505 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 01030300000000FFFFFFFF00
22:22:03:464 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 00030300000000FFFFFFFF00
22:22:05:414 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 00030300000000FFFFFFFF00
burken- commented 3 years ago

If someone wants to test the latest code I've created a bash-script to run from within a deconz container. It downloads necessary build-tools fetches a specified branch and compiles it: https://gist.github.com/burken-/1efef238e03483d5aa1f347b2415e4ee (Remember to make the file executable... chmod +x deconz-dev.sh)

I'm using the following setup: In the docker-compose definition I'm mounting my local dir to the deCONZ-folder (as usual). After performing a dev-build I uncomment the second volume definition to tell the container to use the newly built rest plugin instead of the default one.

    volumes:
      - ${DOCKER_BASE_DIR}/deconz:/root/.local/share/dresden-elektronik/deCONZ
     # - ${DOCKER_BASE_DIR}/deconz/libde_rest_plugin.so:/usr/share/deCONZ/plugins/libde_rest_plugin.so

In the main deCONZ-directory I create a new "dev" directory and place the bash-script there. Log in to the container console and execute the script.

Example to build the latest Doorlock-branch from Smanar.

/root/.local/share/dresden-elektronik/deCONZ/dev/deconz-dev.sh https://github.com/Smanar/deconz-rest-plugin.git doorlock_v2 ../../

Nice to have everything within the container so whenever you want to go back to the original branch you just have to remove the plugin-mount and restart the container and everything is back to normal again.

Smanar commented 3 years ago

Have corrected all your problems except the " multiple sound notifications." I realy don't understand why it happen with the api and not the GUI.

And you have sometime, 3 time the notifications.

22:22:01:505 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 01030300000000FFFFFFFF00
22:22:03:464 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 00030300000000FFFFFFFF00
22:22:05:414 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 00030300000000FFFFFFFF00

You don't see a difference in logs when using the API and the GUI ? (request can be visible in "aps" and "aps_l2" )

burken- commented 3 years ago

First and foremost, huge thanks for all the excellent work! Easy to forget to show my appreciation when reporting log results and such.

I'm not familiar with the aps-logs, anything I should look for in particular? I can see that when calling from the api GET/PUT/DELETE commands are triggred multiple times (sometimes, not always). When calling through the api it seems to repeat the command until the aps-logs shows a complete flow eg.

Clear PIN from GUI (runs once... not sure where to start and stop the logs):

21:25:02:815 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
21:25:03:785 APS-DATA.request id: 70, addrmode: 0x03, addr: 0x847127fffe77cbd1, profile: 0x0104, cluster: 0x0006, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
21:25:03:815 APS-DATA.confirm id: 70, status: 0x00 SUCCESS
21:25:03:815 APS-DATA.confirm request id: 70 -> erase from queue
21:25:03:829 APS-DATA.indication srcAddr: 0xa80d, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 207, rssi: -68

DELETE command from api (one call, multiple executed commands followed by multiple notifications):

21:13:49:737 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
21:13:49:791 APS-DATA.confirm id: 236, status: 0x00 SUCCESS
21:13:49:791 APS-DATA.confirm request id: 236 -> erase from queue
21:13:49:795 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -49
21:13:49:795    asdu: 195b0700
21:13:49:795 APS-DATA.request id: 236 erase from queue
21:13:49:795 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
21:13:49:799 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -49
21:13:49:799    asdu: 195b0700
21:13:49:799 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
21:13:50:785 APS-DATA.request id: 3, addrmode: 0x03, addr: 0x847127fffe77cbd1, profile: 0x0104, cluster: 0x0006, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
21:13:50:805 APS-DATA.confirm id: 3, status: 0x00 SUCCESS
21:13:50:805 APS-DATA.confirm request id: 3 -> erase from queue
21:13:50:817 aps request id: 3 finished, erase from queue
21:13:50:819 APS-DATA.indication srcAddr: 0xa80d, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 207, rssi: -68
Smanar commented 3 years ago

Missed ^^ On your first logs it s about a cluster 0x0006 (on/off) and not the same device

BTW can you make a try again with the last version ? I have enabled a defaut response. But it's strange, for me it will work better without it

burken- commented 3 years ago

Here are some (manually filtered) logs that should contain traffic for cluster 0x0101 only

SET PIN GUI

12:36:05:659 APS-DATA.request id: 227, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 12 tx.options 0x00
12:36:05:682 APS-DATA.confirm id: 227, status: 0x00 SUCCESS
12:36:05:683 APS-DATA.confirm request id: 227 -> erase from queue
12:36:05:740 aps request id: 227 finished, erase from queue
12:36:07:759 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:36:07:760 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
12:36:09:815 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:36:09:815 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 0102030004313233340001FFFFFFFF0431323334
12:36:09:816 APS-DATA.request id: 255, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
12:36:09:837 APS-DATA.confirm id: 255, status: 0x00 SUCCESS
12:36:09:837 APS-DATA.confirm request id: 255 -> erase from queue
12:36:09:890 aps request id: 255 finished, erase from queue

CLEAR PIN GUI

12:36:25:729 APS-DATA.request id: 94, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
12:36:25:745 APS-DATA.confirm id: 94, status: 0x00 SUCCESS
12:36:25:746 APS-DATA.confirm request id: 94 -> erase from queue
12:36:25:810 aps request id: 94 finished, erase from queue
12:36:25:978 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:36:25:984 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
12:36:28:418 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:36:28:419 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 01030300000000FFFFFFFF00
12:36:28:419 APS-DATA.request id: 111, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
12:36:28:439 APS-DATA.confirm id: 111, status: 0x00 SUCCESS
12:36:28:439 APS-DATA.confirm request id: 111 -> erase from queue
12:36:28:454 aps request id: 111 finished, erase from queue

SET PIN API

12:36:50:533 APS-DATA.request id: 239, addrmode: 0x03, addr: 0x680ae2fffe6bb91f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 13 tx.options 0x04
12:36:53:413 APS-DATA.confirm id: 239, status: 0x00 SUCCESS
12:36:53:414 APS-DATA.confirm request id: 239 -> erase from queue
12:36:53:428 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:36:53:430 APS-DATA.request id: 239 erase from queue
12:36:53:432 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
12:36:53:479 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:36:53:480 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
12:36:53:498 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:36:53:499 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
12:36:55:351 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:36:55:352 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 010203000531323334350001FFFFFFFF053132333435
12:36:55:352 APS-DATA.request id: 15, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
12:36:55:371 APS-DATA.confirm id: 15, status: 0x00 SUCCESS
12:36:55:371 APS-DATA.confirm request id: 15 -> erase from queue
12:36:55:410 aps request id: 15 finished, erase from queue
12:36:57:118 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:36:57:119 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 000403000531323334350001FFFFFFFF053132333435
12:36:57:119 APS-DATA.request id: 28, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
12:36:57:139 APS-DATA.confirm id: 28, status: 0x00 SUCCESS
12:36:57:139 APS-DATA.confirm request id: 28 -> erase from queue
12:36:57:170 aps request id: 28 finished, erase from queue
12:36:58:888 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:36:58:889 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 000403000531323334350001FFFFFFFF053132333435
12:36:58:889 APS-DATA.request id: 41, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
12:36:58:908 APS-DATA.confirm id: 41, status: 0x00 SUCCESS
12:36:58:908 APS-DATA.confirm request id: 41 -> erase from queue
12:36:58:929 aps request id: 41 finished, erase from queue
12:37:00:650 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:37:00:655 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 000403000531323334350001FFFFFFFF053132333435
12:37:00:656 APS-DATA.request id: 52, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
12:37:00:694 APS-DATA.confirm id: 52, status: 0x00 SUCCESS
12:37:00:695 APS-DATA.confirm request id: 52 -> erase from queue
12:37:00:770 aps request id: 52 finished, erase from queue

CLEAR PIN API (probably mixed up with attribute fetching)

12:37:20:377 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:37:20:378 Door lock debug 0x680AE2FFFE6BB91F, command  0x0A, payload 03003001
12:37:20:379 APS-DATA.request id: 167, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
12:37:20:379 [INFO] - No button map for: ID Lock 150, unicast to: 0x0000, endpoint: 0x01, cluster: DOOR_LOCK (0x0101), command: ATTRIBUTE_REPORT (0x0A), payload: 03003001, zclSeq: 54
12:37:20:379 ZCL attribute report 0x680AE2FFFE6BB91F for cluster: 0x0101, ep: 0x01, frame control: 0x08, mfcode: 0x0000 
12:37:20:379 APS-DATA.request id: 168, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 1 len: 5 tx.options 0x00
12:37:20:409 APS-DATA.confirm id: 167, status: 0x00 SUCCESS
12:37:20:410 APS-DATA.confirm request id: 167 -> erase from queue
12:37:20:421 APS-DATA.confirm id: 168, status: 0x00 SUCCESS
12:37:20:422 APS-DATA.confirm request id: 168 -> erase from queue
12:37:20:449 aps request id: 167 finished, erase from queue
12:37:20:529 aps request id: 168 finished, erase from queue
12:37:21:468 Bind response success for 0x680ae2fffe6bb91f ep: 0x01 cluster: 0x0101
12:37:21:468 APS-DATA.request id: 176, addrmode: 0x03, addr: 0x680ae2fffe6bb91f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 19 tx.options 0x04
12:37:21:472 Bind response success for 0x680ae2fffe6bb91f ep: 0x01 cluster: 0x0101
12:37:21:472 APS-DATA.request id: 178, addrmode: 0x03, addr: 0x680ae2fffe6bb91f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 1 len: 19 tx.options 0x04
12:37:22:514 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:37:22:519 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
12:37:22:520 APS-DATA.request id: 191, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 3 len: 5 tx.options 0x00
12:37:22:521 APS-DATA.request id: 192, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 4 len: 5 tx.options 0x00
12:37:22:554 APS-DATA.confirm id: 176, status: 0x00 SUCCESS
12:37:22:554 APS-DATA.confirm request id: 176 -> erase from queue
12:37:22:581 APS-DATA.confirm id: 178, status: 0x00 SUCCESS
12:37:22:581 APS-DATA.confirm request id: 178 -> erase from queue
12:37:22:584 APS-DATA.confirm id: 191, status: 0x00 SUCCESS
12:37:22:585 APS-DATA.confirm request id: 191 -> erase from queue
12:37:22:588 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:37:22:588 APS-DATA.request id: 176 erase from queue
12:37:22:588 APS-DATA.request id: 178 erase from queue
12:37:22:588 APS-DATA.request id: 191 erase from queue
12:37:22:589 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
12:37:22:589 APS-DATA.request id: 194, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 2 len: 5 tx.options 0x00
12:37:22:589 APS-DATA.request id: 195, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 3 len: 5 tx.options 0x00
12:37:22:589 ZCL configure reporting rsp seq: 60 0x680AE2FFFE6BB91F for ep: 0x01 cluster: 0x0101 attr: 0x0000 status: 0x00
12:37:22:590 ZCL configure reporting rsp seq: 60 0x680AE2FFFE6BB91F for ep: 0x01 cluster: 0x0101 attr: 0x0003 status: 0x00
12:37:22:611 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:37:22:612 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
12:37:22:612 APS-DATA.request id: 197, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 4 len: 5 tx.options 0x00
12:37:22:612 reject aps request to enddevice node queue is full (4)
12:37:22:641 APS-DATA.confirm id: 192, status: 0x00 SUCCESS
12:37:22:641 APS-DATA.confirm request id: 192 -> erase from queue
12:37:22:672 APS-DATA.confirm id: 194, status: 0x00 SUCCESS
12:37:22:672 APS-DATA.confirm request id: 194 -> erase from queue
12:37:22:690 aps request id: 192 finished, erase from queue
12:37:22:702 APS-DATA.confirm id: 195, status: 0x00 SUCCESS
12:37:22:702 APS-DATA.confirm request id: 195 -> erase from queue
12:37:22:706 APS-DATA.confirm id: 197, status: 0x00 SUCCESS
12:37:22:706 APS-DATA.confirm request id: 197 -> erase from queue
12:37:22:769 aps request id: 194 finished, erase from queue
12:37:22:850 aps request id: 195 finished, erase from queue
12:37:22:930 aps request id: 197 finished, erase from queue
12:37:32:923 APS-DATA.request id: 4, addrmode: 0x03, addr: 0x680ae2fffe6bb91f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x04
12:37:35:636 APS-DATA.confirm id: 4, status: 0x00 SUCCESS
12:37:35:637 APS-DATA.confirm request id: 4 -> erase from queue
12:37:35:646 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:37:35:647 APS-DATA.request id: 4 erase from queue
12:37:35:648 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
12:37:35:697 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:37:35:698 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
12:37:35:702 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:37:35:703 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
12:37:37:993 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:37:37:997 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 01030300000000FFFFFFFF00
12:37:37:998 APS-DATA.request id: 36, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
12:37:38:020 APS-DATA.confirm id: 36, status: 0x00 SUCCESS
12:37:38:020 APS-DATA.confirm request id: 36 -> erase from queue
12:37:38:050 aps request id: 36 finished, erase from queue
12:37:39:950 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:37:39:950 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 00030300000000FFFFFFFF00
12:37:39:951 APS-DATA.request id: 50, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
12:37:39:970 APS-DATA.confirm id: 50, status: 0x00 SUCCESS
12:37:39:970 APS-DATA.confirm request id: 50 -> erase from queue
12:37:39:970 aps request id: 50 finished, erase from queue
12:37:41:906 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:37:41:906 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 00030300000000FFFFFFFF00
12:37:41:907 APS-DATA.request id: 63, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
12:37:41:927 APS-DATA.confirm id: 63, status: 0x00 SUCCESS
12:37:41:927 APS-DATA.confirm request id: 63 -> erase from queue
12:37:41:970 aps request id: 63 finished, erase from queue
12:37:43:865 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:37:43:865 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 00030300000000FFFFFFFF00
12:37:43:866 APS-DATA.request id: 77, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
12:37:43:885 APS-DATA.confirm id: 77, status: 0x00 SUCCESS
12:37:43:885 APS-DATA.confirm request id: 77 -> erase from queue
12:37:43:896 aps request id: 77 finished, erase from queue
12:37:45:821 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52
12:37:45:822 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 00030300000000FFFFFFFF00
12:37:45:822 APS-DATA.request id: 89, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
12:37:45:841 APS-DATA.confirm id: 89, status: 0x00 SUCCESS
12:37:45:841 APS-DATA.confirm request id: 89 -> erase from queue
12:37:45:890 aps request id: 89 finished, erase from queue
Smanar commented 3 years ago

Ok so new experimental code to test, I have modified the code to mimic same request

GUI > APS-DATA.request id: 227, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 12 tx.options 0x00 API > APS-DATA.request id: 239, addrmode: 0x03, addr: 0x680ae2fffe6bb91f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 13 tx.options 0x04

But it s totaly experimental no logic in that ...

Another thing not logic

GUI > 12:36:09:815 Door lock debug 0x680AE2FFFE6BB91F, command 0x21, payload 0102030004313233340001FFFFFFFF0431323334 API > 12:36:55:352 Door lock debug 0x680AE2FFFE6BB91F, command 0x21, payload 010203000531323334350001FFFFFFFF053132333435

Why the payload are not the same ?

                01 02 0300 05 31 32 33343500 01FFFFFFFF 05 31 32 33 34 35
                01 02 0300 04 31 32 33340001   FFFFFFFF 04 31 32 33 34

It s like you have used "1234" on one and "12345" on the other, but the synthax is not logic. From the doc we need to have

tmp

burken- commented 3 years ago

You're right, I was rotating pin codes when setting just to make sure it actually got set, that is why one was 1234 and the other one 12345. For the ID Lock 150 the pin length is between 4-10 characters long. The return syntax seems to be Octet 5 = nr. of characters in pin code Octet 6 - 6 + nr. of characters in pin code = pin code Followed by 0001FFFFFFFF And then repeated again nr. of characters in pin followed by actual pin

It doesn't seem to follow the protocol at all

1234
01 02 0300 04 31 32 33 34 0001FFFFFFFF 04 31 32 33 34

12345
01 02 0300 05 31 32 33 34 35 0001FFFFFFFF 05 31 32 33 34 35

123456
01 02 0300 06 31 32 33 34 35 36 0001FFFFFFFF 06 31 32 33 34 35 36

1234567
01 04 0300 07 31 32 33 34 35 36 37 0001FFFFFFFF 07 31 32 33 34 35 36 37

12345678
01 04 0300 08 31 32 33 34 35 36 37 38 0001FFFFFFFF 08 31 32 33 34 35 36 37 38

123456789
01 04 0300 09 31 32 33 34 35 36 37 38 39 0001FFFFFFFF 09 31 32 33 34 35 36 37 38 39

1234567890
01 04 0300 0A 31 32 33 34 35 36 37 38 39 30 0001FFFFFFFF 0A 31 32 33 34 35 36 37 38 39 30

9999999999
01 04 0300 0A 39 39 39 39 39 39 39 39 39 39 0001FFFFFFFF 0A 39 39 39 39 39 39 39 39 39 39

When testing the latest code the SET and CLEAR PIN-commands doesn't work any more. This is what the logs shows when setting pin 12345 for user 3 from both the GUI and API as well as CLEAR-ing the same user:

SET PIN GUI

20:47:30:973 APS-DATA.request id: 252, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 13 tx.options 0x00
20:47:32:886 APS-DATA.confirm id: 252, status: 0x00 SUCCESS
20:47:32:886 APS-DATA.confirm request id: 252 -> erase from queue
20:47:32:898 aps request id: 252 finished, erase from queue
20:47:33:922 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 103, rssi: -81
20:47:33:922    asdu: 190e0500
20:47:33:923 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
20:47:33:923 [Door lock] - Set PIN command received, Status: 0
20:47:35:945 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 103, rssi: -81
20:47:35:945    asdu: 097d21010203000531323334350001ffffffff053132333435
20:47:35:946 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 010203000531323334350001FFFFFFFF053132333435
20:47:35:946 APS-DATA.request id: 21, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
20:47:36:960 APS-DATA.confirm id: 21, status: 0x00 SUCCESS
20:47:36:960 APS-DATA.confirm request id: 21 -> erase from queue
20:47:36:978 aps request id: 21 finished, erase from queue

CLEAR PIN GUI

20:48:09:460 APS-DATA.request id: 166, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
20:48:12:326 APS-DATA.confirm id: 166, status: 0x00 SUCCESS
20:48:12:326 APS-DATA.confirm request id: 166 -> erase from queue
20:48:12:338 aps request id: 166 finished, erase from queue
20:48:13:355 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 103, rssi: -81
20:48:13:355    asdu: 19150700
20:48:13:356 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
20:48:13:356 [Door lock] - Clear PIN command received, Status: 0
20:48:15:376 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 103, rssi: -81
20:48:15:376    asdu: 097f2101030300000000ffffffff00
20:48:15:377 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 01030300000000FFFFFFFF00
20:48:15:377 APS-DATA.request id: 195, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
20:48:16:386 APS-DATA.confirm id: 195, status: 0x00 SUCCESS
20:48:16:386 APS-DATA.confirm request id: 195 -> erase from queue
20:48:16:418 aps request id: 195 finished, erase from queue

SET PIN API

20:49:12:392 APS-DATA.request id: 188, addrmode: 0x02, addr: 0x0000, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 13 tx.options 0x00
20:49:12:404 APS-DATA.confirm id: 188, status: 0x00 SUCCESS
20:49:12:404 APS-DATA.confirm request id: 188 -> erase from queue
20:49:12:421 aps request id: 188 finished, erase from queue
20:49:12:421 APS-DATA.indication srcAddr: 0x0000, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 117, rssi: 32
20:49:12:421    asdu: 11010503000100053132333435
20:49:12:421 Door lock debug 0x00212EFFFF05AEB4, command  0x05, payload 03000100053132333435

CLEAR PIN API

20:50:07:080 APS-DATA.request id: 173, addrmode: 0x02, addr: 0x0000, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
20:50:07:093 APS-DATA.confirm id: 173, status: 0x00 SUCCESS
20:50:07:093 APS-DATA.confirm request id: 173 -> erase from queue
20:50:07:109 APS-DATA.indication srcAddr: 0x0000, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 117, rssi: 32
20:50:07:109    asdu: 1102070300
20:50:07:109 APS-DATA.request id: 173 erase from queue
20:50:07:110 Door lock debug 0x00212EFFFF05AEB4, command  0x07, payload 0300
Smanar commented 3 years ago

It doesn't seem to follow the protocol at all

Ok, that help a lot .... At least with your try, we have the good parsing.

GUI > APS-DATA.request id: 252, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 13 tx.options 0x00 API > APS-DATA.request id: 188, addrmode: 0x02, addr: 0x0000, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 13 tx.options 0x00

Not so bad. but after taking a look on the code again all seem fine, will ask to other devs. I have removed the last modification for the moment because if he have time there is another users with doorlock and sniffer that can compare request (on zigbee side)

Smanar commented 3 years ago

Ok, so no information about the sniff yet.

But after looking logs when doing with api

12:36:50:533 APS-DATA.request id: 239, addrmode: 0x03, addr: 0x680ae2fffe6bb91f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 13 tx.options 0x04

12:36:53:413 APS-DATA.confirm id: 239, status: 0x00 SUCCESS 12:36:53:414 APS-DATA.confirm request id: 239 -> erase from queue 12:36:53:430 APS-DATA.request id: 239 erase from queue

12:36:53:428 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52 12:36:53:432 Door lock debug 0x680AE2FFFE6BB91F, command 0x05, payload 00

12:36:53:479 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52 12:36:53:480 Door lock debug 0x680AE2FFFE6BB91F, command 0x05, payload 00 12:36:53:498 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52 12:36:53:499 Door lock debug 0x680AE2FFFE6BB91F, command 0x05, payload 00 12:36:55:351 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -52

All the part in bold is like if the device haven't receive a confirmation and redoing the request to have an answer.

On rest_sensor.cpp around line 2654 Can you try to use this code

    // To test
    task.req.setTxOptions(0);
    task.req.setDstAddressMode(deCONZ::ApsNwkAddress);
    //task.req.dstAddress().setNwk(sensor->address().nwk());

And if you still have

API > APS-DATA.request id: 188, addrmode: 0x02, addr: 0x0000, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 13 tx.options 0x00

Comment too the line task.req.setDstAddressMode(deCONZ::ApsNwkAddress);

burken- commented 3 years ago

After compiling the latest code I get a Segmentation fault (core dumped) message in my logs and deconz won't start.

Do I understand you correctly that test 1:

    // To test
    task.req.setTxOptions(0);
    task.req.setDstAddressMode(deCONZ::ApsNwkAddress);
    //task.req.dstAddress().setNwk(sensor->address().nwk());

If addr: 0x0000 then try code:

    // To test
    task.req.setTxOptions(0);
    //task.req.setDstAddressMode(deCONZ::ApsNwkAddress);
    //task.req.dstAddress().setNwk(sensor->address().nwk());

And check again if the addr-value gets set

?

Smanar commented 3 years ago

Have just updated the code to last version from official.

After compiling the latest code I get a Segmentation fault (core dumped) message in my logs and deconz won't start

Try with

cd deconz-rest-plugin
make clean
qmake && make -j2
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins

If you still have segmentation fault, I need to check the code, but last changes was just thoses 3 lines, or your last tests was older ?

And check again if the addr-value gets set

I think it s better to check if your device still react 3 times, for me the device need to work even if deconz use 0x680ae2fffe6bb91f instead of 0x220f

burken- commented 3 years ago

Ok, I've tried three different scenarios now.

  1. Original code from your repo
  2. Uncommented these rows, compiled and tested again task.req.setTxOptions(0); task.req.setDstAddressMode(deCONZ::ApsNwkAddress);
  3. Commented task.req.setDstAddressMode(deCONZ::ApsNwkAddress); so that only task.req.setTxOptions(0); was uncommented. Compiled and tested again.

Result from test 1 - Got multiple replies:

08:48:53:647 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:48:53:647    asdu: 19570500
08:48:53:647 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
08:48:53:647 [Door lock] - Set PIN command received, Status: 0
08:48:53:673 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:48:53:673    asdu: 19570500
08:48:53:673 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
08:48:53:673 [Door lock] - Set PIN command received, Status: 0
08:48:55:653 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:48:55:653    asdu: 096621010403000531323334350001ffffffff053132333435
08:48:55:653 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 010403000531323334350001FFFFFFFF053132333435
08:48:55:653 APS-DATA.request id: 232, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
08:48:55:674 APS-DATA.confirm id: 232, status: 0x00 SUCCESS
08:48:55:674 APS-DATA.confirm request id: 232 -> erase from queue
08:48:55:754 aps request id: 232 finished, erase from queue
08:48:57:421 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:48:57:421    asdu: 096721000403000531323334350001ffffffff053132333435
08:48:57:422 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 000403000531323334350001FFFFFFFF053132333435
08:48:57:422 APS-DATA.request id: 245, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
08:48:57:461 APS-DATA.confirm id: 245, status: 0x00 SUCCESS
08:48:57:461 APS-DATA.confirm request id: 245 -> erase from queue
08:48:57:514 aps request id: 245 finished, erase from queue
08:48:59:183 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:48:59:184    asdu: 096821000403000531323334350001ffffffff053132333435
08:48:59:187 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 000403000531323334350001FFFFFFFF053132333435
08:48:59:187 APS-DATA.request id: 0, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
08:48:59:214 APS-DATA.confirm id: 0, status: 0x00 SUCCESS
08:48:59:214 APS-DATA.confirm request id: 0 -> erase from queue
08:48:59:274 aps request id: 0 finished, erase from queue

Result from test 2 - didn't work at all:

Call 1
08:53:57:280 APS-DATA.request id: 62, addrmode: 0x02, addr: 0x0000, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 1 len: 14 tx.options 0x00
08:53:57:287 APS-DATA.confirm id: 62, status: 0x00 SUCCESS
08:53:57:287 APS-DATA.confirm request id: 62 -> erase from queue
08:53:57:291 APS-DATA.indication srcAddr: 0x0000, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:53:57:291    asdu: 1144050300010006313233343536
08:53:57:291 APS-DATA.request id: 62 erase from queue
08:53:57:291 Door lock debug 0x00212EFFFF05AEB4, command  0x05, payload 0300010006313233343536

Call 2
08:54:18:813 APS-DATA.request id: 214, addrmode: 0x02, addr: 0x0000, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 15 tx.options 0x00
08:54:18:822 APS-DATA.confirm id: 214, status: 0x00 SUCCESS
08:54:18:823 APS-DATA.confirm request id: 214 -> erase from queue
08:54:18:828 APS-DATA.indication srcAddr: 0x0000, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 239, rssi: -64
08:54:18:829    asdu: 115105030001000731323334353637
08:54:18:830 APS-DATA.request id: 214 erase from queue
08:54:18:831 Door lock debug 0x00212EFFFF05AEB4, command  0x05, payload 030001000731323334353637

Result from test 3, tried multiple times, most worked fine but sometimes I still got multiple replies:

Call 1 - Fine
08:56:49:581 APS-DATA.request id: 22, addrmode: 0x03, addr: 0x680ae2fffe6bb91f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 1 len: 14 tx.options 0x00
08:56:49:604 APS-DATA.confirm id: 22, status: 0x00 SUCCESS
08:56:49:604 APS-DATA.confirm request id: 22 -> erase from queue
08:56:49:682 aps request id: 22 finished, erase from queue
08:56:52:256 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -62
08:56:52:257    asdu: 19810500
08:56:52:257 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
08:56:52:257 [Door lock] - Set PIN command received, Status: 0
08:56:54:302 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:56:54:302    asdu: 096d2101040300063132333435360001ffffffff06313233343536
08:56:54:303 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 01040300063132333435360001FFFFFFFF06313233343536
08:56:54:304 APS-DATA.request id: 54, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 1 len: 5 tx.options 0x00
08:56:54:330 APS-DATA.confirm id: 54, status: 0x00 SUCCESS
08:56:54:330 APS-DATA.confirm request id: 54 -> erase from queue
08:56:54:401 aps request id: 54 finished, erase from queue

Call 2 - Fine
08:57:08:940 APS-DATA.request id: 143, addrmode: 0x03, addr: 0x680ae2fffe6bb91f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 15 tx.options 0x00
08:57:08:991 APS-DATA.confirm id: 143, status: 0x00 SUCCESS
08:57:08:991 APS-DATA.confirm request id: 143 -> erase from queue
08:57:09:042 aps request id: 143 finished, erase from queue
08:57:09:488 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:57:09:489    asdu: 198d0500
08:57:09:490 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
08:57:09:490 [Door lock] - Set PIN command received, Status: 0
08:57:11:532 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -62
08:57:11:533    asdu: 096f210104030007313233343536370001ffffffff0731323334353637
08:57:11:533 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 0104030007313233343536370001FFFFFFFF0731323334353637
08:57:11:533 APS-DATA.request id: 161, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
08:57:11:553 APS-DATA.confirm id: 161, status: 0x00 SUCCESS
08:57:11:554 APS-DATA.confirm request id: 161 -> erase from queue
08:57:11:615 aps request id: 161 finished, erase from queue

Call 3 - Multiple replies, might been some interferance from attribute reads?
08:57:20:601 APS-DATA.request id: 212, addrmode: 0x03, addr: 0x680ae2fffe6bb91f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 12 tx.options 0x00
08:57:20:622 APS-DATA.confirm id: 212, status: 0x00 SUCCESS
08:57:20:622 APS-DATA.confirm request id: 212 -> erase from queue
08:57:20:649 aps request id: 212 finished, erase from queue
08:57:21:699 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:57:21:699    asdu: 19930500
08:57:21:700 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
08:57:21:700 [Door lock] - Set PIN command received, Status: 0
08:57:22:406 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:57:22:406    asdu: 08710a03003001
08:57:22:407 Door lock debug 0x680AE2FFFE6BB91F, command  0x0A, payload 03003001
08:57:22:407 APS-DATA.request id: 226, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
08:57:22:407 [INFO] - No button map for: ID Lock 150, unicast to: 0x0000, endpoint: 0x01, cluster: DOOR_LOCK (0x0101), command: ATTRIBUTE_REPORT (0x0A), payload: 03003001, zclSeq: 113
08:57:22:407 ZCL attribute report 0x680AE2FFFE6BB91F for cluster: 0x0101, ep: 0x01, frame control: 0x08, mfcode: 0x0000 
08:57:22:407 APS-DATA.request id: 227, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 1 len: 5 tx.options 0x00
08:57:22:436 APS-DATA.confirm id: 226, status: 0x00 SUCCESS
08:57:22:436 APS-DATA.confirm request id: 226 -> erase from queue
08:57:22:457 APS-DATA.confirm id: 227, status: 0x00 SUCCESS
08:57:22:457 APS-DATA.confirm request id: 227 -> erase from queue
08:57:22:481 aps request id: 226 finished, erase from queue
08:57:22:562 aps request id: 227 finished, erase from queue
08:57:22:733 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:57:22:733    asdu: 19930500
08:57:22:734 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
08:57:22:734 [Door lock] - Set PIN command received, Status: 0
08:57:23:697 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -62
08:57:23:698    asdu: 0973210104030004313233340001ffffffff0431323334
08:57:23:698 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 0104030004313233340001FFFFFFFF0431323334
08:57:23:698 APS-DATA.request id: 237, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
08:57:23:718 APS-DATA.confirm id: 237, status: 0x00 SUCCESS
08:57:23:718 APS-DATA.confirm request id: 237 -> erase from queue
08:57:23:762 aps request id: 237 finished, erase from queue
08:57:25:456 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:57:25:457    asdu: 0974210004030004313233340001ffffffff0431323334
08:57:25:458 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 0004030004313233340001FFFFFFFF0431323334
08:57:25:459 APS-DATA.request id: 250, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
08:57:25:484 APS-DATA.confirm id: 250, status: 0x00 SUCCESS
08:57:25:485 APS-DATA.confirm request id: 250 -> erase from queue
08:57:25:550 aps request id: 250 finished, erase from queue

Call 4 - Fine
08:57:33:706 APS-DATA.request id: 42, addrmode: 0x03, addr: 0x680ae2fffe6bb91f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 13 tx.options 0x00
08:57:33:729 APS-DATA.confirm id: 42, status: 0x00 SUCCESS
08:57:33:729 APS-DATA.confirm request id: 42 -> erase from queue
08:57:33:790 aps request id: 42 finished, erase from queue
08:57:34:808 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:57:34:809    asdu: 199b0500
08:57:34:810 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
08:57:34:810 [Door lock] - Set PIN command received, Status: 0
08:57:38:367 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:57:38:368    asdu: 097621010403000531323334350001ffffffff053132333435
08:57:38:369 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 010403000531323334350001FFFFFFFF053132333435
08:57:38:369 APS-DATA.request id: 70, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
08:57:38:396 APS-DATA.confirm id: 70, status: 0x00 SUCCESS
08:57:38:396 APS-DATA.confirm request id: 70 -> erase from queue
08:57:38:443 aps request id: 70 finished, erase from queue

Call 5 - Fine
08:57:48:344 APS-DATA.request id: 129, addrmode: 0x03, addr: 0x680ae2fffe6bb91f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 15 tx.options 0x00
08:57:48:366 APS-DATA.confirm id: 129, status: 0x00 SUCCESS
08:57:48:367 APS-DATA.confirm request id: 129 -> erase from queue
08:57:48:433 aps request id: 129 finished, erase from queue
08:57:50:525 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -59
08:57:50:525    asdu: 19a30500
08:57:50:525 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
08:57:50:525 [Door lock] - Set PIN command received, Status: 0
08:57:52:573 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:57:52:573    asdu: 0978210104030007313233343536370001ffffffff0731323334353637
08:57:52:573 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 0104030007313233343536370001FFFFFFFF0731323334353637
08:57:52:573 APS-DATA.request id: 155, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
08:57:52:594 APS-DATA.confirm id: 155, status: 0x00 SUCCESS
08:57:52:594 APS-DATA.confirm request id: 155 -> erase from queue
08:57:52:642 aps request id: 155 finished, erase from queue

Call 6 (tested delete command also)
08:58:09:058 APS-DATA.request id: 14, addrmode: 0x03, addr: 0x680ae2fffe6bb91f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
08:58:09:076 APS-DATA.confirm id: 14, status: 0x00 SUCCESS
08:58:09:076 APS-DATA.confirm request id: 14 -> erase from queue
08:58:09:122 aps request id: 14 finished, erase from queue
08:58:11:759 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:58:11:759    asdu: 19b10700
08:58:11:759 Door lock debug 0x680AE2FFFE6BB91F, command  0x07, payload 00
08:58:11:759 [Door lock] - Clear PIN command received, Status: 0
08:58:14:190 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:58:14:191    asdu: 097a2101030300000000ffffffff00
08:58:14:192 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 01030300000000FFFFFFFF00
08:58:14:192 APS-DATA.request id: 45, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
08:58:14:212 APS-DATA.confirm id: 45, status: 0x00 SUCCESS
08:58:14:212 APS-DATA.confirm request id: 45 -> erase from queue
08:58:14:264 aps request id: 45 finished, erase from queue
08:58:16:180 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:58:16:180    asdu: 097b2100030300000000ffffffff00
08:58:16:180 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 00030300000000FFFFFFFF00
08:58:16:180 APS-DATA.request id: 59, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
08:58:16:202 APS-DATA.confirm id: 59, status: 0x00 SUCCESS
08:58:16:202 APS-DATA.confirm request id: 59 -> erase from queue
08:58:16:242 aps request id: 59 finished, erase from queue

Call 7 - Fine
08:58:26:471 APS-DATA.request id: 119, addrmode: 0x03, addr: 0x680ae2fffe6bb91f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 15 tx.options 0x00
08:58:26:494 APS-DATA.confirm id: 119, status: 0x00 SUCCESS
08:58:26:495 APS-DATA.confirm request id: 119 -> erase from queue
08:58:26:562 aps request id: 119 finished, erase from queue
08:58:28:959 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:58:28:960    asdu: 19ba0500
08:58:28:961 Door lock debug 0x680AE2FFFE6BB91F, command  0x05, payload 00
08:58:28:961 [Door lock] - Set PIN command received, Status: 0
08:58:31:005 APS-DATA.indication srcAddr: 0x220f, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -61
08:58:31:006    asdu: 097d210102030007313233343536370001ffffffff0731323334353637
08:58:31:007 Door lock debug 0x680AE2FFFE6BB91F, command  0x21, payload 0102030007313233343536370001FFFFFFFF0731323334353637
08:58:31:007 APS-DATA.request id: 149, addrmode: 0x02, addr: 0x220f, profile: 0x0104, cluster: 0x0101, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00
08:58:31:025 APS-DATA.confirm id: 149, status: 0x00 SUCCESS
08:58:31:026 APS-DATA.confirm request id: 149 -> erase from queue
08:58:31:089 aps request id: 149 finished, erase from queue
Smanar commented 3 years ago

So I have some answer from manup, it s a little complicated for me, so I will just put the c/c, it s about the setTxOptions() command

This enables APS ACKs for unicast transmissions through the full routing path. If a device doesn't acknowledge an request the request is sent again. This is more heavy weight as without and should be done carefully especially for end-devices

It depends on a few the factors, requests can only be send to end-devices when they are awake, if the door lock isn't awake or doesn't MAC poll the parent nothing can be send to it. The coordinator will happily try to send via router where the request is queued (for ca. 7.6 seconds) until it is thrown away by the router, since no ACK is received in the mean time the coordinator retries 3 times.

So the tricky part is to know when a device is actually awake, the new Device code has a mechanism to deal with this.

So for the moment, have modified the code to use setTxOptions(0x00);

And if all is working on your side, will be next doorlock PR.

burken- commented 3 years ago

When using setTxOptions(0x00) code seems to work for me when testing. (latest commit from your branch)

I was playing around with the code a bit and tried to hard code the network-value to see if everything was working that way also... to see if I could get the command to match the one sent when using the GUI. Example:

task.req.setDstAddressMode(deCONZ::ApsNwkAddress);
task.req.dstAddress().setNwk(0x220f);

This worked and gave basically the same log output as when calling from the GUI. But when looking at the sensor loaded from getSensorNodeForId(id) I couldn't get the nwk-value (instead it shows 0x0000). Do you have any idea why that is? Shouldn't sensor address contain a value for nwk... perhaps it doesn't matter and task.req.setDstAddressMode(deCONZ::ApsExtAddress); + Ext-address gives the same result.

Smanar commented 3 years ago

shouldn't sensor address contain a value for nwk

Yes, it should, manup have no idea for that, can be a problem in deconz core, but he recommend to use task.req.setDstAddressMode(deCONZ::ApsExtAddress); + Ext-address method, and for the moment like you said it seem to give the same result.

I have something to ask you, I can make the PR now, but I would like to clean the code a little, I want to put all the doorlock code in the doorlock.cpp file, but I can break all the code like that.

Could you make a last test in some hours (need to move the code yet) to be sure all features are still working ?

burken- commented 3 years ago

I'll be away all day today but I can test the code tonight to check if anything is broken.

Smanar commented 3 years ago

Perfect, thx. Have push the new code, always same branch.

burken- commented 3 years ago

I have tested to SET, GET and DELETE pin-codes from the API on the latest code from the _doorlockv2-branch and all works fine. Good work

Smanar commented 3 years ago

And state/lockstate and state/doorstate are still working ?

burken- commented 3 years ago

Yup, doorstate and lockstate are still working