-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed to interview the Yale lock YDM4109+ #3290
Comments
Could you sniff the traffic when controlling lock/unlock? https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html |
@Koenkk please check the traffic as below As I checked more detail, each time controlling unlock, the error in Zigbee2mqtt as below:
|
Could you send the pcapng file? |
@Koenkk please check the pcapng as below: |
I need you network key to decrypt the file. |
@Koenkk please use the decrypt key below: |
@Koenkk please let me know if you need any further information. |
It looks that there are 2 Zigbee networks operating on this channel (both Texas Instruments coordinator). Can you confirm this? If yes, I would recommend to move one of your networks to a different channel. |
@Koenkk Yes last time I have 2 Zigbee coordinators but I already set different channels. By the way, I just turn off all the Zigbe coordinator and set up new one from scratch. The new decrypt key: |
Here is the log from Zigbee2mqtt, I already tested with latest version 1.12.2. This time, same error and the battery of the log is even unable to read as before. |
Lock/unlock timeout should be fixed in latest dev branch. Regarding configure fail, can you provide the herdsman debug logging of this. To enable herdsman debug logging, see https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-loggingg |
@Koenkk the lock/unlock functions work well in dev branch now. Debug log of lock/unlock from Home Assistant: |
@dinhchinh82 thats because the configure fails.
(from above comment) |
@Koenkk I have not seen the configure failed anymore with dev branch. Here is the debug logging: |
Can you try to trigger it manually and see if it errors: https://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html#zigbee2mqttbridgeconfigure |
@Koenkk I've tried to setup everything from scratch to test again. Then I still found the error.
Here are the test result:
The debugging log (from starting zigbee service to the time lock/unlock from Home Assistant) Please let me know if you need any other information for investigation. |
I also have tried to trigger the configuration manually and got error:
|
Could you sniff the traffic of this again? |
@Koenkk please check the updated sniff & debug log:
decrypt key: 01:03:05:07:09:0B:0D:0F:00:02:04:06:08:0A:0C:0D (default)
Test environment:
Today Test result:
|
Please point me a bit more to the problematic parts (provide the No. where e.g. commands fails). Regarding the delay, I indeed see that the lock takes 5 seconds to response, but I don't think we can solve that from Zigbee2mqtt itself. The device only requests for data every 5 seconds. |
@Koenkk it's quite strange that after about 8 hours from setting lock, it seems to work more reliable.
2. Report status from Real lock to Home Assistant:
Other points:
Remaining points to fix:
Full debug log: |
I've added support for it in the latest dev branch. Both points should be fixed. |
@Koenkk I've just tested with the latest dev branch. Remaining points to fix:
|
This does not look like the latest code.
|
@Koenkk I did not use the hassio addon for this test. I've install dev branch manually as your guide.
Yes. I just used the default converter, not changed the devices.js |
@Koenkk I'm sorry that I had used the modified device.js so the test result is not correct.
Result:
So in order to test the new configuration, I've removed the config part of YMF40 and change the configuration as below:
By this way, the YDM4109+ is recognized correctly. It's paired successfully and fast. But if take a look more detail in the debugging log, there is still error during configuring step as below:
Summary:
Remaining points to fix:
Full debugging log using DEBUG=zigbee-herdsman* npm start |
Should be fixed in latest dev (please wait a few hours before trying) Regarding configure error, please provide a bit longer logging (yours stop some moments before I expect the error). |
@Koenkk I confirm the latest commit in dev branch now recognized the lock exactly. For the configure error, please check full debugging log again as below: |
Could you sniff the traffic while the configure is happening? |
@Koenkk I've just test the latest branch again. Please check the result and related data. Test result by 2020.04.25:
Debugging lock: Sniff zigbee data: 2nd test: decrypt key: 01:03:05:07:09:0B:0D:0F:00:02:04:06:08:0A:0C:0D (default) Test environment:
|
Please add some annotation to the log where you unlock it by fingerprint (otherwise I have no clue were to look at). |
@Koenkk I check the debugging log and found out the following points:
By the way, I feel it's quite strange because I already catched the log when opening by fingerprint by the test on Apr 22 as below (from previous comment):
I also confirmed the test on Apr 23, if opening by fingerprint, the status is updated immediately to the Home Assistant. |
|
|
Can you try again with latest dev branch? (pushed a possible fix) |
@Koenkk I have tested with the latest dev branch ( 1.13.0-dev (commit #772f6c0)) Here are the result:
|
Should be fixed in latest dev branch. |
@Koenkk I confirm the lock status is updated correctly to HA once unlock by fingerprint. |
Cool! thanks |
Hi, Could you please post a link or a picture of the Zigbee Module that you used for the YDM4109+ |
Hi @Koenkk , I update this module to last version, from 1.7, and now My Yale YMF40 is publishing this to mosquitto:
So, is sending the correct message to MQTT broker, but inmediatly change this:
To this: So, previous data is deleted by the last one.... Do you know why this is happened? I tried to erase and repair the lock, but It happened anyway. |
This is expected behaviour, this is an action and only applies to this specific message. The next time a message is received from the lock this does not apply anymore so it is not cached |
In my case, every time I unlock/lock the door, this message is being send. Now, my lock doesn't update anymore in Home Assistant. I remove the lock, and restart HA. Autodiscovery tool find the lock again, but always shows as Unlock. |
I opened the door 3 minutes ago, this is what I get:
This is what I get in HA: |
@dinhchinh82 are you able to provide details on the Zigbee Module that you used for the YDM4109+ |
@matisaul I would expect the lock to confirm the lockState with and attributeReport. The problem of using Can you try to reconfigure your lock via https://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html#zigbee2mqttbridgeconfigure and see if it works after that? Make sure to wake the lock up before executing this command. |
@Koenkk After reconfigure the lock, I get correctly the status (lock/unlock) but fails with action_user and action_source. It seems that the addon is publishing twice the info, the first one with all the data, and the second one without action information (in HA don't get action_source and action_user):
Maybe It is a problem with the auto_lock feature... |
Now I'm getting a lot of this messages:
|
@matisaul the empty action after the |
But I think that show the"auto-lock" feature when you are "unlocking" the door doesn't any sense... I need to use action_user and action_source on my automations, but I can't because this attributes disappears after less than 1 second after unlock the door. |
@matisaul it depends how you use it, in my opinion it's shouldn't be persistent as it only applies at the moment the lock is done, after e.g. 10 minutes it doesn't make sense anymore. You should be able to do all kinds of stuff with this value in an automation. In case you want to persist it set it into a input_text inside an automation. |
@Koenkk Sadly, I can't do that, because action_user and action_source attributes disappears after less than once second (not just the value, but whole attributes). HA is not able to trigger any automation in that short time. |
@matisaul AFAIK Home Assistant should handle all messages, even when appearing for a short time. I've created a small example automation (not tested), first create the input_text.lock_last_user_action and use this: automation:
- alias: Persist last lock last action user
trigger:
platform: mqtt
topic: 'zigbee2mqtt/<FRIENDLY_NAME>'
condition:
condition: template
value_template: '{{ trigger.payload_json.action_user is defined }}'
action:
- service: input_text.set_value
data_template:
entity_id: input_text.lock_last_user_action
value: "{{ trigger.payload_json.action_user }}" |
Wow! Thanks @Koenkk . That did the trick! Thanks for all your patience! |
Bug Report
I tried to add the Yale Zigbee lock which is using Zigbee module to Zigbee2mqtt 1.12.0 but got some errors.
I reuse the configuration of YFM40 as below:
What happened
The lock is recognized even got the failed to interview in the log but it still shows on HASS. Sometimes could not interviewed.
The lock/unlock still work but not stable. Sometime, when click the lock/unlock, the response is quite slow (5-10 seconds) even the lock is very near to the Coordinator. Please check the log below.
The report status works well and it is very fast (when lock/unlock using finger print or code).
Here is the log:
What did you expect to happen
The lock/unlock function works stability without error.
How to reproduce it (minimal and precise)
click lock/unlock on the HASS interface.
Debug Info
zigbee2mqtt version: 1.12.0.
CC253X firmware version: CC2530 (Gban) Source routing. Revision:20190619
The text was updated successfully, but these errors were encountered: