No, the current solution supports only one lock. In order to do a second one I’d have to tweak the code for the name of the REST sensors and the others too, adding a suffix. Didn’t have this in mind as a requisite when I started it. 
Are you using 2 nuki locks?
Even if you add a second nuki using its own dedicated bridge imho will also requires some modifications to the configuration. I just ordered a second nuki without bridge, planning to use it using my existing bridge. I’ll post my results somewhere next week when I had the time to play with it.
Yes, like I wrote before, the configuration needs to be adapted to support more than one lock. Actually, it should be redesigned with this requisite.
Can I get you some JSON’s from it? Just managed to install it partially today (I can open, but not ring to open).
Just tell me what to call and I’ll try to do it
First I need to study the Nuki docs regarding the API etc. then we can make some tests so I can understand how to add it to this integration.
I was also thinking to eliminate all the sensors that provide all technical info regarding the system and place them as attributes of the Door Sensor, that, by the way, already has some attributes. The only downside is the lovelace card: can you show attributes on the card there? IIRC, there was a limitation regarding that.
At first idea didn’t sit well, but the when once again I looked at what attributes (sensors) there are now, well, actually it’s great idea.
In theory, you can then have only one sensor per device - for ex. Lock, Bridge, Keypad (and in future Opener). All attributes related to sensor can be part of the sensor. If anyone needs it, you can always create sensor from attribute and it should make adding multiple Lock devices also a bit more easier (I think) as you only have to handle individual sensor name not multiple sensors.
The question is would door be also separate sensor for all those using Smart Door sensor (BETA) - as this can be used in other automation as possible trigger. But that’s something to think of in future of course As I presume, this will take some time.
Hi all, and especially Alex -
big thanks for my side.
Bought a Raspberry a few days ago, and this is my first step into the world of HA.
To be honest, this is all quite complex, and I had a hard enough time to copy and paste the code, and start learning that way a bit about how the system works.
Now I think I am OK, the card is set up, I don’t get any errors, and the Nuki Door State is correctly shown.
But: none of the other sensors are. E.g. the battery level is not shown in the card.
Is that something anybody else in this thread was struggling with?
I think I’ll do it that way, and if someone needs to export some of those attributes to a card, they can create a “shadow sensor” linked to the state of the attribute.
Well, the keypad actually is not a device from the Nuki API point of view. You can have 2-3 devices: the lock, the door and the bridge. Right now we have two devices with this integration: the lock and the door.
I don’t understand what you mean, the door is already exposed as a device/sensor, actually it’s the main one, and I use its attributes to link the Lock sensor/device.
Right now I’m busy on some other projects, but as soon as I get back on the Nuki, I’ll redesign it and implement the new version. I’ll contact you to test the opener.
thanks for your kind words.
all the other sensors get their status from the two REST sensors, so first thing: make sure those two rest sensors are working. Check the syntax and also check the log for errors. If those 2 REST sensors are not working, all the info about the system is not retrieved so all those status sensors will not work.
I’m pretty sure you have a copy&paste error somewhere that is preventing those sensors to work as designed.
Aha!
Solved!
In my secrets.yaml I had for “nuki_bridge_host:” the IP of the Bridge, but with HTTP in front of it. (e.g. HTTP://192.168 etc)
And this was clashing with the rest_sensor code, as it has HTTP in the code already. Took it out in the secrets.yaml, and now it is working.
Thanks Alex!
Great. Glad you solved it and it’s working also for you. 
Sorry, me again, total noob.
I get this error - I don’t have the keypad:
Template variable warning: ‘dict object’ has no attribute ‘keypadBatteryCritical’ when rendering ‘{% if states(‘sensor.nuki_endpoint_list’) == “OK” %} {{ state_attr(‘sensor.nuki_endpoint_list’, ‘lastKnownState’)[‘keypadBatteryCritical’] }} {% endif %}’
Can I delete this line from the template then?
Yes, you can delete it.
Don’t delete it, it’s a bug: I didn’t check if the keypad existed. Please replace with this and tell me if it works:
- name: "Nuki Keypad Battery Critical State"
icon: mdi:battery-alert-variant-outline
state: >
{% if states('sensor.nuki_endpoint_list') == "OK" %}
{% if state_attr('sensor.nuki_endpoint_list', 'lastKnownState')['keypadBatteryCritical'] != 'unknown' %}
{{ state_attr('sensor.nuki_endpoint_list', 'lastKnownState')['keypadBatteryCritical'] }}
{% endif %}
{% endif %}
Please also change this in the binary_sensor on the top of templates.yaml (the door sensor)
keypad_battery_critical: >
{% if trigger.platform == 'webhook' %}
{% if trigger.json.keypadBatteryCritical != 'unknown' %}
{{ trigger.json.keypadBatteryCritical }}
{% endif %}
{% else %}
{% if states('sensor.nuki_keypad_battery_critical_state') != 'unknown' %}
{{ states('sensor.nuki_keypad_battery_critical_state') }}
{% endif %}
{% endif %}
I changed it, getting the same error; seems like the “unknown” state is not carried over to the if-statement:
Template variable warning: ‘dict object’ has no attribute ‘keypadBatteryCritical’ when rendering ‘{% if states(‘sensor.nuki_endpoint_list’) == “OK” %} {% if state_attr(‘sensor.nuki_endpoint_list’, ‘lastKnownState’)[‘keypadBatteryCritical’] != ‘unknown’ %} {{ state_attr(‘sensor.nuki_endpoint_list’, ‘lastKnownState’)[‘keypadBatteryCritical’] }} {% endif %} {% endif %}’
I talked about this in a previous post: Nuki Card with callbacks (official integration not needed) - #97 by alexdelprete
It’s tricky, but I want to solve it. Please try this and tell me what it does:
- name: "Nuki Keypad Battery Critical State"
icon: mdi:battery-alert-variant-outline
state: >
{% if states('sensor.nuki_endpoint_list') == "OK" %}
{% set my_state = state_attr('sensor.nuki_endpoint_list', 'lastKnownState')['keypadBatteryCritical']
{% if my_state != 'unknown' %}
{{ state_attr('sensor.nuki_endpoint_list', 'lastKnownState')['keypadBatteryCritical'] }}
{% endif %}
{% endif %}
Mh, unfortunately nothing:
Invalid config for [template]: invalid template (TemplateSyntaxError: expected token ‘end of statement block’, got ‘{’) for dictionary value @ data[‘sensor’][16][‘state’].
It’s fine Alex if it doesnt work, not a worry at all, its not limiting the functionality. Just came across it, and wanted to raise it. To me it doesnt matter
It’s not for you, the code has to work for all those who use Nuki, even if they don’t have the Keypad.
So you’re helping me solve it, if you want obviously.
I gladly help
Ok, this test works here, hope it works for you too, let me know:
- name: "Nuki Keypad Battery Critical State"
icon: mdi:battery-alert-variant-outline
state: >
{% if states('sensor.nuki_endpoint_list') == "OK" %}
{% if state_attr('sensor.nuki_endpoint_list', 'lastKnownState')['keypadBatteryCritical'] != null %}
{{ state_attr('sensor.nuki_endpoint_list', 'lastKnownState')['keypadBatteryCritical'] }}
{% endif %}
{% endif %}
And also this in the binary door sensor at the beginning:
keypad_battery_critical: >
{% if trigger.platform == 'webhook' %}
{% if trigger.json.keypadBatteryCritical != null %}
{{ trigger.json.keypadBatteryCritical }}
{% endif %}
{% else %}
{% if states('sensor.nuki_keypad_battery_critical_state') != 'unknown' %}
{{ states('sensor.nuki_keypad_battery_critical_state') }}
{% endif %}
{% endif %}