Kein Problem mit dem Klick in Gladys. Es ist einfach die Ausbreitungszeit bis zum Schloss, die lang ist. Und aus Nutzersicht wirft das Zweifel auf und ich hatte Lust, ein zweites Mal zu klicken…
Vielen Dank @StephaneB für dein Feedback und deine Zeit! Ich sehe, dass es einige gute Dinge gibt, die wir umsetzen können. Bei manchen Punkten würde ich sagen, dass das auch die Aufgabe der Dokumentation ist.
Die Geschichte mit dem Button muss ich noch genauer untersuchen 
Ich werde sehen, was ich diese Woche ändern kann.
Bei der Geschichte des Buttons denke ich nicht, dass das ein Blockierer für ein Release ist, es sei denn, du siehst ein Problem mit der Langsamkeit in der Nuki-Integration, aber ansonsten ist das nicht die Verantwortung der Integration und es verhindert nicht das Release 
Aber alle kleinen UX-Rückmeldungen sind sehr relevant!
Bonjour @StephaneB& @pierre-gilles
-
Die Seite ‹ Geräte › zeigt eine interessante Erklärung an, wenn noch keine MQTT-Konfiguration vorhanden ist (soweit ich mich erinnere, ein Text, der erklärt, dass es zwei Möglichkeiten gibt, sich zu verbinden: entweder über MQTT oder über NukiWeb). Sobald jedoch eine MQTT-Konfiguration vorhanden ist, wird diese Erklärung nicht mehr angezeigt und man sieht die beiden Schaltflächen MQTT-Erkennung und Web-Erkennung. Ich denke, die Erklärung sollte sichtbar bleiben, bis keine Geräteerkennung durchgeführt wurde.
-
Warum nicht; es ist implementiert
-
Die Seite ‹ Konfiguration › ist tatsächlich spezifisch für die Version ‹ web ›. Vielleicht sollte sie in ‹ Web-Konfiguration › umbenannt werden
-
Erledigt
-
Auf dieser Seite ‹ Konfiguration › sollte in Schritt 1 eine Präzisierung hinzugefügt werden: « Wenn Sie noch kein Nuki Web-Konto haben, erstellen Sie eines, indem Sie den Anweisungen von https://help.nuki.io/hc/fr/articles/360016485718-Activer-et-désactiver-un-compte-Nuki-Web folgen »
-
Geändert mit: „1. Wenn Sie noch kein Nuki Web-Konto haben, erstellen Sie eines, indem Sie diesen Anweisungen folgen und gehen Sie dann auf die NukiWeb-Website“
und der Link ist an jede Sprache angepasst -
Auf der NukiWeb-Seite wird zunächst ein API-Schlüssel angezeigt, aber ich verstehe, dass dies nicht der Schlüssel ist, den du brauchst, und dass man etwas weiter auf der Seite scrollen muss, um ein API-Token zu generieren. Vielleicht könnte deine Konfigurationsseite dies in Schritt 3 präzisieren: „… (Achtung, es handelt sich nicht um den OAuth2-Schlüssel, sondern um ein speziell zu erstellendes Token).“
-
Geändert zu: „3. Geben Sie Ihr API-Token unten ein (Achtung, es handelt sich nicht um den OAuth2-Schlüssel, sondern um das zuvor erstellte API-Token)“
-
Und auf allen Seiten, auf denen du den Begriff API-Schlüssel verwendest, könntest du ihn vielleicht durch API-Token ersetzen?
-
In der Tat, ich habe es geändert
-
Wenn das API-Token auf NukiWeb erstellt wird, kann man die zu vergebenden Rechte an- und abwählen. Brauchst du alle? Es wäre gut, die Rechte anzugeben, die wirklich notwendig sind, um nicht unnötige Rechte zu vergeben.
-
Man braucht nicht alle (und es ist sicherer, nicht alle zu setzen), aber das scheint mir ein großer Block an Erklärung zu sein, der in die Gladys-Schnittstelle integriert werden muss. Die Dokumentation und die Screenshots sprechen davon.
-
Wenn der API-Schlüssel in Gladys gespeichert wird, wird er mit Sternchen angezeigt, und die Schaltfläche „Konfiguration speichern“ ist aktiv. Ich habe es nicht ausprobiert, aber wenn ich auf diese Schaltfläche klicke, wird der zuvor eingegebene echte Schlüssel (z. B. ‹ qslkjhqdgiuyzeart ›) durch ‹ qsl**********art › überschrieben und es funktioniert nicht mehr? Ich schlage vor, die Schaltfläche zu deaktivieren, solange nichts Neues im API-Schlüssel-Feld eingegeben wird…
-
Wenn der Schlüssel nicht geändert wird, ändert das Drücken der „Speichern“-Schaltfläche nichts (ich habe einen Änderungsdetektor). Jetzt ist die Speicherschaltfläche deaktiviert, wenn der Schlüssel nicht geändert wird. Das Risiko dabei ist, dass beim Einfügen eines Zeichens X nach „qsl**********art“ zum Beispiel, dies als Änderung betrachtet wird, die Schaltfläche aktiviert wird und beim Speichern der neue Ersatzschlüssel „qsl**********artX“ ist.
-
Nach der Eingabe eines gültigen API-Schlüssels könnte ein Text erscheinen, der dazu auffordert, zur Seite „Web-Erkennung“ zu gehen
-
Ich habe keine Möglichkeit gefunden, zu überprüfen, ob der eingegebene Schlüssel gültig ist. Ich schlage vor, den Schritt „4. Führen Sie eine Suche in Web-Erkennung durch, um Ihre Geräte hinzuzufügen“ hinzuzufügen
-
Auf der Seite Web-Erkennung steht „Automatische Erkennung…“, aber ich habe nicht sofort verstanden, dass man trotzdem auf die Schaltfläche „Suchen“ klicken muss
-
Ich habe es einfach gehalten und den Text geändert zu: „Eine Suche starten, um Geräte von Ihrem NukiWeb-Konto zu erkennen.“
-
Im Dashboard ist die Hinzufügung des Schlosses mit dem Geräte-Widget sehr klar, top. Nur ein Detail: Ein Klick auf Verriegeln/Entriegeln dauert eine variable Zeit, zwischen ‹ sofort › und mehreren Sekunden. Es könnte vielleicht eine Information geben, die zum Warten auffordert, um versehentliche Klicks zu vermeiden?
Dieser von dir hervorgehobene Punkt kam daher, dass ich den Status der Schaltfläche in Abhängigkeit vom Zustand des Schlosses aktualisiert habe (um abgestimmt zu sein, wenn ein Benutzer die Anwendung verwendet oder eine manuelle Aktion durchführt), und das war nicht gut durchdacht. Es ist Web & MQTT korrigiert.
Noch einmal: Danke für dieses wertvolle Feedback (wie man sieht, gibt es nichts Besseres als Tests durch Benutzer). Das Bild ist maj & verfügbar.
Danke für all diese Änderungen, das klingt wirklich nicht schlecht, wenn ich das so lese. Ich denke, ich kann das am Freitag testen…
Danke, dass du dir heute Mittag Zeit für ein kurzes Gespräch genommen hast, @ProtZ
Feedback nach unserem Anruf:
- Bild der Integration für eine bessere Qualität ändern → Ich habe dir das Bild in einem PR-Kommentar hinterlassen. Ich denke, du kannst
"whiteBackground": trueoder"invertInDarkMode": truein der JSON-Datei vondevices.jsonangeben, um Gladys eine Anweisung für den Dark Mode zu geben. Du kannst beide Optionen testen und sehen, welche im Dark Mode besser aussieht! - Eine Nachricht hinzufügen, um zu spezifizieren, dass, wenn HTTP verwendet wird, das Schloss nur einmal pro Minute aktualisiert wird, falls sich etwas in einer anderen Anwendung ändert
- Beim Code habe ich nur ein Feedback, aber wirklich nichts Ernstes, ich habe das Gefühl, dass ein Stück Code dupliziert ist: https://github.com/GladysAssistant/Gladys/pull/2288#pullrequestreview-3567357332
Ansonsten, wie ich schon sagte, ist das ein super PR! Nochmals Glückwunsch zu dieser Entwicklung, ich freue mich schon darauf, das in Gladys zu sehen 
Ich habe die paar Änderungen gemacht, danke für dein Review (das Bild wird gerade gebaut).
Habe heute leider keine Zeit zum Testen gehabt. Ist es trotzdem sinnvoll, wenn ich am Wochenende teste, also eher mit der Version, die du heute gebaut hast?
Ja, gerne für einen Test, wenn es erfolgreich ist, kann ich Montag mergen
Ich habe die Implementierung der Integration getestet, nichts zu beanstanden, das passt mir sehr gut. Und die Funktionsweise ist auch im Normalfall gut.
Es gibt allerdings eine Kleinigkeit, die mich stört, wenn ein Verriegeln ausgelöst wird und es nicht möglich ist, weil der Griff nicht korrekt angehoben ist. Ich führe genauere Tests durch, um es beschreiben zu können…
Erstens (im Normalfall): Da der Zustand des Schlosses nur einmal pro Minute aktualisiert wird, ergibt sich direkt nach einer Aktion eine inkonsistente Anzeige, bis die Aktualisierung erfolgt ist. Zum Beispiel ist die schaltbare Schaltfläche „verriegeln“ und die andere Schaltfläche zeigt „entriegelt“ an, während das Status-Symbol ein geschlossenes Schloss ist.
Vielleicht sollte es ein Status-Symbol geben, das einen unbestimmten Zustand anzeigt, der auf eine Aktualisierung wartet?
@ProtZ Vielleicht könnte man im Fall, dass der Benutzer auf den „Sperren“- oder „Entsperren“-Button drückt, eine oder zwei Ausnahmen 10-15 Sekunden später programmieren und einen „in Bearbeitung“-Status in der Zwischenzeit setzen?
@StephaneB vielen Dank für diesen neuen Test.
@pierre-gilles ja, genau (entweder eine Umfrage oder eine etwas frühere Aktualisierung des Status). Ich versuche, das zu vertiefen.
Und dann gibt es den anderen Fall, wenn ich auf „Verriegeln“ klicke, während der Griff nicht hochgeklappt ist: Nach der Aktion und dem Update in der nächsten Minute erhalte ich diese Schnittstelle:
Sie ist konsistent, aber eigentlich nicht real, da das Schloss nicht geschlossen wurde.
Und ich habe fünf Tests durchgeführt, und einmal von fünf Malen hatte ich vorübergehend eine seltsame Anzeige, bis zum Update in der Minute:
Hallo @StephaneB,
Ich habe eine Änderung bereitgestellt (zumindest habe ich etwas versucht), die bei mir zu funktionieren scheint.
Nach der Adressierung des Befehls per HTTP sende ich einen Aktivitätsstatus und nach 10 Sekunden ein Update des Schlosszustands.
Ich habe nichts Besseres gefunden
Das klingt perfekt! Danke für die Änderung! Haltet mich auf dem Laufenden, wenn ihr braucht, dass ich merge
Ich teste das morgen.
Voilà, Test durchgeführt. Für den normalen Betrieb ist es einwandfrei: Das Symbol, das einige Sekunden vor dem Anzeigen des tatsächlichen Status nach einem Verriegeln oder Entriegeln angezeigt wird, funktioniert gut.
Für den speziellen Fall eines Verriegelungsversuchs, während der Griff angehoben war, stelle ich fest, dass die Anzeige nicht konsistent ist, aber die Nuki-App selbst (auf meinem Smartphone) macht es nicht besser: Wenn ich eine Verriegelung starte, während der Griff angehoben ist, zeigt die App mir zunächst eine Warnung an, dass die Verriegelung unmöglich ist, aber der anschließend angezeigte Status ist „verriegelt“, obwohl dies nicht der Realität entspricht. Daher ist es nicht verwunderlich, dass du in der Integration, die du in Gladys machst, nicht besser sein kannst!
Ich werde es gelegentlich erneut testen, wenn ich sehe, dass sich die Nuki-App verbessert hat. Aber ich denke, dass dies nicht verhindern sollte, dass du das, was du gemacht hast, in die nächste Release von Gladys integrierst.
Bravo für diese Entwicklung!
Ah ja, nur eine kleine Anregung: Wäre es kompliziert, die Steuerung des Schlosses in Szenen einzubinden?
Danke @StephaneB für den letzten Test!
Für die Steuerung des Schlosses in den Szenen hatte ich kurz reingeschaut, aber ich habe nicht verstanden, wie das geht.
Das ist in der zukünftigen Roadmap + Verwaltung des letzten Nutzers am Schloss (z. B. manuell, Anwendung, Nutzer Schwiegervater, Nutzer meine Frau usw. …)