Home assistant 0.111.1 : cannot read nuki state

[Ciqsky]

Logger: homeassistant.helpers.entity
Source: components/nuki/lock.py:124
First occurred: 11:40:21 (377 occurrences)
Last logged: 14:56:51

Update for lock.porta fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 279, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 472, in async_device_update
await self.hass.async_add_executor_job(self.update)
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/src/homeassistant/homeassistant/components/nuki/lock.py", line 124, in update
self._nuki_device.update(aggressive=level)
File "/usr/local/lib/python3.7/site-packages/pynuki/device.py", line 90, in update
"Failed to update data for lock. "
AssertionError: Failed to update data for lock. Nuki ID None volatized.

[pschmitt]

Thanks for raising this.
What does running the following bit of code yield back?

from pynuki import NukiBridge
nb = NukiBridge.discover()[0]
nb.token = "YOUR_TOKEN"
print(f"locks: {nb.locks}")
print(f"openers: {nb.openers}")

[dvbit]

Fyi 111.0 works

[Ra72xx]

Anything I can do to help with this?
Currently the Nuki integration of HomeAssistant is pretty useless for me as the bridge constantly goes offline without any warning. Sometimes it gets online by itself after some time, sometimes one (or several) restarts of Homeassistant help.
I tried the above php piece of code with "php -f filename.php", but that only prints out the file content (?!?).

[pschmitt]

That's python.

[Ra72xx]

Stupid me... ;-)

[Ciqsky]

Thanks for raising this.
What does running the following bit of code yield back?

from pynuki import NukiBridge
nb = NukiBridge.discover()
nb.token = "YOUR_TOKEN"
print(f"locks: {nb.locks}")
print(f"openers: {nb.openers}")

How I can run this code from HASSIO?? How I can help you to resolve this problem?

[Ra72xx]

Doesn't work.

pi@raspi:~ $ python code.py 
  File "code.py", line 4
    print(f"locks: {nb.locks}")
                             ^
SyntaxError: invalid syntax

EDIT: Sorry, too fast. But also no success from my homeassistant virutalenv:

(homeassistant) $ python code.py 
Traceback (most recent call last):
  File "code.py", line 3, in <module>
    nb.token = "secret"
AttributeError: 'list' object has no attribute 'token'

[pschmitt]

My bad it should have been:

​nb​ ​=​ ​NukiBridge​.​discover​()[​0​]

I updated the original post above.

[Ra72xx]

  File "code.py", line 2
    nb​ ​=​ ​NukiBridge​.​discover​()[​0​]
      ^
SyntaxError: invalid character in identifier

[chiefdeputy]

Try

from pynuki import NukiBridge
nb = NukiBridge.discover()
for bridge in nb:
  bridge.token = "xxxx"
  print(f"locks: {bridge.locks}")
  print(f"openers: {bridge.openers}")

[Ra72xx]

Do I have to enter this when the lock is working or offline? Currently it is online (strange - without any change in the configuration it has been online for at least 24h). Result is

locks: [<NukiLock: {'deviceType': 0, 'nukiId': xxxx, 'name': 'door', 'firmwareVersion': '2.7.20', 'mode': 2, 'state': 1, 'stateName': 'locked', 'batteryCritical': False}>]
openers: []

[Ra72xx]

So now the lock is offline again. However, the piece of code gives the same result as before.

locks: [<NukiLock: {'deviceType': 0, 'nukiId': xxxx, 'name': 'door', 'firmwareVersion': '2.7.20', 'mode': 2, 'state': 3, 'stateName': 'unlocked', 'batteryCritical': False}>]
openers: []

The reported state is wrong. And trying to operate the lock from HA gives

404 Client Error: Not Found for url: http:/nukiip:8080/lockAction?ts=2020-06-26T16:24:22Z&r .....

[pschmitt]

The snippet's purpose is just to provide some basic info about your devices. Nothing more. No need to run it again.

[derandiunddasbo]

Don't know if this provides any clue to solve the issue, but operating the lock via python script from the HA instance (in my case a bash session inside the HA container) is working just fine, even while the lock is shown as unavailable in HA the whole time.

[Ciqsky]

@pschmitt do you think to resolve this problem in pynuki? Or is an HA problem?

[jacekkjw]

Definitly it's a pynuki problem. In the newest version of HA: 0.113, I downgraded nuki component to vs 0.110.7 (last worked) and together a pynuki to vs 1.3.3. Nuki lock works good again. I think (based on logs of HA), the problem appears during polling the state of nuki lock when nuki bridge is in unstable state (for example overload 503 error). I'm not sure but the problem cause one of these to lines or even both:

82: self._json = {k: v for k, v in data.items() if k != "success"}
or
93 self._json = data[0]._json.

At vs 1.3.3 of pynuki coresponding lines look that:

97: self._json.update({k: v for k, v in data.items() if k != 'success'})
and
103: self._json.update(data[0]._json)

You keep nuki_id in the _json list. If you've get messed return form the bridge (during unstable state) setting just new value to the list can result in lossing nuki_id information. If you update the list (as was in previous version - 1.3.3) the messed answer from bridge doesn't overwirite nuki_id.

[pearlythepirate]

The fix here resolves the issue in the original post which leads me to believe it is an HA integration problem.

The only substantive difference in the lock.py (from the zip) is in line 54 removing an erroneous comma.

Using the new lock.py in my HA v0.113 got rid of the "volatized" error in my logs and now the included _LOGGER.warning entries which were the only other change in that file.

[pschmitt]

So with 1.3.7 to reproduce this issue:

from pynuki import NukiBridge

nb = NukiBridge.discover()[0]
nb.token = "MY_TOKEN"

l = nb.locks[0]

print(l._json)
l.update()
print(l._json)
l.update()
print(l._json)
l.update(aggressive=True)
print(l._json)
# Shit hits the fan here:
l.update(aggressive=True)

It turns out the bridge does not return the nukiId in the response when polling with aggressive=True.

I must say that I was quite surprised that:

1. The responses are different
2. HASS uses aggressive polling by default. This is bad.