Yes, you need snapshot version. For testing you can just download snapshot distribution, unzip it, put the jar into addons and run it locally on your pc. But it shouldn’t be too hard to make build that works on current stable version, i’ll look into it.
1 Like
OK, made it.
Created a bridge, afterwards the scan revealed the lock itself. Things are working.
See all the channels, looks perfect.
Thanks again !
Locking the door from OH I get an error in the Log:
2021-05-06 17:59:22.710 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Turschloss_LockState' changed from 3 to 4
2021-05-06 17:59:29.193 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'nuki:smartlock:xxxxxxxxxxx:yyyyyyyyyy' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Bad Request
2021-05-06 17:59:29.199 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Turschloss_Lock' changed from ON to OFF
2021-05-06 17:59:29.202 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Turschloss_LockState' changed from 4 to 255
2021-05-06 17:59:29.203 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Turschloss_DoorState' changed from 2 to 4
Somehow the connection seems to break down during the process of locking the door.
Same happens when unlocking the door.
Regards,
Thomas
That’s weird, are you using the switch channel (lock) or the number channel (lockState)? Try setting log level for org.openhab.binding.nuki.internal to DEBUG, try again and post log here.
Here’s version which works on stable (3.0.x) branch
org.openhab.binding.nuki-3.1.0-SNAPSHOT.jar.txt (58.2 KB)
1 Like
Good news everyone! The pull request is finally merged, big thanks to @fwolter for reviewing it. You can get it in 3.2.0 M2 milestone build, or by downloading jar from this url (then just uninstall current binding and put this jar into addons folder).
Final changes include:
- Support for Nuki Opener
- Support for automatic discovery of Bridge, Smart lock and Opener
- New smart lock channels
- Support for secure communication
- Better callback management
- Device uuids generated from nuki identifiers, that means deleting and adding nuki bridge and devices will preserve channel links
I recommend deleting current devices and adding them again using discovery. For more info check updated documentation. Let me know if you have any problems.
(sorry for the edit, can’t post additional replies)
3 Likes
Hi @m0rgoth
I have an issue with the updated binding.
- It looks like the callback is not working correctly. The state is updated delayed.
Edit: doorsensorState seems to work in callback, only lock and lockState are delayed
I have the same behavior if I set the callback manually or via the bridge thing.
With the old binding, the state was updated immediately.
I deleted the old things and added them again after the update.
Switch Frontdoor_Lock
"Haustüre [%s]"
<nuki>
(gPersist)
{channel="nuki:smartlock:xxxxx:yyyyyy:lock"}
Number Frontdoor_State
"Haustüre (Status) [MAP(nukilockstates.map):%s]"
<nuki>
(gPersist)
{channel="nuki:smartlock:xxxxxx:yyyyyyy:lockState"}
2021-09-09 20:39:03.729 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Frontdoor_Lock' received command OFF
2021-09-09 20:39:03.729 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Frontdoor_Lock' predicted to become OFF
2021-09-09 20:39:03.733 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Frontdoor_Lock' changed from ON to OFF
2021-09-09 20:39:15.387 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Frontdoor_State' changed from 1 to 3
2021-09-09 20:39:22.184 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Frontdoor_Lock' received command ON
2021-09-09 20:39:22.187 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Frontdoor_Lock' predicted to become ON
2021-09-09 20:39:22.189 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Frontdoor_Lock' changed from OFF to ON
2021-09-09 20:39:33.380 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Frontdoor_State' changed from 3 to 1
- The new actions & states do not make sense in some cases
- Lock action 1 (Unlock) is now state “Locked” → state should be “Unlocking”
- Lock action 2 (Lock) is now state “Unlocking” → state should be “Locking”
- Lock action 3 (Unlatch) is now state “Unlocked” → state should be “Unlatching”
- Lock action 4 (Lock ‘n’ Go) is now state “Unlocked” → state should be “Unlock (Lock ‘n’ Go)”
- Lock action 5 (Lock ‘n’ Go with Unlatch) is now state “Unlocked” → state should be “Unlatched (Lock ‘n’ Go)”
In the old binding, these actions/states were correct.
But actually it is not possible to send action “1” to unlock the door, because the locked state is already “1”. I know, lock/unlock is also possible with the channel “lock”.
| Values | Action old | State old | Action new | State new |
|---|---|---|---|---|
| 0 | - | - | - | Uncalibrated |
| 1 | - | Locked | Unlock | Locked |
| 2 | Unlock | Unlocking | Lock | Unlocking |
| 3 | - | Unlocked | Unlatch | Unlocked |
| 4 | Lock | Locking | Lock 'n' Go | Locking |
| 5 | - | - | Lock 'n' Go with Unlatch | Unlatched |
| 6 | - | - | - | Unlatched (Lock 'n' Go) |
| 7 | Unlatch | Unlatching | - | Unlatching |
| 254 | - | - | - | Motor blocked |
| 255 | - | - | - | Undefined |
| 1002 | Lock 'n' Go | Unlocking initiated through Lock 'n' Go | - | - |
| 1007 | Lock 'n' Go with Unlatch | Unlatching initiated through Lock 'n' Go with Unlatch | - | - |
I took a look into the Nuki Bridge HTTP API.
lockState and lockAction are different ressources:
/lockAction:
https://developer.nuki.io/page/nuki-bridge-http-api-1-12/4#heading--lockaction
/lockState:
https://developer.nuki.io/page/nuki-bridge-http-api-1-12/4/#heading--lockstate
It looks like we should have an additional channel (r/w) to separate it from the lockState (ro).
Or as done in the “old” binding with additional lockState values (1002/1007) and only allow values 2,4,10xx to be used for an action. But this seems to be confusing.
The idea is that you have some commands you can send to the lockState channel, and the lock report it’s state using the same channel. It could be two separate channels, but one would be read only and the other write only, I’m not sure it improves anything.
About the delay - state of the lock changes as soon as the binding receives callback from bridge with new state. Unfortunately when you send lock command, the bridge will send callback after it finishes locking, no itermediate states are reported (like locking/unlocking or lock’n’go when you activate it by button on the smart lock).
The old version basically faked the lock state by setting it manually without checking value from bridge, I don’t see any good reason why do that (maybe you do? let me know). You can force state update by sending REFRESH command to the channel (binding will then call /lockState endpoint and request new data directly from lock), but I just tried it and you can’t get the bridge to report for example ‘locking’ state, it will throw 503 error until the lock finishes.
Actually, if you use a switch in a sitemap, the “Unlock” button (action=1) is marked as active, if the door is locked (state=1).
This can be confusing and anyway I guess it is easier for someone who starts using the binding, if we have a channel for actions and one for states.
Switch item=Frontdoor_State label="Frontdoor [MAP(nukilockstates.map):%s]" icon="nuki" mappings=[1="Unlock", 2="Lock"]
I see it now. It seems to work the same way as before. Also before it took about 15 seconds until the final state was reported.
This is the event.log before the upgrade.
2021-08-17 17:55:10.284 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Frontdoor_State' received command 2
2021-08-17 17:55:10.284 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Frontdoor_State' predicted to become 2
2021-08-17 17:55:10.286 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Frontdoor_State' changed from 1 to 2
2021-08-17 17:55:24.367 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Frontdoor_Lock' changed from ON to OFF
2021-08-17 17:55:24.368 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Frontdoor_State' changed from 2 to 3
Ok, didn’t knew that. Then I guess the new implementation is better, as I can fake the state via a rule if necessary.
I’m not sure I understand. If you want to use simple switch to lock/unlock doors, there is a dedicated lock switch channel for that, any reason not to use it instead?
Because I use also the other actions (Unlatch/Lock‘n‘Go) on the same switch. I have just removed these in the example in my last post.
Can you describe how does that “switch” look like and how do you expect it to work? You mean like switch on sitemap with value mappings?
If the lockState = 1 (locked), the map value from the switch shows the button “Öffnen” as selected.
Therefore, pressing “Öffnen” does nothing. And this is a issue.
Currently we cannot use lockState as a switch in the sitemap with the additional actions like Unlatch/Lock ‘n’ Go/Lock ‘n’ Go with Unlatch. And the alternative channel “lock” only supports unlock/lock.
The actions Unlock/Unlatch/Lock 'n’nGo cannot work in every case.
Switch item=Frontdoor_State label="Frontdoor [MAP(nukilockstates.map):%s]" icon="nuki" mappings=[1="Öffnen", 2="Schliessen"]
If lockState = 3 (unlocked), both buttons are not active.
The problem is you’re trying to combine 2 different things and map them on a switch, but the lock states have different values than commands so you’ll end up with switch unselected most of the time. Even if the channel for commands was separate (and write only), then the switch would just have value of last command you sent to it.
I think better solution would be not to bind the switch directly to lockState channel, but to create simple rule that would forward commands from the switch to Nuki and also update it depending on your needs.
Correct, they are unselected but are working all the time. Better than the situation we have now.
I already did that and also included the transition states, so I have a working solution (or workaround).
But for a new binding user, it is not obvious or convenient to create a proxy item and write rules if more lock actions than on/off are required.
It works pretty well with new UI, after clicking the item you get popup with all the available lock actions. But I agree that it’s not great that there is no simple way to make it work with sitemap switch, right now there isn’t any simple button control in sitemap, only those that work as a toggle.
I’m thinking maybe adding another channel, something like lockCommand, that would accept same commands as a lockState (for compatibility purposes), but would always return 0 after executing the command (or maybe 0 if it succeded and -1 if it failed). That way you could bind switch to it in site map, and it would always reset after selecting value. Would that work for you? Thinking about it, it doesn’t seem like too much of a hack.
1 Like
Would be great. But I already implemented the „hack“ above with rules. Anyway it would help users to have a simple way to use it in a sitemap.
Hello
is there a simple way to trigger a rule on unlatching? Right now i enable the entrylight but this is triggered only in case the lockstate is changing from locked. In case of auto unlock from an unlocked door this does not work.
Any ideas?
rule "coming home Flurlicht"
when
Item Frontdoor_LockState changed from 1
then
if( (MINUTEN_VOR_SU.state != 999 && MINUTEN_VOR_SU.state <= 30) || (MINUTEN_VOR_SA.state >= -15 && MINUTEN_VOR_SA.state != 999)) {
Licht_EG_Flur.sendCommand(ON)
}
end
You only get report if state of the lock changes. If your lock is unlocked, then unfortunately there is no other state for the lock to change to. Although the official API specifies states like Unlatching (7) and Unlocking (2), I don’t think the lock actually report those. Nuki binding relies on HTTP callbacks and if you use Nuki app to open the door (either directly or using auto unlock), the lock only sends callback after the door finishes opening.
You can try looking into openHAB’s events.log file when you use auto unlock to see if you can trigger the rule with something else (like door doorsensorState).