Ja, ich dachte, ich wĂŒrde die KompatibilitĂ€t auf dieser Ebene hinzufĂŒgen. Ich weiĂ nicht, ob ich mich klar ausgedrĂŒckt habe.
Man mĂŒsste in jeder Integration und vor allem auf Code-Ebene, zum Beispiel ein JSON vorsehen, das es ermöglicht, alle GerĂ€te aufzulisten, die mit dieser Integration funktionieren
Kleines Update fĂŒr alle zu den behobenen Fehlern / neuen Funktionen:
- Merge der Sonoff-KompatibilitÀt dank der Arbeit von @AlexTrovato
- Neue Philips Hue-KompatibilitÀt dank @Helldog136
- Firefox Gladys Plus-KompatibilitÀtsfehler
- Xiaomi-GerÀtefilter
- Allgemeine Verbesserung der Philips Hue-Benutzerfreundlichkeit
- Das Docker-Image verwendet nun Node.js 12 LTS
- Fehler der leeren Integrationsseite (HinzufĂŒgen eines Fallbacks zu EN)
- Darksky-Link-Fehler
- Verbesserung der UI der Gladys Plus-Backup-Seite
- Und vieles mehr
Das ist nicht so einfach, jede Service-UI ist einzigartig, also wo wĂŒrde diese Liste angezeigt werden?
Auf Ebene der Richtlinien fĂŒr jeden Service wĂ€re es vielleicht schön, einen Abschnitt âunterstĂŒtzte Hardwareâ hinzuzufĂŒgen, mit einer Tabelle, die den UnterstĂŒtzungsstatus angibt (unterstĂŒtzt, in Entwicklung, nicht unterstĂŒtzt, usw.).
ZusĂ€tzlich könnte dies es denen ermöglichen, die weniger gebrĂ€uchliche Hardware haben, sich zu melden, die notwendigen Hardwareinformationen fĂŒr die Entwicklung beizusteuern und dann die damit verbundenen Entwicklungen zu testen, oder?
Oder jeder Dienst muss eine Seite mit den KompatibilitĂ€ten hinzufĂŒgen und einen direkten Link vom Vorschaubild, falls vorhanden
Edit: @Reno war schneller 
Grilled @VonOx 
FĂŒr mich können wir bei Gladys sehr gut einen Ordner hinzufĂŒgen, der mehrere JSON-Dateien enthĂ€lt, die den Diensten entsprechen, und das Frontend kann eine dedizierte Seite haben, die es ermöglicht, alle verfĂŒgbaren GerĂ€te aufzulisten. Es liegt also am Entwickler, nach und nach die kompatiblen GerĂ€te hinzuzufĂŒgen.
Dieser Ordner wird einfach statisch sein.
Zusammenfassend gibt es also drei verschiedene Anfragen in diesem Thread:
- Eine Liste der kompatiblen GerÀte pro Dienst, direkt in einem Dienst in Gladys
- Eine Liste der kompatiblen Gladys-GerÀte in Gladys, aber auf globaler Ebene von Gladys.
- Eine Liste der kompatiblen Gladys-GerÀte in der Gladys-Dokumentation
Die drei sind nicht gegensÀtzlich, man kann durchaus mehrere davon machen, aber die Informationsquelle muss dieselbe sein. Sonst wissen wir sehr gut, wie das enden wird, nach einem Update wird eine Liste nicht mehr aktuell sein im Vergleich zu den anderen.
Ich denke, dass es tatsĂ€chlich Sinn macht, diese Informationen in der Gladys-Repo in einer Konfigurationsdatei zu haben, da sie direkt mit dem Gladys-Code gekoppelt sind. Dadurch kann der Entwickler die Ănderung der Konfigurationsdatei im selben PR vornehmen, der eine KompatibilitĂ€t hinzufĂŒgt, und so in allen Punkten konsistent bleiben.
Diese Informationen mĂŒssen internationalisiert werden, daher wird es eine Datei pro Sprache geben mĂŒssen.
Wir mĂŒssen Tests durchfĂŒhren, um sicherzustellen, dass, wenn ein GerĂ€t in einer Sprache hinzugefĂŒgt wird, es auch in einer anderen Sprache hinzugefĂŒgt wird, sonst werden wir uns sehr schnell mit Entwicklern wiederfinden, die eine Sprache ausfĂŒllen und die andere nicht, und die Liste wird desynchronisiert sein!
Was denkt ihr darĂŒber?
Persönlich bin ich eher fĂŒr die VorschlĂ€ge 2) und 3), ich denke, dass 1) eine zu komplexe Arbeit erfordert und die UI ĂŒberall in den Diensten ĂŒberladen wird.
Wenn ihr Ideen habt und einen PR dafĂŒr vorschlagen möchtet, wird das mit Freude aufgenommen
Man muss auch bedenken, dass bestimmte GerĂ€te von verschiedenen Diensten verwaltet werden können, wie zum Beispiel Xiaomi-GerĂ€te, die mit den Xiaomi-Diensten oder zigbee2mqtt verwendet werden können. Da der Entwicklungsstand nicht unbedingt derselbe ist, werden einige GerĂ€te mit einem der Dienste kompatibel sein, möglicherweise aber nicht mit dem anderen, âŠ
Deshalb ist es vielleicht kompliziert, dies auf globaler Ebene darzustellen.
Es sei denn, man erstellt eine Tabelle mit den GerÀten in den Zeilen und den Diensten in den Spalten. Aber diese Tabelle könnte mit der Entwicklung schnell wachsen.
Wir werden denselben Fall bei den geflashten und nicht geflashten Sonoff-GerÀten haben.
Sie werden fĂŒr einen Dienst funktionieren, aber nicht fĂŒr den anderen.
Es sei denn, es gibt einen einzigen Dienst fĂŒr die Sonoff-GerĂ€te
Option 2 und 3 erscheinen mir gut, ich bin der Meinung von @pierre-gilles
Eine Dokumentation in Form einer Tabelle mit mehreren Spalten:
- Marke
- Produktname
- ein Bild (optional)
- das Protokoll des Produkts
- Typ: Tasten, Lampe, Sensor, Kamera, Aktuator
- der Dienst, der es in Gladys funktionieren lÀsst
- Entwicklung (Farben: grĂŒn ok, orange in Arbeit, rot noch nicht)
- ein Link zum Kauf (nicht ĂŒberzeugt, da der Link tot sein kann, was bei Jeedom passiert)
Ich wusste es schon, aber man sieht sofort, warum neben dem Pseudonym von @pierre-gilles âLeaderâ steht.
Mit einem kleinen Kommentar kann man visualisieren, wie man es grafisch und architektonisch umsetzen kann, damit es fĂŒr alle tragbar und funktionsfĂ€hig ist.
Ich möchte die Anmerkung von @Reno und die von @Tlse-vins ergÀnzen.
Ich denke, man sollte diesen Katalog nicht auf Service-Ebene erstellen, sondern das GerĂ€t mit mehreren Services verknĂŒpfen können.
Diese Seite wird riesig
Ja und nein, ich verstehe deine Punkte. Allerdings gibt es derzeit Websites, die sehr gute Ăbersetzungen ermöglichen, zum Beispiel DeepL. Ich empfehle es dir, es ist eine ausgezeichnete Ăbersetzungswebsite, viel mĂ€chtiger als Google Ăbersetzer.
Dann ja, du machst alle Sprachen und ja, einige Ăbersetzungen werden vielleicht schlecht sein! Daher kann jemand kommen und einen PR vorschlagen, um die Ăbersetzung zu korrigieren.
Ich denke, das ist meiner Meinung nach kein groĂes Handicap. Vor allem, weil es am Ende der Entwicklung gemacht werden kann.
@Tlse-vins Ich stimme dir bei der Attributliste zu, das klingt gut.
Jetzt mĂŒssen wir sehen, wo in Gladys das untergebracht werden könnte. Ich habe Schwierigkeiten, mir vorzustellen, wo wir das momentan unterbringen könnten⊠Eigentlich frage ich mich sogar, ob das ĂŒberhaupt Sinn macht, das im Produkt zu haben, ich sehe nicht, wo man das unterbringen könnte, ohne die OberflĂ€che mit etwas zu ĂŒberladen, das nicht unbedingt tĂ€glich nĂŒtzlich ist:
Vielleicht hat das nur in der Dokumentation seinen Platz?
Ganz genau, man kann die Liste der kompatiblen Dienste in der Tabelle angeben.
Das ist aber eine Frage der grundsĂ€tzlichen Philosophie bei Ăbersetzungen in Gladys. Es ist das gleiche Problem mit der UI: Wenn du eine Funktion entwickelst, in welchen Sprachen lieferst du dann die Ăbersetzungen?
Meine Meinung dazu ist ziemlich klar: Alle Sprachen, in denen wir kommunizieren, mĂŒssen unterstĂŒtzt werden, ĂŒberall. Ich wĂŒrde keinen PR akzeptieren, der die Sprachen, in denen wir kommunizieren, nicht unterstĂŒtzt, sonst wird die UI ĂŒberall kaputt sein und es ergibt keinen Sinn zu sagen, dass wir diese Sprache verwalten.
Du sprichst von Deutsch, ehrlich gesagt, es sei denn, eines Tages haben wir jemanden, der sehr engagiert im Projekt ist, Deutsch spricht und tĂ€glich ĂŒber mehrere Monate hinweg involviert ist, dann ja, wir werden Deutsch in Betracht ziehen, aber sonst nein. Eine Sprache hinzuzufĂŒgen ist sehr einfach, aber eine Sprache zu pflegen ist eine tĂ€gliche Arbeit, denn die Ăbersetzungen Ă€ndern sich mehrmals am Tag.
Das ist die Philosophie von Gladys 4: Wir machen nicht viel, aber was wir machen, machen wir gut.
Mach dir also keine Sorgen, es werden nur EN und FR zu verwalten sein.
Ja, er arbeitet noch daran, den richtigen Farbauswahl-Tool zu finden.
DarĂŒber wird hier gesprochen
Und ich arbeite weiter an der UX von Gladys 4!
Basierend auf dem Feedback, das ich erhalten habe, habe ich gestern an der âChatâ-Ansicht von Gladys gearbeitet.
Ich habe das Design des leeren Zustands verbessert:
Und ich habe am Prozess des Nachrichtensendens gearbeitet, damit die Nachricht, wenn die Verbindung nicht gut ist, in einem Zustand âWird gesendetâ ist, bevor sie veröffentlicht wird:
AuĂerdem habe ich das Problem behoben, dass Nachrichten beim Senden nicht in der richtigen Reihenfolge waren.
Edit: Ah, und vor allem dank der Arbeit von @bertrandda sind wir mit Gladys 4 auf Preact X umgestiegen!! 
Das ist noch nicht gemacht, ja
Am besten wÀre es, wenn man pro Integration auswÀhlen könnte, ob der Benutzer Zugriff hat oder nicht.
TatsĂ€chlich ist der Multi-User-Teil noch nicht fertig: Es wurde noch nichts gemacht Deshalb gibt es auch keine OberflĂ€che! Alle Probleme, auf die du gestoĂen bist, sind einfach darauf zurĂŒckzufĂŒhren, dass es noch in Entwicklung ist. Das ist eine meiner aktuellen PrioritĂ€ten zusammen mit Z-Wave.
Hallo!
Hat jemand die Roadmap zum Launch von Gladys 4 
?
Danke im Voraus