Das wäre am benutzerfreundlichsten. Standardmäßig sollte das, was in zigbee2mqtt unterstützt wird, auch in Gladys unterstützt werden.
Ist nicht so einfach 
Ich glaube, ich habe die Smart Steckdosen wie Schalter für Tasmota verwaltet.
Ja, das kann ich mir vorstellen!
Ansonsten, damit es sehr benutzerfreundlich wird, schlage ich vor:
- Der Scan zeigt alle Geräte an, auch die nicht unterstützten
- Nicht unterstützte Geräte sind grau hinterlegt, mit der Erklärung, dass sie noch nicht unterstützt werden
- Eine Option in Gladys ermöglicht es, die Logs des Gladys- und Zigbee2Mqtt-Containers zu sammeln, um sie im Forum einzureichen und anschließend einen Pull-Request zu erstellen.
Was haltet ihr davon?
Jedenfalls zeigt Gladys nichts bezüglich meiner Steckdose an, die dennoch den Status, die Spannung und die momentane Leistung zurückgibt.
Ein weiterer Bug: Wenn ich die mobile Oberfläche nutze, funktioniert der Scan nicht und zeigt eine Fehlermeldung an.
Wenn ich jedoch im selben mobilen Browser „Desktop-Version anzeigen“ auswähle, funktioniert es wieder.
Hallo. Es ist tatsächlich unmöglich, die verfügbaren Funktionen für ein Gerät ohne deren Vorabplanung im Code abzuleiten 
Laut der Dokumentation hier enthält die Liste der Geräte keine Funktionen, sondern nur das Modell / die Marke:
Aber ich stimme dir zu, dass man dies dem Benutzer erklären sollte. Und ich finde deinen Vorschlag gut, das machen wir auch bei anderen Diensten.
Ich schlage die folgende Schnittstelle vor. Der Button Gerät vorschlagen öffnet ein Issue auf Github mit Marke + Modell. Dadurch können wir alle Informationen erhalten, um es zu Gladys hinzuzufügen.
Sagt mir, was ihr davon haltet.
Das ist okay @cicoub13, sauber!
Toll, dass dir meine Idee gefällt 
Dein Vorschlag ist sehr gut, genau das, was ich als Nutzer gerne gesehen hätte.
Für den Satz schlage ich vor: « Dieses Gerät wird noch nicht unterstützt, aber kontaktieren Sie uns, um uns zu helfen, es in Gladys zu verbinden. »
Das wäre auch gut für die anderen Integrationen.
@pierre-gilles Sollten wir das vielleicht schwarz auf weiß in den Entwicklungsrichtlinien für ein neues Modul schreiben, so wie du es bei anderen Punkten gemacht hast (plus die PR-Vorschläge, falls möglich)?
Hmm, ich finde, das ist nicht so einfach. Manche Dienste funktionieren nicht auf die gleiche Weise! Meiner Meinung nach sollte man nicht standardisieren. Aber wenn es möglich ist, ist das super interessant
Super!
Das ist bereits der Fall! Wir haben es in 2 Integrationen: z-wave und früher Philips Hue (bevor wir es automatisiert haben).
Aber ich stimme zu, wir sollten es in die Entwicklungsrichtlinien aufnehmen.
Genau darum geht es: Wenn der Fall eintreten kann, dann muss man ihn behandeln. An sich ist das nicht schwer umzusetzen, zumindest weniger als die dynamische Verwaltung der Ausrüstung 
(was übrigens nicht möglich zu sein scheint).
Ansonsten denke ich als Benutzer: « Das ist komisch, entweder funktioniert Gladys nicht, oder meine Steckdose ist kaputt ».
Zum Glück hatte ich den Reflex, die Logs zu überprüfen, aber das zählt nicht, weil ich in der Kategorie « fortgeschrittene Benutzer » bin".
Ja, ich verstehe, du hast recht Einige Dienste schreiben einfach nur „Geräte werden nicht unterstützt“. Aber das wird definitiv die Hinzufügung vieler Geräte erleichtern, besonders für diejenigen, die GitHub etc. nicht verstehen! Man muss nicht mal im Forum sein
Ja, bei Philips Hue wusste ich Bescheid, aber nicht bei Z-wave.
Beim Suchen habe ich gerade gesehen, dass wir das auch beim TP-Link-Service haben
Weißt du, wo ich die Liste der von Gladys unterstützten features finden kann (um die Datei zu erstellen)?
Hier ist, was meine ZigBee-Steckdose anzeigt (Lonsonho Tuya ZigBee Smart Plug):
(Bild von Zigbee2MQTT, Port 8080 von Gladys)
Mit diesem Code habe ich Fehler:
const { features } = require('../utils/features');
/**
* Tuya verwaltete Modelle.
*/
const Tuya = {
brand: 'Tuya',
models: {
'TS0121_plug': [features.state, features.power, features.current, features.voltage, features.energy, features.power_outage_memory, features.linkquality] // Lonsonho Tuya Smart Plug
},
};
module.exports = {
Tuya,
};
Fehler:
2021-02-08T10:06:53+0100 <warn> handleMqttMessage.js:87 () Zigbee2mqtt-Gerät 0x60a423fffe685063, Feature state nicht in Gladys konfiguriert.
2021-02-08T10:06:53+0100 <warn> handleMqttMessage.js:87 () Zigbee2mqtt-Gerät 0x60a423fffe685063, Feature voltage nicht in Gladys konfiguriert.
2021-02-08T10:07:53+0100 <warn> handleMqttMessage.js:87 () Zigbee2mqtt-Gerät 0x60a423fffe685063, Feature current nicht in Gladys konfiguriert.
2021-02-08T10:07:53+0100 <warn> handleMqttMessage.js:87 () Zigbee2mqtt-Gerät 0x60a423fffe685063, Feature energy nicht in Gladys konfiguriert.
2021-02-08T10:07:53+0100 <warn> handleMqttMessage.js:87 () Zigbee2mqtt-Gerät 0x60a423fffe685063, Feature linkquality nicht in Gladys konfiguriert.
2021-02-08T10:07:53+0100 <warn> handleMqttMessage.js:87 () Zigbee2mqtt-Gerät 0x60a423fffe685063, Feature power nicht in Gladys konfiguriert.
2021-02-08T10:07:53+0100 <warn> handleMqttMessage.js:87 () Zigbee2mqtt-Gerät 0x60a423fffe685063, Feature power_outage_memory nicht in Gladys konfiguriert.
2021-02-08T10:07:53+0100 <warn> handleMqttMessage.js:87 () Zigbee2mqtt-Gerät 0x60a423fffe685063, Feature state nicht in Gladys konfiguriert.
2021-02-08T10:07:53+0100 <warn> handleMqttMessage.js:87 () Zigbee2mqtt-Gerät 0x60a423fffe685063, Feature voltage nicht in Gladys konfiguriert.
Hier: Gladys/server/utils/constants.js at master · GladysAssistant/Gladys · GitHub
Die von dir erstellte Datei sieht gut aus. Achte auf die Marke (TuYa statt Tuya) und vergiss nicht, die Datei in die Liste der Modelle hier zu importieren: https://github.com/cicoub13/Gladys/blob/zigbee2mqtt-service/server/services/zigbee2mqtt/model/index.js
