I have no more ideas to improve communication with the bridge.
@alexdelprete Thanks for the great script, works (almost) out-of-the-box for me.
I’ve slightly updated my variant, to use “Simple Lock Actions” API, instead of “Lock Actions”. The reason - my door is knob type, so lock.unlock did nothing as “unlatch” action was needed. WDYT about the changes below (top-most change)?
Thanks for your kind words, I appreciate it.
This is the actions code of the lock:
lock:
service: rest_command.nuki_lock_action
data:
action: 2
unlock:
service: rest_command.nuki_lock_action
data:
action: 1
As you can notice, I use a parameter action to leverage the /lockAction command of the Nuki Bridge API.
This is the rest command used in the code:
rest_command:
nuki_lock_action:
url: "{{ states('input_text.nuki_bridge_url') }}/lockAction?nukiId={{ states('sensor.nuki_id') }}&action={{ action }}&token={{ states('input_text.nuki_bridge_token') | urlencode }}"
Basically it uses the action variable to execute the appropriate action on the lock.
These are the possible lock actions:
In your case, you just needed to change action: 2 in action: 3 of the actions code, that’s it.
Nuki Card v8.4 released: reconfigured automation mode and rest sensors polling times to avoid concurrent calls to the bridge
Hi,
I was away for 2 days and there are 2 new versions 
Thanks for your hard work!
The last version I used (8.2) was pretty stable… although I had many errors as other users described here.
I was wondering, if the script for the callback list, add and delete was excluded from the automation in a way that I’de have to ran it manually only at first time (or if I get an error) would it be easier on the bridge communication?
maybe split the package into 2 automations so one can turn the callback automation on or off as needed?
Just a thought… does it make sense?
In your case, you just needed to change
action: 2inaction: 3of the actions code, that’s it.
That’s the thing. Users with knob style doors have to change the action value after every code update. Or make this value configurable. Where Simple lock API handles the configuration difference on lock side and executes the right operation.
Have v8.4-rc1 installed and running now for 15 hours, only 1 HA log error. Installung v8.4 now.
Ok, you convinced me. But there’s no need to have two rest commands like you did, we stick with same approach.
Changed lock to this:
lock:
service: rest_command.nuki_lock_action
data:
action: lock
unlock:
service: rest_command.nuki_lock_action
data:
action: unlock
And rest_command to this:
rest_command:
nuki_lock_action:
url: "{{ states('input_text.nuki_bridge_url') }}/{{ action }}?nukiId={{ states('sensor.nuki_id') }}&token={{ states('input_text.nuki_bridge_token') | urlencode }}"
Furthermore, with Simple Lock Actions there’s a minimum fw version to have on the bridge, I’ll put it in the release notes.
1 Like
Nuki Card v8.5 released: changed lock actions to Simple Lock Actions (thanks @kvj), device configuration driven, so if you configured the lock with a knob (instead of a handle) it will unlatch instead of simply unlocking. Min. bridge fw required: v2.5.3.
I’m having fun solving the issues, no problem. 
The problem of communication is not related to the add/delete callbacks to the bridge, that are activated only when needed. There were problems also during normal cycles. Probably it happens when it receives 2 commands simultaneously, now I changed polling times to not have list/info commands in the same seconds. Seems like things are much better now.
I’d rather solve problems than bypass them.
Great to hear that from you. You’re the canary in the coal mine for Nuki Card.
Let me know how it goes. On my system v8.4 (and v8.5 just released) are working much better in terms of comm. errors with the bridge.
tweet, twee,t no error so far since installation of v8.4 except the 3 warnings I mentioned earlier I believe belong to Nuki Card. Looks like you made it by equalizing the Http requests. Great job!
You mean the “Platform rest not ready yet” warnings? Those are when the 3 REST sensors initialize the first time, I found no possible way to avoid those, unfortunately, I even did the check before initializing, but it still pops up. it’s nothing to worry about.
Let’s wait 48hrs before declaring it solved.
Hi Alessandro,
I see a lot has happened since the last few days when I was away with my family, you have changed a lot.
I have forked your code on gist and changed some things:
- Where states were based on texts, changed it to numbers. To my opinion, it’s better to use numerical states instead of text states because it is less sensitive to typos and if a text changes somewhere in the code, your code breaks, with numerical states the chance of breaking the code is much less.
- Implemented the translations again.
The code can be found on my gist. To make it work the, file nuki_languages.json (also published on my gist) has to be put in the packages directory of HA.
2 Likes
Alas, I’m here with some errors after 12+ hours of running v8.5. Sorry.
2021-07-26 08:08:24 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.nuki_bridge_endpoint_list is taking over 10 seconds
2021-07-26 08:08:24 ERROR (MainThread) [homeassistant.components.rest.data] Error fetching data: http://192.168.1.41:8080/list?&token=XXXX failed with
2021-07-26 08:08:24 WARNING (MainThread) [homeassistant.components.rest.sensor] Empty reply found when expecting JSON data
2021-07-26 09:02:15 ERROR (MainThread) [homeassistant.components.rest.data] Error fetching data: http://192.168.1.41:8080/info?&token=XXXX failed with illegal status line: bytearray(b'150')
2021-07-26 09:02:15 WARNING (MainThread) [homeassistant.components.rest.sensor] Empty reply found when expecting JSON data
2021-07-26 10:20:15 ERROR (MainThread) [homeassistant.components.rest.data] Error fetching data: http://192.168.1.41:8080/info?&token=XXXX failed with illegal status line: bytearray(b'150')
2021-07-26 10:20:15 WARNING (MainThread) [homeassistant.components.rest.sensor] Empty reply found when expecting JSON data
2021-07-26 11:38:15 ERROR (MainThread) [homeassistant.components.rest.data] Error fetching data: http://192.168.1.41:8080/info?&token=XXXX failed with illegal status line: bytearray(b'150')
2021-07-26 11:38:15 WARNING (MainThread) [homeassistant.components.rest.sensor] Empty reply found when expecting JSON data
Hi, 2 errors in HA log since 26 hours of running:
2021-07-26 00:14:25 ERROR (MainThread) [homeassistant.components.rest.data] Error fetching data: http://192.168.1.47:8080/list?&token=ucqbkj failed with
2021-07-26 07:20:26 ERROR (MainThread) [homeassistant.components.rest.data] Error fetching data: http://192.168.1.47:8080/list?&token=ucqbkj failed with
Could it be that you have lost your internet connection for a short period of time? There seems to be a bug in the NUki firmware, that is doesn’t work correctly when the internet connection doesn’t exist: API does not respond on commands - Bridge HTTP-API - Nuki Developers
Not as far as I’m aware, I’ve been working all morning, since 8am, and haven’t noticed it drop off.
Not that, that means it hasn’t. I’ll see if I can spot anything in my routers logs.
In another topic on developer.nuki.io, there is also said that the bridge can handle only one request at a time and an integration needs to take care of serialization. So maybe we can find a way to serialize requests…
You are right, numeric states are much bettere, and more resilient to future changes of the API. I will take a look at your code to understand how you implemented the languages feature. Once I understood, I’ll publish it. Thank you so much for your great help. I appreciate it a lot.
1 Like