Slow response

Nuki APIs Bluetooth API
1

I’m using the nukiPyBridge which is working but I’m not satisfied with the speed.
The first steps take about 6 seconds until the command will be processed:
Starting BLE adapter…
Init Nuki BLE connection…
Nuki BLE connection established

after about 6 - 7 seconds the command is processed:
Nuki CHALLENGE Request sent: Nuki_REQ
Payload: Nuki_CHALLENGE

I also use the FHEM-API, here the speed is okay - about 3 seconds. But with FHEM and the callback-function enabled, I can send one command which will be executed immediately - but sending the next command soon after the first will end in error
“NUKIBridge (Nuki_Bridge) - invalid json detected: HTTP 503 Unavailable”
and the command isn’t executed.

Whitout callback-function the next command will be executed in FHEM correct. But I want let the callback-function enabled, so that I can get the correct status of the nuki.

What can I do to improve the performance?
Greetings Raimund

2

I’m using the nukiPyBridge

I tried to contact the developer of NukiPyBridge (as it was not done by us), who could contribute the most here, but could not reach him yet.

I also use the FHEM-API

I am not 100% to what you are reffering here. https://wiki.fhem.de/wiki/NUKI?

3

Hi. I’m the developer of the nukiPyBridge.
Unfortunately it’s been a while since I wrote this code and I’m not fully familiar with it anymore.
That being said, I do remember that I deliberately needed to add some sleep statements in my code (and that of the Bluetooth library) to make it work reliable with the nuki lock.
Don’t really know how to solve that…
Sorry

Br
Jan

1 Like
4

Got the same issue with response time here. Since my original bridge is dead, I used the BLE module of my doorpi installation, which is naturally in perfect range.
The problem with response is in the modified gatttool.py which Jan changed for some timing and event corrections.
In function char_write_handle you may tune the try-block to something like:

try:
	self._receiver.wait("char_written", timeout=5) 
	waitingForIndications = True
	while waitingForIndications == True:
	try:
		self._receiver.wait("indication", timeout=0.1)
		self._receiver.clear("indication")
	except NotificationTimeout:
		waitingForIndications = False 
except NotificationTimeout:
	log.error("No response received", exc_info=True)
	raise

The first timeout could be as high as you want it to be. It is the timeout for checking if there is any response. It is hopefully never triggered, as long as the lock isn’t dead.
The second timeout is really important to overall performance. It is for looping the response, until there isn’t any more data to receive. The stop condition in Jan’s script is triggered by an exception, which is why the second timeout is also triggered exactly once at the end of the data even if everything ran nice and smooth.

My connection is running rock-solid with 5s / 0.1s. Response time was reduced down to what my wife would call “quick enough”…

2 Likes
5

@paddsen

I have forked the repo a year back and made a lot of changes to speed it up and make it more use friendly (rest API for example). I’m still not really satisfied with the speed, it takes approx 10 to 15 seconds to unlock. Are you still seeing speeds of 5 seconds with the latest firmware (2.18.15)?

My gatttool changed and it’s not using the indication while loop anymore so that should not be the problem.

This is the repo: https://github.com/giejay/nukiPyBridge, am I correct to assume that the gatttool shouldn’t be the problem anymore?