oyooyo / keyble

Command line tools and library for controlling eqiva eQ-3 Bluetooth smart locks
92 stars 29 forks source link

Switches to status "UNKNOWN" after locking #32

Closed markusweibofner closed 3 years ago

markusweibofner commented 3 years ago

When sending the command "lock", keyble switches to the state "UNKNOWN" followed by a timeout error.

Is there a remedy?

MOVING UNKNOWN Error: Promise did not resolve within 45000 milliseconds

oyooyo commented 3 years ago

You should try using the official smartphone app, go to the lock configuration inside the app, and double-check if your lock is really correctly set up. (Neutral position, number of revolutions, side of the door etc.) In particular, check if the number of revolutions is correct.

My understanding is that the UNKNOWN state means that the smart door lock is unsure about the lock cylinder's actual state. I think this is the case for example if

  1. the smart lock has just been installed on the lock cylinder, and has not moved the lock cylinder yet. It cannot know the lock cylinder's actual state yet - it will be determined the first time the lock cylinder is opened.
  2. The smart lock believes to know the actual state of the lock cylinder, but when it tried to execute a command, the lock cylinder somehow reacts differently than the smart lock expects, and now the smart lock is confused/unsure. For example, say the lock cylinder is currently in the "unlocked" position, the smart door lock is configured so that the "locked" position is two complete revolutions apart from the "unlocked" position, but in reality, it is only one revolution. Now the smart lock receives a "lock" command and tries to do two revolutions as configured. But since it's actually only one revolution, the lock cylinder will block after one revolution and the smart lock will recognize this and be confused.

Case 2 can for example also happen if the lock requires too much force for some reason. Or in my case, during the development of the library, the smart lock was not actually mounted on the lock cylinder, but was lying on my desk right next to me for testing purposes, so the smart lock was able to rotate infinitely, which also made it realize something's not as it should be.

Anyhow, I'm almost sure in this case that this is not a software bug in the keyble library. The UNKNOWN state is reported by the smart lock itself.

markusweibofner commented 3 years ago

Hi oyooyo, thanks very much for your detailed answer! In fact, I've tried to set up only one revolution but the result is basically the same. What is also weird is that the smartphone app seems to recognize the correct status, whereas in the library it is UNKNOWN.

I've figured out that it is not too important to know the actual state, especially when deactivating the timeouts. I'm using the library to let the door open via fingerprint, so the respective command is sent either way.

I'll let you know once I've found out why we get the UNKNOWN state.

Thank you so much for your help!

oyooyo commented 3 years ago

In fact, I've tried to set up only one revolution but the result is basically the same. What is also weird is that the smartphone app seems to recognize the correct status, whereas in the library it is UNKNOWN.

That's weird. Since as I said the UNKNOWN state is reported by the smart lock itself, I would have expected that the smartphone app also shows the state to be unknown. So maybe this actually is connected to some bug in the keyble library... But without being able to reproduce it, I don't see how I could fix it. If you find out more about this issue, let me know.

markusweibofner commented 3 years ago

I've just rechecked and you are absolutely right. The UNKNOWN state comes from the lock. In fact i figured out that it needs way more power to do the end of the first revolution and the second one. In the end it does not finally get through and is at 1.5 revolutions. Unfortunately, only one revolution yields UNKNOWN as well unless i press manually against the door while locking it. I guess it has to do with my door.

markusweibofner commented 3 years ago

I've just found a quick and dirty workaround: When the lock command ends in an UNKNOWN state, just send the command again. The lock then realizes that no further revolution is possible and turns into LOCKED