Core: Home assistant 0.111.1 Nuki update problem

[Ciqsky]

The problem

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

Environment

host_os | HassOS 4.10
os_version | 4.19.126-v7
python_version | 3.7.7
supervisor | 227
version | 0.111.1

• 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 https://github.com/pschmitt/pynuki/issues/54 but my problem is not with netgear

[probot-home-assistant[bot]]

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]

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]

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

[Ciqsky]

No, with nuki lock i use only its bridge (nuki) with hassio on raspberry

Il Ven 12 Giu 2020, 19:30 Philipp Schmitt [e-mail] 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
https://github.com/home-assistant/core/issues/36719#issuecomment-643397285,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN7AGOU3JDWK2RCHFRXCCPTRWJQ33ANCNFSM4N4KPGFA
.

[rafuz]

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]

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: https://github.com/pschmitt/pynuki/pull/31

[joydashy]

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

[mecrip]

+1 same problem here, started with latest 0.111

[SeraphimSerapis]

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]

same problem here, started with latest 0.111

[juanrferia]

+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]

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]

+1 here, please fix

[swissmaster1]

+1, same problem

[CptKalibak]

+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]

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>

[Larx]

This issue?
https://github.com/pschmitt/pynuki/issues/56
Currently Nuki is pretty much unusable in HA :-( ...

[loadamasta]

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]

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

[mokusnz]

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]

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

[Ciqsky]

Works It now on 112.0 release?

[stiltjack]

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

[stiltjack]

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

[chpego]

Problem still exist on on 112.0 release

[marcobag]

Confirm, still exist!

Inviato da iPhone

Il giorno 2 lug 2020, alle ore 11:23, chpego [e-mail] 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]

+1. Problem still on 112.0. 👎

[Ciqsky]

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]

@Ciqsky Maybe problem is in HA maybe NOT. What about Nuki lock/gw firmware update? Maybe Nuki changed something.. I did lock fw update maybe day before i discover this problem.. Coincidence?

[chpego]

@Ciqsky Maybe problem is in HA maybe NOT. What about Nuki lock/gw firmware update? Maybe Nuki changed something.. I did lock fw update maybe day before i discover this problem.. Coincidence?

I've already the latest firmware on my Nuki lock/gw before install HA 111.1

[Larx]

In my case there was no change in Nuki firnware. The only thing I updated was HA. So it's pretty safe to say that some change on HA broke Nuki. Please also note that a downgrade of HA solves the issue.

[stiltjack]

Mine is still working perfectly after 24 hours (nearly).

There are so many different versions of Home Assistant maybe we should compare our set-ups? Mine is:

I'm running HA on a Pi4.

As far as Nuki is concerned, I have:

Lock firmware version: 2.7.20
Bridge firmware version: 2.5.2
Door sensor not enabled

[stiltjack]

But... after rebooting the Nuki bridge the HA errors return. No change, then. Seems clear where the problem is, though:

[stiltjack]

Come on - really?

[Larx]

At least for me, 0.112 didn't change anything. It only made me lose my HarmonyHub in addition to Nuki, but that's another bug.
Anything which can be done from user side to help devs fix this problem?

[kachalex]

HA 112.1
ERROR
Logger: homeassistant.helpers.entity
Source: components/nuki/lock.py:124
First occurred: 15:13:13 (3 occurrences)
Last logged: 15:14:15

Update for lock.alexanna fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 272, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 466, in async_device_update
self.update # type: ignore
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.

[cassianyoung]

I see that the NA Nuki integration uses the pynuki library.

Did HA picked up a new version of the pynuki python library that it should not have done?

pynuki seems to have had quite a few changes in May.

https://github.com/pschmitt/pynuki/commits?author=pschmitt

Do we need to roll back thomkaufmann's update of the pynuki version in the HA integration on May 16th ???

[mamoel666]

Same problem here. Started wit HA 111.1 (I think):

`Logger: homeassistant.helpers.entity
Source: components/nuki/lock.py:124
First occurred: 3. Juli 2020, 20:20:15 (2353 occurrences)
Last logged: 16:57:40

Update for lock.haustur fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 272, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 466, in async_device_update
self.update # type: ignore
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.
`

[joydashy]

At least for me, 0.112 didn't change anything. It only made me lose my HarmonyHub in addition to Nuki, but that's another bug.
Anything which can be done from user side to help devs fix this problem?

Same here, note that the Harmony issue has a workaround (disable XMPP).

[wmnl25]

+1: AssertionError: Failed to update data for lock. Nuki ID None volatized. & Network issues detect with None

[Ciqsky]

Someone has tried if last Nuki firmware version 2.7.30 change anything with home assistant >= 111.0 ?
I have 110.7.

[chpego]

Someone has tried if last Nuki firmware version 2.7.30 change anything with home assistant >= 111.0 ?
I have 110.7.

I will try with Nuki _2.7.30_ // HA _0.112.4_ ;)

[joydashy]

I have also just updated both Opener and Lock firmware as well as HA, now running that combo. We'll see!

[Ciqsky]

Feedback?

[Larx]

New Nuki firmware now working for about 12h. However, the previous firnware sometimes also stayed online in HA for some time, so it`s too early draw conclusions.

[mamoel666]

Yesterday I updated my Nuki (v2) to 2.7.30 and HA to 0.112.4.
My Nuki went 'offline' after ~14h. In the Nuki App everything is still working fine.

[Ciqsky]

@pvizeli, @pschmitt , have you feedback for us? Most of us cannot upgrade to lastest home assistant release because nuki not work after 110.7. You can help us? Nuki is one of the few smart locks that work really well and supported by the home assistant.
If you need testing or feedback from us, ask us, but please answer us!
Thank you.

[mamoel666]

Nuki is one of the few smart locks that work really well

worked really well

[joydashy]

I currently have an uptime of 28hrs with working Lock and Opener on latest HASS + latest Nuki firmware. Not sure if that's long enough to make any statements, but I feel I didn't manage this long on the older firmware.

[ReneHezser]

After reactivation of the Nuki integration this morning, the errors are still in the logs with HA 112.4 and Nuki 2.7.30 on my setup.

[mamoel666]

There was no change in HA's code to fix this bug and I'm quite sure that Nuki didn't change anything in the firmware because the problem is on HA's side.

[joydashy]

Indeed I still see the errors in the log as well, so I suppose the services remaining online in the GUI are a coincidence.

[derandiunddasbo]

In my opinion, this is a problem with HA, something has been forgotten.

I also think, the problem is caused by HA rather than pynuki. As I already wrote in the related pynuki issue, operating the lock via python inside the HA container is working just fine, even while the HA instance is unable to access or operate the lock. I'm quite sure I could create a stable workaround with some python & shell scripting using command line entities and sensors in a couple of hours, but ATM I'm still hoping, this issue will be resolved soon in the existing nuki component.

[stiltjack]

Home assistant 0.112.4, nuki 2.7.30. Errors start appearing after 48 hours. Which is a bit odd - what happens after 48 hours? I was away at the time, so it can't be anything to do with the use of the lock.

[Larx]

Well, sometimes at once, sometimes after a few hours, it simply sooner or later happens, no matter if the lock is operated in the meantime or not.

[Friedrieck]

Just to +1, it's a real problem.

[Gummientchen]

I have the same problem with the following logged:

`Logger: homeassistant.helpers.entity
Source: components/nuki/lock.py:124
First occurred: 10 July 2020, 14:20:03 (12392 occurrences)
Last logged: 0:51:07

Update for lock.home fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 272, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 466, in async_device_update
self.update # type: ignore
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.`

HA details:
arch | x86_64
chassis | vm
dev | false
docker | true
docker_version | 19.03.8
hassio | true
host_os | HassOS 4.8
installation_type | Home Assistant OS
os_name | Linux
os_version | 5.4.43
python_version | 3.7.7
supervisor | 228
timezone | Europe/Zurich
version | 0.112.3
virtualenv | false

Nuki details:
firmware: 1.9.6 (newest available for me)

[myGithub-Markus]

I have the same problem. I haven't such problems before. Home Assistant and nuki worked perfect.

Nuki 2.7.30
HA 112.4
ERROR
Logger: homeassistant.helpers.entity
Source: components/nuki/lock.py:124

2020-07-14 17:16:04 ERROR (MainThread) [homeassistant.helpers.entity] Update for lock.haupteingang fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 272, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 466, in async_device_update
self.update # type: ignore
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.
2020-07-14 17:16:35 ERROR (MainThread) [homeassistant.helpers.entity] Update for lock.haupteingang fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 272, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 466, in async_device_update
self.update # type: ignore
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.
2020-07-14 17:17:05 ERROR (MainThread) [homeassistant.helpers.entity] Update for lock.haupteingang fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 272, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 466, in async_device_update
self.update # type: ignore
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.

[marcobag]

It’s absurd that no one is working on this bug.

Inviato da iPad

Il giorno 15 lug 2020, alle ore 08:00, myGithub-Markus [e-mail] ha scritto:


I have the same problem. I haven't such problems before. Home Assistant and nuki worked perfect.

Nuki 2.7.30
HA 112.4
ERROR
Logger: homeassistant.helpers.entity
Source: components/nuki/lock.py:124

2020-07-14 17:16:04 ERROR (MainThread) [homeassistant.helpers.entity] Update for lock.haupteingang fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 272, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 466, in async_device_update
self.update # type: ignore
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.
2020-07-14 17:16:35 ERROR (MainThread) [homeassistant.helpers.entity] Update for lock.haupteingang fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 272, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 466, in async_device_update
self.update # type: ignore
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.
2020-07-14 17:17:05 ERROR (MainThread) [homeassistant.helpers.entity] Update for lock.haupteingang fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 272, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 466, in async_device_update
self.update # type: ignore
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.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

[joydashy]

It’s absurd that no one is working on this bug. Inviato da iPad
…

You mean, with the absurd amounts of monthly support fees we are paying for this open-source project? Agree!

[ReneHezser]

It’s absurd that no one is working on this bug. Inviato da iPad
…

https://opensource.com/resources/what-open-source
Even when you are not a programmer you can support the project. Find the API used or provided by Nuki. Then look for a changelog. If you don't find anything, look for the changelog on the Home Assistant. Now try to figure out what changed.
Show us your findings.

Please don't complain like this. Try to feel how engaged people feel about their commitment of (spare)time to support the community.

[bigboban]

@joydashy I think opensource project should follow some common sw development rules exactly the same way as paid project. For example track bugs and its severity. And i think critical bug should have preference against new feature development for example.

@ReneHezser Blindly look into HA and Nuki changes is not the best way to find problem. Someone should debug problem, improve logging or do some maybe small step to bring near to solution.

Maybe little is sometimes more..

[ReneHezser]

@bigboban fully agree. If you are a developer :-)

[marcobag]

I don’t meant to be offensive at all, i’m grateful for all single row of code written… the issue here is that seams that no one is working on this - I THINK - critical bug that can afflict something more than just Nuki.

A word by one of the developer like “We are investigating on that” will be more than enough for me.

Right now seam that no one care apart us.

If the issue is that no one of the developer has a Nuki lock i’ll be more than glad to donate some bucks to give them the opportunity to better debug.

Regards.
Il 15 lug 2020, 09:01 +0200, joydashy [e-mail], ha scritto:

It’s absurd that no one is working on this bug. Inviato da iPad
…
You mean, with the absurd amounts of monthly support fees we are paying for this open-source project? Agree!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

[SeraphimSerapis]

Many of the folks that are supporting this integration are also supporting many other integrations, or the homeassistant core itself. Patience or proactivity may help in this case.

[bigboban]

Proactivity.. I have Nuki. I sent stack trace like many others. What else can i do? Try to send my some test code and i will run. I tested broadlink integration this way using custom python test source.. But now a don't know how to help more here in this problem.

[myGithub-Markus]

I am not sure which module is causing the error (HA, pynuki or nuki itself). Fact is the initialization works. All devices (locks and openers) are found via the nuki bridge and updates a couple of time their properties. After a time of x hours the function updating properties of a lock (it would be interesting if this also happens with an opener? ... I have only one lock) fails in line 86 of pynuki/device.py for l in self._bridge._get_devices(self.device_type) if l.nuki_id == self.nuki_id. Whatever the reason is, this does not work and get back a empty result of l and throw's this error with self.nuki_id none which is shown in the ha log as AssertionError: Failed to update data for lock. Nuki ID **None** volatized.

[aidbish]

@bigboban

@joydashy I think opensource project should follow some common sw development rules exactly the same way as paid project. For example track bugs and its severity. And i think critical bug should have preference against new feature development for example.

what maybe your priority is not necessarily someone elses. the people who develop HA integrations primarily do so in there own free time
There are currently 1000 odd issues open and some far longer than this one and with more comments, so no you cant force people to look at this issue if they have no interest in it or do not own the hardware to diagnose and isn't their priority.

What if the nuki integration developer sees these comments and thinks, meh i dont care anymore and just decided to abandon it we will be screwed as it would then end up dead and possibly removed

[myGithub-Markus]

If I understand that correctly ... the update function in the nuki integration over HA is triggered about every minute. After a time x hours, the function causes an error. The function in HA /components/nuki/lock.py should be perform two attempts per trigger interval. One with param aggressive=false and one with aggressive=true. The first with aggressive=false occurs the error. This error is not a RequestException otherwise you should see the following in the log "Network issues detect with% s". The function HA /components/nuki/lock.py->update with aggressive=false, calls in pynuki get all device via nuki bridge like http://192.168.1.138:8080/list?token=xxxx and then all devices are queried individually using by their own nukiId's delivered by the list of the first call. If I do it myself via browser in such a HA error situation, it works and the nuki bridge provides correct responses. Like first call http://192.168.1.138:8080/list?token=xxxx and then with this result call http://192.168.1.138:8080/lockState?nukiId=xxxx&token=xxxx. Based on the logs, unfortunately I can not determine why the query with aggressive=false causes an error, although it works quite a while when restart HA. Based on this information, I would first exclude the error on the nuki side. In any case, the exception != RequestException is not caught. Maybe that helps to find the error 😅

[bigboban]

I see more problems in code, but i am Python newbie so some things may be some false observations. I changed lock.py little bit to log more info. I see these problems:

A) Http timeouts. Default timeout in pynuki lib is 5 seconds. But my bridge has very slow responses (checked manually in Chrome browser) - sometimes 6 sometimes 8 seconds!! So it is more than timeout limit!

B) Few first tries of update has nuki identification - name and nukiId. But after few minutes requests has no nuki id. I see this in log (this is my custom code):

2020-07-16 12:48:54 WARNING (SyncWorker_17) [custom_components.nuki.lock] XXX Nuki update error 404 Client Error: Not Found for url: http://192.168.X.X:8080/lockState?ts=2020-07-16T10:48:54Z&rnr=32217&hash=XXXXX&nukiId=None&deviceType=0

Note nukiId=None in URL!

EDIT: 404 is really result of "None" as Nuki ID.

Maybe something is consequence of something else. Maybe ID is lost after timeouts?

Test this URL and report response time please (you have to know IP, token and nuki-ID):

http://192.168.X.X:8080/lockState?token=ZZZZZZ&nukiId=88888&deviceType=0

[myGithub-Markus]

@bigboban your are right. I tested it with the url http://192.168.X.X:8080/lockState?token=ZZZZZZ&nukiId=88888&deviceType=0 my response times are from 158ms up to over 8 seconds. So that mean's that could be the reason, but the times are always different and if HA re-trigger every minute it would be strange to have always more than 5 seconds of reaction time 🤔

[bigboban]

Something bad inside lock.py! I see
DEFAULT_TIMEOUT = 20
in lock.py. It should override 5s default inside pynuki? But it does NOT work! I clearly see 5s timout in log:

2020-07-16 12:46:51 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: name=custom_components.nuki.lock, message=['XXX Nuki update start Můj Nuki zámek'], level=WARNING, source=['custom_components/nuki/lock.py', 123], timestamp=1594896411.3951974, exception=, count=1, first_occurred=1594896411.3951974>

2020-07-16 12:46:56 WARNING (SyncWorker_15) [custom_components.nuki.lock] XXX Nuki update error HTTPConnectionPool(host='192.168.X.X', port=8080): Read timed out. (read timeout=5)

Note message and note 5s gap between messages.

[bigboban]

@myGithub-Markus I see two problems - timeouts and missed nukiId in requests. Few first requests ok. Nuki id missed after first timeout? I am not Python expert.. But i see 404's because i custom improved logging for me..

[myGithub-Markus]

@bigboban I also think that after each timeout it loses the nuki-id, but after the next re-trigger by HA, it should come back if the answer is less than 5 seconds. If the error occurs, no more queries work and I don't think that each query takes longer than 5 seconds. In my test via Http Get there are definitely queries that take longer, but also many that are in time. I don't really understand it?

[bigboban]

I see this:

• correct req with ID
• first timeout
• first request without ID -> 404
  ...
  2 hours of log
• hundreds of 404's after req without ID

No other correct REQ. After "id missing" no request is correct so bridge refuse to serve.

My opinion is bug with ID missing was there a long ago (HA bug) but bridge is slow after some update (Nuki bug?) and is is reason 5s timeout is too short now.

I think the fastest and easiest solution (workaround) is to set longer timeout. Why 20s constant in lock.py does NOT override 5s default in pynuki? Some python guru here to explain this?

[myGithub-Markus]

@bigboban I am not a python guru, but I thing there is an error by calling the constructor of bridge.
This is the define of the constructor in pynuki
def __init__( self, hostname, token=None, port=8080, secure=True, timeout=REQUESTS_TIMEOUT, ):
and this is the call from HA
bridge = NukiBridge( config[CONF_HOST], config[CONF_TOKEN], config[CONF_PORT], DEFAULT_TIMEOUT, )
so the param secure is missing and for that timeout is not set correct.

[dominik-doll]

@bigboban I am not a python guru, but I thing there is an error by calling the constructor of bridge.
This is the define of the constructor in pynuki
def __init__( self, hostname, token=None, port=8080, secure=True, timeout=REQUESTS_TIMEOUT, ):
and this is the call from HA
bridge = NukiBridge( config[CONF_HOST], config[CONF_TOKEN], config[CONF_PORT], DEFAULT_TIMEOUT, )
so the param secure is missing and for that timeout is not set correct.

Is this in relation to the following?

https://github.com/home-assistant/core/issues/36844

[myGithub-Markus]

@dominik-doll Yes I thing it is. It is a good idea to create a nuki custom component and test it with your params and of course with secure=false.

[joydashy]

I am not sure which module is causing the error (HA, pynuki or nuki itself). Fact is the initialization works. All devices (locks and openers) are found via the nuki bridge and updates a couple of time their properties. After a time of x hours the function updating properties of a lock (it would be interesting if this also happens with an opener? ... I have only one lock) fails in line 86 of pynuki/device.py for l in self._bridge._get_devices(self.device_type) if l.nuki_id == self.nuki_id. Whatever the reason is, this does not work and get back a empty result of l and throw's this error with self.nuki_id none which is shown in the ha log as AssertionError: Failed to update data for lock. Nuki ID **None** volatized.

I have both the Lock and the Opener. My Opener has still worked perfectly fine for the full uptime of HA, only the Lock stops functioning. If this helps.

[bigboban]

Yes i am trying this right now. Custom component, fixed constructor call with 20s timeout + my new custom logging messages. Let me 24h test and i will report result..

EDIT: Very first and fast look to log - 5s timeouts are gone!
EDIT2: Second fast look - ID is NOT missing anymore, i think it was result of timeouts..

[myGithub-Markus]

Me too, I create a custom component of nuki and will check this too.

[chpego]

Cool @bigboban @myGithub-Markus ; can we help you as well? if you have a process to follow, don't hesitate to share it with us.

[dominik-doll]

Cool @bigboban @myGithub-Markus ; can we help you as well? if you have a process to follow, don't hesitate to share it with us.

+1 happy to help

[Ciqsky]

Great job! Fingers crossed! :)

[cassianyoung]

I believe that these occasional slow response times are a known features of the underlying Nuki hardware which will not respond while it is doing some other update. There was a long discussion about this somewhere a few months ago that terminated with the conclusion that nothing could be done to reduce it.

[myGithub-Markus]

Long timeouts are really not nice ... and nuki bridge API is a good bad example 😜 but in this case the behavior would be the wrong calling of the nuki bridge constructor from HA side. This issue set the HA implentation timeout from 20 seconds to the default 5 seconds. And the secure mode to true. Currently everything looks fine for me. Let's see what happened after 24 hours 😅

[bigboban]

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

[joydashy]

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

Loaded and testing!

[myGithub-Markus]

regardless of the logging extension for the update function, I only changed the following in line lock.py 54 in
config[CONF_HOST], config[CONF_TOKEN], config[CONF_PORT], False, DEFAULT_TIMEOUT, and since then it has works fine for me too.

[bigboban]

Yes this is the fix. Logging is only for me to see/not see messages with timeouts.

[myGithub-Markus]

there is a small difference. I have set the secure param to False as described here https://github.com/home-assistant/core/issues/36844 posted by @dominik-doll. I don't really know if secure should be True or False. Whatever both seem to work fine 😊

[myGithub-Markus]

Short feedback. For me it it works fine for about 17h

[bigboban]

meetoo 👍

[bigboban]

I put bridge http api url into my nagios using check_website_response.sh script. I have nagios graph too, so after 24h i will have nice graph of bridge response times during day.. I will post there and i will send to Nuki support too.

[chpego]

Hi Guys, i put the False settings (in lock.py) and after a reboot, the problem still exists.
Now, i put the True settings
Wait & see...

[bigboban]

It is not about true/false it is about bad constructor call and about bad timeout override (5 vs 20 seconds). I think bug in code still exists (nuki id lost after first? timeout)! Timeout change from 5 to 20s is only workaround!

[legi1]

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

sorry for this question but I'm not a programmer and use HA more or less out of the box. What hat to be done with the lock.py file? I've only added the adress and code in the configuration.yaml file up to now.

[SeraphimSerapis]

@legi1 Make a copy of the Nuki integration and move it into custom_components/nuki, then paste the modified files from the zip file into this folder, restart Home Assistant, and you should be good to go!

[legi1]

Is it possible that I‘dont have an integration, I just made the necessary entries in the configuration.yaml. Or where is this directory?
Sorry again..
Peter

Von meinem iPad gesendet

Am 17.07.2020 um 10:47 schrieb Tim Messerschmidt [e-mail]:


@legi1 Make a copy of the Nuki integration and move it into custom_components/nuki, then paste the modified files from the zip file into this folder, restart Home Assistant, and you should be good to go!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Larx]

Maybe then better wait until the fix is in mainline in your case?

[myGithub-Markus]

@legi1 see a screenshot of my HA config. If you are not familiar with this you should wait until the fix is in mainline.

[chpego]

I've a physical bridge ans still the problem After changing line in lock.py

[bigboban]

I have same important test results:
1) Nagios logs during half-day these values of bridge response times: min 0.8s, avg 3.38s, max 7.73s.
2) My new source only fix bad pynuki constructor call - 5s vs 20s timeout. So timeouts are now gone (all response times below 20s, see previous point)
3) Nuki disconnect problem is still here! Nuki fails after many hours. Now reason is http 503, but result is the same - component lost nuki-ID. I think lock.py has some strange error in code - it losts nuki ID every time some error occured.

I think to fix Nuki integration two fixes are necessary:

• fix/workaround timeout problem - DONE
• fix nuki-id lost after error - STILL BROKEN

[bigboban]

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]

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

[dominik-doll]

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

[Larx]

Hardware here.

[joydashy]

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

Yep, hardware bridge, Opener, Keypad and Lock.

[myGithub-Markus]

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]

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]

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]

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]

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

[derandiunddasbo]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

EDIT: PR opened -> https://github.com/home-assistant/core/pull/38159

[chpego]

@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]

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]

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]

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

[joydashy]

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