Yale YDF 40 - Payload with NULL infos for fingerprint action (it worked fine) #15665
Comments
|
Can you provide the debug log of this? (not the herdsman one) See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable debug logging. |
|
I think you want the file log_1.txt, right?
|
|
Yes, but then with log level set to debug. |
It's here. |
|
Thanks, I assume that the following happened:
If this is correct, the issue is that the device doesn't send the
|
|
On the block you consider not via fingerprint there is one with fingerprint, but the behavior is the same than the two lines you assume that is with fingerprint, so the understanding is correct. Two questions please: And about re-pairing, I did it on Monday and no success. And the last info, there are other people with the same issue: |
|
EDIT:
external_converters:
- ext_converter.js
|
|
Ok, I'll test it as soon as I arrive at home. |
|
This shouldn't conflict, can you provide me the external converter you are currently using? Then I can add this device for out of the box support. |
|
Hi Koenkk. |
|
I've been having this problem for a while and even with ext_converter.js it still says "null". this is my log. |
See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable the herdsman debug logging. Note that this is only logged to STDOUT and not to log files. @everson7 you probably need to re-pair the device |
|
Koenkk, I'm working with this external converter since yesterday. I believe it fixed my issue. |
|
It is not the same, line 34 changed. |
|
Ahahahaha, sorry... you sent me the same URL, I just have compared this :-) |
|
@Koenkk , two important infos: |
|
@Koenkk, it is my first-time using converters and I already have another one. Should I save this converter with another name if I am already using a converter for other device in my Z2M configuration.yaml? I am wondering if I should rename your code to something like "_v2" and add like this: external_converters:
*Where the first one would be my existing converter |
|
I did the re-pair and it continues with "null" status. |
@relombardo yes, you can give it a different file name (any you like, just make sure it ends with @everson7 I see you are using an old version, 1.27.2, make sure to use 1.28.4 + external converter + re-pair |
|
@Koenkk , I got this result after adding converter with this change: User 2 unlocking the door: Is this the expected result? My automation for other unlock methods was based on payload messages and in this case, I did not find a way to translate this result as a flag on my Node-RED to identify this action. |
|
@relombardo this is good indeed (I've updated the converter with your changes). It seems no action is send (that's what this issue is about) |
|
@Koenkk, the model YMF40 sends payload.action_source = 4 for fingerprint unlock. I am wondering if we could replicate it on the YDF40 via converter, leveraging YMF40 logic. The weird thing is that their Z2M documentations look identical regarding action/source sections.
|
|
Just to be clear here... my model is YDF40 and it is working fine with the present version after the tests I described here. |
@gregolin , are you getting payload.action_source message for fingerprint unlock on your YDF40 without the converter? |
|
Exactly. As I mentioned here (quoted below), I un-paired my two Yale locks (different models), re-paired them three times and everything is working fine so far. I've tested with and without the external converter and it doesn't change anything for me, I can see all messages again perfectly like before.
|
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days |
|
@gregolin, thanks for the update. I removed the converte and then I tried removing and re-pairing my YDF40. Now it is being recognized as YMF40. I thought it could be promising, but I still cannot identify fingerprint unlock, as I am getting exactly same message as before. @Koenkk, is the converter still necessary? Is there any reason for YDF40 be identified as YMF40 recently without the converter? |
|
@relombardo can you provide the data/database.db entry of your device? |
|
here is exactly the same, my ydf40 being recognized as ymf40 and unable to identify fingerprint unlock. |
|
I don't know if it helps for something, but mine also is recognized as YMF40, but it works perfectly.
|
@Koenkk , here is the related line I see on data/database.db: {"id":5,"type":"EndDevice","ieeeAddr":"0x000d6f0012bb3015","nwkAddr":2767,"manufId":4491,"manufName":"ASSA ABLOY iRevo","powerSource":"Battery","modelId":"iZBModule01","epList":[1],"endpoints":{"1":{"profId":260,"epId":1,"devId":10,"inClusterList":[0,1,3,4,5,9,10,32,257],"outClusterList":[10,25],"clusters":{"genBasic":{"attributes":{"modelId":"iZBModule01","manufacturerName":"ASSA ABLOY iRevo","powerSource":3,"zclVersion":1,"appVersion":11,"hwVersion":0}},"genPollCtrl":{"attributes":{"checkinInterval":360}},"genPowerCfg":{"attributes":{"batteryPercentageRemaining":90}},"closuresDoorLock":{"attributes":{"lockState":1}}},"binds":[{"cluster":32,"type":"endpoint","deviceIeeeAddress":"0x00212effff07e12c","endpointID":1},{"cluster":257,"type":"endpoint","deviceIeeeAddress":"0x00212effff07e12c","endpointID":1},{"cluster":1,"type":"endpoint","deviceIeeeAddress":"0x00212effff07e12c","endpointID":1}],"configuredReportings":[{"cluster":257,"attrId":0,"minRepIntval":0,"maxRepIntval":3600,"repChange":0},{"cluster":1,"attrId":33,"minRepIntval":3600,"maxRepIntval":62000,"repChange":0}],"meta":{}}},"appVersion":11,"hwVersion":0,"zclVersion":1,"interviewCompleted":true,"meta":{"configured":1439519238},"lastSeen":1675087190815,"defaultSendRequestWhen":"fastpoll"} |
|
I think your device contains a generic module: I don't know about the action, seems to be an issue with the module itself as re-pairing fixed it for @gregolin |
|
Hi Koen.
Mine has the same module and it works fine... see my infos:
{"id":2,"type":"EndDevice","ieeeAddr":"0x000d6f001516d57d","nwkAddr":15565,"manufId":4491,"manufName":"ASSA
ABLOY
iRevo","powerSource":"Battery","modelId":"iZBModule01","epList":[1],"endpoints":{"1":{"profId":260,"epId":1,"devId":10,"inClusterList":[0,1,3,4,5,9,10,32,257],"outClusterList":[10,25],"clusters":{"genBasic":{"attributes":{"hwVersion":0}},"genPollCtrl":{"attributes":{"checkinInterval":360}},"genPowerCfg":{"attributes":{"batteryPercentageRemaining":90}},"closuresDoorLock":{"attributes":{"lockState":1}}},"binds":[{"cluster":32,"type":"endpoint","deviceIeeeAddress":"0x00124b001cd4a28c","endpointID":1},{"cluster":257,"type":"endpoint","deviceIeeeAddress":"0x00124b001cd4a28c","endpointID":1},{"cluster":1,"type":"endpoint","deviceIeeeAddress":"0x00124b001cd4a28c","endpointID":1}],"configuredReportings":[{"cluster":257,"attrId":0,"minRepIntval":0,"maxRepIntval":3600,"repChange":0},{"cluster":1,"attrId":33,"minRepIntval":3600,"maxRepIntval":62000,"repChange":0}],"meta":{}}},"appVersion":11,"hwVersion":0,"zclVersion":1,"interviewCompleted":true,"meta":{"configured":1439519238},"lastSeen":1675098272145,"defaultSendRequestWhen":"fastpoll"}
I have only one difference to his setup... I have another Yale lock (it's a
Brazilian version) which I use an external converter (this one:
#8946)
IMPORTANT TO SAY TWO THINGS:
1 - both of them are working fine;
2 - when I need to repair it (YDF 40), it's common to get some errors to do it and I
get success after 3 or 4 attempts.
Abs,
Leandro Gregolin
…On Mon, Jan 30, 2023 at 2:05 PM Koen Kanters ***@***.***> wrote:
I think your device contains a generic module: iZBModule01, I've renamed
the device to YMF40/YDM4109+/YDF40 (only a cosmetical change).
I don't know about the action, seems to be an issue with the module itself
as re-pairing fixed it for @gregolin <https://github.com/gregolin>
—
Reply to this email directly, view it on GitHub
<#15665 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMDC4GGDA4F2JY64OD2FZ3WU7YGRANCNFSM6AAAAAATEWMPFE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi @gregolin , this is interesting, thanks for sharing. In my case it is identified as Unknown device, then it becomes the YMF40 after a while. Once I check that fingerprint payload message is not available, I force to remove the device on Z2M. Then I go to my locker (YMF40) and I use the Function 9 (create new connection) - remove connection by pressing 3, then I use the Function 9 again to create a new connection, by pressing option 1 while my Z2M is scanning to find new devices. At this point I restart the loop: The device is recognized as Unknown, then it becomes YMF40 once again. Are you getting some similar behavior when you mention you need to retry? |
|
Not exactly. |
|
I just tried again, I only noticed green pop-up messages coming in while interview was occurring and finally, I got a successfully completed message. I am assuming there were no errors. Then I tried fingerprint unlocking and got only this: Zigbee2MQTT:debug 2023-01-30 17:37:15: Received Zigbee message from 'YMF40', type 'attributeReport', cluster 'closuresDoorLock', data '{"lockState":2}' from endpoint 1 with groupID null @gregolin when you say it worked for you, are you getting a specific payload message? I believe it is action_source 4, but I never had the opportunity to succeed, so I am not sure. |
|
I receive the correct message. See: Zigbee2MQTT:info 2023-01-29 17:59:38: MQTT publish: topic 'zigbee2mqtt/Sala_Fechadura', payload '{"action":"unlock","action_source":4,"action_user":1,"battery":100,"linkquality":123,"lock_state":"locked","state":"LOCK"}' The action_source 4 is fingerprint. |
|
Thanks @gregolin. I tried something different. I removed battery cells to force a shutdown of my locker, thank I turned it back on. It simply started working and I received payload message action_source":4. I tested several times with different users and it is consistently working now. Not sure if it was a coincidence, but I did not have to re-pair my device nor rebooting any system/application. So, here are my thoughts on possible solution for users with similar issue:
These were actions that worked so far, perhaps there are different insights with time of maybe a future update fix a potential root cause. @everson7 , could you try step 4 once you are sure your device is fully interviewed with no errors. I am curious to check if it works for you and I really hope so.
|
|
Yes, it's working now! |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days |
|
Hi everyone. "InputError: Invalid action format: unlock" And all actions following the node result in error. @Koenkk , is "action" a right label for this node? I'm thinking if ACTION could be some protected word, something similar that. |
|
@Koenkk , it seems the word "action" is a reserved word nowadays, see:
Thanks. |
What happened?
After some update the door lock Yale YDF 40 is sending NULL when the unlocking is started by fingerprint.
The behavioral is different with passcode, which everything works fine.
Attached are two files:
Log 1 - Only Z2M log, where we can see line 1 for a passcode unlock action; line 90 for the unlock from internal side; line 94 a fingerprint action with null values (I've cleaned lines regarding other devices);
Log 2 - With some attempts related to fingerprint (still null values), including the herdsman log.
log_1.txt
log_herdsman.txt
What did you expect to happen?
When it is opened by fingerprint the payload must have the action_source value (4) and the action_user value (X). It worked for a long time, but it has been broken around 1-2 weeks.
How to reproduce it (minimal and precise)
No response
Zigbee2MQTT version
1.28.4-1
Adapter firmware version
20221213.1 - latest OR 0.14.76 (I'm not sure about the question)
Adapter
Sonoff Dongle
Debug log
log_herdsman.txt
log_1.txt
The text was updated successfully, but these errors were encountered: