New openHAB2 Binding for Nuki Smart Locks

mkatter · April 4, 2017, 12:33am

OK, thanks for helping and the feedback!

Have fun with the Smart Lock, the Binding and openHAB2

philKrylc · April 5, 2017, 7:52pm

Great work - works perfectly for me as well. This was the right .things configuration-format for me:

Bridge nuki:bridge:NukiBridge1 [ IP="192.168.x.x", PORT=8080, APITOKEN="xxxxxx", CALLBACK_PORT=8081 ] { 
  Thing smartLock FrontDoorLock [ NUKIID="123456789" ]
}

Now here is my wishlist (it’s Easter period soon ):

Could you add support for pulling the latch?
Could you add a string item that reflects all states?
Could you add the “critical battery” information?

Thanks for your great work and keep it up!

kevin · April 5, 2017, 8:47pm

I’ve noticed that when I use the binding I get an error in the log, there is a slight delay between operating the test item and the lock operating, this doesn’t really upset the functionality. I only usually get the “takes more than 5000ms” errors around 4 times on booting from the RFXCOM binding

2017-04-06 08:44:18.388 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.ThingManager@f49244' takes more than 5000ms.
2017-04-06 08:44:18.393 [WARN ] [ome.core.thing.internal.ThingManager] - Handler for thing 'nuki:smartLock:NukiBridge1:FrontDoorLock' takes more than 5000ms for processing event
2017-04-06 08:45:04.661 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.ThingManager@f49244' takes more than 5000ms.
2017-04-06 08:45:04.667 [WARN ] [ome.core.thing.internal.ThingManager] - Handler for thing 'nuki:smartLock:NukiBridge1:FrontDoorLock' takes more than 5000ms for processing event

philKrylc · April 6, 2017, 9:31am

@kevin @mkatter forgot to mention this. I see this errors as well.

mkatter · April 6, 2017, 10:49am

@kevin @philKrylc
Thanks for the feedback. This issue is already written down on my internal issue tracker

mkatter · April 6, 2017, 10:58am

@philKrylc
Please use the latest Nuki Binding .jar (see first post). As I can see from the config you posted you are still using the outdated configuration!

Use the channel “smartLockUnlatchClose” to pull the latch.

I’ll think about this as the Nuki Bridge does not really send all of the available states.

I added this to my internal Feature Request list

Thx

mkatter · April 6, 2017, 11:37am

For issues and feature requests, please use the github issue tracker here:

So… there is no longer an internal issues tracker / internal feature request list

Thx

mkatter · April 7, 2017, 8:17pm

@kevin @philKrylc
FYI - I just fixed the issue

takes more than 5000ms for processing event

philKrylc · April 7, 2017, 8:41pm

Great to see your progress - I already love the binding. However, I don’t prefer the implementation of the mentioned channel. Why? Because, often I open (and unlatch) my locked door, but than I leave it unlocked (but closed). This channel would be in the state “ON” then. Now I cannot unlatch the door without locking it before unlatching it. This is just my personal opinion and behavior. Maybe it is a good solution to implement a string that can be used to send any command: Lock, Unlock, Unlatch?

Thanks a lot for your great work! Wishing you a pleasant weekend!

mkatter · April 7, 2017, 10:49pm

You already got everything you need!

Just define an Switch Item depending on your door and a String Item for Command:

// Use Channel smartLockOpenClose if you have a handle
Switch Frontdoor_OpenClose 		"Frontdoor (Open / Close)"		<switch> { channel="nuki:smartLock:NB1:SL1:smartLockOpenClose" }
// Use Channel smartLockUnlatchClose if you have a knob
Switch Frontdoor_UnlatchClose	"Frontdoor (Unlatch / Close)"	<switch> { channel="nuki:smartLock:NB1:SL1:smartLockUnlatchClose" }
// Independently of the above, configure your String Item to send commands
String Nuki_Action 				"Nuki Action"					<lock>

Next, define your Sitemap as desired, e.g.

sitemap nuki label="Nuki Smart Lock" {
	Frame label="Switches" icon="lock" {
		Switch item=Frontdoor_OpenClose    label="Frontdoor (Open / Close)"
		Switch item=Frontdoor_UnlatchClose label="Frontdoor (Unlatch / Close)"
	}
	Frame label="Nuki Action" {
		Switch item=Nuki_Action mappings=[cmdOpen="Open", cmdUnlatch="Unlatch", cmdClose="Close"]
	}
}

Lastly, handle your desired command, e.g.

rule "Nuki Action"
when
	Item Nuki_Action received command
then 
	switch (receivedCommand) {
		case "cmdOpen":
			Frontdoor_OpenClose.sendCommand(OFF)
		case "cmdUnlatch":
			Frontdoor_UnlatchClose.sendCommand(OFF)
		case "cmdClose":
			Frontdoor_OpenClose.sendCommand(ON)
	}
	Nuki_Action.postUpdate(NULL)
end

uweb · April 18, 2017, 9:05pm

Hi Markus,

I have now successfully added the binding. I configured the Things via PaperUI (you could add this option to your Readme).
As I am using Alexa to control several Switches within the house in my former manual setup for Nuki I set the OFF command to “lock” and ON command to “unlock” which allowed me to “Switch the house completely off” with only one spoken command leading to locking the door.
Now with the binding the Switch ON is hardwired to “lock” and OFF hardwired to “unlock”. Is there an easy way you could implement with the binding to define which way you want it to be handled?
Unfortunately ON or OFF does not properly match the status of a door lock neither does Alexa offer door lock commands currently.

But I think you understand the point from a voice command perspective when switching a house “off” where an unlock command sent to the lock does not match.
Maybe there is an easy work-around I currently don’t think off but maybe it is easy to be implemented with the Things definition to decide what switch state leads to what command.

Thanks for the good work and I also like the features on the feature list.

EDIT 1: Maybe I can make use of the described Nuki String Action by defining a “virtual” Switch Item (just have to figure out how) for Alexa to toggle this Switch.

EDIT 2: I got it to work. If anyone is interested:

// virtual Switch item to trigger a rule to reverse the commands for open/close to match Alexa ON/OFF actions
// goal is to have the door closed when command is sent to "switch off" Nuki or "the house"
Switch Nuki      				"Nuki "     			<door>	[ "Switchable" ] // tagging as Switchable is mandatory for Alexa to find the Item via Hue Emulation and have it toggled with ON/OFF commands
Switch Frontdoor_OpenClose      "Frontdoor Open/Close"  <door>	{ channel="nuki:smartLock:NB1:SL1:smartLockOpenClose" }

rule "Nuki reverse open/close"

when 
	Item Nuki received update
then
	if (Nuki.state == ON) {
		sendCommand(Frontdoor_OpenClose, OFF)
	}
	if (Nuki.state == OFF) {
		sendCommand(Frontdoor_OpenClose, ON)
	}
end

BR

Uwe

mkatter · April 19, 2017, 7:21am

Hi Uwe,
that’s exactly how I would have done that - nice!

Thanks for sharing!

CU

halloween · April 21, 2017, 9:41am

I think i will buy a nuki too.

Does anyone use the NUKI android bridge software instead of the nuki bridge?

Is this working the same way?

Can i use nuki and nuki bridge offline only in my house or will it always be connected to the cloud? I only want to use it inside my house connected only to openhab2 and not to the cloud. Is this possible or will nuki stop working?

kevin · April 26, 2017, 3:54am

I’ve been running the binding live for a few days now and its working well.
Thanks @mkatter for developing this

uweb · April 27, 2017, 8:46pm

@halloween

You can block outbound nuki traffic on a firewall or operate it not being connected to the cloud service. You will then be restricted with Nuki App to features working with bluetooth within bluetooth range.
However, there were reports that Nuki requires web access for time sync to properly work (unfortunately no ntp is used), at least sometimes.
Same should apply for updates.

But in principle you can operate it without being connected to the Nuki cloud servers.

Uwe

uweb · May 8, 2017, 7:40pm

I am not sure if there is a technical issue with my bridge.
But what I and a friend experience with the binding is, that the status of the Switch Item displayed in the sitemap does not change when the Nuki is locked/unlocked via e.g. the Nuki App or the Nuki button (when being pressed).

Expected behaviour would be that the lock reports status change to the bridge which reports to callback URL@openHAB and openHAB to reflect this status change on the Switch Item (eg in the sitemap).

Can anyone confirm this to work? @mkatter what is the expected behaviour?
I am not 100% sure, but I thought it worked on my initial tests.

Regards,

Uwe

mkatter · May 8, 2017, 8:07pm

@uweb
It is hard to say what is going wrong if you do not post any configuration files or log files.

~~Are you using the current pull request version? If so, please restart openHAB on each configuration change as there is currently a problem with the re-initialization of the binding.~~
update: This issue is not true for the current release version of openHAB 2. Everything works fine on my 2.0.0~RC1-1 installed via “deb http://dl.bintray.com/openhab/apt-repo2 testing main”. Re-initialization just fails in my development environment (git checkout).

BR Markus

Dim · May 9, 2017, 5:09am

I am thinking the same, especially with the availability of this new binding !

Without wanting to hijack the thread: How would the existing openHAB users of the Nuki lock rate it (from 0=crap to 10=awesome) ?
Is it working properly and is it worth it?

fonz · May 9, 2017, 8:26am

Ah sorry misinterpreted…

missing auto-discovery in the binding itself;-)

6-7 for the lock, don’t wanna miss it anymore

halloween · May 9, 2017, 10:45am

Would be nice if you could explain why you only give 6-7 points.

Can you explain what the bad things (or not so good things) are?

Is it working with 100% or do you sometimes get an error and you have to look after the lock or close the lock manually? Because it´s a thing for the security of my house, i will have a 100% rate of doorlock and not only maybe 9 out of 10 attempts.