I suspect you have an old firmware on the bridge. The Nuki Card uses Nuki Bridge API v1.12 and requires at least v2.5.0 of the firmware.
Check this post of a couple of days ago.
A request to /info says the firmware is up to date:
“firmwareVersion”: “2.9.3”
I did not use the card code but added the entities manually to lovelace. Won’t this work?
If the fw is ok, it means all the REST calls to the bridge are not working. Check HA logs for errors and report them here.
The lock is actioned through this REST command:
#######################################################################################################################
### ###
### rest commands ###
### ###
#######################################################################################################################
rest_command:
nuki_lock_action:
url: "http://{{ states('input_text.nuki_bridge_host') }}:{{ states('input_text.nuki_bridge_port') }}/lockAction?nukiId={{ states('sensor.nuki_id') }}&token={{ states('input_text.nuki_bridge_token') }}&action={{ action }}"
The info sensors are fed by these two REST sensors:
#######################################################################################################################
### ###
### sensors ###
### ###
#######################################################################################################################
sensor:
- platform: rest
scan_interval: 150
resource_template: "http://{{ states('input_text.nuki_bridge_host') }}:{{ states('input_text.nuki_bridge_port') }}/list?&token={{ states('input_text.nuki_bridge_token') }}"
name: "Nuki Endpoint List"
value_template: "OK"
json_attributes:
- lastKnownState
- firmwareVersion
- nukiId
- name
- platform: rest
scan_interval: 150
resource_template: "http://{{ states('input_text.nuki_bridge_host') }}:{{ states('input_text.nuki_bridge_port') }}/info?&token={{ states('input_text.nuki_bridge_token') }}"
name: "Nuki Endpoint Info"
value_template: "OK"
json_attributes:
- versions
- scanResults
- wlanConnected
- serverConnected
So the REST calls in your case are not working. Check the logs.
Ah, thanks for reminding me. I checked the logs and there was actually a rest error logged.
Obviously it is because the token is not url-encoded. I have special chars in my token which makes the rest call fail. Is there a way to escape url special chars like ‘&’ in the token?
Do I have to escape them manually in the secrets.yaml or can this be done programmatically?
& is %26. Try to use https://www.urlencoder.net/
I didn’t think of this potential issue, thanks for reporting it, I will try to handle it in the code.
Yes, I know. The problem ist that the parameters are sent via the url as get parameters. If there was a way to send them via post, this should fix the problem, shouldn’t it?
We could use
method: POST
payload: '{"token" : "{{ states('sensor.nuki_bridge_token') }}"}'
or similar, right?
You forget that we use an API of the bridge, and unfortunately it uses URL-parameters:
Yes, you are right. POST seems to be allowed for the callback url only…
OK, so we neet to url-encode the token within yaml.
Try this code for the REST command and sensors:
#######################################################################################################################
### ###
### rest commands ###
### ###
#######################################################################################################################
rest_command:
nuki_lock_action:
url: "http://{{ states('input_text.nuki_bridge_host') }}:{{ states('input_text.nuki_bridge_port') }}/lockAction?nukiId={{ states('sensor.nuki_id') }}&token={{ states('input_text.nuki_bridge_token') | urlencode }}&action={{ action }}"
#######################################################################################################################
### ###
### sensors ###
### ###
#######################################################################################################################
sensor:
- platform: rest
scan_interval: 150
resource_template: "http://{{ states('input_text.nuki_bridge_host') }}:{{ states('input_text.nuki_bridge_port') }}/list?&token={{ states('input_text.nuki_bridge_token') | urlencode }}"
name: "Nuki Endpoint List"
value_template: "OK"
json_attributes:
- lastKnownState
- firmwareVersion
- nukiId
- name
- platform: rest
scan_interval: 150
resource_template: "http://{{ states('input_text.nuki_bridge_host') }}:{{ states('input_text.nuki_bridge_port') }}/info?&token={{ states('input_text.nuki_bridge_token') | urlencode }}"
name: "Nuki Endpoint Info"
value_template: "OK"
json_attributes:
- versions
- scanResults
- wlanConnected
- serverConnected
1 Like
Well, it’s still not working. Does the order in which the files (templates.yaml, sensors.yaml etc.) are included matter?
What do you have in the logs now? Same error?
Not exactly. I restarted HA and got this in the logs:
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:269
Integration: Sensor (documentation, issues)
First occurred: 2:55:17 AM (2 occurrences)
Last logged: 2:55:17 AM
Platform rest not ready yet: Unsupported URL protocol ''; Retrying in background in 30 seconds
That is ok, at startup the REST sensors are not ready yet and generate that event. But it works anyway.
So you have no errors now. What do you see in the card?
The same as before.
Lock and door sensor report the correct status (lock after locking or unlocking once) and the host and port are shown. BT RSSI is 0 dB and the rest shows no values.
I just noticed now: why are you pointing at nuki-bridge.axel.dom ? 
That is the hostname of my bridge, you have to put in the secrets variable the ip/hostname of YOUR bridge.
OMG - Don’t knwo how I was able not to see this 
You are in my timezone, it’s late…these things happen. But it’s funny, isn’t it? 
Yes, it actually is!
But the urlencoding was necessary anyways.
Correct, so for a stupid thing, we actually found something to improve.
Let me know if the urlencode filter works with your complex token.
Sure, I’ll test it after the restart.
Edit: All the values are shown now. Semms to work just fine!
You should publish this on HACS!