Home assistant 0.111.1 Nuki update problem #36719

Ciqsky · 2020-06-12T13:24:50Z

The problem

After update to 0.111.1 my nuki lock do not update status.

Environment

Home Assistant Core release with the issue:
Last working Home Assistant Core release (if known): 0.110.7
Operating environment (Home Assistant/Supervised/Docker/venv): HASS.io
Integration causing this issue:
Link to integration documentation on our website:

Problem-relevant `configuration.yaml`

Traceback/Error logs

logs:
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.

Additional information

found also pschmitt/pynuki#54 but my problem is not with netgear

The text was updated successfully, but these errors were encountered:

probot-home-assistant · 2020-06-12T13:55:03Z

Hey there @pvizeli, mind taking a look at this issue as its been labeled with a integration (nuki) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

pvizeli · 2020-06-12T16:19:54Z

AssertionError: Failed to update data for lock. Nuki ID None volatized

Yeah, I see that also in my logs. The question is what changed on lib... @pschmitt ?

pschmitt · 2020-06-12T17:30:23Z

That depends. Are you using a software bridge, @Ciqsky ?

Ciqsky · 2020-06-12T18:14:15Z

No, with nuki lock i use only its bridge (nuki) with hassio on raspberry Il Ven 12 Giu 2020, 19:30 Philipp Schmitt <notifications@github.com> ha scritto:

…

That depends. Are you using a software bridge, @Ciqsky <https://github.com/Ciqsky> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#36719 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN7AGOU3JDWK2RCHFRXCCPTRWJQ33ANCNFSM4N4KPGFA> .

rafuz · 2020-06-13T20:24:27Z

Same error here, starting from 111.1
I have a Nuki Bridge Firmware 2.5.2 (2.1.17 WiFi Firmware)
I have a Nuki Opener associated to the same bridge and it works correctly.

What seems strange is that the Nuki ID disappears from the entity:

After a restart the ID appears again and the integration works.

Logger: homeassistant.helpers.entity
Source: components/nuki/lock.py:124
First occurred: 20:06:31 (266 occurrences)
Last logged: 22:23:07

Update for lock.porta_d_ingresso 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.

HASS Info:

arch | x86_64
-- | --
chassis | vm
dev | false
docker | true
docker_version | 19.03.8
hassio | true
host_os | HassOS 4.10
installation_type | Home Assistant
os_name | Linux
os_version | 5.4.44
python_version | 3.7.7
supervisor | 227
timezone | Europe/Rome
version | 0.111.2
virtualenv | false

pschmitt · 2020-06-13T22:59:47Z

hm. That's odd behavior. I see these in my logs as well.
I don't get why this is happening though.
I'm tempted to add a check to for data validity in the update call at the hass or pynuki level (EDIT: or request throttling). The bridges are really sensible to parallel REST calls and do return garbage from time to time it seems.

pynuki isn't quite perfect yet.
Ref: pschmitt/pynuki#31

joydashy · 2020-06-15T17:30:41Z

Glad it's not just me! Same problem here.

mecrip · 2020-06-17T18:54:15Z

+1 same problem here, started with latest 0.111

SeraphimSerapis · 2020-06-19T07:58:41Z

Joining the group of people that encounters this issue.

Logger: homeassistant.helpers.entity
Source: components/nuki/lock.py:124
First occurred: 9:36:53 AM (38 occurrences)
Last logged: 9:56:29 AM

Update for lock.haustur 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.

kachalex · 2020-06-19T11:08:33Z

same problem here, started with latest 0.111

juanrferia · 2020-06-20T08:15:50Z

+1. I also wanted to share some other information: While my nuki lock is locked, from time to time I see status change in HA to unlocked when unexpected (actually nuki is still locked), firing the automations I have for that lock status. When it happened, I checked the nuki id is gone in HA. If I restart HA then the nuki id is set again and status is correct (locked). But after a while (aprox a day) the issue comes again.

stiltjack · 2020-06-20T13:06:43Z

Same issue here. Factory reset of the nuki bridge (and hence a new token in configuration.yaml) resolves it, but it returns after a couple of days. I'm rebooting the Pi after editing, of course.

marcobag · 2020-06-21T06:21:44Z

+1 here, please fix

swissmaster1 · 2020-06-21T10:04:35Z

+1, same problem

CptKalibak · 2020-06-21T11:42:21Z

+1, same. Nuki lock is unavailable and a bunch of Timeout errors in my logs like: "socket.timeout: timed out"

Edit: I've renamed my lock in Nuki web and restarted Home Assistant and the Lock is back. will watch how long this works.

bigboban · 2020-06-22T19:58:37Z

After some update (Nuki fw?) i have many problems with Nuki. Sometimes Nuki component is not available (ok after restart again for few hours). For example right now component IS available but LOCK command fail with this error in log:

2020-06-22 21:54:03 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: name=homeassistant.helpers.entity, message=['Update for lock.muj_nuki_zamek fails'], level=ERROR, source=['components/nuki/lock.py', 124], timestamp=1592855643.219114, exception=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.
, count=1, first_occurred=1592855643.219114>

Ra72xx · 2020-06-23T06:06:17Z

This issue?
pschmitt/pynuki#56
Currently Nuki is pretty much unusable in HA :-( ...

loadamasta · 2020-06-23T15:53:05Z

I have exactly the same problem. Both of my locks become unavailable and do not update the status until a restart of HA. Before 0.111, the service nuki.check_connection did bring back the locks to HA, but now hass does not even find the service any more. The nuki integration cannot be used in reliable automations until this bug is not resolved.

Update: I went back to 0.110.7 and Nuki integration works as usual. So, there is a problem with HA 0.111. and not on the Nuki side.

dominik-doll · 2020-06-24T20:53:40Z

Same here.
Going back to 0.110 helps - 0.111 Not working.

mokusnz · 2020-06-29T16:48:33Z

Same problems.
0.110 working - 0.111 Not working.
In my opinion, this is a problem with HA, something has been forgotten. We are waiting for an update.

cassianyoung · 2020-06-30T08:16:06Z

+1 Note: that the link via IFTTT still works and can be used as a workaround.

Ciqsky · 2020-07-01T17:09:39Z

Works It now on 112.0 release?

stiltjack · 2020-07-01T17:37:14Z

Haven't had the new release yet, but there's no mention of Nuki in the release notes.

stiltjack · 2020-07-01T19:41:48Z

Just upgraded. Lock seems to be working normally so far - no errors. Fingers crossed.

chpego · 2020-07-02T09:23:39Z

Problem still exist on on 112.0 release

marcobag · 2020-07-02T09:57:18Z

Confirm, still exist! Inviato da iPhone

…

Il giorno 2 lug 2020, alle ore 11:23, chpego ***@***.***> ha scritto: Problem still exist on on 112.0 release — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

bigboban · 2020-07-02T10:25:35Z

+1. Problem still on 112.0. 👎

Ciqsky · 2020-07-02T10:45:15Z

What can we do to help @pvizeli and @pschmitt solve this problem? Guys, what are the changes in the code made between version 110.7 and 111.0 that impact the NUKI component? The problem is there ...

bigboban · 2020-07-18T19:24:42Z

I think id lost is connected with this piece of code:

self._available = False

It sets available to false after first error of bridge http call. But as we now bridge is slow and unreliable on rest api.

I changed code to count errors and my new code sets available to false after 5 rest api call fails.
EDIT - (count errors to 5 and reset to zero after ok call)

I will report results..

joydashy · 2020-07-18T19:36:50Z

My Nuki, opener and lock, have been stable for 50 hrs now with just the lock.py fix.

dominik-doll · 2020-07-18T20:50:44Z

Do you all have a Hardware Bridge in use?
https://nuki.io/de/bridge/

Ra72xx · 2020-07-19T03:12:38Z

Hardware here.

joydashy · 2020-07-19T03:38:34Z

Do you all have a Hardware Bridge in use?
https://nuki.io/de/bridge/

Yep, hardware bridge, Opener, Keypad and Lock.

myGithub-Markus · 2020-07-19T09:15:51Z

I also have a nuki bridge and have only changed the constructor calling (fixed the timeout problem 5 to 20 sec). My system works fine since over 3 days

loadamasta · 2020-07-22T13:45:09Z

Made a custom nuki componten with the lock.zip files. Still no luck. At least one of my two nuki locks becomes unavailable and not comes back. It happens when an automation calls both locks to close or open at the same time. Thus, the lock.zip files are not the solution as all worked unser 0.110.

joydashy · 2020-07-22T13:57:59Z

Made a custom nuki componten with the lock.zip files. Still no luck. At least one of my two nuki locks becomes unavailable and not comes back. It happens when an automation calls both locks to close or open at the same time. Thus, the lock.zip files are not the solution as all worked unser 0.110.

Sure it's loaded properly? Mine has been up working perfectly for 140 hours now.

loadamasta · 2020-07-22T14:03:55Z

Made a custom nuki componten with the lock.zip files. Still no luck. At least one of my two nuki locks becomes unavailable and not comes back. It happens when an automation calls both locks to close or open at the same time. Thus, the lock.zip files are not the solution as all worked unser 0.110.

Sure it's loaded properly? Mine has been up working perfectly for 140 hours now.

Yes. I think, it's caused by simultaneous service calls two both locks. Maybe it's too much for the slow bridge API.

pvizeli · 2020-07-22T14:42:31Z

That can be solved with a simple flag on INI to tell home assistant core for do not parallel service calls.

derandiunddasbo · 2020-07-22T14:51:46Z

For every loaded custom component HA generates a warning in the log on startup. If you can see this warning, your custom component is used:

2020-07-20 22:27:53 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for nuki which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.

By temporarily disabling one of the entities in the config you may verify, if the other entity remains available and if your problem is indeed caused by multiple nuki components somehow.

marcobag · 2020-07-22T14:52:59Z

Try this experimental fix. Works fine for me.
lock.zip

Thank you so much, working flawlessly since 4 days!
I know maybe it's not final but really thank you!

loadamasta · 2020-07-22T15:25:47Z

I just have one warning for another custom component, but not for the nuki one. Have I to disable the existing nuki lock entities in oder to get the custom nuki component loading?

derandiunddasbo · 2020-07-22T15:47:28Z

If the custom component files are located in the right folder, they should be loaded on next startup. No need to disable anything.

The files should be located in <config-dir>/custom_components/nuki/. Please remember to first copy the other files from the original component and only replace lock.py from the zip. In a hass.io installation the other component files are located in /usr/src/homeassistant/homeassistant/components/nuki/

Finally the custom component folder should look similar to this listing:

root@homesweethome:/usr/share/hassio/homeassistant# ls -la /usr/share/hassio/homeassistant/custom_components/nuki/ insgesamt 44 drwxr-xr-x 3 root root 4096 Jul 19 19:50 . drwxr-xr-x 7 root root 4096 Jul 20 21:11 .. -rw-r--r-- 1 root root 43 Jul 19 18:07 __init__.py -rw-r--r-- 1 root root 5704 Jul 19 19:50 lock.py -rw-r--r-- 1 root root 5416 Jul 19 18:07 lock.py.orig -rw-r--r-- 1 root root 1861 Jul 19 18:07 lock.zip -rw-r--r-- 1 root root 178 Jul 19 18:07 manifest.json drwxr-xr-x 2 root root 4096 Jul 19 19:50 __pycache__ -rw-r--r-- 1 root root 232 Jul 19 18:07 services.yaml

loadamasta · 2020-07-22T16:00:03Z

If the custom component files are located in the right folder, they should be loaded on next startup. No need to disable anything.

The files should be located in <config-dir>/custom_components/nuki/. Please remember to first copy the other files from the original component and only replace lock.py from the zip. In a hass.io installation the other component files are located in /usr/src/homeassistant/homeassistant/components/nuki/

Finally the custom component folder should look similar to this listing:

root@homesweethome:/usr/share/hassio/homeassistant# ls -la /usr/share/hassio/homeassistant/custom_components/nuki/ insgesamt 44 drwxr-xr-x 3 root root 4096 Jul 19 19:50 . drwxr-xr-x 7 root root 4096 Jul 20 21:11 .. -rw-r--r-- 1 root root 43 Jul 19 18:07 __init__.py -rw-r--r-- 1 root root 5704 Jul 19 19:50 lock.py -rw-r--r-- 1 root root 5416 Jul 19 18:07 lock.py.orig -rw-r--r-- 1 root root 1861 Jul 19 18:07 lock.zip -rw-r--r-- 1 root root 178 Jul 19 18:07 manifest.json drwxr-xr-x 2 root root 4096 Jul 19 19:50 __pycache__ -rw-r--r-- 1 root root 232 Jul 19 18:07 services.yaml

Thank you very much for the info.

I just picked up the Nuki component files from github and the copied the lock.py into the right folder.

How can I access the component folder on an Hass.io installation in order to copy the files? Via ssh and samba and config editor I can only access the /config folder.

derandiunddasbo · 2020-07-22T18:41:11Z

To access the components folder of your current hass.io installation you would need shell access to the host running the homeassistant docker container and open a shell inside the container, i.e. docker exec -it homeassistant bash.

But copying them from GitHub is just fine as well. I just didn't think about this method.

jacekkjw · 2020-07-22T21:23:53Z

I've also has this bug. I read the conversation and tried the fix proposed by derandiunddasbo. For me it doesn't work. After upplied the fix I can easly triggered "unavaiable" state just quickly clicking many times on "lock" action. I've checked the diferences of nuki integartion between version 0.110.7 and 0.111.0. In 0.111.0 pynuki was changed from 1.3.3 to 1.3.7. Pynuki 1.3.3 works on the old api. Pynuki 1.3.7 works on api version 1.10. There are also introduced nuki opener support. Pynuki was rewrited heavly between versions. I've just downgreded nuki component to version 0.110.7 and pynuki to 1.3.3. For now it works.

loadamasta · 2020-07-23T05:26:49Z

I've also has this bug. I read the conversation and tried the fix proposed by derandiunddasbo. For me it doesn't work. After upplied the fix I can easly triggered "unavaiable" state just quickly clicking many times on "lock" action. I've checked the diferences of nuki integartion between version 0.110.7 and 0.111.0. In 0.111.0 pynuki was changed from 1.3.3 to 1.3.7. Pynuki 1.3.3 works on the old api. Pynuki 1.3.7 works on api version 1.10. There are also introduced nuki opener support. Pynuki was rewrited heavly between versions. I've just downgreded nuki component to version 0.110.7 and pynuki to 1.3.3. For now it works.

Sorry for the question: bit where do you find pynuki.py as older version and where do I have to place it? Thanks.

jacekkjw · 2020-07-23T06:23:28Z

Do nothing with pynuki. Follow the derandiunddasbo instruction about custom components but download version 0.110.7 of nuki component form githab (not the latest). In file manifest.json there is information about required version of pynuki: "requirements": ["pynuki==1.3.3"]. Base on that HA will download correct version of pynuki. Don't try to mix old version of pynuki and newest version of nuki component - it doesn't work.

pschmitt · 2020-07-23T16:04:03Z

Anyway. I'm pretty sure that I fixed the here described issue at a pynuki level with version 1.3.8.

For implementation details see the upstream commit and my comment in the corresponding issue.

I must say that I'm not exactly a fan of the fact that the hass component uses aggressive polling by default. This should really be avoided at any cost. I was myself wondering why the batteries were running out so quickly on my lock...

pschmitt · 2020-07-23T16:05:22Z

Oh yeah. Can someone please confirm if pynuki 1.3.8 fixes this here issue? And open a PR with the requirements update? 👼

EDIT: PR opened -> #38159

chpego · 2020-07-24T06:59:26Z

@pschmitt yes, i will try ;)
Edit1 : how can i reload/rebuild the component ? I modified the /usr/src/homeassistant/homeassistant/components/nuki/manifest.json file to include version 1.3.8

jacekkjw · 2020-07-24T08:52:52Z

I'm using nuki with the newest pynuki librabry (version 1.3.8) from several hours. I've also performed few stress tests. Previously these test caused the problem, now nuki survive all these tests. For me is ok.

bigboban · 2020-07-27T19:58:14Z

Issue closed but i think some problem is still there. Now HA Nuki component is probably fixed and more reliable. BUT! I think Nuki bridge is still unreliable, because i have many small "unavailable" thin grey lines on Nuki HA graph. I will try to continue issue on Nuki dev web.

pschmitt · 2020-07-28T18:12:32Z

@bigboban that's another issue. Please open a new one for this.

joydashy · 2020-07-31T07:13:44Z

I think the problem may not be fixed, had the Lock go unresponsive after a week or so of uptime on latest HA version.

frenck added the integration: nuki label Jun 12, 2020

probot-home-assistant bot assigned pvizeli Jun 12, 2020

pearlythepirate mentioned this issue Jul 23, 2020

Home assistant 0.111.1 : cannot read nuki state pschmitt/pynuki#56

Closed

pschmitt added a commit to pschmitt/home-assistant that referenced this issue Jul 24, 2020

Fix home-assistant#36719

ac8dc44

pschmitt mentioned this issue Jul 24, 2020

Fix Nuki Locks and Openers not being available after some time #38159

Merged

20 tasks

frenck closed this as completed in #38159 Jul 24, 2020

Home assistant 0.111.1 Nuki update problem #36719

Home assistant 0.111.1 Nuki update problem #36719

Comments

Ciqsky commented Jun 12, 2020 • edited Loading

The problem

Environment

Problem-relevant configuration.yaml

Traceback/Error logs

Additional information

probot-home-assistant bot commented Jun 12, 2020

pvizeli commented Jun 12, 2020

pschmitt commented Jun 12, 2020

Ciqsky commented Jun 12, 2020 via email

rafuz commented Jun 13, 2020 • edited Loading

pschmitt commented Jun 13, 2020 • edited Loading

joydashy commented Jun 15, 2020

mecrip commented Jun 17, 2020

SeraphimSerapis commented Jun 19, 2020

kachalex commented Jun 19, 2020

juanrferia commented Jun 20, 2020

stiltjack commented Jun 20, 2020 • edited Loading

marcobag commented Jun 21, 2020

swissmaster1 commented Jun 21, 2020

CptKalibak commented Jun 21, 2020 • edited Loading

bigboban commented Jun 22, 2020

Ra72xx commented Jun 23, 2020

loadamasta commented Jun 23, 2020 • edited Loading

dominik-doll commented Jun 24, 2020

mokusnz commented Jun 29, 2020

cassianyoung commented Jun 30, 2020

Ciqsky commented Jul 1, 2020

stiltjack commented Jul 1, 2020

stiltjack commented Jul 1, 2020

chpego commented Jul 2, 2020

marcobag commented Jul 2, 2020 via email

bigboban commented Jul 2, 2020

Ciqsky commented Jul 2, 2020 • edited Loading

bigboban commented Jul 18, 2020 • edited Loading

joydashy commented Jul 18, 2020

dominik-doll commented Jul 18, 2020

Ra72xx commented Jul 19, 2020

joydashy commented Jul 19, 2020

myGithub-Markus commented Jul 19, 2020

loadamasta commented Jul 22, 2020

joydashy commented Jul 22, 2020

loadamasta commented Jul 22, 2020

pvizeli commented Jul 22, 2020

derandiunddasbo commented Jul 22, 2020

marcobag commented Jul 22, 2020

loadamasta commented Jul 22, 2020

derandiunddasbo commented Jul 22, 2020

loadamasta commented Jul 22, 2020

derandiunddasbo commented Jul 22, 2020

jacekkjw commented Jul 22, 2020

loadamasta commented Jul 23, 2020

jacekkjw commented Jul 23, 2020

pschmitt commented Jul 23, 2020

pschmitt commented Jul 23, 2020 • edited Loading

chpego commented Jul 24, 2020 • edited Loading

jacekkjw commented Jul 24, 2020

bigboban commented Jul 27, 2020

pschmitt commented Jul 28, 2020

joydashy commented Jul 31, 2020

Ciqsky commented Jun 12, 2020 •

edited

Loading

Problem-relevant `configuration.yaml`

rafuz commented Jun 13, 2020 •

edited

Loading

pschmitt commented Jun 13, 2020 •

edited

Loading

stiltjack commented Jun 20, 2020 •

edited

Loading

CptKalibak commented Jun 21, 2020 •

edited

Loading

loadamasta commented Jun 23, 2020 •

edited

Loading

Ciqsky commented Jul 2, 2020 •

edited

Loading

bigboban commented Jul 18, 2020 •

edited

Loading

pschmitt commented Jul 23, 2020 •

edited

Loading

chpego commented Jul 24, 2020 •

edited

Loading