Wäre es sinnvoll, in der Dokumentation, die über die MQTT-Integration zugänglich ist, eine Beschreibung und/oder ein Bild davon zu haben, wie jede Funktion auf der Dashboard-Oberfläche aussehen wird?
Denn wenn ich einen Slider anzeigen möchte, muss ich im Moment erraten, dass er Variator heißt oder dass er unter Beleuchtung zu finden ist usw.
Wenn ich ein Bild des Endergebnisses hätte, würde mir das bei der Auswahl meiner Funktion helfen.
Das ist eine gute Idee! Darauf kommen mir zwei Dinge in den Sinn:
Alternative Option: Das MQTT-Bildschirm neu überdenken, um diese „Dokumentation“ direkt in die Integration zu integrieren.
Ich denke, dafür braucht ihr nicht unbedingt meine Hilfe, es geht hauptsächlich darum, Inhalte zu schreiben 
@qleg Du, der oft PRs für Übersetzungen macht, falls du mit @guim31 an dem Thema zusammenarbeiten möchtest!
Ich würde mich ja gerne mit dem beschäftigen, was ihr wollt, aber ich weiß nicht, wie man GitHub benutzt (außer um Issues zu schreiben) und ich weiß nicht, wie man eine Entwicklungsumgebung benutzt.
Für mich wäre es WIRKLICH eine bessere Option, diese Dokumentation in die MQTT-Integration zu integrieren. Das Lambda (zu dem ich gehöre) klickt nur sehr selten auf einen Link Dokumentation auf einer Webseite.
Wie würdest du das sehen?
Da bin ich gerade etwas ratlos, aber ich nehme mir gerne Zeit, um darüber nachzudenken und einen Vorschlag zu machen! 
Also, ich habe das Ding sehr schnell gemacht, ich gebe zu, dass mich meine Fähigkeiten zum Basteln zwingen ^^
Die Idee ist:
Auf der Seite zum Erstellen eines MQTT-Geräts würde es kein Suchfeld für Funktionen mehr geben, sondern nur den Button:
Wenn man auf den Button klickt, wird dann unter dem Button / in einem Modal / oder anderswo ein Abschnitt angezeigt, der von dem berühmten Suchfeld überragt wird, sowie dem « Katalog » der Funktionen, der so dargestellt werden könnte:
Ich war nicht hyper ausführlich, ich gebe es zu ^^ aber die Idee ist, den « generischen » Namen der Funktion, ihre Darstellung auf dem Dashboard, aber auch die Schlüsselwörter, mit denen sie verknüpft ist (abzuwarten, ob es super relevant ist, sie anzuzeigen oder nicht).
So wird jemand, der beginnt, temp einzugeben, ein Filter für alle Funktionen erstellen, die diese Zeichenfolge enthalten, wie in der aktuellen Funktionsweise, aber wird sehr schnell finden, wonach er sucht: einen Temperatursensor? Einen Dimmer? Einen Farbtemperatur-Dimmer? Einen Sturmdetektor?! 
Das ist die allgemeine Idee. Eure Meinungen dazu!
Ich mag die Idee! Soweit ich mich erinnere, sagte PG:
Modals sollten aus Nutzersicht vermieden werden, da sie unpraktisch sind.
Mal sehen, wie man diese Katalogkomponente integrieren kann
das sieht ja wirklich gut aus !!!
Also, was ich interessant fände, wäre zu sehen, ob es in die UI-Richtlinien von Gladys passt, ein System zum Zusammenklappen, damit sich dieses Katalog unter dem Button öffnet, den man gerade angeklickt hat. Ich finde, das würde den Benutzer gut bei der Erstellung eines Geräts leiten.
Das ist nicht schlecht! Ich mag die Idee, aber wie würde der „Suchen/Auswählen“-Teil der Funktion aussehen?
Denn dieser Teil wird bereits die bereits erstellten Funktionen haben. Außerdem gibt es bei den möglichen Funktionen in Gladys Dutzende von Möglichkeiten, daher könnte dieser Teil riesig werden.
Ich bin mir nicht sicher, ob ich deine Frage verstehe.
Also, in meinem Kopf ist das ein Div, das unter dem Button angezeigt wird, sobald man darauf klickt, sagen wir mal willkürlich mit einer Höhe von 300px, das also scrollbar ist (und selbst wenn ich mich komplett verirre, würde ich sagen in „Lazy Loading“? So nennt man die Dinge, die sich beim Scrollen nach und nach laden?).
Also, ich stelle mir vor, dass die Höhe dieses Rahmens es ermöglichen sollte, mindestens eineinhalb Zeilen Funktionen anzuzeigen, damit die Leute verstehen, dass sie scrollen können.
Das verhindert vor allem, dass 85 Kacheln die Seite ins Unendliche hinaus überlappen.
Ich sehe keine effizientere Möglichkeit, alles auf einen Blick zu haben und den suchbaren Aspekt zu behalten, um direkt dorthin zu gelangen, wo man hin möchte.
Zu diesem Thema hatte ich gestern Abend vor dem Schlafengehen eine Eingebung und habe schnell eine Skizze gemacht:
Ja, es ist nicht besonders sauber, aber zumindest habe ich meine Idee notiert 
Die Idee ist, dass Features standardmäßig ausgeblendet sind und sich zum Bearbeiten öffnen lassen.
Das Hinzufügen neuer Features erfolgt in einem neuen Bildschirm mit demselben Layout, das du vorgeschlagen hast @guim31.
Ich würde gerne ein kleines Whimsical davon machen, vielleicht am Wochenende an meinem nächsten Gladys-Tag
Gefällt mir. Wenn du auf die Funktion rechts klickst, öffnet sich dann das Erstellungs-/Bearbeitungsformular?
Gefällt mir! (falls ich es richtig gelesen / verstanden habe haha)
Das klingt auch für mich sympathisch.
Könnte es auf der Ansicht des virtuellen Geräts, das alle Funktionen anzeigt, Informationen (vielleicht in Form von Icons) geben, die anzeigen, ob die Funktion historisiert ist oder nicht, und ob es sich um einen Sensor handelt oder nicht?
Ich denke, das wäre eine gute Antwort auf:
Ja, warum nicht!
Gut, ich bin heute Morgen gut mit dem Thema vorangekommen
Ich habe einen ersten Designvorschlag für Sie: MQTT Virtual devices view
Hier sind einige Screenshots zur Erklärung:
Komprimiertere Liste, als Liste und ohne Details, die bereits in der Bearbeitungsansicht enthalten sind.
Ich habe mich sehr stark von dem Vorschlag von @guim31 inspirieren lassen
Das ist ein erster Entwurf, ich bin offen für Feedback
Das Ziel ist es, dann zu iterieren, und sobald wir alle einverstanden sind, müssen wir das mobile Design machen, dann die Liste aller Gerätetypen (für Schritt Nr. 3), und alle Texte schreiben.
Schließlich können wir mit der Entwicklung beginnen, aber das ist nur Frontend, nichts wirklich Kompliziertes, das Schwierigste ist wirklich, sich zu einigen und all den Inhalt zu erstellen.
j’adore 
Ein visueller Eindruck des Ergebnisses ist wirklich toll und die Sortierung nach Räumen auch.
Achtung bei den Min/Max-Werten und Einheiten, die standardmäßig ausgeblendet sein können, aber ich werde sie bei Bedarf über ein Dropdown-Menü (falls man das so im Jargon sagt) zugänglich machen.
Kleine Frage: Wofür stehen deine 96% und 14% in deinem ersten Screenshot?
Falls das den Batteriestand der Sensoren (oder batteriebetriebenen Schalter) entspricht, dann zeigt das, dass es sich nicht um ein „virtuelles Gerät“, sondern um ein physisches Gerät handelt (naja, für mich).
Aber sind physische Geräte nur die von z2m oder liege ich da falsch?
Ich würde mir nur die Icons der Funktionen anzeigen lassen, wenn das nicht zu schwer visuell wirkt (mit nur einem Blitzsymbol für z. B. zwei oder mehr gemeldete Leistungen).
Erste schnelle Rückmeldung: Ich mag es sehr 
. Ich werde es heute Abend noch einmal genauer anschauen…
Nur ein erster Punkt: Ich habe oft Geräte, in denen ich mehrere Funktionen desselben Typs konfigurieren. Zum Beispiel ein Gerät „Heizungsvorgaben“, für das ich eine Funktion „Minimalvorgabe“, eine andere „Maximalvorgabe“, eine andere „Temperaturänderung über 15 Minuten“ usw. habe. Ich denke also, dass im Bildschirm 2 auch der Name jeder Funktion stehen sollte.
Warum nicht!
Ja, es handelt sich um die Batterie.
Vielleicht ist der Begriff „virtuelles Gerät“ nicht sehr klar. Es handelt sich einfach um ein Gerät, das du manuell in Gladys deklariert hast und das außerhalb von Gladys über Node-RED oder ein selbstgeschriebenes Skript verwaltet wird. Aber es kann durchaus ein echtes physisches Gerät sein
Ja, du liegst falsch, wir haben viele Integrationen in Gladys, nicht nur Zigbee2mqtt.
Der Name wird doch angezeigt
