Nuki integration development

Hi @ProtZ! :waving_hand:

Thanks for the recent changes, they’re great :folded_hands:

I was looking at your recent changes on the lock display widget:

Screenshot 2026-01-19 at 09.28.50

Wouldn’t we want to standardize the values used?

It seems like you relied on the values exposed by Nuki.
But if we implement another brand later, with the current setup, it will have to conform to a kind of “Nuki standard” :grinning_face_with_smiling_eyes:

Also, if we look at the locks already implemented (home, car), we see that the state is inverted compared to Nuki.

In my view, adding a small conversion layer, very simple, with Gladys-specific constants would be more future-proof and more consistent from a product perspective.

For example:

unlock: 0
lock: 1
activity: 2
alert: 3

What do you think? :slightly_smiling_face:

Hello @pierre-gilles ,
The mapping was supposed to be relatively “standard” (we discussed it in the meeting), I removed the comments that were confusing and were indeed aligned with what Nuki proposed.
However I wasn’t aligned with the other existing “lock” (lock and unlock were inverted).
Last night I therefore made the changes to align with your proposal (+ a small improvement to the reporting of an error state over MQTT).
The doc is up to date as well.
Everything has been pushed.

1 Like

For your information, I reported this inconsistent display to Nuki support, who confirmed that they are aware of the problem.

1 Like

Excellent, thank you very much for these latest changes, it’s perfect!
The PR is really great as it is, I’ve approved :slight_smile:

I’ll merge this at the end of the week for a release ASAP!

Thanks again @ProtZ for the development and @StephaneB for the testing :folded_hands:

2 Likes

The PR has been merged and will be included in the next Gladys release!

It’s live in Gladys Assistant v4.67 :