Nuki Card with Callback support (supports both Lock & Opener, it replaces the official integration)

Share your Projects!
, , ,
629

another twwet. just had another occurence of the callback/list failing. This time I looked it up right after I opend and closed the door. Lokks like the bridge can handle list and info request during this without errors bur hails with callback/list. They are also not logged, at least I haven’t found any entries of callback/list in the log. This is the Nuki log:
[{“timestamp”: “2021-08-02T14:15:20+00:00”, “type”: “HTTP-Log”},
{“timestamp”: “2021-08-02T14:13:36+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2021-08-02T14:13:30+00:00”, “type”: “HTTP-List”},
{“timestamp”: “2021-08-02T14:13:03+00:00”, “type”: “SSE-Connected”, “serverNum”: 9},
{“timestamp”: “2021-08-02T14:12:59+00:00”, “type”: “WLAN-Connected”, “ipAddr”: “192.168.1.47”},
{“timestamp”: “2021-08-02T14:12:55+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-Disconnected”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2021-08-02T14:12:55+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-Disconnect”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2021-08-02T14:12:55+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-ConnectionTimeout”},
{“timestamp”: “2021-08-02T14:12:53+00:00”, “type”: “WLAN-Disconnected”},
{“timestamp”: “2021-08-02T14:12:53+00:00”, “type”: “SSE-Disconnected”, “serverNum”: 8},
{“timestamp”: “2021-08-02T14:12:50+00:00”, “type”: “HTTP-Post”, “nukiId”: “192ABBDD”},
{“timestamp”: “2021-08-02T14:12:50+00:00”, “nukiId”: “192ABBDD”, “type”: “SSE-KeyturnerEventReq”},
{“timestamp”: “2021-08-02T14:12:50+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-ReadStates”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:12:50+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-TurnOnNotific”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:12:50+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-Connected”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2021-08-02T14:12:50+00:00”, “type”: “BLE-Connect”, “macAddr”: “54D2722ABBDD”},
{“timestamp”: “2021-08-02T14:12:50+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-Connect”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:12:50+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-StateChanged”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:09:59+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-Disconnected”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2021-08-02T14:09:59+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-Disconnect”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2021-08-02T14:09:59+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-ConnectionTimeout”},
{“timestamp”: “2021-08-02T14:09:54+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-CommandComplete”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:09:54+00:00”, “nukiId”: “192ABBDD”, “type”: “SSE-KeyturnerResponse”, “pairIndex”: 0, “bytes”: 205},
{“timestamp”: “2021-08-02T14:09:54+00:00”, “nukiId”: “192ABBDD”, “type”: “SSE-KeyturnerResponse”, “pairIndex”: 0, “bytes”: 273},
{“timestamp”: “2021-08-02T14:09:54+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-AlreadyConnected”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:09:54+00:00”, “nukiId”: “192ABBDD”, “type”: “SSE-KeyturnerRequest”, “pairIndex”: 0, “bytes”: 96},
{“timestamp”: “2021-08-02T14:09:53+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-CommandComplete”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:09:53+00:00”, “nukiId”: “192ABBDD”, “type”: “SSE-KeyturnerResponse”, “pairIndex”: 0, “bytes”: 245},
{“timestamp”: “2021-08-02T14:09:53+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-AlreadyConnected”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:09:53+00:00”, “nukiId”: “192ABBDD”, “type”: “SSE-KeyturnerRequest”, “pairIndex”: 0, “bytes”: 56},
{“timestamp”: “2021-08-02T14:09:53+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-CommandComplete”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:09:53+00:00”, “nukiId”: “192ABBDD”, “type”: “SSE-KeyturnerResponse”, “pairIndex”: 0, “bytes”: 229},
{“timestamp”: “2021-08-02T14:09:53+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-AlreadyConnected”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:09:53+00:00”, “nukiId”: “192ABBDD”, “type”: “SSE-KeyturnerRequest”, “pairIndex”: 0, “bytes”: 56},
{“timestamp”: “2021-08-02T14:09:53+00:00”, “type”: “SSE-KeyturnerEventResp”},
{“timestamp”: “2021-08-02T14:09:53+00:00”, “type”: “HTTP-Post”, “nukiId”: “192ABBDD”},
{“timestamp”: “2021-08-02T14:09:53+00:00”, “nukiId”: “192ABBDD”, “type”: “SSE-KeyturnerEventReq”},
{“timestamp”: “2021-08-02T14:09:53+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-ReadStates”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:09:52+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-TurnOnNotific”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:09:52+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-Connected”, “pairIndex”: 0, “bleHandle”: “0001”},
{“timestamp”: “2021-08-02T14:09:52+00:00”, “type”: “BLE-Connect”, “macAddr”: “54D2722ABBDD”},
{“timestamp”: “2021-08-02T14:09:52+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-Connect”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:09:52+00:00”, “nukiId”: “192ABBDD”, “type”: “BLE-StateChanged”, “pairIndex”: 0},
{“timestamp”: “2021-08-02T14:07:33+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2021-08-02T14:07:28+00:00”, “type”: “HTTP-List”},
{“timestamp”: “2021-08-02T14:04:32+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2021-08-02T14:04:27+00:00”, “type”: “HTTP-List”},

the request for callback/list happend at 14:10:30, no entry in the log. Inbetween sould have been at least 2 mor request for list and info. Don’t show in the Nuki log and no errors in HA log.

630

While busy with the lock, with BLE/BT operations, it won’t handle http requests, it can do 1 thing at a time…(I wonder what kind of dumb and weak chipset they are using). So it won’t process a list/info command either.

I will think a little about it, but obviously, there’s not much I can do if the polling happens when you open the door or action the lock. I mean, I could do something if the REST sensors would pass me the status codes of the call, but that’s a limitation of HA, not the bridge.

Anyway, this is a great improvement vs the previous versions of Nuki Card…too bad I can’t make it 100% resilient to the bridge limitations. Serialization is ok from what I can see.

Thanks Joachim, you helped me a lot…will think about it…:slight_smile:

631

I thought about it: instead of using one of the 3 rest sensors as a clock to send the serialized commands, the callback could be used. I think that after a callback (lock action or door action) is the most appropriate time to refresh the sensors sending the commands because the bridge should not be doing anything.

Obviously icontinuously opening/closing the door every 3 secs could create problems…:slight_smile:

Best thing would be asking Nuki devs to send ALL data in the callback, not only the status of the door and lock. If they sent a periodic callback to refresh system info, plus the event based callback, we wouldn’t need to start an http request to the bridge and all these issues would be solved.

632

RC2 released with that modification: Nuki Card v10.0-RC2 (github.com)

@jezinke, the nuki card’s coal-mine canary, can you test it when you can? thanks a lot. :slight_smile:

633

I wrote Nuki devs about these seralization issues and asked if they can implement something on the callback: passing also info/list data through the callback, that would eliminate all http GET calls to the bridge, solving every issue. Hope they listen: Callback only functionality - Bridge HTTP-API - Nuki Developers

634

Devs asked me to open a Feature Request: please vote for it so we have some chance to have it implemented.

Thanks,

Alessandro

3 Likes
635

Hi Alessandro,

I just installed Nuki Card v10.0-RC2. If something happens I will let you know.

636

Thanks a lot Jeroen. 10 minutes ago I added a nowait=1 parameter to the lockaction, could you make sure it’s there? :slight_smile:

rest_command:
  nuki_lock_action:
    url: "{{ states('input_text.nuki_bridge_url') }}/lockAction?action={{ action }}&nowait=1&nukiId={{ states('sensor.nuki_id') }}&token={{ states('input_text.nuki_bridge_token') | urlencode }}"
637

RC3 released. Sorry, I’m in active dev. mode today, and I’m constantly improving things.

I optimized some critical delays in RC3, should work much better than RC2 if you open/close door very frequently (every 5-10secs.) like during my tests. :slight_smile:

Thanks for testing it, let me know how it works.

638

@spokin you won’t believe the impact this small difference in calling the script from the webhook makes. :slight_smile:

image
image982×223 9.1 KB

image
image644×724 60 KB

639

Nuki Card v10.0 released: breaking change release. introduced serialization of http calls to the bridge, finally those errors in the log due to the bridge limitations should disappear. Had to redesign the way to communicate with the bridge, and am very happy with the result. Hope you’ll notice the difference. Just upgrade the code and restart HA.

Enjoy it, and let me know how it works for you. :slight_smile:

1 Like
640

Just installed V10 and that change is seriously impressive! <5 seconds for the state to reflect the new value, for lock/unlock and door open/closed. :clap:t2:

Only the usual suspect warnings in the log about the REST sensor and input_select taking more than 10 seconds, following restart of my instance. New warning has appeared, about nuki_bridge_polling_queue already running, but everything works so nothing that I’m concerned about. Just for your info:

2021-08-03 18:31:54 WARNING (MainThread) [homeassistant.components.sensor] Platform rest not ready yet: Unsupported URL protocol ''; Retrying in background in 30 seconds
2021-08-03 18:31:54 WARNING (MainThread) [homeassistant.components.sensor] Platform rest not ready yet: Unsupported URL protocol ''; Retrying in background in 30 seconds
2021-08-03 18:31:54 WARNING (MainThread) [homeassistant.components.sensor] Platform rest not ready yet: Unsupported URL protocol ''; Retrying in background in 30 seconds
2021-08-03 18:32:04 WARNING (MainThread) [homeassistant.setup] Setup of input_select is taking over 10 seconds.
2021-08-03 18:32:04 WARNING (MainThread) [homeassistant.setup] Setup of input_text is taking over 10 seconds.
2021-08-03 18:33:32 WARNING (MainThread) [homeassistant.components.script.nuki_bridge_polling_queue] nuki_bridge_polling_queue: Already running

As always, awesome work!

Thanks. :slight_smile:

641

Installed the V10 and same here, state of lock changes in 1-3 seconds and for the door state the same.
Only 1 warning in the logs:

WARNING (MainThread) [homeassistant.components.script.nuki_bridge_polling_queue] nuki_bridge_polling_queue: Already running

You did a good job again :slight_smile:

642

Installed V10 an hour ago and I second this. No warning or errors here so far…

643

Nuki Card v10.1 released: forgot to configure the script mode, sorry about that.

@Sym0nd0, @madface, @Joerg please let me know if the nuki_bridge_polling_queue: Already running warning doesn’t appear in the logs anymore. Sorry about that.

644

This warning can happen at startup, it’s starting the sensor before the variable that uses it is initialized, no big deal, you can safely ignore it, but it should happen 1 time, not 3. If it happens 3 times, I suspect you are running on a slow system. What platform do you use to run HA?

Ditto, read above. Slow to initialize. :slight_smile:

This is my fault, I forgot one thing, just release v10.1. Sorry.

645

Like in my case: door state is updated in 2 seconds, lock takes a little more. But it’s fast. :slight_smile:

I can always improve it. v10.1 is released, I forgot to configure the running mode of the script, hence that warning you noticed. Sorry about that.

646

0 warnings/errors? Great. :slight_smile:

v10.1 is released.

647

Yeah - even with V10.1 :smiley:

648

Happy. :slight_smile:

And it is quick on status updates of door/lock?