Perfect, this worked! Thank you so much. No more errors in the log!
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:
- From the api.nuki.io site (totally different respect to that command, it tells you how to call their cloud’s Web API), check screenshot below, you should do a POST (that command you used does a GET), and you should pass parameters through a JSON list, so you should also set the content_type.
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:
- platform: state
to: unlocked
entity_id: lock.haus
condition: []
action: - service: light.turn_on
target:
entity_id: light.wled
data:
brightness_pct: 100
color_name: green
mode: single
The integration receives a callback from the bridge, that happens like this:
- you click the lock/unlock
- the integration sends the command to the bridge via REST command (wifi)
- the bridge sends the command to the lock via bluetooth
- the lock starts locking/unlocking
- when the lock has completed the action it notifies the bridge via bluetooth
- the bridge then does the callback configured for this integration (wifi)
- the integration shows the appropriate status on the card
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.