Delay in executing a sendcommand

[nfcplusplus]

Hi, first of all I'd like to thank you for sharing the code. I have been looking for such a program since 2017. By chance and little help from google, I found your code. It is working flawlessly.

The only issue that I am having is amount of time between sending a KEYBLE-SENDCOMMAND and initial reaction from the Eqiva Smart lock. I have measured it and averages between 5 to 7 seconds from the moment hitting enter key until lock starting to react (not including the time to rotate the lock). It is the same for all commands, open, lock, unlock even status. I tried it from a bunch of other computers but it is the same.

When I use the app it is almost instantaneously, no delay at all. I thought it might be due to auto_disconnect feature, so I disabled it with -adt 0 but no luck.

In my setup, the smart lock is powered by a external power source and I have no concern about saving batteries, rather I'd like instant reaction from the smart lock.

What I would like to know is:

1- is it normal for the lock to take 5 to 7 seconds for a keyble-sendcommand? 2- what causes this delay? 2- is there any way to reduce the above mentioned time? 3- how can I check that I am connected to the smart lock?

I really appreciate any help or comment.

many thanks, NFC++

[oyooyo]

Hi, the delay between initiating a command and the command being executed is mainly driven by two factors:

1. The time it takes to connect to the smart lock via Bluetooth LE. On my PC, this time is roughly 1-1.5 seconds.
2. The time it takes to initialize the keyble-sendcommand tool (for example loading the required node.js modules, precompiling the Javascript code etc.). How long this takes depends a lot on the hardware keyble-sendcommand is running on. When I start keyble-sendcommand on my desktop PC, I guess this takes about one second or so. But when I start keyble-sendcommand on a Raspberry Pi for example, this takes significantly longer.

It should indeed be possible to solve the first problem via the "-adt 0" command line parameter - just as you tried. The problem is: The -adt 0 parameter basically has no effect when keyble-sendcommand is running in one-shot-mode, where you pass the command to be executed on the command line via the -c command line option, where keyble-sendcommand executes just one command and then instantly terminates again.

To get the best response time, keyble-sendcommand must be run in continuous mode, or what's called "Piping data into keyble-sendcommand" in the documentation, and combining this with the -adt 0 command line option. The usual way to do this is to make keyble-sendcommand controllable via MQTT, as described in the docs. That way, it should be possible to reduce the delay to less than one second.

To get some debug output that might help identifying what causes the delays, you could also try prepending the keyble-sendcommand command with DEBUG="simble:*,keyble:*"

[nfcplusplus]

Hi, the delay between initiating a command and the command being executed is mainly driven by two factors:

1. The time it takes to connect to the smart lock via Bluetooth LE. On my PC, this time is roughly 1-1.5 seconds.
2. The time it takes to initialize the keyble-sendcommand tool (for example loading the required node.js modules, precompiling the Javascript code etc.). How long this takes depends a lot on the hardware keyble-sendcommand is running on. When I start keyble-sendcommand on my desktop PC, I guess this takes about one second or so. But when I start keyble-sendcommand on a Raspberry Pi for example, this takes significantly longer.

It should indeed be possible to solve the first problem via the "-adt 0" command line parameter - just as you tried. The problem is: The -adt 0 parameter basically has no effect when keyble-sendcommand is running in one-shot-mode, where you pass the command to be executed on the command line via the -c command line option, where keyble-sendcommand executes just one command and then instantly terminates again.

To get the best response time, keyble-sendcommand must be run in continuous mode, or what's called "Piping data into keyble-sendcommand" in the documentation, and combining this with the -adt 0 command line option. The usual way to do this is to make keyble-sendcommand controllable via MQTT, as described in the docs. That way, it should be possible to reduce the delay to less than one second.

To get some debug output that might help identifying what causes the delays, you could also try prepending the keyble-sendcommand command with DEBUG="simble:*,keyble:*"

Thanks alot for your explanation. I have no desktop I am indeed sending the command from the terminal of a bunch of old laptops, no wonder it takes so long.

This might be unrelated but is there any way to add a physical open button to the Eqiva smart lock? There are already two unlock and lock button on the smart lock but I really need is an open button. This way I do not have to use keyble or bluetooth at all and eliminate the delay completely. I want to connect the (hypothetical) open button to the GPIO of my raspberry pi 3 and send a simple command to open the lock/door. I think it is worth mentioning that the pi is connected to an RFID reader and when the authorised key is read, it simply sends an open command (at the moment via keyble) to the smart lock. It is working but the delay gets sometimes so frustrating that you want to stick the key and let yourself in.

I have looked on the internet to find any diagram or schematics of the Eqiva smartlock t but I found so far nothing.

[oyooyo]

This might be unrelated but is there any way to add a physical open button to the Eqiva smart lock? There are already two unlock and lock button on the smart lock but I really need is an open button. This way I do not have to use keyble or bluetooth at all and eliminate the delay completely. I want to connect the (hypothetical) open button to the GPIO of my raspberry pi 3 and send a simple command to open the lock/door.

Can't you use the physical "unlock" button as an "open" button? I haven't tried it myself, but I assume it would be rather easy to wire a RPI GPIO pin to the unlock/lock buttons in order to simply control the smart lock via the RPI GPIO pins.

I think it is worth mentioning that the pi is connected to an RFID reader and when the authorised key is read, it simply sends an open command (at the moment via keyble) to the smart lock. It is working but the delay gets sometimes so frustrating that you want to stick the key and let yourself in.

Nice solution, exactly what I was originally planning to do as well.

I can easily understand that some 5-7 seconds delay feels way too long. Running keyble-sendcommand in continuous mode with -adt 0 should dramatically reduce the delay to maybe half a second, but if you have a Raspberry Pi close to the smart lock anyway, that should be an even better solution.

[nfcplusplus]

Can't you use the physical "unlock" button as an "open" button? I haven't tried it myself, but I assume it would be rather easy to wire a RPI GPIO pin to the unlock/lock buttons in order to simply control the smart lock via the RPI GPIO pins.

No, it does not work. The current buttons can only lock and unlock the door (turning the lock 2 or 3 rotations forward or backward). Let's say you go out of the apartment to pick the mails and you simple close (not locked) the door behind you. In this scenario, when the unlock button is pressed, it does nothing. It simply flashes green and beeps since it is already in unlock position. On the terminal you get: Moving and then Unlocked, but no rotations happen since it is already in unlock position. What really needed is to open the door but it does not happen. It can be only done via app or your program.

I can easily understand that some 5-7 seconds delay feels way too long. Running keyble-sendcommand in continuous mode with -adt 0 should dramatically reduce the delay to maybe half a second, but if you have a Raspberry Pi close to the smart lock anyway, that should be an even better solution.

I have not tried the MQTT yet but I will be soon. I hope this solves the delay problem and I'll be letting you know.

[oyooyo]

No, it does not work. The current buttons can only lock and unlock the door (turning the lock 2 or 3 rotations forward or backward). Let's say you go out of the apartment to pick the mails and you simple close (not locked) the door behind you. In this scenario, when the unlock button is pressed, it does nothing. It simply flashes green and beeps since it is already in unlock position.

Damn, you're right. I thought it would open the door, but indeed, the light only flashes green. I'm afraid I do not see an easy solution to controlling the lock via GPIO pins then. :-(