FHEM - Hausautomations-Systeme > Home Connect

Verbesserungs- / Erweiterungswüsche an HomeConnect

<< < (5/5)

PatrickR:
Hallo Heiner!


--- Zitat von: Heiner am 05 Oktober 2021, 13:08:02 ---hi, ich hab eine siemens Spuelmaschine ueber Homeconnect angebunden. Kann man eventuell die Readings und deren Values etwas kuerzer gestalten und den "Prefix" Anteil loeschen?

--- Ende Zitat ---

Den Ansatz, die Readings und Values unverändert(?) aus der API durchzureichen, ist eigentlich ziemlich gut. Das ist ziemlich flexibel und auch robust gegenüber Änderungen. Für den optischen Aspekt könntest Du auf FHEM-Bordmittel wie userreadings oder readingsgroups zurückgreifen.

Patrick

Timmäää:
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.

PatrickR:
Hi!


--- Zitat von: Timmäää am 30 November 2021, 20:54:11 ---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.

--- Ende Zitat ---
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

Navigation

[0] Themen-Index

[*] Vorherige Sete

Zur normalen Ansicht wechseln