Time sync with Nuki opener

[dotdoom]

Checklist

• I have filled out the template to the best of my ability.
• This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
• This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.

The clock in Nuki opener may drift away over time, or shift during DST transition, resulting in scheduled Night mode being off the clock. Nuki API has a "update time" function (which is locked behind a security PIN).

Describe the solution you'd like

We could have a periodic time sync, or based on the drift of Nuki's clock.

Here's an example, the code is for esphome platform:

https://github.com/dotdoom/esphome/blob/bc12358d51eb7ab0f3140d1d86a9feb1e15ab212/components/nuki_lock/nuki_lock.cpp#L234-L275

Describe alternatives you've considered

Simulating Night mode behavior in HA would be possible, but is less reliable than having a lock manage its state automatically.

Additional context

The "set time" function has a code of 0x0021. Details can be found in Nuki's excellent API documentation e.g. https://github.com/I-Connect/NukiBleEsp32/blob/198482dabd3a6e8204af2b918482a888cf69e97a/documentation/20200316NukiSmartLockAPI2_1.pdf

[ronengr]

Thanks for the feedback.
looks like a very interesting idea, I will look into it

[ronengr]

@dotdoom
I've added an action to hass_nuki_bt called update_nuki_time.
You can call it from an automation, so you can periodically update your Nuki's time how frequent you want.
You can find details about and test it in the "actions" tab in developer tools.

The action has one optional parameter "time", that is a datetime type. You can use the built-in scripting feature to have different time formats.
for example, you can pass something like "{{ utcnow() - timedelta(hours=2) }}" or you can use "now()" instead of "utcnow()" if you want UTC time.

If you don't specify a time the local machine time is used (converted to UTC).
From what I see in my Nuki, the internal clock is using UTC and there is a setting for the local timezone (there is timezone_id, timezone_offset and dst_mode in the config struct).

I hope this solves your issue. If not let me know and i will try to improve the solution.

[dotdoom]

Thank you @ronengr ! Now that esphome/issues#6701 fix is under review, I'm moving the rest of my Nuki locks from esphome custom component and into a btproxy soon, so this is indeed very timely.

I'll let you know how it goes with testing, and update this issue.

[dotdoom]

@ronengr I have given it a try; there's something I might not be getting correctly.

There doesn't seem to be an option to choose which lock I want to update. Among them, it seems a random lock will be updated; I'm guessing it takes the last registered lock, because the code keeps overriding the handler to the next device:

hass_nuki_bt/custom_components/hass_nuki_bt/__init__.py

Lines 114 to 126 in e022e25

	async def async_handle_update_nuki_time(call: ServiceCall) -> ServiceResponse:
	time = call.data.get("time")
	if not coordinator._security_pin:
	raise ConfigEntryAuthFailed("Security PIN is required to update nuki time.")
	await device.update_nuki_time(coordinator._security_pin, time)
	hass.services.async_register(
	DOMAIN,
	UPDATE_NUKI_TIME_SERVICE_NAME,
	async_handle_update_nuki_time,
	schema=UPDATE_NUKI_TIME_SCHEMA,
	supports_response=SupportsResponse.NONE,
	)

Note how async_register doesn't take any device ID with it, i.e. action handler seems to be global, and device from the last one is bound to it. Perhaps it needs a different handler, which processes "target" e.g.

https://github.com/home-assistant/core/blob/cab6ec0363824ce78932a7b711ed1d3513d7946a/homeassistant/components/lock/__init__.py#L85-L87

Final note: it would be even nicer if the service could return whether update was successful. There are plenty of reasons why an update may fail, e.g. bluetooth unreachable, incorrect PIN, lock refused to take specified time etc.

[ronengr]

oops.
You are correct, I didn't think of a system with several Nuki devices.

I'm new to services in HA, so I just used the easiest I could find. I will look for a better solution.
I will also look into returning a response.