Hi!
Grundsäzlich ja, aber es sollte auch konsistent zu anderen Modulen und den Coding Guidelines sein.
Ein State sollte Off, On oder oder was auch immer sein und nicht "BSH.Common.EnumType.PowerState.Off ".
Aber gut. Natürlich geht das auch mit Bordmitteln, aber etwas mehr Anpassung wäre cool, leider kann ich dafür aktuell wenig beisteuern.
Hast Du mal einen Link zu den Coding Guidelines? Die finde ich leider nicht und auch in DevelopmentModuleIntro bin ich auf die Schnelle nicht fündig geworden.
Das Problem ist aber ein anderes. Das zwangsweise Mapping auf Standardwerte erfordert bei komplexen Systemen (so wie der HomeConnect-API) eine Menge an Handarbeit und das ggf. bei jedem neuen unterstützten Gerät. Daher ist es normalerweise nicht leistbar, direkt von Anfang an die Readings zu mappen, selbst wenn es offensichtliche Mappings wie on und off gibt. Dann passiert das, was man z. B. bei HMCCU gut sehen kann: Die Werte werden nach und nach geändert und Eventhandler laufen "still" ins Leere. Zudem vergibt man die Chance, beim Verstehen eines Readings auf die API-Spezifikation zurückzugreifen, die oftmals detaillierter ist als die Commandref. Gibt es keine offensichtlichen Mappings, wird es noch unangenehmer: Der Entwickler müsste "kurze" Values erfinden und aus der Spezifikation des Herstellers in die Commandref übersetzen. Hat er (nachvollziehbarerweise) dafür keine Zeit, dann bleiben die Phantasievalues undokumentiert und der Rückgriff auf die API-Doku wird erschwert oder erfordert ein Nachlesen des Mappings im Code durch den Nutzer.
Diesen - in meinen Augen - massiven Nachteilen stehen bislang nicht greifbare Vorteile einer Einheitlichkeit von Readings entgegen, die sich - unter Berücksichtigung der Bordmitteln von FHEM (s. o. aber bspw. auch <struct_type>_map bei structures) - vermutlich auf den persönlichen Geschmack beschränken.
Patrick
