No problem with the click in Gladys. It’s indeed the propagation time to the lock that’s long. And from a user’s point of view it creates doubt and makes me want to click a second time…
1 Like
Thank you so much @StephaneB for your feedback and your time! I see there are quite a few good things to put in place. For some points, I would say that’s also the role of the documentation.
About the button issue, I need to dig into it 
I’ll see what I can change this week.
Regarding the button issue, I don’t think it’s blocking for a release, unless you consider that there’s a slowness bug in the Nuki integration, but otherwise it’s not the integration’s responsibility and it doesn’t prevent the release 
However, all the small UX feedback is very relevant!
Hello @StephaneB & @pierre-gilles
-
The ‹ Devices › page displays a useful explanation when there is no MQTT configuration yet (from memory, a text explaining that there are two ways to connect: either via MQTT or via NukiWeb). But as soon as an MQTT is configured, this explanation no longer appears and you see the two buttons MQTT Discovery and Web Discovery. I think the explanation should remain visible until a device discovery has been performed.
-
Why not; it’s in place
-
The ‹ Configuration › page is actually specific to the ‹ web › version. So maybe rename it ‹ Web Configuration ›
-
Done
-
On this ‹ Configuration › page, add a clarification to step 1: "If you do not yet have a Nuki Web account, create one by following the instructions at https://help.nuki.io/hc/fr/articles/360016485718-Activer-et-désactiver-un-compte-Nuki-Web
-
Modified to: “1. If you do not yet have a Nuki Web account, create one by following these instructions then go to the NukiWeb site”
and the link is adapted for each language -
On the NukiWeb page, an API key is displayed first, but I understand that’s not the key you need, and you have to scroll down a bit on the page to generate an API token. Perhaps your configuration page could clarify this in step 3: “… (Warning, this is not the OAuth2 key, but rather a token to be created specifically).”
-
Modified to: “3. Enter your API token below (Warning, this is not the OAuth2 key, but the API token created previously)”
-
And on all pages where you use the term Clé API, maybe replace it with API token?
-
Indeed, I changed it
-
When creating the API token on NukiWeb, you can check/uncheck the permissions to grant. Do you need them all? It would be good to indicate the permissions that are actually necessary so as not to grant unnecessary rights.
-
You don’t need them all indeed (and it’s safer not to check them all), but that seems like a big block of explanation to integrate into the Gladys interface. The documentation and screenshots cover it.
-
When the API key is saved in Gladys, it is displayed with asterisks, and the « Save configuration » button is active. I haven’t tried it, but if I click that button again, will it overwrite the real key entered previously (for example ‹ qslkjhqdgiuyzeart ›) with ‹ qsl\\\\\\\\\*\*art › and then stop working? I suggest greying out the button as long as nothing new has been entered in the API key field…
-
If the key is not changed then pressing the « save » button does nothing (I do have a change detector). Now the save button is disabled if the key is not modified. The risk of this is that by pasting 1 character X after “qsl\\\\\\\\\\art” for example, it considers that it’s a change, the button activates and on save the new replacement key becomes “qsl\\\\\\\\\*\*artX”.
-
After entering a valid API key, there could be a text inviting the user to go to the « Web Discovery » page
-
I couldn’t find a way to verify that the entered key is valid. I propose adding step “4. Do a search in Web Discovery to add your devices”
-
On the Web Discovery page, the text says « Automatic discovery… » but I didn’t immediately understand that you still need to click the « Search » button
-
I kept it simple and changed the text to: « Start a search to discover devices from your NukiWeb account. »
-
In the dashboard, adding the lock with the Device widget is very clear, great. Just one detail: a click on lock/unlock takes a variable amount of time to complete, between ‹ immediate › and several seconds. Maybe there could be a message asking to wait, to avoid unintended repeated clicks?
This point you highlighted came from the fact that I update the button status based on the lock state (to stay in sync when a user uses the app or does a manual action) and that wasn’t very well thought out. It’s fixed for Web & MQTT.
Once again: thanks for this valuable feedback (as we see, user testing is the best). The image is updated & available.
2 Likes
Thanks for all these changes, it looks pretty good to me as I read it. I think I’ll be able to test this Friday…
Thank you for taking the time for a quick call at noon today @ProtZ
Feedback following our call:
- Change the integration image for better quality → I put the image in a PR comment. I think you can set
\"whiteBackground\": trueor\"invertInDarkMode\": truein thedevices.jsonJSON to give Gladys a hint for dark mode. You can test both options and see which one looks better in dark mode! - Add a message to specify that if used over HTTP, the lock will only be updated once per minute when changed from another application
- As for the code, I only have one piece of feedback but it’s really nothing serious, there seems to be a duplicated bit of code I think: Nuki by ngeissel · Pull Request #2288 · GladysAssistant/Gladys · GitHub
Otherwise, as I said, it’s a great PR! Congrats again on this development, can’t wait to see it in Gladys 
I’ve made the few changes, thanks for your review (the image is being built)
1 Like
I didn’t have time to test today after all. Is it still useful for me to test this weekend, and therefore with the version you built today?
Yes, happy to run a test; if it’s successful I can merge on Monday
I tested setting up the integration — no complaints, it’s fine with me. And it also works well in the normal case.
However, there’s a little thing that bothers me in the case where we trigger a lock and it’s not possible because the handle isn’t properly raised. I’m doing more precise tests so I can describe it…
One first thing (in the normal case): since the lock state is only updated once per minute, you end up with an inconsistent display just after an action, while waiting for the update: for example the actionable button is ‹ Lock › and the other button displays ‹ Unlocked › while the status icon is a closed padlock.
Maybe there should be a status icon indicating an uncertain state, awaiting an update?
@ProtZ Maybe that in the case where the user presses the « lock » or « unlock » button, we can schedule one or two exceptional polls 10-15 seconds later, and set an « in progress » state while waiting?
@StephaneB thanks for this new test.
@pierre-gilles yes indeed (either a poll; or a state update a bit early) I’m trying to dig into that
1 Like
And so the other case is when I click on ‹ lock › while the handle is not lifted: after the action and the update at the next minute, I end up with this interface:
It looks consistent, but it’s not actually the case since the lock failed to close.
And I did five tests like that, and once out of the five I temporarily had a strange display, until the minute update:
Hello @StephaneB,
I’ve made a change available (at least I tried something) that seems to work for me.
After sending the command via HTTP, I push a state activity then after 10s an update of the lock’s state.
I haven’t found anything better
1 Like
That seems perfect! Thanks for the change! Let me know when you need me to merge