Documentation states to test is None but it doesn’t work. That’s why I had to go trial&error. Finally I had the idea of testing the old-school NULL. 
Did you change also the keypad_battery_critical? Can you show me the attributes list of the Nuki Door State binary sensor (binary_sensor.nuki_door_state)? Thanks.
Can you show me the state of sensor.nuki_keypad_battery_critical_state and also can you please trigger an event, opening/closing door or locking/unlocking the lock, then repost me that screenshot, it should have “Trigger Platform” set to webhook.
Thanks.
Correct, and it should be unavailable. I added availability to that sensor. I also added “not installed” in case the keypad is not installed.
Final code, to be tested. It should show not installed in the attributes and the sensor that didn’t update anymore shouldn’t even be available. Let me know.
- name: "Nuki Keypad Battery Critical State"
icon: mdi:battery-alert-variant-outline
availability: {{ state_attr('sensor.nuki_endpoint_list', 'lastKnownState')['keypadBatteryCritical'] != null }}
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'] }}
{% else %}
not installed
{% endif %}
{% endif %}
keypad_battery_critical: >
{% if trigger.platform == 'webhook' %}
{% if trigger.json.keypadBatteryCritical != null %}
{{ trigger.json.keypadBatteryCritical }}
{% else %}
not installed
{% endif %}
{% else %}
{% if states('sensor.nuki_keypad_battery_critical_state') != 'unknown' %}
{{ states('sensor.nuki_keypad_battery_critical_state') }}
{% else %}
not installed
{% endif %}
{% endif %}
Documentation states to test
is Nonebut it doesn’t work.
Not sure that explains your problem though.
@123 explanations make sense. The problem is that it’s true that HA is inconsistent at first glance, or, let’s say, fails to let this determination be dev-friendly. If I want to test if an object exists, there should be a proper function for every entity so you can do, e.g.: isNone(sensor.xxx) or isNone(state_attr(sensor.xxx.yyy)). Something like that.
During the developement of this integration, I lost a ton of time due to this inconsistency. I posted before about this: Nuki Card with Callback support (supports both Lock & Opener, it replaces the official integration) - #97 by alexdelprete
Obviously this is due my lack of experience with HA, but in general, even if now I know it’s inconsistent, in the future I will still fall in the same issues probably.
Yes, it doesn’t work, I read the docs while developing this. Read the post I linked in previous post. The only one that works, when an attribute does not exist, is == null. Unknown and null are two totally different states, as @123 also stated in the thread you linked. Unknown is for strings.
There should be a universa isNone() for every kind of entity. Otherwise it becomes a mess.
availability: {{ state_attr('sensor.nuki_endpoint_list', 'lastKnownState')['keypadBatteryCritical'] != null }}
Something is wrong with the commas in here, it’s giving me an error while saving
missed comma between flow collection entries at line 238, column 78:
… endpoint_list’, ‘lastKnownState’)[‘keypadBatteryCritical’] != nu …
no comma missing, just quote it.
Let me know if it works. Thanks for your help.
availability: "{{ state_attr('sensor.nuki_endpoint_list', 'lastKnownState')['keypadBatteryCritical'] != null }}"
In the template editor, no quotes are needed. Another weird thing…
Strange, I mean I copied it before, and it wasn’t working - but now it is.
Thanks for all your efforts - I will keep monitoring the log and report errors if I see any.
I added this entry to the rest_commands.yaml:
nuki_open_door_action:
url: "http://{{ states('sensor.nuki_bridge_host') }}:{{ states('sensor.nuki_bridge_port') }}/lockAction?nukiId={{ states('sensor.nuki_id') }}&token={{ states('sensor.nuki_bridge_token') }}&action={{ 5 }}&type={{ 3 }}"
content_type: "application/json"
This way it is possible to have a service for opening the door, which can be handy if you have an intercom system that can send a command to HA for opening the door. You can then create an automation that triggers on the “open door” command and calls the service “RESTful Command: nuki_open_door_action”. This is what I’ve done with my Dahua VTO2202F-P, dahuavto2mqtt, your work and the NUKI smart lock
Great that people use their creativity with this integration for their specific needs. Personally I would never automate opening+unlatching of the door. Too many things can go wrong, but it’s your system and your house, do what you prefer.
There’s an error in your command: it should be deviceType, not type.
Furthermore, content_type isn’t needed, it’s for the request, and for the request you use URL-parameters, not a json payload. The bridge answers with a JSON list, but that doesn’t depend on setting the content_type in the request.
Hi Alex,
Thank you for your reply. “type” is correct, at least it is doing what I want and I was combining your “nuki_lock_action” from the first post, with what I found on https://api.nuki.io/#/ in the section “Smartlock” → “/smartlock/{smartlockId}/action”. There nuki says you have to put in an action 5 and type 3 as parameters…
You are confusing many things:
the command you posted (same as mine) use the Nuki BRIDGE API, not the SmartLock. You used the /lockAction bridge api command, not the smartlock action of the Web API. Check the command you posted.
From the bridge API doc: I highlighted the two relevant parameters.
Device type can be 0 or 2
These are the possible Lock Actions:
The fact that works doesn’t mean it’s the correct way of doing things, it could be pure luck out of a messy configuration.
Basically you told the bridge to do an action 5 (lock&go with unlatch). While in reality you wanted to do an unlatch (action=3). But the API you have consulted (Nuki Web API) has nothing to do with what you achieved with that command.
Where did you read that you need to put action 5 and type 3 as parameters? On that page I didn’t find any mention. Do a screenshot please, thanks.
If you want to do the unlatch via Dahua, just call my original command, with no changes, like this:
service: rest_command.nuki_lock_action
data:
action: 3
That is why I made that command “generic”: so that you can pass it the action you need and it will execute it, as per Bridge API documentation. No need to modify anything or define another command with fixed parameters like you did.
The idea was that when touching the lock icon on my tablet the icon should change and I can be sure that the state change was triggered. As I wrote it takes about 5 sec to unlock the door (2 turns of the key) and it takes several more seconds till the icon on the Lovelace interface changes.
Additionally I have a green led strip outside next to the door and this is turned on when the lock is in the open state (so I can see if the door is open when coming home). It takes about 30 sec till this automation is done.
Does anybody have an idea why this takes that long?
This is my automation (with the NUKI integration in HA)
alias: WLED Haustuere an
description: ‘’
trigger:
The integration receives a callback from the bridge, that happens like this:
I’d say that steps 1-4 happen in 1-2 seconds.
Steps 4-5 take 5 seconds if configured with full nr. of key-turns
Steps 5-6 take 2 seconds (sometimes more like 4-5 secs, but it’s an exception)
Step 7 is immediate, let’s say 1 second
So steps 1-7 normally should take at maximum 10 seconds (5 of which are for the key-turns).
Try to debug each step and see if the problem is there.
Regarding your automation, a question: is entity_id: lock.haus the lock made with this integration or is it the official Nuki integration lock? Because that one is based on polling, sometimes it takes 20-30 secs to update. Make sure you are using the lock device of this integration and not the official one. If you want to be sure, uninstall the official one, it’s not needed.
Ciao Alessandro,
thank you for your quick reply. My current automation is using the sensor provided by the official NUKI integration, not your solution. I will reprogram the automation using the attribute lock_state of the binary_sensor.nuki_door_state entity (based on your solution). I will post the result.
The more general question again: is there a way to change the icon of a switch card on a Lovelace dashboard temporarily when the icon is touched?
Thank you in advance.
That’s what I suspected. We gave for granted you were using my integration, because you’re writing in this thread, but I had the feeling that was not the case.
This integration was made exactly for the problem you are seeing: the official integration is based on polling, so you have to wait for the polling timer to expire before seeing a status update. That is your problem. You have the solution, but it’s up to you to decide using it or not. Next time please specify that you are NOT using this integration but you are looking for help for the official integration. 
I don’t know the answer to this because I never had the need. But I’m pretty confident that if you use this integration and not the official one, the benefits will let you reconsider the need.
You could add an instant notification via telegram (or other platform) when you action the lock/unlock.
Ciao,
Alessandro