core: Home assistant 0.111.1 Nuki update problem

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 …

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

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…

@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

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 notifications@github.com 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.

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

@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

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

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!

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

Great job! Fingers crossed! 😃

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

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 😅

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.

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.

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

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.

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.

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.