Diskussion:Attribut genericDeviceType

Wie bereits an anderer Stelle (rund um https://forum.fhem.de/index.php/topic,119447.msg1197783.html#msg1197783) angemerkt, finde ich das hier propagierte Konzept Gründen fragwürdig. Kritisch sehe ich: - zum einen war es bisher eher Praxis, ein Device genau einem genericDeviceType zuzuordnen. Mehrere (durch Kommata getrennte) gDT wäre (uU.) ein Novum, das m.E. einer besseren Begründung bedarf als der für Developer verpflichtenden Festlegung, welche Readingnamen dann zu vergeben sind; - bisher gängige gDT wie "light" und "switch" werden nunmehr "verengt", indem z.B. "light" keinen Helligkeitswert mehr haben darf (?). Weiter soll "pct" für Helligkeitswerte oder Öffnungsgrade Pflicht sein? Das macht Umrechnungen erforderlich, wenn das betreffende Gerät das nicht direkt unterstützt (ZWave oder Geräte, die HEX-Werte (0-254/255) übermitteln, wie teils bei MQTT anzutreffen); - das zunächst propagierte Ziel, die Zahl der in FHEM verwendeten gDT zu reduzieren, wird konterkariert, indem nunmehr auf Vollständigkeit (im Sinne von Kompabilität zur "Welt da draußen" Wert gelegt wird ("thermometer" und "TemperatureSensor"). Siehe auch die m.E. berechtigte Kritik von justme1968 in https://forum.fhem.de/index.php/topic,125238.msg1199844.html#msg1199844

MAn. wäre es sinnvoller, wieder zur ursprünglichen Idee zurückzukommen, für FHEM eine kleine Auswahl zu generieren. Die an anderer Stelle anztreffende Vielfalt kann man ggf. dadurch abfangen, dass man "aliases" definiert.

Unzweifelhaft erscheinen mir Standardisierungen bei Readingnamen und zugehörigen set-Befehlen sinnvoll, siehe dazu auch https://forum.fhem.de/index.php/topic,117933.msg1123606.html#msg1123606. Derartig standardisierte Namensgebung erlaubt es auch, direkt die "Fähigkeiten" eines Gerätes anhand einer "Großtype" zu erkennen. -- Beta-User, 14.01.2022