EasyAccess EasyCodeTouch

[stolevegen]

Device

• Product name: EasyAccess EasyCodeTouch
• Manufacturer: Onesti Products AS
• Model identifier: easyCodeTouch_v1
• Device type :
  • Lock

Screenshots

[Mimiix]

Missing all other screenshots. Please provide a screen per cluster.

[stolevegen]

Updated, let me know if anything else is needed.

[stolevegen]

@Mimiix I have the user manual describing all clusters, attributes, implementation details etc. Should I attach it here or is the above sufficient?

[Mimiix]

@stolevegen Please attach :)! Always usefull for devs i guess.

[stolevegen]

adding user manual describing implementation details, clusters etc. Note ; The Lock/Unlock command does not support PIN code in the command, and if a Pin Code parameter is present, it can only have the parameter Length and it must be set to 0. user manual.pdf

[Smanar]

Hello, I m on some doorlock ATM, not sure I can make your device working (I realy don't know the cluster 0xFFEA) but have you a linux machine to compile the code for tests ?

[stolevegen]

Yes, I can compile and test.

Not sure about 0xFFEA either. I got Wireshark up and running now, sniffing traffic with a CC2531. I can share a log after.

[Smanar]

Perfect ^^. For the moment I have just added your device to the doorloock code > https://github.com/Smanar/deconz-rest-plugin/commit/5890ca7307fbf7f2cdf241a979ccfb0df1bc5072 You have the discussion on other issue https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3750#issuecomment-761600010

[stolevegen]

Didn't work, but it's my first time compiling. Not sure I've done it right. Deconz Commit : 97b0c1fa379d882d4e0089211f2430de6156827c

REST-API

Do you have a short step by step? Raspberry pi - os lite

[Smanar]

Honestly, I don't know where to find the Git commit ^^.

The procedure is explained here https://github.com/dresden-elektronik/deconz-rest-plugin#install-deconz-development-package-optional-linux-only

So first install deconz too on your Raspberry, then

sudo apt install deconz-dev This part is the more important, you need to have no error message, and I m not sure as you have a "lite" OS

Then

git clone --branch doorlock 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

It s a second machine, or your principal one ? If it s your production machine better to make a backup of the libde_rest_plugin.so file in another folder.

[stolevegen]

Thanks. That's the procedure I followed, but I must have done something wrong. On the correct commit now though.

I use a second machine. Will get back when I have tested.

[Smanar]

I can be wrong too, and you need to re-include your device with the new code (or force a new inclusion whith setting phoson in permit join and reading again the basic attribute in deconz)

[stolevegen]

Didn't work. It does respond when I send unlock / lock command from Deconz "door lock cluster" interface. Though if I send the command once, the door lock actuates three times.

The door lock is visible in Deconz GUI, but not in Phoscon App.

Manufacturer says it should be open and ready for integration in any system by zigbee standards.

[Smanar]

I have checked the code again, all seem fine. A tips to make the test easier.

You are not forced to reset the device if the device is already present in deconz to make a new inclusion.

• Set phoscon in permit join "add new sensor"
• Read again the basic attribute, cluster "Basic" 0x0000, button "read"

But the device will be not visible in phoscon, you need to check in third app or direclty the api.

If the device is realy not present in the API, can you share the log just before the manipulation, and some minuts after ? To check what happen during the inclusion ? For log can use "info" "info_l2" "error" "error_l2"

To check the api you can use http://IP:PORT/api/KEY/sensors

IP and PORT are the same used to access phoscon KEY is an api key, do you have one ?

[stolevegen]

When added the lock to my non-dev version I can choose clusters, and the device is not in the API list. When added to the dev-version with your code compiled, I can't choose clusters, and the device is not in the API list.

See attached log starting a couple of seconds before including the doorlock (0xF4CE3632A29609AB) : https://pastebin.com/8AbFnQX2

Got API by POST : http://IP:PORT/api + body { "devicetype": "Conbee" } Got API list by GET : http://IP:PORT/api/KEY/sensors and did the same for lights

[Smanar]

Wich one deconz version are you using ?

Perphaps it's no luck, the code is working for other doorlock, and I don't find something specific to your device in the code It s visible on your log too, deconz start the inclusion, but never reach the second step

20:20:50:166 [1] get node descriptor for 0xf4ce3632a29609ab

On the not working mode, you can probably enable the cluster list with re-sending commands visible on your last capture (Read .... Descriptor). But yes, there is a problem, why deconz block during the node descriptor request ? The device is already sleeping ? but why it work on the other version ...

[stolevegen]

@Smanar I've been using both dev and non-dev version. Right now I'm on dev-version with your commit "5890caxxxxxxxxxxxx5072", and on this commit I can't choose clusters. I tried enabling them by re-sending Read commands already, but no luck. I can try again, while getting help to keep device awake by manual input.

I spoke with manufacturer, and everything should be open and per Zigbee standard, so there should not be any issues. I'm trying to integrate to Zigbee2mqtt also, and I'm having troubles there as well.

May be wishful thinking, but could I perhaps have gotten a bad module..?

[Smanar]

May be wishful thinking, but could I perhaps have gotten a bad module

No, I don't think, it s rare, and it works without my modification. But I realy don't see what can block the procedure when using my version, wich one deconz version are you using ? (the deconz version, not the plugin one).

You can try too, include the device direclty in deconz, without using the API (so without using my code), you can too disable the api plugin in the deconz menu.

[stolevegen]

No, I don't think, it s rare, and it works without my modification.

Not 100%. The clusters show, but when I send unlock command once, the lock actuates "unlock - delay - lock" three times. It looks like the chip is from Nordic Semiconductor, and I'm using another Nordic chip with sniffer firmware, and still cant pick up any battery/lock state/change datapackets transmitted from the lock.

This is the deconz version : 2.07.01 Deconz commit (not API) : 97b0c1fa379d882d4e0089211f2430de6156827c

Not sure it will make any difference, but at this point I'm prepared to make a fresh rpi install, deconz install, fresh firmware on the Conbee II, reset zigbee module on the door lock, remove the door lock from the door, and start from scratch, away from any other zigbee traffic.

[Smanar]

remove the door lock from the door

Ha ok, in my mind you are making tries "out of the door" so can be an explanation for the triple cycle, but if you are making the try in real condition it s another strange reaction, yes.

And your deconz version is just 2/3 months old, so I don't think the problem is from that.

[stolevegen]

I'm trying to do a fresh install, but when installing your commit I now get following error :

de_web_plugin.cpp: In member function ‘void DeRestPluginPrivate::updateSensorNode(const deCONZ::NodeEvent&)’: de_web_plugin.cpp:9235:51: error: redeclaration of ‘ResourceItem* item’ ResourceItem *item = i->item(RStateLockState); ^~~~ de_web_plugin.cpp:9227:51: note: ‘ResourceItem* item’ previously declared here ResourceItem *item = i->item(RConfigLock); ^~~~ Developer says to get status from doorlock we need to bind endpoint 11 and cluster 0x0101. (door lock cluster) In Z2M I can change endpoint number to 11, not sure how it's done in deCONZ ?

[Smanar]

Arf, my bad, have corrected the code

Developer says to get status from doorlock we need to bind endpoint 11 and cluster 0x0101. (door lock cluster)

It s done too in deconz, but ATM the problem is not the information return, but your device that don't appear in the API. When you make try on the version without modification deconz don't make the bind, but your device appear and completely in deconz. I don't understand why with the modified code it s not the same result.

Edit: Can you retry with the last code, I have updated the whole code, with the last official master (long time I have started this branch, sorry, was totally out of date)

[stolevegen]

I tried with the last code, but I can't add/include the doorlock. It does not show in deCONZ GUI, phoscon app or in REST api (sensors/lights)

I successfully added/included the lock in zigbee2mqtt(then reset the doorlock), so there should be no problem to add it in deCONZ.

[Smanar]

You mean my modification prevent the device be included in deconz itself ? No special error in logs ?

You are not using docker ?

[stolevegen]

It's strange. The door lock does not include with your modification. I then ;

• Uninstalled deconz/deconz-dev
• Deleted common files
• Deleted user files
• Deleted deconz-rest-plugin dir
• Reset doorlock module.
• Reset conbee ii gateway
• Install deconz (non-dev)
• and still not including.

Tested with an Aqara sensor after, which got included straight away.

Any idea what can cause this?

[Smanar]

nope, but it s worreid ...

You can see it on log during the inclusion ? (with "info") Log starting by "DeviceAnnce of LightNode" for light part. Log starting by "device announce XXXXXX" for sensor part.

[stolevegen]

I can't see the doorlock in the logs, no announce on either light or sensor. Before it was included in deCONZ GUI, but not in phoscon. Now it won't appear in GUI, Phoscon, or logs. I can't understand why, as I have reset/re-installed every component in the chain.

If I do another reset, I can include the doorlock in Zigbee2mqtt w/CC2531 gateway, so the doorlock is functioning, and able to pair.

The Aqara sensor appears in logs, phoscon and GUI.

[Smanar]

If I do another reset, I can include the doorlock in Zigbee2mqtt w/CC2531 gateway, so the doorlock is functioning, and able to pair.

I was going to propose a battery problem, but if it work on zigbee2mqt ... And I don't see a setting in deconz that can change something.

[stolevegen]

Did another reset, made sure all Zigbee devices had no power, re-install software, reset gateway etc.

deCONZ GUI : It's appearing and has green line to coordinator. It does go unavailable at intervals. Phoscon : Not showing Home Assistant : Sensor, and battery sensor visible, but no lock/unlock.

Executing lock/unlock from deCONZ GUI, works sometimes. It goes unavailable, but most of the time it will respond if I do a power cycle of the lock and then execute the command.

Will test some more later, and do more logging.

Log snippet from unlock success ; https://pastebin.com/PnyNE9G8

[Smanar]

I think some issue are from HA. The device create a new sensor now, the ZHADoorLock, and this one is visible on log, HA don't manage them yet, and ofc it is invisible on phoscon.

You have the procedure here, else I can explain more : https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3750#issuecomment-761600010 (you don't need to recompile, it s the same code you are using ATM, even I have just updated it, with the last official)

On log

06:47:49:930 Poll ZHADoorLock sensor node easyCodeTouch_v1 06:47:50:792 poll node f4:ce:36:32:a2:96:09:ab-0b-0101

This is not good deconz try to pool your device, need to block that, can use your battery, or spam request for nothing if your device ignore them. 2 possibilities

• your device don't support reporting, so I just need to disable it.
• Your device haven't send a reporting so deconz is using pooling.

Do you know how to set a reporting manualy to test ? The only attribute checked for cluster 0x0101 is the attribute 0x0000

This can explain too the

It does go unavailable at intervals.

and

06:47:51:329 DeviceAnnce of SensorNode: 0xF4CE3632A29609AB [1]

Your device have joined the network again during your command ? or you have left the permit join at "on" ?

[stolevegen]

You have the procedure here

OK I will get on it later today

2 possibilities

• your device don't support reporting, so I just need to disable it.

It should report. To receive reports, a bind must be made between endpoint 11 and cluster 0x0101

• Your device haven't send a reporting so deconz is using pooling.

Do you know how to set a reporting manualy to test ? The only attribute checked for cluster 0x0101 is the attribute 0x0000

I will add screenshots of the 0x0101 clusters attributes. I'm not sure how to manually set reporting.

I will flash a zigbee dongle later with sniffer firmware and check traffic at least.

Your device have joined the network again during your command ? or you have left the permit join at "on" ?

Did not leave it on, I will try later to make sure, but I had the same symptoms on Zigbee2mqtt. When unlocking it would do a "unlock/delay/lock" cycle three times then rejoin the network.

[Smanar]

I had the same symptoms on Zigbee2mqtt

So the problem is not specific to conbee ? there is an issue about their tests on z2m issue ?

bind must be made between endpoint 11 and cluster 0x0101

Ok, so I don't need to disable it. To check if the bind is done, I think the only way is checking logs (I don't think it s visible on deconz) or remade if in deconz. For attribute it s easy

• cluster 0x0101
• attribute 0x0000
• then on the popup "read config"

setting used by code

        rq.dataType = deCONZ::Zcl8BitEnum;;
        rq.attributeId = 0x0000; // Current Lock Position
        rq.minInterval = 1;
        rq.maxInterval = 300;
        //rq.reportableChange8bit = 1;

[stolevegen]

Using REST client I modified "lock: true" ;

PUT http://192.168.212.65:80/api/<api>/sensors/<id>/config payload: { "lock": true }

Confirmed updated ; https://pastebin.com/Ts6ATym6

As to checking if binding is done. Only thing related to bind in log is ;

18:48:03:852 Force binding of attribute reporting for node easyCodeTouch_v1 18:48:04:516 poll node f4:ce:36:32:a2:96:09:ab-0b-0101 18:48:04:519 Poll ZHADoorLock sensor node easyCodeTouch_v1

[Smanar]

And the lock have worked, on the device ?

Config/lock seem working state/lockstate is null, so this one have problem (and this one is updated whith return from the device)

Perhaps the device need bind but not report ? and it send notification only after the request ? Will take a look on z2m side, have found your issue. Because all seem fine on your capture.

for memory The manual : https://github.com/Koenkk/zigbee2mqtt/files/5921232/user.manual.pdf The link on Z2m : https://github.com/Koenkk/zigbee2mqtt/issues/5884

[Smanar]

For information, we have corrected the missing return > https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3750

But idk if your device swill have still the strange working mode with the last code.

[stolevegen]

Ok I will try out the new code.

As to your question in the previous post, the lock kinda works, but it goes "unlock-delay-lock" times three. It falls unavailable at intervals also, but maybe this is related to the missing return.

@Smanar looks like there is some syntax error in the code ;

bindings.cpp: In member function 'bool DeRestPluginPrivate::checkSensorBindingsForAttributeReporting(Sensor*)': bindings.cpp:3288:17: warning: init-statement in selection statements only available with -std=c++17 or -std=gnu++17 if (*i == DOOR_LOCK_CLUSTER_ID && sensor->type() != QLatin1String("ZHADoorLock") ^ bindings.cpp:3288:93: error: expected ';' before '{' token if (*i == DOOR_LOCK_CLUSTER_ID && sensor->type() != QLatin1String("ZHADoorLock") ^ ; { ~ bindings.cpp:3294:98: error: expected ')' before ';' token sensor->address().ext(), qPrintable(sensor->modelId()), (*i), srcEndpoint); ^ ) bindings.cpp:3288:16: note: to match this '(' if (*i == DOOR_LOCK_CLUSTER_ID && sensor->type() != QLatin1String("ZHADoorLock") ^ bindings.cpp:3294:98: warning: suggest braces around empty body in an 'if' statement [-Wempty-body] sensor->address().ext(), qPrintable(sensor->modelId()), (*i), srcEndpoint); ^

[Smanar]

Yep, sorry, my bad, just corrected, I haven't enought time to compile code for each branch.

[stolevegen]

I'm just glad your working on the issue, thanks.

I compiled the new code, but still get the same "unlock - 7 sec delay - lock" looping three times. I'll get the sniffer up and running tomorrow and check for traffic.

[stolevegen]

At least now I get some info from debug ; https://pastebin.com/AewfN22R Reporting config was empty but I put "1" as min and "300" as max

From REST API sensors: 2: { "config": { "battery": 100, "lock": false, "on": true, "reachable": true }, "ep": 11, "etag": "a43862f76b7fa48b0fbb9107df123b0e", "lastseen": "2021-03-06T22:25Z", "manufacturername": "Onesti Products AS", "modelid": "easyCodeTouch_v1", "name": "easyCodeTouch_v1", "state": { "lastupdated": "2021-03-06T21:25:45.624", "lockstate": "undefined" }, "swversion": "20201211", "type": "ZHADoorLock", "uniqueid": "f4:ce:36:32:a2:96:09:ab-0b-0101" },

[Smanar]

But still the "unlock - 7 sec delay - lock" looping three times, even with correct config this time ...

I hope for something visible with the sniffer, because we can't compare with the original gateway, to see the trick we miss.

[stolevegen]

I've attached some log from Wireshark. It's routed via a light, and not directly to coordinator. Source : 0x0000 and destination 0x6014.

I ran unlock command during sniff.

Doorlock sniff.zip

[Smanar]

You can't save the log uncrypted ? Or at least a picture from your wireshark with all requests globaly ? (It don't seem crypted, but all data are unusable)

And you have the "strange cycle" too during this sniff ?

[stolevegen]

Yes, it's still cycling.

Are the files not opening, or is the data pn the fil not usable?

I'm attaching some screenshots from Wireshark

[Smanar]

I can open the file, but I haven't the key , so the data are still encrypted on my side (the file is saved encrypted) You can't let them in chronologic time ? and with gateway > device and device > gateway ?

It s possible your device wait for a defaut response, but it s strange you have the problem on deconz and z2m, and no problem for other device.

And if you can take a look on the "attribute reporting" you need to have just after the request. in this one the device send it s state, so we can perhaps see an error message here.

[stolevegen]

The manufacturer says "to get status you need to bind endpoint 11 and cluster 0x0101. All functionality is open for everyone"

The doorlock is routed via an ikea bulb (0x7379).

"just after the request" ..do you mean the unlock command/request or something else?

I'm adding more pictures, with a overview in chronological order as the last picture.

1. pic : route record

2.pic : unlock command

3.pic : config reporting doorlock to coordinator

4.pic : config reporting coordinator to doorlock'

5.pic : data request doorlock to gu10 bulb ikea

6.pic : report attributes doorlock to coordinator

7.pic : Bind response success

8.pic : config reporting response doorlock to coordinator

9. pic : default response coordinator to doorlock

10.pic : bind request coordinator to doorlock

11.pic unlock command overview in chronological order

[Smanar]

Ok I see some strange things.

• The report attribute give 0xff as state, are you sure the device is correclty installed, no need a sensor somewhere ? This can explain the strange device reaction, on normal doorlock if you block the working mode, the device retry the move.
• On the last capture, you have hightlighted a unlock request, there is a second one at timer 321, with same sequence number but not the same lenght.

[stolevegen]

Should be no extra sensors and zigbee module is mounted correctly. I have already taken it out and used pressure air to clean connections also, just to be sure. I will take another look again and take some pictures.

As to the second unlock request, here is screenshots ;

[Smanar]

Just for information, not realy dangerous, but you have expend the zigbee header, so we can see the network key.

[stolevegen]

If someone finds my address, travels to my home and manages to connect to my system, I will open the door for them with coffee ready :) I will remove the pictures with key showing once they are not needed anymore.

I took apart everything and checked with light and magnifier, and I found one bent pin. I carefully straightened it out and now we are one step further.

Deconz GUI show the lock state as locked/unlocked. When issuing a lock/unlock command the attribute value is updated (locked/unlocked)

Sending unlock command :

• 0x01 unlock is issued.
• Response from doorlock to coordinator is success (0x00)
• Then shortly after response comes again as failure (0x01) several times
• When sending an unlock command, it will "unlock - delay about 7 seconds - lock", only one time. This is the exact same behaviour as when opening manually with pin code.

1. Could this be a symptom of attribute 0x0023 (AutoRelockTime) being 0x01 (enabled) ? Writing 0x00 disables the autorelock.

2. I also get an unknown command 0x20, but I think this relates to Operation Notification Response and perhaps the opening-with-zigbee action is returned as unknown method?

3. From the manual; Door Response value 0x01 == SUCCESS, but from Wireshark it seems to be defined as 0x01 == Failure.

Unlock command:

Unlock command --> success --> unknown --> failure x 4

The unknown command :

[Smanar]

If someone finds my address, travels to my home and manages to connect to my system, I will open the door for them with coffee ready :) I will remove the pictures with key showing once they are not needed anymore.

Lol, yes, zigbee is not realy sensible, but I prefer prevent, and you have some doorlock, can be more sensible, but easy to change the key when test are finished.

I also get an unknown command 0x20, but I think this relates to Operation Notification Response and perhaps the opening-with-zigbee action is returned as unknown method?

Yes, but unfortunately, not realy usefull for me FF 0D 0000 00 000000

If I m right 0xFF mean "Indeterminate" and 0x0D "manual lock"

For the answer, take care not all are the same. When you send a zigbee request, you can have a success return because the command was valid and after a failure because the state was bad.

0x00 > Success. Operation was successful. 0x01 > Failure. Operation was not successful.

And yes there is the reverse on the manual ...

But something strange is the reporting

Deconz GUI show the lock state as locked/unlocked

How it can be possible ?

And

7.3.2.17.2 Unlock Door Response Command This command is sent in response to a Toggle command with one status byte payload. The Status field SHALL be set to SUCCESS or FAILURE (see 2.5). The status byte only indicates if the message has received successfully. To determine the lock and/or door status, the client SHOULD query to [Lock State attribute] and [Door State attribute].