You’re using Nuki Card, not the Nuki NG custom component, right? I would advice to switch to the component but if you need scripts to make buttons, check this post.
The battery lifetime is a huge over promise - would not place too much reliance. I bought the battery pack for a nuki 2.0, 6months they indicate but that’s perhaps for people who don’t unlock /lock their door; in my experience 6 to 8 weeks is more accurate. I had the pack replaced by customer service; replacement pack has exactly the same issue.
I have the 2.0 since august, still the original batteries (not rechargeable), I open and close at least once a day. It tells me 62% left.
If someone has experienced low battery, how does Nuki behave ? Does it die suddenly or are there other symptoms before that ?
Why I ask ?
For a week or two, I get the “jammed” status every now and then. I don’t see a reason.
Although it’s almost when I changed from the card to the custom component ? Could it be ?
Or could it be that with colder weather, the Nuki has troubles ? (it’s on my front door, and I’ve noticed Nuki Lock gets kind of cold)
First of all, thanks a lot for this! It is amazing 
Recently joined HA and this was a must have/1st integration to enable!
Could anyone share or provide pointers on how to trigger a HA notification/action once the Opener gets a ring?
Thanks,
anthonws.
p.s. I don’t have Ring to Open active.
First of all, thanks for the awesome HACS integration!
Quick question regarding an automation we used to figure out together with the Nuki Card V11.
How to implement this with the new custom component? Same problem as before: I can’t use the RTO = active condition because it gets disabled (locked) as soon as someone rings the door.
Any ideas? Any help is appreciated!
This automation for the custom component would open the yourlock1 if:
The group is at home
RTO is (was) enabled and the doorbell rings
- id: "nuki_rto_unlock_smartlock"
alias: "Nuki RTO Unlock SmartLock "
trigger:
- platform: state
entity_id: sensor.nuki_youropener_state
from: 'rto active'
to: 'opening'
- platform: state
entity_id: sensor.nuki_youropener_state
from: 'rto active'
to: 'open'
condition:
- condition: and
conditions:
- condition: state
entity_id: group.awesome_people
state: home
action:
- service: lock.open
entity_id: lock.nuki_yourlock1_lock
If you don’t use RTO then you have to use the ring_action binary_sensor (for me it’s binary_sensor.nuki_opener_ring_action)
The trigger would look like:
trigger:
- platform: state
entity_id: binary_sensor.nuki_opener_ring_action
from: 'off'
to: 'on'
4 Likes
Thanks for providing support Mike, I appreciate it.
After updating home assistant to the latest version, I noticed these warnings in the logfile. Functionality doesn’t seem to be impacted.
2022-02-03 22:43:35 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'int' got invalid input 'unknown' when rendering template '{% if states('input_number.nuki_bt_state') | int == 1 %}
mdi:bluetooth-connect
{% elif states('input_number.nuki_bt_state') | int == 2 %}
mdi:bluetooth-off
{% else %}
mdi:bluetooth-audio
{% endif %}' but no default was specified. Currently 'int' will return '0', however this template will fail to render in Home Assistant core 2022.1
I’m not maintaining Nuki Card anymore, since it has been ported to a custom component (check first post), you can find it here: https://github.com/kvj/hass_nuki_ng
1 Like
Sorry, my bad. Honestly didn’t see the update, I just skimmed the first post to see if there was a new version.
Thanks, I’ll check out the new component.
No problem, we’re still here in case you need support for the component. In case of problems write here or open an issue on github.
1 Like
Thanks, so far everything worked flawlessly and I’m really impressed with the custom component. I can finally see the usage of the keypad as well.
A quick question to the people who are using the opener. When im trying to open the external gate with
- service: lock.open
entity_id: lock.nuki_opener_lock
i have to do this 2-4 times until the opener is blinking and opens the electric strike actuater.
If it opened and i repeat it works every time but if i wait a few minutes it is the same problem.
Is this only my opener? What Firmware is yours, mine is on 1.7.3?
+1 Last attempts to open my building door failed. I had to click a few times, and eventually I think only when I opened the actual entity details (long press on card [ Android app]) it changed color and was then ready to receive instructions.
Hey guys, i have setup https://github.com/kvj/hass_nuki_ng and it’s working.
Also using my bridge access token which worked like charm in fhem.
Sometimes the lock states are a little bit slow.
My “binary_sensor.nuki_bridge_bridge_callback_set” is on/true.
So my question are:
- Does the true/on of the binary sensor mean my callback is really working?
- If not, how can i check if the callback is working?
thx
If you open the sensor and check its attributes, you’ll see the URL that is in the callback list of the bridge. That url is configured by the component when you first configure it. The binary_sensor is simply telling the user that the callback is present on the bridge.
When the lock or door sensor changes state, the bridge calls that url to communicate the change of state. If everything works fine it is immediate. That means that if you have the door sensor and open the door, you should see the door transition to the open state. If you lock the lock, you should see immediate transition too. If it takes more than 3 seconds, it means there’s a problem.
First thing: double-check the url that you see in the binary sensor, make sure the IP and port are correct, those are the HA ip and port, and that’s where the bridge calls back. If those parameters are correct, and you still don’t see state changes in 3-4 seconds then that’s not the problem.
Second thing: the bridge doesn’t support HTTPS, its hw is very limited (and the fw too). So make sure the URL is plain http. If you hardened HA configuration to support only https, that is your problem.
Third thing: you can enable debug logging for the component in the logger integration, adding this line:
custom_components.nuki_ng: debug
After restarting HA, all activity of the components, callbacks included, will be written in HA logs with many details, and you can check if the callback has been received.
Let us know how it goes.
Thanks a lot for your help.
Yes the callback seems correct:
But sometimes it takes up to ~12 seconds until the state changes. Sometimes it takes ~5 seconds.
In may case, it’s set with the local hostname (because when i set it up i was accessing HA with the host name). Does the bridge support hostnames?
When i access the link internally with my browser i get “405: Method Not Allowed”.
I think this does mean that i just have not accessed the callback API correctly but the callback URL is working, right?
thx
@alexdelprete i solved it by removing the integration and readding it with the HA IP address instead of the hostname for the internal URL.
Now it’s working and states changing way faster.
thx
pOpY
1 Like