dresden-elektronik / deconz-rest-plugin

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

EasyAccess EasyCodeTouch #4253

Closed stolevegen closed 3 years ago

stolevegen commented 3 years ago

Device

Screenshots

OTAU CLUSTER DOORLOCK CLUSTER 2 DOORLOCK CLUSTER GROUP CLUSTER 2 SCENES CLUSTER 3 SCENES CLUSTER 2 SCENES CLUSTER IDENTIFY CLUSTER POWER CONFIGURATION CLUSTER BASIC CLUSTER DOORLOCK ATTRIBUTES NODE INFO EASYCODETOUCH ENDPOINTS EASYCODETOUCH
stolevegen commented 3 years ago

But something strange is the reporting

report attributes doorlock to coordinator

This was before I straightened out the bent pin. The problem with door lock status was not firm/software, but actually hardware related. After I straightened the pin so it made contact, I get door lock status.

How it can be possible ?

See attached picture and explanation above.

Screenshot 2021-03-11 at 16 13 02 Screenshot 2021-03-11 at 16 12 52

The "problem" is that after unlocking it auto locks after about 7 seconds. And maybe I'm wrong, but could that be the reason that this happens :

  1. Unlock command == Success
  2. Door physically unlocks
  3. Unknown command (0x20)
  4. about 7 seconds delay
  5. Door physically locks
  6. Unlock door response == Failure (because door automatically locked after x seconds)

And could perhaps this be solved by disabling attribute 0x0023 (AutoRelockTime)? Or could this be configured as a switch so you could choose between AutoRelockTime enabled/disabled?

Smanar commented 3 years ago

You can change this setting using deconz ? But his attribute is not the same on the GUI .... <attribute id="0x0021" name="Auto Relock Time" type="u32" default="0" access="rw" required="o"></attribute>

So you have no more the "strange cycle" ?

Unlock command == Success
Door physically unlocks
Unknown command (0x20)
about 7 seconds delay
Door physically locks
Unlock door response == Failure (because door automatically locked after x seconds)

But the step 6 is strange, I can understand you have a reporting with different status, but why a "Unlock door response" ? this response need to be preceded (immediately) by a "Unlock request", you can compare the sequence number too.

stolevegen commented 3 years ago

So you have no more the "strange cycle" ?

No, all good now. Must have been the bent pin.

You can change this setting using deconz ? But his attribute is not the same on the GUI...attribute id="0x0021"

Should it not be 0x0023?

I added AutoRelockTime attribute and SoundVolume attribute to general.xml. After reboot I can write to AutoRelockTime, but once I read attributes (using read button on top left of attributes box) the AutoRelockTime attribute greys out. The SoundVolume attribute is still active.

Writing 0 to AutoRelockTime(just after reboot, before read attributes) disables auto lock, writing 1 enables. Writing 2 to SoundVolume sets volume high, writing 1 sets volume low, and writing 0 sets volume off.

I added a REST sensor to Home Assistant, and although a bit delayed, it updates the lock state correctly.

Screenshot 2021-03-12 at 10 21 29

Just after reboot :

Screenshot 2021-03-12 at 09 36 05

After "read" :

Screenshot 2021-03-12 at 09 37 48

But the step 6 is strange, I can understand you have a reporting with different status, but why a "Unlock door response" ?>this response need to be preceded (immediately) by a "Unlock request", you can compare the sequence number too.

I will run the sniffer again

Smanar commented 3 years ago

Should it not be 0x0023?

0x0023 AutoRelockTime uint32 Read*Write Reportable 0 O

You are right, Need to correct the PR, sorry.

I will run the sniffer again

But I think deconz will ignore the "Unlock door response" and take care only at the attribute return, so can work.

stolevegen commented 3 years ago

Would lock action (and relocktime) need to be configured as a light resource?

Smanar commented 3 years ago

No light ressource created for door lock device now, all is in the ZHADoorlock sensor. Relocktime is not in code yet, another user have asked for PIN management first.

stolevegen commented 3 years ago

@Smanar

Ran another sniff. This time I opened first with key, which I believe should report 0x09 when unlocked and 0x08 when locked. Then with code panel.

First Bind Request --> Bind Request Response : Success --> Configure reporting --> Reporting response

Bind request (2)


Bind response success (2)


Configure reporting plus reporting response

Then when I unlock with key the following is sniffed in order ;

Then when opening with code panel there is ;

Skjermbilde (209)

Bind requests ;

Skjermbilde (210)

Smanar commented 3 years ago

All seem normal, you are trying to do something special ? I hope bind request stop after a moment (trying during 5s, can be normal for me with lazy device) But what are the unknow command ? It s a leak in wireshark ? If the device is realy "standard" as they said the manufacture, why there is unknow command ?

stolevegen commented 3 years ago

I've been trying to edit general.xml to see if I could get any Operation Notification Response, but haven't been successful. In the manual it only states it's "partially supported"

Source: 0x00 KeyPad: If the user uses the code panel. 0x02 Manual: If the user used a key, button or fingerprint. 0x03 RFID: If the user used an RFID tag. 0xFF Other: If the user used an unknown method.

Event Code: 0x00 Lock: The device was locked using either button, code panel or RFID. 0x01 Unlock: The device was unlocked using either button, code panel or RFID. 0x08 Key Lock: If the user locked with a key. 0x09 Key Unlock: If the user unlocked with a key. 0x10 Fingerprint Lock: The device was locked using fingerprint. 0x11 Fingerprint Unlock: The device was unlocked using fingerprint.

Smanar commented 3 years ago

Ha yes, nothing visible on deconz log ? From my memory have added some debug line for that ? Can I have the capture with more information on the unknow command ?

If I remember can have report , alarm or event, but not sure all can ba handled by code yet.

stolevegen commented 3 years ago

deCONZ log when opened with code : https://pastebin.com/a17q3BTz

Doesn't seem to log anything when opened with key.

Smanar commented 3 years ago

15:37:31:019 Door lock debug 0xF4CE3632A29609AB, data 0x00000020 15:37:31:116 Door lock debug 0xF4CE3632A29609AB, data 0x0000000A

Have made a mistake, the code data are command in fact 0x0A is attribute command, but 0x20 ....., it s not your unknow command ?

For attribute report

payload: 00003002

0x0000 is the attribute 0x03 the type and 0x02 the value ?

stolevegen commented 3 years ago

0x0A is attribute command, but 0x20 ....., it s not your unknow command ?

Is it Operation Notification Response? Operation Notification Response [RSP_ID 0x20][SOURCE][CODE][USER_ID 0x00][PIN 0x00][LOCAL_TIME 0x00][DATA 0x00]

From ZCL Specs : 7.3.2.17 Server Commands Generated The commands generated by the server are listed in Table 7-27. 0x20 - Operating Event Notification - O

For attribute report

payload: 00003002

0x0000 is the attribute 0x03 the type and 0x02 the value ?

That would make sense. 0x02 corresponds to manual opening with key.

Smanar commented 3 years ago

Ha yes right, my debug line don't describe if it s cluster command or a profile command.

But if it s that "Operating Event Notification" can be something usefull no ? you have catch the request on wireshark too ?

stolevegen commented 3 years ago

But if it s that "Operating Event Notification" can be something usefull no ? you have catch the request on wireshark too ?

Yes, that is wanted by users, to know the unlock source.

I unlocked using three different sources, and sniffed with Wireshark. First using KeyPad:

Skjermbilde (215)

Second using physical key: Nothing

Third using RFID tag:

Skjermbilde (216)

The manual states that "The Operation Notification Response is defined in the ZCL Specification chapter 7.3.2.17.27, and is partially supported. " This might be the reason why unlocking using key doesn't give "0x02 Manual: If the user used a key"

stolevegen commented 3 years ago

Also, regarding unlocking by KeyPad, this is the full log ;

  1. Report attribute (Attribute unknown (0x0023) This is AutoRelockTime no? Should only be reported if changed
  2. Report attribute (Attribute unknown (0x0023) Again.
  3. Unknown command 0x20 with payload 00 02 00 00 00
  4. Report attribute "Unlocked (0x02)"
  5. Report attribute "Unlocked (0x02)"

Skjermbilde (213)

Skjermbilde (214)

Skjermbilde (215)

Smanar commented 3 years ago

Realy usefull.

First I m seing a possible issue on deconz

15:37:31:019 Door lock debug 0xF4CE3632A29609AB, data 0x00000020 15:37:31:105 Status doorlock : 2

It seem the command 0x20 have trigger the code part used with attribute, perhpas because I think deconz doesn't handle this command.

returns payload 03 02 00 00 00

Operation Event Source 0x03 Operation Event Code 0x02 User ID PIN 0x0000 ZigBeeLocalTime 0x00 Data (nothing, this field is variable)

I can add them in debug line on deconz ? Or add a field state/notification ? with a mix of all values, can be usefull for me

and yes for the attribute 0x0023 I think it s the AutoRelockTime, I can't see the cluster on your capture but the type is the same. I think wireshark doesn't have a full support for this cluster.

stolevegen commented 3 years ago

I can add them in debug line on deconz ? Or add a field state/notification ? with a mix of all values, can be usefull for me

Field state/Notification would be good. Hopefully we can expose this to in example Home Assistant for a "last operating source" sensor.

Smanar commented 3 years ago

Ok so have started to implement notification on a new branch

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

You will have the notification detail in log

DBG_Printf(DBG_INFO, "Door lock notifications > source: 0x%02X, code: 0x%02X, pin: 0x%04X local time:0x%02X", source, code, pin, localtime);

If it work, can't test the compilation on my side ATM.

stolevegen commented 3 years ago

I think there is a syntax error in doorlock.cpp (quint8 source), I can't check again yet because coincidentally my sd-card corrucpted, so I have to do a fresh install of everything. First time I've had that happen.

Smanar commented 3 years ago

Right, have corrected the syntax error.

stolevegen commented 3 years ago

doorlock.cpp: In member function 'void DeRestPluginPrivate::handleDoorLockClusterIndication(const deCONZ::ApsDataIndication&, deCONZ::ZclFrame&)': doorlock.cpp:29:59: error: expected ';' before ':' token stream.setByteOrder(QDataStream::LittleEndian): ^ ; doorlock.cpp:36:23: error: 'source' was not declared in this scope stream >> source; ^~~~~~ doorlock.cpp:36:23: note: suggested alternative: 'Resource' stream >> source; ^~~~~~ Resource

Smanar commented 3 years ago

Updated again, sorry I m on other branch ATM, so can 't test compilation for the moment.

Smanar commented 3 years ago

Ok so have installed a virtual machine to compile code, the link have failed (problem i386 <> X86), but the compilation was ok (with last version fro official, from yesterday)

stolevegen commented 3 years ago

@Smanar

With these active ;

INFO INFO_L2 ERROR ERROR_L2

LOCK deconz

18:44:02:298 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
18:44:02:308 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 
18:44:02:310 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
18:44:02:311    payload: 00003001

UNLOCK deconz

18:45:24:683 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
18:45:24:687 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 
18:45:24:689 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
18:45:24:690    payload: 00003002

UNLOCK RFID tag

18:57:43:145 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload 
18:57:43:187 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
18:57:43:192 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 
18:57:43:193 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
18:57:43:195    payload: 00003002

UNLOCK keypad

18:59:39:104 enqueue event config/localtime for /config/
18:59:39:434 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
18:59:39:438 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 
18:59:39:440 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
18:59:39:441    payload: 00003002

Can't find source and code in debug log. Lock/unlock works, but I can't see autorelock and sound volume in GUI attributes. They are however in general.xml

Smanar commented 3 years ago

Lock/unlock works, but I can't see autorelock and sound volume in GUI attributes. They are however in general.xml

Yes they are https://github.com/Smanar/deconz-rest-plugin/blob/master/general.xml#L1501 https://github.com/Smanar/deconz-rest-plugin/blob/master/general.xml#L1502

You probably haven't updated your deconz version, so you need to overwrite yourself the xml file, compiling the code do'nt update the xml file. The file is in /usr/share/deCONZ/zcl/general.xml for raspberry.

18:59:39:438 Door lock debug 0xF4CE3632A29609AB, command 0x0A, payload

:( Nothing on command 0x20 ? The code is trying to decode the notification event. why you have it on the sniff and not on deconz ? A missing setting somewhere ? I realy don't undersand how work the mask setting.

stolevegen commented 3 years ago

My general.xml is up to date. I overwrote again to be sure.

The sound volume and auto relock attributes is included in general.xml, but does not show in GUI Attributes @ cluster info. They were showing there before though.

I used API to delete door lock from /sensors, and now I get an error that ID 2 is missing from API. I did fresh install, but still same. Maybe I have to reset gateway as well?

Smanar commented 3 years ago

It s strange, can you make a capture to see where your attribute panel is trunkated ? I have made a test on my side with a fake cluster, and i have all attributes displayed.

stolevegen commented 3 years ago

@Smanar Not quite sure what happened here. This exact part was missing, but the rest was present :

          <attribute id="0x0027" name="Default Configuration Register" type="bmp16" default="0x0000" access="r" required="o">
              <value name="Enable Local Programming" value="0"></value>
              <value name="Keypad Interface" value="1"></value>
              <value name="RF Interface" value="2"></value>
             <value name="Sound Volume attribute" value="5"></value>
             <value name="Auto Relock Time attribute" value="6"></value>

I used Samba and overwrote the general.xml file.

The attributes are visible now, but greyed out.

Screenshot 2021-03-30 at 20 58 44

Still no payload however.

19:02:13:577 enqueue event config/localtime for /config/
19:02:13:740 Door lock debug 0xF4CE3632A29609AB, command  0x00, payload 
19:02:13:759 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload 
19:02:13:800 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
19:02:13:801 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 
19:02:13:802 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
19:02:13:803    payload: 00003001
Smanar commented 3 years ago

Ok have found why the payload was invisible, my fault. Now the payload will be present

Have added too 2 more debug line, because you still missing the log starting by "Door lock notifications > source"

But for attribute disabled, it s something funny ... It have worked before ? we don't need a manufacture parameter in the zigbee request ?

On the wiresahrk sniff can you expend the "frame control field" for the command 0x20 I need to be sure for the side : Server To Client ?

stolevegen commented 3 years ago

Ok have found why the payload was invisible, my fault. Now the payload will be present

Have added too 2 more debug line, because you still missing the log starting by "Door lock notifications > source"

Ok I'll test

But for attribute disabled, it s something funny ... It have worked before ? we don't need a manufacture parameter in the zigbee request ?

Before it was working initially, I could switch from enabled to disabled on autorelock, and I could set Sound volume. After reading again, they were both greyed out.

On the wiresahrk sniff can you expend the "frame control field" for the command 0x20 I need to be sure for the side : Server To Client ?

That's correct.

unknown command frame control field

Smanar commented 3 years ago

Ok so have updated the code again 20 mn ago, I think the notification will be displayed too.

But I still don't understand why attributes was disabled. To be disabled in deconz the device need to send "unsupported attribute", can be a protection feature ?

stolevegen commented 3 years ago
12:04:57:325 Door lock debug 0xF4CE3632A29609AB, command  0x01, payload 
12:04:57:352 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload 
12:04:57:379 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
12:04:57:383 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 
12:04:57:385 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
12:04:57:386    payload: 00003002
12:05:11:333 Door lock debug 0xF4CE3632A29609AB, command  0x01, payload 
12:05:11:359 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload 
12:05:22:619 Door lock debug 0xF4CE3632A29609AB, command  0x00, payload 
12:05:22:645 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload 
12:05:22:690 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
12:05:22:694 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 
12:05:22:695 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
12:05:22:696    payload: 00003001
12:05:23:135 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload 

I checked that doorlock.cpp and de_web_plugin.cpp / de_web_plugin_private.h matched yours. I may do a reset of deCONZ and Conbee II just to be sure. Or do you have some other suggestion?

Smanar commented 3 years ago

No, just restart deconz is enought, but it s strange I m missing so much log on your tests

    QString zclPayload = zclFrame.payload().isEmpty() ? "None" : qPrintable(zclFrame.payload().toHex().toUpper());
    DBG_Printf(DBG_INFO, "Door lock debug 0x%016llX, command  0x%02X, payload %s\n", ind.srcAddress().ext(), zclFrame.commandId(), qPrintable(zclPayload) );

    if ( zclFrame.isClusterCommand())
    {
        DBG_Printf(DBG_INFO, "Door lock debug 77\n");
    }
    if (zclFrame.frameControl() & deCONZ::ZclFCDirectionServerToClient)
    {
        DBG_Printf(DBG_INFO, "Door lock debug 78\n");
    }

You haven't error message during compilation ? it can fail, so you can have copied the older version.

stolevegen commented 3 years ago

Ok I deleted deconz-rest-plugin and compiled again.

I had some irregular behaviour at first, commands would timeout etc, but it seems to have settled. AutoRelock and SoundVolume still greyed out though. The first time AutoRelock and SoundVolume was added to general.xml I could change value and it would actually change the doorlock settings. Then I read attributes again, and it's been greyed out since.

Lock success :

13:55:10:752 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
13:55:10:757 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 00003001
13:55:10:759 Door lock debug 78
13:55:10:761 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 

13:55:20:925 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload FF0D000000000000
13:55:20:927 Door lock debug 77
13:55:20:929 Door lock debug 78
13:55:20:930 Door lock notifications > source: 0xFF, code: 0x0D, pin: 0x0000 local time:0x00

Unlock success:

13:56:10:636 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload FF0E000000000000
13:56:10:637 Door lock debug 77
13:56:10:638 Door lock debug 78
13:56:10:639 Door lock notifications > source: 0xFF, code: 0x0E, pin: 0x0000 local time:0x00
13:56:10:689 Door lock debug 0xF4CE3632A29609AB, command  0x01, payload 00
13:56:10:690 Door lock debug 77
13:56:10:692 Door lock debug 78
13:56:10:735 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
13:56:10:740 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 00003002
13:56:10:742 Door lock debug 78
13:56:10:743 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
13:56:10:745    payload: 00003002

RFID tag unlock:

13:46:12:306 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
13:46:12:311 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 00003002
13:46:12:313 Door lock debug 78
13:46:12:315 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
13:46:12:317    payload: 00003002

Delayed lock:

13:52:49:654 Door lock debug 0xF4CE3632A29609AB, command  0x00, payload 00
13:52:49:656 Door lock debug 77
13:52:49:657 Door lock debug 78
13:52:49:692 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload FF0D000000000000
13:52:49:693 Door lock debug 77
13:52:49:694 Door lock debug 78
13:52:49:696 Door lock notifications > source: 0xFF, code: 0x0D, pin: 0x0000 local time:0x00

Another lock success:

13:50:31:363 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload FF0D000000000000
13:50:31:368 Door lock debug 77
13:50:31:371 Door lock debug 78
13:50:31:372 Door lock notifications > source: 0xFF, code: 0x0D, pin: 0x0000 local time:0x00
13:50:31:420 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
13:50:31:428 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 00003001
13:50:31:432 Door lock debug 78
13:50:31:435 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
13:50:31:437    payload: 00003001
stolevegen commented 3 years ago

I seemed to miss some lines there. I'll add another log.

Keypad unlock:

14:15:46:794 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload FF0D000000000000
14:15:46:796 Door lock debug 77
14:15:46:797 Door lock debug 78
14:15:46:798 Door lock notifications > source: 0xFF, code: 0x0D, pin: 0x0000 local time:0x00
...
14:15:52:261 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
14:15:52:266 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 00003002
14:15:52:267 Door lock debug 78
14:15:52:269 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
14:15:52:270    payload: 00003002

RFID tag unlock:

14:14:17:196 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload 0302000000000000
14:14:17:205 Door lock debug 77
14:14:17:207 Door lock debug 78
14:14:17:209 Door lock notifications > source: 0x03, code: 0x02, pin: 0x0000 local time:0x00
...
14:14:19:772 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
14:14:19:776 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 00003002
14:14:19:778 Door lock debug 78
14:14:19:779 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
14:14:19:780    payload: 00003002

Powerbutton lock (no 0x20) :

14:13:10:281 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
14:13:10:288 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 00003001
14:13:10:291 Door lock debug 78
14:13:10:292 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
14:13:10:295    payload: 00003001

deCONZ lock command:

14:20:38:401 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload FF0D000000000000
14:20:38:404 Door lock debug 77
14:20:38:405 Door lock debug 78
14:20:38:407 Door lock notifications > source: 0xFF, code: 0x0D, pin: 0x0000 local time:0x00
...
14:20:48:375 Door lock debug 0xF4CE3632A29609AB, command  0x00, payload 00
14:20:48:377 Door lock debug 77
14:20:48:378 Door lock debug 78

deCONZ unlock command:

14:23:35:319 Door lock debug 0xF4CE3632A29609AB, command  0x20, payload FF0E000000000000
14:23:35:321 Door lock debug 77
14:23:35:323 Door lock debug 78
14:23:35:324 Door lock notifications > source: 0xFF, code: 0x0E, pin: 0x0000 local time:0x00
...
14:23:45:328 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
14:23:45:345 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 00003002
14:23:45:347 Door lock debug 78
14:23:45:350 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
14:23:45:352    payload: 00003002
14:23:45:444 Door lock debug 0xF4CE3632A29609AB, command  0x01, payload 00
14:23:45:447 Door lock debug 77
14:23:45:450 Door lock debug 78
...
4:23:49:053 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
14:23:49:059 Door lock debug 0xF4CE3632A29609AB, command  0x01, payload 0000003001010000300002000010B1110000216400
14:23:49:060 Door lock debug 78
14:23:49:351 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101
14:23:49:356 Door lock debug 0xF4CE3632A29609AB, command  0x01, payload 120000213200130000213200
14:23:49:358 Door lock debug 78
Smanar commented 3 years ago

Perhaps need to not disturb the device at start (battery powered one) ? But it s realy strange, you can't catch the request using your sniffer or "aps" log in deconz when it disable the attribute ? It s a new boring issue ....

BTW have updated the code, don't need to re-pair, just restart You will have a new field in the json, state/notification, that will make a resume of the command

14:23:35:324 Door lock notifications > source: 0xFF, code: 0x0E, pin: 0x0000 local time:0x00

But with code decrypted

stolevegen commented 3 years ago

Perhaps need to not disturb the device at start (battery powered one) ?

Makes sense.

But it s realy strange, you can't catch the request using your sniffer or "aps" log in deconz when it disable the attribute ? It s a new boring issue ....

I added aps log below. In Z2M the attributes can be controlled. And in deCONZ I could control the first time, but not since. It's strange.

All the different lock / unlocks : https://pastebin.com/gFgAfEi3 APS log : https://pastebin.com/AsaFg7Y3

To sum up; Lock by powerbutton (physical) : source: 0xFF, code: 0x0D (code: nothing in manual, but 0x0D is consistent) Lock by zigbee/deCONZ: source: 0xFF, code: 0x0D (same as above) Unlock by RFID tag : source: 0x03, code: 0x02 (source is good, code should be 1?) Unlock by keypad : source: 0x00, code: 0x02 (same as above) Unlock by zigbee/deCONZ: source: 0xFF, code: 0x0E (code: nothing in manual, but 0x0E is consistent)

The response from powerbutton lock and zigbee lock is the same, so I think the source: 0xFF is valid.

Manual states :

Source:
0x00 KeyPad: If the user uses the code panel.
0x02 Manual: If the user used a key, button or fingerprint.
0x03 RFID: If the user used an RFID tag.
0xFF Other: If the user used an unknown method.
Event Code:
0x00 Lock: The device was locked using either button, code panel or RFID.
0x01 Unlock: The device was unlocked using either button, code panel or RFID.
0x08 Key Lock: If the user locked with a key.
0x09 Key Unlock: If the user unlocked with a key.
0x10 Fingerprint Lock: The device was locked using fingerprint.
0x11 Fingerprint Unlock: The device was unlocked using fingerprint.
Smanar commented 3 years ago

I have asked log with aps, but I think the "code part" that disable the attribute is not managed by the API, it s deconz itself. You have same result after waiting 10mn before asking for attribute table in deconz ? Will ask for other devs if they have idea ... but perhaps something is visible on sniff during the "accident", a bad param in the request (some device need the manufacture code, other not)

For the second part, you haven't the new field in the device json with the value decoded ?

const QStringList EventSourceList({"keypad","rf","manual","rfid"});
const QStringList EventCodeList({
"Unknown","Lock","Unlock","LockFailureInvalidPINorID","LockFailureInvalidSchedule","UnlockFailureInvalidPINorID","UnlockFailureInvalidSchedule","OneTouchLock","KeyLock",
    "KeyUnlock","AutoLock","ScheduleLock","ScheduleUnlock","Manual Lock","Manual Unlock","Non-Access User Operational Event"
    });

The code is normally able to decode source and event, and update the field in the json (to be used by third app)

stolevegen commented 3 years ago

I deleted deconz/rest_api_plugin, and reset the gateway and doorlock. As the doorlock wouldn't show up in API.

I have paired it back, but get error : API error 1, /sensors/2, unauthorized user Any idea how to resolve it?

Smanar commented 3 years ago

Are you using the same api key ?

I deleted deconz/rest_api_plugin, and reset the gateway and doorlock. As the doorlock wouldn't show up in API.

But I don't understand, when you restart deconz you miss the device ? else as it was in the api before the restart, why he is not here after it ?

stolevegen commented 3 years ago

It showed in the deCONZ GUI, but not in GET /api/<apikey>/sensors The doorlock had ID nr 2. Now ID nr 1 and 3 is present, but nr 2 is missing completely.

I renewed the API key, using POST /api

Having reset gateway and doorlock module, and deleted everything deCONZ related, I would have thought there would be no references to doorlock in deCONZ after re-installing?

Smanar commented 3 years ago

So you loose the device in api at every restart ? Not normal, you shouldn't have to re-include it The tricks never work to force a re-inclusion in in the api ? (phoscon in permit join and read again basic attributes ?)

stolevegen commented 3 years ago

I deleted the sensor using API. After that it never got included in API again. Yes, tried your suggestion multiple times. Tried letting the doorlock "rest" first, as well as keeping it "awake" after pairing. But no luck

Smanar commented 3 years ago

Ha, ok. If it still impossible to re-include it, can you share logs with error and info L1 and L2, pls ?

stolevegen commented 3 years ago

I went away for about an hour, when I came back it's showing in GUI. Not showing in api/sensors

Binding coordinator and doorlock cluster fails.

Before resetting everything I remember the green line was not going directly to the coordinator, but via an Ikea bulb.

Screenshot 2021-04-01 at 17 29 48

Read attributes log : https://pastebin.com/iJK8hYFE Binding fail log : https://pastebin.com/z0gAbhGE

Smanar commented 3 years ago

17:24:02:505 channel is 19 but should be 11, start channel change

You have a channel confilct, change it again, with following command order https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Network-lost-and-configuration-restore-does-not-help#in-case-the-network-does-still-not-come-up

17:26:27:474 0x2557 seems to be a zombie recv errors 10

It s possible the problem was from the channel issue, the device leave the network, as you said.

stolevegen commented 3 years ago

Procedure didn't work.

I get a long loop of polls, then API error 1, /sensors/2, unauthorized user or unknown child Command unlock / lock times out.

I even tried with a fresh build on a different sd card with the gateway reset and the doorlock module reset. Same behaviour.

4.1] Get sw build id
16:50:26:071 skip check bindings for client clusters (no group)
16:50:26:129 poll node f4:ce:36:32:a2:96:09:ab-0b-0101
16:50:26:132 Poll ZHADoorLock sensor node DoorLock 2
16:50:26:347 MAC poll fastEnddeviceProbe() 0xF4CE3632A29609AB
6:52:58:693 API error 1, /sensors/2, unauthorized user
16:52:58:777 poll node f4:ce:36:32:a2:96:09:ab-0b-0101
16:52:58:778 Poll ZHADoorLock sensor node DoorLock 2
16:52:58:959 Daylight now: solarNoon, status: 170, daylight: 1, dark: 0
16:52:58:960 enqueue event config/localtime for /config/
16:52:59:615 poll node f4:ce:36:32:a2:96:09:ab-0b-0101
16:52:59:616 Poll ZHADoorLock sensor node DoorLock 2

16:54:27:046 Node data 0xf4ce3632a29609ab profileId: 0x0104, clusterId: 0x0101

16:54:27:051 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 00003002
16:54:27:052 enqueue event state/lastupdated for /sensors/2
16:54:27:053 [INFO] - No button map for: easyCodeTouch_v1, unicast to: 0x0000, endpoint: 0x0B, cluster: DOOR_LOCK (0x0101), command: ATTRIBUTE_REPORT (0x0A), payload: 00003002, zclSeq: 13
16:54:27:054 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
16:54:27:055    payload: 00003002
stolevegen commented 3 years ago

@Smanar

Ok now it's showing in API :

2: {
"config": {
"battery": 100,
"lock": false,
"on": true,
"reachable": true
},
"ep": 11,
"etag": "xxxxxx",
"lastseen": "2021-04-01T19:02Z",
"manufacturername": "Onesti Products AS",
"modelid": "easyCodeTouch_v1",
"name": "DoorLock 2",
"state": {
"lastupdated": "2021-04-01T19:00:56.250",
"lockstate": "unlocked",
"notification": "source:rfid,code:Unlock,pin:0"
},
"type": "ZHADoorLock",
"uniqueid": "f4:cexxxxxxxx0b-x"
}
}

but still get API error 1, /sensors/2, unauthorized user , constant polling and unlock/lock command timesout.

Update. After resetting doorlock again and waiting 10 minutes, the unlock/lock command works. JSON is included.

Zigbee/deCONZ lock

21:39:57:240 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 00003001
21:39:57:241 enqueue event state/lastupdated for /sensors/2
21:39:57:243 [INFO] - No button map for: easyCodeTouch_v1, unicast to: 0x0000, endpoint: 0x0B, cluster: DOOR_LOCK (0x0101), command: ATTRIBUTE_REPORT (0x0A), payload: 00003001, zclSeq: 39
21:39:57:244 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
21:39:57:246    payload: 00003001
21:39:57:311 Websocket 192.168.212.66:53820 send message: {"config":{"battery":100,"lock":true,"on":true,"reachable":true},"e":"changed","id":"2","r":"sensors","t":"event","uniqueid":"f4:ce:36:32:a2:96:09:ab-0b-0101"} (ret = 2124231848)
21:39:57:314 Websocket 192.168.212.223:65502 send message: {"config":{"battery":100,"lock":true,"on":true,"reachable":true},"e":"changed","id":"2","r":"sensors","t":"event","uniqueid":"f4:ce:36:32:a2:96:09:ab-0b-0101"} (ret = 2124231848)
21:39:57:317 Websocket 192.168.212.66:57680 send message: {"config":{"battery":100,"lock":true,"on":true,"reachable":true},"e":"changed","id":"2","r":"sensors","t":"event","uniqueid":"f4:ce:36:32:a2:96:09:ab-0b-0101"} (ret = 2124231848)
21:39:57:319 enqueue event config/localtime for /config/
21:39:57:321 poll node f4:ce:36:32:a2:96:09:ab-0b-0101
21:39:57:322 Poll ZHADoorLock sensor node DoorLock 2
21:39:57:365 Websocket 192.168.212.66:53820 send message: {"e":"changed","id":"2","r":"sensors","state":{"lastupdated":"2021-04-01T19:39:57.241","lockstate":"locked","notification":"source:unknow,code:Manual Lock,pin:0"},"t":"event","uniqueid":"f4:ce:36:32:a2:96:09:ab-0b-0101"} (ret = 2124231848)
21:39:57:369 Websocket 192.168.212.223:65502 send message: {"e":"changed","id":"2","r":"sensors","state":{"lastupdated":"2021-04-01T19:39:57.241","lockstate":"locked","notification":"source:unknow,code:Manual Lock,pin:0"},"t":"event","uniqueid":"f4:ce:36:32:a2:96:09:ab-0b-0101"} (ret = 2124231848)
21:39:57:372 Websocket 192.168.212.66:57680 send message: {"e":"changed","id":"2","r":"sensors","state":{"lastupdated":"2021-04-01T19:39:57.241","lockstate":"locked","notification":"source:unknow,code:Manual Lock,pin:0"},"t":"event","uniqueid":"f4:ce:36:32:a2:96:09:ab-0b-0101"} (ret = 2124231848)

Zigbee/deCONZ unlock

21:38:34:051 Door lock debug 0xF4CE3632A29609AB, command  0x0A, payload 00003002
21:38:34:053 enqueue event state/lastupdated for /sensors/2
21:38:34:055 [INFO] - No button map for: easyCodeTouch_v1, unicast to: 0x0000, endpoint: 0x0B, cluster: DOOR_LOCK (0x0101), command: ATTRIBUTE_REPORT (0x0A), payload: 00003002, zclSeq: 36
21:38:34:058 ZCL attribute report 0xF4CE3632A29609AB for cluster: 0x0101, ep: 0x0B, frame control: 0x08, mfcode: 0x0000 
21:38:34:060    payload: 00003002
21:38:34:063 0xF4CE3632A29609AB (easyCodeTouch_v1) create binding for attribute reporting of cluster 0x0101 on endpoint 0x0B
21:38:34:065 queue binding task for 0xF4CE3632A29609AB, cluster 0x0101
21:38:34:135 Websocket 192.168.212.66:53820 send message: {"config":{"battery":100,"lock":false,"on":true,"reachable":true},"e":"changed","id":"2","r":"sensors","t":"event","uniqueid":"f4:ce:36:32:a2:96:09:ab-0b-0101"} (ret = 2124231848)
21:38:34:139 Websocket 192.168.212.223:65502 send message: {"config":{"battery":100,"lock":false,"on":true,"reachable":true},"e":"changed","id":"2","r":"sensors","t":"event","uniqueid":"f4:ce:36:32:a2:96:09:ab-0b-0101"} (ret = 2124231848)
21:38:34:142 Websocket 192.168.212.66:57680 send message: {"config":{"battery":100,"lock":false,"on":true,"reachable":true},"e":"changed","id":"2","r":"sensors","t":"event","uniqueid":"f4:ce:36:32:a2:96:09:ab-0b-0101"} (ret = 2124231848)
21:38:34:226 Websocket 192.168.212.66:53820 send message: {"e":"changed","id":"2","r":"sensors","state":{"lastupdated":"2021-04-01T19:38:34.053","lockstate":"unlocked","notification":"source:unknow,code:Manual Unlock,pin:0"},"t":"event","uniqueid":"f4:ce:36:32:a2:96:09:ab-0b-0101"} (ret = 2124231848)
21:38:34:229 Websocket 192.168.212.223:65502 send message: {"e":"changed","id":"2","r":"sensors","state":{"lastupdated":"2021-04-01T19:38:34.053","lockstate":"unlocked","notification":"source:unknow,code:Manual Unlock,pin:0"},"t":"event","uniqueid":"f4:ce:36:32:a2:96:09:ab-0b-0101"} (ret = 2124231848)
21:38:34:231 Websocket 192.168.212.66:57680 send message: {"e":"changed","id":"2","r":"sensors","state":{"lastupdated":"2021-04-01T19:38:34.053","lockstate":"unlocked","notification":"source:unknow,code:Manual Unlock,pin:0"},"t":"event","uniqueid":"f4:ce:36:32:a2:96:09:ab-0b-0101"} (ret = 2124231848)
Smanar commented 3 years ago

For the api error, try to enable "http" flag in debug, you will see more information about the third app that make the request, but logs are realy hudge with this flag, I think it will be easier to close third app one by one. Can be a phoscon instance too. Perhpas one on them ?

21:39:57:365 Websocket 192.168.212.66:53820 21:39:57:369 Websocket 192.168.212.223:65502 21:39:57:372 Websocket 192.168.212.66:57680

There is realy something "special" with your device, it s like it can't support the command spam during inclusion, and need some time to finish it itself ...

I have made a mistake fo the "pin, but we can see it in the payload, will be 0x0000 too.

Now the device is included, don't delete it, I think future improvement will not need re-inclusion. And BTW do you need something more ?