Nuki opener

[Xhinde]

No idea if this goes here. But i get an error with the nuki opener. As far as i could read from a HA forum post by you, you don't have one? If i can test stuff for you, please do tell. The error is as follows.

404 Client Error: Not Found for url: http://[MYip]:8080/lockAction?token=[MyToken]&nukiId=[MyNukiID]&action=3&noWait=1

[pschmitt]

Please give the current master branch a try.
Can you provide the output of the following?

from pynuki import NukiBridge
nb = NukiBridge.discover()
nb.token = "XXXXXXX"
print(nb.locks)
print(nb.openers)

[alceasan]

I have the same problem using this on HA, their nuki component is using this pynuki lib.
The problem is in the request is doing HA to unlock the opener is lacking a new mandatory parameter (deviceType) as explained here.

This is the error HA is reporting when trying to unlock my opener:
404 Client Error: Not Found for url: http://XX.XX.XX.XX:8080/lockAction?token=XXXXXX&nukiId=XXXXXXX&action=1&noWait=1

As you can see, this parameter is not in the url, and that is the cause of the error. If you put it manually in the url (deviceType=2, for the opener) it works like a charm. The same thing will happen with the lockStatus endpoint.

I think a solution could be the inclusion of this parameter in the lock and unlock methods in both bridge.py and lock.py, but I'm not confident in my Python abilities to do it myself :)

[damikh]

Please give the current master branch a try.
Can you provide the output of the following?

@pschmitt, here you go. Right now, I only have an opener and no lock:

from pynuki import NukiBridge
nb = NukiBridge.discover()
nb[0].token = "XXXXXXX"

Then the output is:

>>> print(nb[0].locks)
[<NukiLock: {'deviceType': 2, 'nukiId': xxxxxxxxx, 'name': 'opener', 'firmwareVersion': '1.3.1', 'mode': 2, 'state': 1, 'stateName': 'online', 'batteryCritical': False}>]

>>> print(nb[0].openers)
[<NukiOpener: {'deviceType': 2, 'nukiId': xxxxxxxxx, 'name': 'Öffner', 'firmwareVersion': '1.3.1', 'mode': 2, 'state': 1, 'stateName': 'online', 'batteryCritical': False}>]

[thomkaufmann]

I have the same problem using this on HA, their nuki component is using this pynuki lib.
The problem is in the request is doing HA to unlock the opener is lacking a new mandatory parameter (deviceType) as explained here.

This is the error HA is reporting when trying to unlock my opener:
404 Client Error: Not Found for url: http://XX.XX.XX.XX:8080/lockAction?token=XXXXXX&nukiId=XXXXXXX&action=1&noWait=1

As you can see, this parameter is not in the url, and that is the cause of the error. If you put it manually in the url (deviceType=2, for the opener) it works like a charm. The same thing will happen with the lockStatus endpoint.

I think a solution could be the inclusion of this parameter in the lock and unlock methods in both bridge.py and lock.py, but I'm not confident in my Python abilities to do it myself :)

If you make the following changes to lock(), unlock(), and open() in https://github.com/home-assistant/core/blob/master/homeassistant/components/nuki/lock.py, it should work for you:

def lock(self, **kwargs):
    """Lock the device."""
    # self._nuki_lock.lock()
    self._nuki_lock._bridge.lock_action(self._nuki_lock.nuki_id, 2, self._nuki_lock.device_type)

def unlock(self, **kwargs):
    """Unlock the device."""
    # self._nuki_lock.unlock()
    self._nuki_lock._bridge.lock_action(self._nuki_lock.nuki_id, 1, self._nuki_lock.device_type)

def open(self, **kwargs):
    """Open the door latch."""
    # self._nuki_lock.unlatch()
    self._nuki_lock._bridge.lock_action(self._nuki_lock.nuki_id, 3, self._nuki_lock.device_type)

[pschmitt]

@thomkaufmann Your "fix" should work anymore since 1.3.4.

Can any of you try out 1.3.4?

[thomkaufmann]

@pschmitt That's right, it no longer works with 1.3.4:

Failed to call service lock/unlock. 'NukiLock' object has no attribute 'device_type'

[pschmitt]

Just to clarify:

• does nb.locks only return locks now?
• does nb.openers only return openers?

Home Assistant is out of scope for now. Openers were only discovered because of #48. I need to focus on pynuki first. I'll probably issue a PR to hass once the pynuki stuff is sorted out here.

Should the NukiOpener class also have lock and unlock methods available? And what would these do in the real world exactly?

[thomkaufmann]

Thanks for you work on this :)
Yes, nb.locks and nb.openers work properly now, only returning their respective devices.

The openers have a feature called "Ring to Open" (rto) which, when activated, triggers the building/community door to buzz you in when you ring your apartment's buzzer.
Lock deactivates rto and unlock activates rto.
https://developer.nuki.io/page/nuki-bridge-http-api-1-10/4#heading--lock-actions

[pschmitt]

Thansk for the clarification. I implemented some of these methods here.
Do these provide the functionality you seem to all be after?

[thomkaufmann]

Yup, those are all of the actions needed.

[alceasan]

Is it working now? Can I make some local test?

[thomkaufmann]

@alceasan It won't yet work in HA, but you can test pynuki using the lock_action() method in bridge.py:

from pynuki import NukiBridge
nb = NukiBridge.discover()
nb[0].token = "XXXXXXX"
nb[0].locks # should return just your lock(s)
nb[0].openers # should return just your opener(s)

Using your nuki_id's from the locks and openers calls above, you can use the lock_action method to control them. For example:

nb[0].lock_action(nuki_id=XXXXXXXXX,action=1,device_type=2) # activates rto
nb[0].lock_action(nuki_id=XXXXXXXXX,action=2,device_type=2) # deactivates rto

You can refer to constants.py for the action values. And you can easily monitor the state changes using your browser: http://[Bridge IP]:8080/list?token=XXXXXXX

@pschmitt I'm happy to help where I can, so please let me know how to contribute.

[pschmitt]

You should also be able to do the following:

from pynuki import NukiBridge
nb = NukiBridge.discover()
br = nb[0]
br.token = "YOUR_TOKEN"
br.openers[0].activate_rto()
br.openers[0].deactivate_rto()

@thomkaufmann If you'd like to tackle the Home Assistant integration update that'd be great. It shouldn't be much work.

A few pointers:

• Update pynuki to 1.3.4+ 1.3.5+
• in the setup both device types should be registered. I'd suggest creating a new NukiOpenerEntity class for that - and renaming the HASS' NukiLock class to NukiLockEntity or HassNukiLock to avoid naming conflicts.
• in the HASS NukiLock class one needs to either call the lock / unlock or activate_rto / deactivate_rto depending on the device type
• The lock_n_go service should only be accepting lock devices

Also I'd like to make sure that we can get the RTO state in pynuki's NukiOpener. Right now I do not know if we can get the state reliably. Maybe we'll need to add a dedicated property?

[pschmitt]

I released 1.3.5 with your changes @thomkaufmann
Openers should now work as expected (from a pynuki standpoint). There still is some work to do (see above) to make the HASS integration behave correctly.

[thomkaufmann]

@pschmitt Great! I'm working on the HASS integration. I'm new to HASS, so I appreciate the pointers above.

[pschmitt]

I'll take a look once you submit your PR. Thanks a lot for your help.
This here issue should be resolved. Feel free to open another if there's something wrong with the openers.

[thomkaufmann]

PR submitted: home-assistant/core#35695

[pschmitt]

Cool, cool. But why did you close it?

[thomkaufmann]

Oh, sorry, I updated the pynuki version in manifest.json and fixed the typo. I submitted a new pull request: home-assistant/core#35702
Was there a better method to adjust those in the original PR?

[pschmitt]

You could just have left it as is. If it is the commit history that worries you, don't. Maintainers can squash commits if your branch's history is too messy. It's what the Home Assistant maintainers normally do as well if I am not mistaken.