So, ethernet port. Makes sense for some users. I think zigbee would solve all of issues.
I also forgot one thing: MQTT. Would cover other use cases.
I agree, but i would prefer zigbee over MQTT, because it is a lot simpler. The V2 bridge does have zigbee possibilities, but Nuki did not activate it because they encountered some security issues if I remember correctly.
I would like the end devices to have direct zigbee support, instead of BLE or in addition. The bridge should be a sort of multiprotocol gateway: zigbee, BLE, wifi, MQTT, etc.
Ideally, in a basic scenario, if the SmartLock and the Opener would be zigbee devices, you wouldn’t need the bridge. If you want to integrate it in a more complex scenario, the bridge would cover that, but it would be an optional thing.
The possible zigbee integration was one of the main reasons for me to choose Nuki…
For me too, I thought it was just a matter of time. I really don’t understand what security issues they’re facing.
Hi I bought Nuki not long ago, but I thought was WiFi only, how to make it Zigbee?
Ok thanks. Is this version of HASS integration still valid (and better then official) as of today? (starting post was May some time ago now)
The post is obviously edited/updated every time there’s a new version, as you can see hovering the mouse on the pencil on the top right:
I also invite you to read carefully the first post, and the thread, at least latest 1-2 months to understand better how it works.
Hello.
I noticed strange behavior regarding magnet door sensor.
I put some persistant notification in HA, because I want for example to turn on the lights when door is opened, and vice versa.
On single event (I once opened the door) it triggeres multiple times binary_sensor.nuki_door_state state.
Here is the example code, you can try at your side also:
- alias: 'Test entrance lights'
trigger:
platform: state
entity_id: binary_sensor.nuki_door_state
action:
service: persistent_notification.create
data:
title: >
{{trigger.to_state.state}}
message: "Test indeed."
The same thing is happening with off state (closed door).
Test case:
- Open wide door
- After 1.5s I receive 4 simultanious notifications ON (it should be just one notification)
3.After 0.5s I receive another 5 simultanious notifications ON
1b. Shut the door
2. After 1.5s I receive 4 simultanious notifications OFF (it should be just one notification)
3.After 0.5s I receive another 5 simultanious notifications OFF
Total 18 notifications, and there should be only 2 notifications (ON and OFF)
That’s not true, because you didn’t notice that the door sensor has a lot of attributes that change based on the callback updates, so even if the state of the door doesn’t change, the way you configured the trigger, it would trigger also for attributes change:
Here’s how state trigger works:
There are several options to solve this:
- Use the to: in order to ignore the attributes change, as per docs. You can test for multiple to: states (on and off or just one)
- alias: 'Test entrance lights'
trigger:
- platform: state
entity_id: binary_sensor.nuki_door_state
to:
- "on"
- "off"
action:
service: persistent_notification.create
data:
title: >
{{trigger.to_state.state}}
message: "Test indeed."
- Holding State - it ignores attributes changes
- alias: 'Test entrance lights'
trigger:
- platform: state
entity_id: binary_sensor.nuki_door_state
for: "00:00:01"
action:
service: persistent_notification.create
data:
title: >
{{trigger.to_state.state}}
message: "Test indeed."
- Check Door State ID attribute (2 is closed, 3 is open)
- alias: 'Test entrance lights'
trigger:
- platform: state
entity_id: binary_sensor.nuki_door_state
attribute: door_state_id
to: 3
action:
service: persistent_notification.create
data:
title: >
{{trigger.to_state.state}}
message: "Test indeed."
- Use the template platform:
- alias: 'Test entrance lights'
trigger:
- platform: template
value_template: '{{ is_state('binary_sensor.nuki_door_state', 'on') }}'
action:
service: persistent_notification.create
data:
title: >
{{trigger.to_state.state}}
message: "Test indeed."
And I’m sure there are other ways…choose the one you prefer.
1 Like
I have a strange problem, maybe somebody has an idea where to search why this is so. I don’t know if this is a problem of this card or not.
Round about every week most of the states of the card goes to unknown. Then it looks like this:
The callbacks from the bridge still works, when i open the door the state goes to open. But when it looks like this and i try to activate rto for example it does not work and the log throws the following error:
In the restful call the devicetype and nukiID is missing. The automation i called looks like this:
- service: lock.unlock
entity_id: lock.nuki_opener_action
As said above, this happens after a couple of days if homeassistant runs without restart. I noticed it the third time yesterday. Restart home assistant and everything is working fine for a while again.
There also was an error related to the nuki card, me stupid does not make a screenshot also, but if i remember right it was something about an empty response. If it happens again i will post it also here.
Maybe there is something that can make the nuki automation stumble?
Mike
I’m so out of time lately that I’ll just sit it the corner and not say a word!!!
Haven’t even managed to install latest version of Door opener and feel so shame 
So I’ll leave to everyone who is able to think straight to come up to some good suggestions - my only one has nothing to do with integration capabilities, but physical problem with device - but that’s different story.
BTW - thank you once again @alexdelprete for all the work and everyone for great suggestions, debugging and testing! You all are really amazing.
I’ll make one definitely. It’s on my priority to-do list! Thank you for great solution!
Error code 404 is “not found”, it means the host is not reachable, that means the bridge. If you retry after some seconds, if you have 404 again, it’s a network issue. In those moment try to ping, or better, telnet on port 8080 the bridge so you are sure the host:port is online.
The meeting with Nuki team is at the beginning of october, so we have time. I really look forward to your suggestions. So when you have time, I’d appreciate your feedbacks. 
Thanks for your kind words. And I agree: I’ve met really amazing people during this adventure. That’s what kept me motivated during the long nights when nothing worked as expected and I had to keep going forward.
No rush, when you have time obviously. And if you need anything to produce the video let me know. Thank you.
It will be great to have a step-by-step video of how to install it from scratch, for new users. Instead of a long post.
This was my first thought too, but as i read, 404 means the server is reachable but does not found what it should serve.
Just tried it (and the nuki card works fine at the moment), and when you do this action on the bridge:
http://ip_of_bridge:8080/lockAction?deviceType=None&action=3&nowait=1&nukiId=None&token=yourtoken
you just get HTTP 404 Not Found. And the above is the restful call that happens when i unlock the nuki opener (should be the same when unlocking the nuki lock). It seems that the automation looses the id’s and more of the connected nukis by some reason
Correct. I didn’t notice you had devicetype and nukiid to None. That is the issue. Never happened to me though. It means all the variables are not initialized for some strange reason. But it’s difficult to debug without detailed info.
If it happens every 2 days, why didn’t you notice before? Maybe you restart HA often? I rarely restart it, sometimes for a week, and I never seen something like this.
Do you have some addons/script that reload automations or something like that?