No hay problema con el clic en Gladys. Es el tiempo de propagación hasta la cerradura el que es largo. Y desde el punto de vista del usuario, esto genera dudas y me apeteció hacer clic una segunda vez…
¡Muchas gracias @StephaneB por tus comentarios y tu tiempo! Veo que hay muchas cosas buenas que implementar. En algunos puntos, diría que también es el papel de la documentación.
La historia del botón, tengo que investigar 
Voy a ver qué puedo cambiar esta semana.
Para la historia del botón, no creo que sea un bloqueo para una versión, a menos que consideres que hay un error de lentitud en la integración de Nuki, pero si no, no es responsabilidad de la integración y no impide la versión 
En cambio, todos los pequeños comentarios de UX son muy pertinentes.
Hola @StephaneB y @pierre-gilles
-
La página ‹ dispositivos › muestra una explicación interesante cuando aún no se tiene una configuración MQTT (de memoria, un texto que explica que hay dos formas de conectarse: ya sea por MQTT o a través de NukiWeb). Pero tan pronto como se tiene un MQTT configurado, esta explicación ya no aparece y se ven los dos botones Descubrimiento MQTT y Descubrimiento Web. Creo que la explicación debería seguir siendo visible hasta que no se haya realizado el descubrimiento de ningún dispositivo.
-
¿Por qué no? ya está en su lugar
-
La página ‹ Configuración › es en realidad específica de la versión ‹ web ›. Por lo tanto, tal vez renombrarla ‹ Configuración Web ›
-
Hecho
-
En esta página ‹ Configuración ›, añadir una precisión en el paso 1: "Si aún no tiene una cuenta Nuki Web, cree una siguiendo las explicaciones de https://help.nuki.io/hc/fr/articles/360016485718-Activer-et-désactiver-un-compte-Nuki-Web
-
Modificado con: “1. Si aún no tiene una cuenta Nuki Web, cree una siguiendo estas explicaciones y luego vaya al sitio NukiWeb”
y el enlace se adapta a cada idioma -
En la página NukiWeb, se muestra una clave API en primer lugar, pero entiendo que no es la clave que necesitas, y que hay que bajar un poco en la página para generar un token API. Tal vez tu página de configuración podría especificar esto en el paso 3: « … (Atención, no se trata de la clave OAuth2, sino de un token que debe crearse específicamente) ».
-
Modificado por: “3. Ingrese su token API a continuación (Atención, no se trata de la clave OAuth2, sino del token API creado anteriormente)”
-
Y en todas las páginas donde usas el término Clave API, tal vez reemplazarlo por Token de API?
-
De hecho, lo he modificado
-
Cuando se crea el token API en NukiWeb, se pueden marcar/desmarcar los permisos a otorgar. ¿Necesitas todos? Sería bueno indicar los permisos a marcar que realmente te son necesarios, para no dar permisos en realidad innecesarios.
-
No los necesito todos en efecto (y es más seguro no ponerlos todos), pero me parece que es un gran bloque de explicación para integrar en la interfaz de Gladys. La documentación y las capturas de pantalla lo mencionan.
-
Cuando la clave API se guarda en Gladys, se muestra con asteriscos, y el botón « Guardar la configuración » está activo. No he hecho la prueba, pero si vuelvo a hacer clic en este botón, ¿va a sobrescribir la clave real ingresada anteriormente (por ejemplo ‹ qslkjhqdgiuyzeart ›) por ‹ qsl**********art › y ya no funcionará? Sugiero desactivar el botón mientras no se ingrese nada nuevo en el campo Clave API…
-
Si la clave no se cambia, entonces presionar el botón « guardar » no cambia nada (tengo un detector de cambios). Ahora el botón guardar está desactivado si la clave no se modifica. El riesgo de esto es que al pegar 1 carácter X después de « qsl**********art » por ejemplo, se considera un cambio, el botón se activa y al guardar la nueva clave de reemplazo es « qsl**********artX ».
-
Después de ingresar una clave API válida, podría haber un texto que invite a ir a la página « Descubrimiento Web »
-
No he encontrado una manera de verificar que la clave ingresada es válida. Propongo añadir el paso « 4. Realice una búsqueda en Descubrimiento Web para añadir sus dispositivos »
-
en la página Descubrimiento Web, el texto dice « Descubrimiento automático… » pero no entendí de inmediato que aún así tenía que hacer clic en el botón « Buscar »
-
Lo he hecho simple y cambiado el texto por: « Iniciar una búsqueda para descubrir dispositivos desde su cuenta NukiWeb. »
-
En el panel de control, la adición de la cerradura con el widget Dispositivo es muy clara, genial. Solo un detalle: un clic en bloquear/desbloquear tarda un tiempo variable en realizarse, entre ‹ inmediato › y varios segundos. Podría haber una información que invite a esperar, para evitar clics intempestivos?
Este punto que señalaste se debía a que actualizaba el estado del botón según el estado de la cerradura (para estar alineado cuando un usuario usa la aplicación o realiza una acción manual) y no estaba muy bien pensado. Está corregido Web & MQTT.
Una vez más: gracias por estos valiosos comentarios (como dicen, las pruebas de los usuarios, no hay nada mejor). La imagen está actualizada y disponible.
Gracias por todos estos cambios, parece muy bien todo según lo que leo. Creo que podré probarlo este viernes…
Gracias por tomarte el tiempo para una pequeña llamada esta tarde @ProtZ
Retorno tras nuestra llamada:
- Cambiar la imagen de la integración para una mejor calidad → Te he puesto la imagen en un comentario de PR. Creo que podrás poner
"whiteBackground": trueo"invertInDarkMode": trueen el JSON dedevices.jsonpara dar una indicación a Gladys para el modo oscuro. ¡Puedes probar las dos opciones y ver cuál queda mejor en modo oscuro! - Poner un mensaje para especificar que si se usa HTTP, el cerrojo solo se actualizará una vez por minuto en caso de cambio en otra aplicación
- En el código, solo tengo un comentario, pero realmente nada grave, hay un trozo de código duplicado creo: https://github.com/GladysAssistant/Gladys/pull/2288#pullrequestreview-3567357332
Por lo demás, como decía, ¡es una PR genial! ¡Enhorabuena por este desarrollo, tengo ganas de verlo en Gladys 
He realizado las modificaciones. ¡Gracias por tu revisión! (La imagen está en construcción)
Al final no he tenido tiempo de probar hoy. ¿Sigue siendo útil que lo pruebe este fin de semana, y por lo tanto con la versión que has construido hoy?
Sí, con gusto para una prueba, si sale bien puedo fusionar el lunes
He probado la implementación de la integración, no hay nada que objetar, me parece muy bien. Y el funcionamiento también es bueno en el caso nominal.
Sin embargo, hay una cosita que me molesta en el caso de que se active un bloqueo y no es posible porque el picaporte no está correctamente levantado. Estoy haciendo pruebas más precisas para poder describir…
Lo primero (en el caso nominal): como el estado del candado solo se actualiza una vez por minuto, nos encontramos con una visualización incoherente justo después de una acción, mientras se espera la actualización: por ejemplo, el botón accionable es ‹ bloquear › y el otro botón muestra ‹ desbloqueado › mientras que el icono de estado es un candado cerrado.
¿Quizás se debería usar un icono de estado que designe un estado incierto, en espera de actualización?
@ProtZ Quizás, en el caso de que el usuario pulse el botón « bloquear » o « desbloquear », podríamos programar una o dos excepciones de sondeo 10-15 segundos después, y poner un estado « en curso » mientras tanto.
@StephaneB gracias por esta nueva prueba.
@pierre-gilles sí, en efecto (ya sea una encuesta; ya sea una actualización del estado un poco adelantada) estoy tratando de investigar eso
Y luego está el otro caso, cuando hago clic en ‹ bloquear › pero el picaporte no está levantado: después de la acción y la actualización al minuto siguiente, me encuentro con esta interfaz:
Es coherente, pero en realidad no es real porque el cerrojo no logró cerrarse.
Y he hecho 5 pruebas así, y una de cada cinco veces tuve temporalmente una pantalla rara, hasta la actualización del minuto:
Hola @StephaneB,
He puesto a disposición una modificación (al menos lo he intentado) que parece funcionar en mi caso.
Después de enviar el comando por http, envío un estado de actividad y luego, después de 10 segundos, una actualización del estado del cerrojo.
No he encontrado nada mejor
¡Me parece perfecto! ¡Gracias por la modificación! ¡Manténgame informado cuando necesite que haga un merge
Lo probaré mañana.
¡Listo, prueba realizada! Para el funcionamiento nominal, es impecable: el icono que se muestra unas pocas segundos antes de mostrar el estado real después de un bloqueo o desbloqueo funciona bien.
Para el caso particular de un intento de bloqueo, cuando el picaporte estaba levantado, en realidad me doy cuenta de que el display no es coherente, pero que la aplicación Nuki en sí (en mi smartphone) no hace mejor: cuando inicio un bloqueo mientras el picaporte está levantado, la aplicación me muestra primero una alerta indicando que el bloqueo es imposible, pero el estado mostrado después es « bloqueado », cuando en realidad no lo está. Por lo tanto, en la integración que haces en Gladys, no es de extrañar que no puedas hacer mejor. ¡Lo volveré a probar en otra ocasión si veo que la aplicación Nuki se ha mejorado. Pero creo que esto no debe impedir integrar lo que has hecho en la próxima versión de Gladys.
¡Bravo por este desarrollo!
Ah sí, solo una sugerencia: ¿sería complicado añadir el control de la cerradura en escenas?
¡Gracias @StephaneB por esta última prueba!
Para el control de la cerradura en las escenas, lo miré rápidamente, pero no entendí cómo hacerlo.
Está en el futuro roadmap + gestionar el último usuario que interactuó con la cerradura (ej: manual, aplicación, usuario suegro, usuario mi esposa, etc.)