Standardisierung FHEM, wo wollen wir hin

[eiten]

Hallo zusammen,

aufgrund von Beta-Testers Thread https://forum.fhem.de/index.php/topic,117933.0.html im Entwicklerforum und eigenen schmerzlichen Erfahrungen eröffne ich den Thread auch hier, da Beta-Tester (und auch ich) denken, dass diese Diskussion wohl alle interessieren dürfte und nicht nur die Entwickler. Mir ist kein besseres Sub-Forum eingefallen, sollte ich hier falsch sein, so bitte ich darum, mich zu verschieben.

Um's gleich vorauszuschicken: mir geht's nicht darum, FHEM sofort komplett umzubauen. Rolläden, Lichter, Garagentor, die komplette Heizung, Boilersteuerung, Abwesenheitssteuerung, TV etc. etc. funktionieren gut bei mir. Ab und zu dauert's einfach etwas länger als nötig, bis ich was geschafft habe, und daher folgende Denkanstösse für die Zukunft/zukünftige Modulentwicklung. Das ist absolut nicht Weisheit letzter Schluss, ich bin sicher, es tauchen noch viel bessere Ideen von euch auf.

Problemstellung
Das geniale an FHEM ist, dass wir ja Systeme verschiedenster Hersteller Kombinieren können. Ein selbst gebastelter MySensors Taster schaltet ein YeeLight, ein BLE-Doppeltaster schaltet ein ZigBee-Rolladenaktor. Das Problem dabei ist, dass die Readings und die Set- und Get- Befehle von Modul zu Modul unterschiedlich sind. Ein Auslöser für diesen Beitrag war unter anderem, dass ich eine Rolladensteuerung mit einem Shelly 2.5 auf eine zigbee2mqtt kopiert habe und stundenlang nach dem Fehler gesucht, bis ich bemerkt habe, dass zwar das eventMap die Gross/Kleinschreibung im event geändert hat, dies aber dem DOIF ziemlich egal war, da es wohl auf das Reading direkt zugreift, was nicht geändert wurde. Die Lösung dafür wäre natürlich eine Standardisierung. Allerdings können wir nicht einfach so alle Module ändern, und das auch ncoh zu unterschiedlichen Zeitpunkten, da würden wir ja unsere Zeit nur noch mit der Fehlersuche nach Updates verbringen.

(Diskutable) Lösungsideen
Ich habe mir dazu ein paar Gedanken gemacht. Allerdings tendiert man im stillen Kämmerchen dazu, nicht alle Aspekte zu sehen. Beta-Testers Beitrag (und PM) hat dann dazu geführt, dass ich nun an euch trete und mit euch bereden will, ob das Problem so überhaupt besteht und ob und was wir da machen könnten.

Zum Problemkreis Update: Wie geschrieben, können wir nicht einfach die Funktionalität der Module komplett und ohne Vorwarnung ändern. Mir fallen dazu zwei mögliche Lösungen ein.
Wir definieren ein Attribut, welches pro Device festlegt, ob wir uns in der neuen oder der alten Welt befinden. Enstprechen müssen die Modulentwickler natürlich in den X_set und X_get Funktionen eine Unterscheidung vorsehen. Nachteil dabei ist, dass die Ausführungszeit durch die zusätzliche Unterscheidung leiden kann. Zudem kann das Attribut global gesetzt werden, um bei neuen Installationen oder wenn wir alles umgestellt haben und neue Devices dazu kommen, nicht immer das Attribut setzen müssen.
Alternativ könnten wir einen Mechanismus implementieren, der ein Modul vom Update sperrt, wenn dieses auf den Standard umgebaut wurde. Dem User wird, zum Beispiel via motd angezeigt, dass das Modul nicht geupdated wurde, am besten zusammen mit einem Link auf einen Forenbeitrag wo steht, was genau geändert hat. Ein solcher Mechanismus wäre auch aktuell wünschenswert, wenn inkompatible Updates kommen. Lösen können wir das zum Beispiel über einen CompatibilityLevel in der controls.txt der jedes Mal erhöht wird, wenn eine inkompatible Änderung gemacht wurde. Vorteile sind eine schneller Ausführung und mehr Sicherheit auch in Zukunft, dass Updates unsere Automatisierung nicht zerschiessen. Nachteil ist unter anderem, das wir dann gezwungen sind unsere Programmierung anzupassen, wenn wir up-to-date bleiben wollen.

Wie soll nun aber die Standardisierung aussehen? Meine Idee dazu lehnt sich an Google an (ich bin sicher, andere Firmen haben ähnliche Konzepte, dies ist halt das, was ich kenne https://developers.google.com/assistant/smarthome/concepts/devices-traits): das Konzept von Geräten und Merkmalen (obwohl ich mir nicht sicher bin, ob wir die Geräte brauchen, macht aber wahrscheinlich die Integration von Alexa, Google Home, Siri und co. einfacher).

Merkmale, Attribute und Einheiten
Um die Steuerung zu vereinheitlichen, definieren wir Merkmale, die ein Device haben kann, wie zum Beispiel OnOff und Volume, die ein Lautsprecher haben kann, oder OnOff und LightTemperature und LightColor, die eine Leuchte haben kann. Damit konnen wir zum Beispiel die Lichttemperatur aller Lampen (egal, mit welchem Modul sie bedient werden) in einem Raum mit einem Befehl wie

Code Auswählen Erweitern

set room=Wohnzimmer,trait=LightTemperature colortemp 4200 die Farbtemperatur aller Leuchten im Wohnzimmer, die das unterstützen, setzen.

Diese Merkmale enthalten Attribute, die den Readings entsprechen. So kann zum Beispiel das Merkmal LightColor die Attribute hsv, rgb und xyY enthalten oder Brightness die Attribute pct und brightness. Ich halte es für wichtig, dass die Einheit jedes Attributes eindeutig definiert ist. Also zum Beispiel ist definiert, dass pct eine Helligkeit von 0 bis 100 ist oder brightness eine Helligkeit von 0 bis 255. Allerdings sollte ein Gerät, dass nur rgb und pct verarbeiten kann auch ein set hsv verarbeiten können. Dazu ist wohl eine Vorverarbeitung der set-Befehle notwendig. Ich finde es auch wünschenswert, dass zum Beispiel ein ReadingsVal oder eine Abfrage in einem DOIF von brightness auf ein Gerät, dass nur ptc als reading anbietet, automatisch umgewandelt wird.

Bei normalen Modulen dürfte das Einigermassen gehen. Etwas komplizierter stelle ich mir das zum Beispiel bei MQTT2_DEVICES vor. Da können wir zwar per perl in der setList und dem jsonMap schon viel erreichen. Was allerdings bisher nur Mühsam über jsonMap und einem userReading geht ist zum Beispiel, wenn ein Gerät eine Temperatur in Fahrenheit meldet, der Standard aber °C vorsieht. Noch schwieriger wird's mit eventMap, das funktioniert zwar auf die Events, aber nicht auf die Readings (welche zum Beispiel im DOIF verwendet werden).

Dokumentation
Sehr wichtig dabei ist wohl die Dokumentation der ganzen Geräte, Merkmale der Attribute und deren Einheiten. Ich schlage dazu das FHEM-Wiki vor, falls wir uns zu einer Standardisierung entscheiden.

Ich bin sicher, ich habe noch 1000 Dinge vergessen, darum will ich das hier mit euch besprechen. Zudem gibt es Probleme wie herstellerspezifische Konfigurationsbefehle etc, die noch überlegt werden müssen.

Liebe Grüsse, Edi

[rudolfkoenig]

Diese Diskussion waere in Development besser aufgehoben.

Die Idee von FHEM Interfaces ist alt, es gab schon viele Anlaeufe, und ausser ermuedende Diskussionen haben wir bisher nicht wirklich was erreicht. Der letzte Versuch war was (mAn) Einfaches: Batteriewerte zu standardisieren, siehe https://forum.fhem.de/index.php/topic,87575.html. Das Ergebnis nach 137 Beitraegen sind 3 optionale Reading Namen mit spezifizierten Wertebereichen, dokumentiert in der Wiki. Manche Modulautoren (mich inklusive) haben es umgesetzt, Andere waren selbst zum Schluss dagegen.

Meine Sicht der Dinge: eine Standardisierung aller Readings waere fuer FHEM unmoeglich, da bei der Definition man nicht alle Faelle kennt, und die Standards und deren Implementierung kontinuierlich anzupassen unsere Energie uebersteigt. Weiterhin ermoeglicht das Fehlen der Standards einem Entwickler, schnell was zu bauen. Im Wesentlichen  geht es darum, wer die Arbeit machen soll: der Entwickler oder der Anwender. Ich bin z.Zt. der Meinung: der Anwender.

Abgesehen von dieser Meinung: fuer meine Module bin ich sehr wohl bereit Standards zu uebernehmen.
Ich will aber nicht den Hut aufhaben, einen Konsens zu erstreiten, und die Entwickler zur Mitarbeit zu zwingen.

[eiten]

Hallo Rudolf,

danke für Deine Antwort, und vielen Dank an dieser Stelle für Deine riesige Arbeit an FHEM!
Ich verstehe Deinen Punkt, dass die Diskussion besser in Developement aufgehoben wäre, leider bin ich aus der Schweiz und deshalb basisdemokratisch orientiert  . Nein Scherz bei Seite, ich denke halt einfach, dass dazu auch die Meinung der Anwender interessant ist, vielleicht sehe ich ja Probleme, wo bei der grossen Mehrheit keine sind.

Natürlich will ich keine FHEM Gesetze aufstellen, sondern eher Richtlinien, wie Jack Sparrow so schön gesagt hat. Ich habe für mich ein Modul entwickelt und dachte, ich mach das gleich richtig, um dann vielleicht auch Anderen damit dienen zu können. Leider habe ich nichts gefunden, was in Richtung so sollten die Readings und die Befehle heissen, damit ein alter FHEM-Hase das auch gleich verwenden kann. Ich dachte, dann schaust Du halt bei ähnlichen Modulen und hab da einen ziemlichen Wildwuchs vorgefunden.

OK, ich hab zwischenzeitlich den Batterie-Thread gelesen. Klingt so, dass viele eine Vereinheitlichung wollen aber damit abtun, dass sie eh keine Chance hat. Wie schon gesagt, ich habe Ideen und Gedanken gepostet, wenn kein Bedarf da ist, ist das auch absolut ok für mich. Ausser vielleicht der Wunsch, das bei Updates mit breaking changes ein Warn-/Sperrmechanisums eingeführt werden könnte.

Gute Nacht, Edi

[Per]

Meine Meinung als Anwender? Ich finde Standardisierung gut. Ob man 100% erreicht, wage ich aber zu bezweifeln.
Aber am Beispiel der Batterie: die notwendigen DOIF, notify, Gruppen oder was auch immer, wurden vereinfacht (dank HomeMatic). Und für den noch nicht standardisierten Rest (z.B. WinConnect) nutze ich UserReadings, welche auf den Standard umbiegen. Ich könnte das zwar auch im Quelltext direkt ändern, aber dann fange ich nach einem Update wieder an. Nö.

Also ein gewisses Grundgerüst vorgeben, neuere Entwicklungen im Auge behalten und ab und zu den Standard anpassen. Also genau wie in der realen Welt.
Und wenn man erstmal den ersten Schritt getan hat, gehen die anderen meist leichter.

[sven.scherf]

Hallo,

Standards sind gut und wichtig.
Standards erleichtern auch das automatische Testen Modul übergreifend.


Aber, man muss damit irgendwo anfangen und es dann langsam aufbauen sonst wird dies nichts.

Da ich mich mit der Modulprogrammierung noch nicht beschäftigt habe.

Gibt es hier keine Templates oder Programmierrichtlinien ?
Macht es vielleicht Sinn hier ein Grid mit vorhandenen Readings und den neuen Readings zu erstellen ?
Hier könnten dann Überganszeiten eingetragen werden bis wann man das Reading in seinem erstellen Modul angepasst haben sollte damit es nicht im updaten weiterhin berücksichtigt wird.

Ohne Standards besteht ja die Gefahr, dass alle weiter auseinander läuft und nur noch komplexer wird.



Viele Grüße

Sven

[rudolfkoenig]

Gibt es hier keine Templates oder Programmierrichtlinien ?

Es gibt unvollstaendige Varianten in der Wiki, an dem sich manche halten.

Macht es vielleicht Sinn hier ein Grid mit vorhandenen Readings und den neuen Readings zu erstellen ?

Es wuerde sich schon lohnen, existierende Namen und Werte (fuer Readings, Attribute, etc) zu sammeln, mit kurzer(!) Bemerkung, wofuer sie gedacht sind. Dann koennen Neuentwicklungen sich an irgendwas orientieren, ob alte Module angepasst werden, darf der Maintainer zunaechst selbst entscheiden.

Das Beste daran: man muss weder programmieren, noch ist eine Diskussion noetig.

[xenos1984]

Generell finde ich (als Anwender, aber vielleicht in Zukunft auch Entwickler) ein gewisses Maß ein Standardisierung positiv, weil es ermöglicht, Komponenten gegeneinander auszutauschen. Es gibt ja doch eine ganze Menge Module, die teilweise ähnliche Funktionen bereitstellen, und bei denen man überlegen könnte, ob sich gemeinsame Funktionen nicht auch durch eine gemeinsame API zugänglich machen lassen.

Um mal ein einfaches, fiktives Beispiel zu nennen: Angenommen, es gibt mehrere Module, die jeweils eine Lampe steuern und deren Zustand anzeigen können, und die als gemeinsame Funktionen an / aus, Helligkeit (Dimmer) und Farbtemperatur implementieren. Dann wäre es mMn praktisch, wenn bei diesen Modulen die gleichen set-Befehle und die gleichen Einheiten / Wertebereiche für Helligkeit und Farbtemperatur verwendet würden (und nicht z.B. bei einem Modul set pct 100, bei einem anderen set brightness 255 die maximale Helligkeit schaltet).

Wenn ich nun eine Lampe durch eine andere ersetze, die von einem anderen Modul gesteuert wird, muss ich mir nicht erst Gedanken machen, wie ich alle DOIF / notify / at etc. anpasse, damit sie mit der API des anderen Moduls arbeiten. Wenn beide Module eine kompatible API anbieten, kann ich einfach eins durch das andere ersetzen.

Es wuerde sich schon lohnen, existierende Namen und Werte (fuer Readings, Attribute, etc) zu sammeln, mit kurzer(!) Bemerkung, wofuer sie gedacht sind. Dann koennen Neuentwicklungen sich an irgendwas orientieren, ob alte Module angepasst werden, darf der Maintainer zunaechst selbst entscheiden.

Ich denke, sich zunächst einen Überblick über den Stand der Dinge zu verschaffen, wäre ein guter Anfang. Dann könnte man besser sehen, wie weit entfernt so eine gemeinsame API für manche Module ist, und dann schauen, ob man diese Schritt für Schritt implementieren könnte, bzw. eine Orientierung für neue Module geben, damit diese ebenfalls möglichst kompatibel gestaltet werden. Mir persönlich fehlt so ein Überblick noch etwas, da es ja doch viele Module sind, aber vielleicht kann man den ja auch (teil-)automatisch aus den Modulen generieren, die ja ihre Attribute, Readings etc. "bekanntgeben".

[Beta-User]

Vorab mal ein Dankeschön an @eiten für's Aufgreifen des Themas!

Es wäre echt toll, wenn sich eine Truppe finden würde, die sich dazu mal auf den Weg macht, es ist wie Rudi schreibt:

Es wuerde sich schon lohnen, existierende Namen und Werte (fuer Readings, Attribute, etc) zu sammeln, mit kurzer(!) Bemerkung, wofuer sie gedacht sind. Dann koennen Neuentwicklungen sich an irgendwas orientieren, ob alte Module angepasst werden, darf der Maintainer zunaechst selbst entscheiden.

Das Beste daran: man muss weder programmieren, noch ist eine Diskussion noetig.

Das "Problem" ist, dass keiner alles kennt, sondern jeder kennt (mehr oder weniger) eben das, das er nutzt.

Als ich die ersten jsonMap-Attribute in den attrTemplate zu MQTT2_DEVICE verteilt habe, stand ich genau vor dem Problem, dass es (bis auf "battery") nicht wirklich was zum Orientieren gab, @eiten hatte jetzt an einer etwas anderen Stelle ein ähnliches Problem, und es gibt noch eine Gruppe von usern, die sich mit ähnlichen Themen bei Solaranlagen beschäftigt.
Irritierend fand ich, dass es zunächst mal gewisse Widerstände gab, als ich das Thema bei sonos2mqtt (mit den AV-Readings, bei denen es guidlines gibt: https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV) angesprochen hatte, an und für sich sollte es eine Selbstverständlichkeit sein, dass man derartige Standards dann einfach übernimmt, wo es möglich ist.

Von daher wäre in der Tat schon einiges gewonnen, wenn man für alles, was man "ab sofort" macht, sowas wie eine geordnete Zusammenfassung hätte (oder zumindest einen Anfang in diese Richtung). Wenn es irgendwo Haken gibt, meldet sich erfahrungsgemäß dann schon jemand...

Was die Erwartungshaltung mancher angeht:
Meine eigene Haltung zu einigen Fragen ist die:
- Verordnete breaking changes sind Mist! (Nicht nur für Entwickler, auch für die User! Tendenziell haben ja alle User heute Systeme, die mit diesen ganzen Eigenheiten irgendwie klarkommen, und auch das umzustellen, ist (mind.) Aufwand!)
- Wer neu einsteigt, sollte die Chance haben, "Sonderlocken" möglichst zu minimieren (Attribut-/featurelevel-gesteuert?)
- Doppelungen sind Mist! Lieber "entweder oder"
- Ganz wird das nicht gelingen. Neben der "Kleinigkeit", dass jeder Entwickler das halten darf, wie er es für richtig hält, gibt es auch technische Gründe, warum manche Module eben keine "100%" können (bzw. kennen). Wer ZWave nutzt, hat vielleicht eine Idee, was gemeint ist... Da zu rechnen, um zwangsweise aus dim 99 100% zu machen ist m.E. keine gute Idee.
- "Attribute" ist m.E. ein gutes Stichwort, aber - abgesehen von gewissen Standard-Attributen wie "disable" - reichlich tricky. Also löblich, falls sich da jemand dranwagt, aber m.E. deutlich weniger dringlich.

Jedenfalls freut es mich, dass es durchaus Interessenten gibt für das Thema!

Das Beste daran: man muss weder programmieren, noch ist eine Diskussion noetig.

Wer auch immer sich dieses Themas (koordinierend) annimmt: Wer es macht, entscheidet über die Tools .

[Per]

Vllt könnte man als zweiten Schritt (der erste mit den bisher "vorgegeben" Werten) pro Modul eine Auflistung der verwendeten Attribute, Befehle und Readings anlegen. Dazu ein Feld mit der Erklärung und eins, ob man an den Namen gebunden ist. Im Gegensatz zur Hilfe ohne Erläuterung der Auswirkungen, dafür in Tabellenform. Das kann man dann in einer Tabellenkalkulation statistisch auswerten, um die Vorgaben zu erweitern.
Für neue Module ist das zumindest praktikabel, wie man Maintainer und Anwender zum Umstieg beweg, ohne sie zu verärgern, weiß ich aber auch nicht.

[frank]

Um mal ein einfaches, fiktives Beispiel zu nennen: Angenommen, es gibt mehrere Module, die jeweils eine Lampe steuern und deren Zustand anzeigen können, und die als gemeinsame Funktionen an / aus, Helligkeit (Dimmer) und Farbtemperatur implementieren. Dann wäre es mMn praktisch, wenn bei diesen Modulen die gleichen set-Befehle und die gleichen Einheiten / Wertebereiche für Helligkeit und Farbtemperatur verwendet würden (und nicht z.B. bei einem Modul set pct 100, bei einem anderen set brightness 255 die maximale Helligkeit schaltet).

was ist daran einfach?

standardisierung bedeutet doch hier:
entweder "beschneide" ich die möglichkeiten, wenn nur noch 100 werte zulässig sind.
oder umgekehrt wird die bedienung "unmöglich" oder nicht mehr intuitiv, wenn ich zb 50% einstellen will. ausserdem müsste ich alles umstellen, was bereits seit 10 jahren möglich war.

demnächst kommt dann ein hersteller mit brightness 768. was dann?


da sollte doch eher das "übergeordnete" modul die standardisierung/das mapping vornehmen, um möglichst viele "zulieferer" bedienen zu können, denke ich. wenn dieses modul dann quasi zum standard wird, weil jeder es haben möchte, werden eventuell auch die "zulieferer" mehr und mehr von sich aus ihr modul anpassen/erweitern.


ich bin jedenfalls gegen jede "standardisierung", wenn diese zu beschneidungen an anderer stelle führt.

[pwlr]

Moin,

ich möchte zunächst allen, die in irgendeiner Form an diesem FHEM gearbeitet haben, ganz herzlich danken !
Ich gehöre zum Kreis der Anwender (bzw. Anwendungsentwickler) und kann mich leider mangels Linux Know How an dieser Arbeit nicht beteiligen.
Aber vielleicht, so im Laufe der Zeit ....

Mein FHEM ist inzwischen auf 960 defined entities gewachsen (inklusive "altem Kram" aus der Startzeit und auch "Leichen"), aber immerhin nicht ganz klein. Für einen möglichst störungsfreien täglichen Betrieb setze ich auf HM-Devices und arbeite zur Risikominimierung sehr viel mit peering. Für den Rest nutze ich Perl-Subroutinen, die primär durch userReadings angesteuert werden.

Ich sehe trotz der bisher sehr guten Funktionalität des FHEM schon im Sinne einer Standardisierung einige Verbesserungsmöglichkeiten - als Richlinien für die Entwickler, nicht als Gesetz! Man sollte damit nicht die Kreativität der Entwickler einschränken und eventuelle neue Lösungen erschweren.

Einige Beispiele, keine Kritik:
1. Standard-Readings (state, pct, level, powerOn, battery, contact, etc) sollten in allen Devices vorhanden und die gleiche Bedeutung haben, natürlich nur soweit sinnvoll.

2. Standard-Steuerungsbefehle (set on|off, pct, active|inactive, etc) sollten für alle Devices gleich sein (soweit sinnvoll)
(aktuell kann man z.B. einen Dimmer (HM-LC-SW1PBU-FM) mit set <device> pct 100 einschalten, einen Switch (HM-LC-SW1PBU-FM) aber nicht (mehr).

3. Bei gepeerten Sensoren liefert FHEM Infos über den Wert und und das Ziel. Diese Infos sollten auch in den einzelnen Devices gleich implementiert sein.
HM-MOD-EM-8 => closed (to Lampe_Schuppen_Device) vs. HM-MOD-EM-8BIT => unknown:28 (to myVCCU)
Bei der korrespondierenden Registerprogrammierung der Devices wird für xxCtValHi bzw, xxCtValLo der Dezimlwert benötigt. Wäre schön, wenn man nicht erst "closed" oder den Hex_Wert umrechnen müsste. Und die Bedeutung von "unknown:" ist mir bis heute unklar.
   
4.Alle Readings sollten mit gleichem Namen sowohl in der GUI und auch in Perl-Subroutinen verfügbar sein und die Steuerung via expert sollte keine Auswirkungen auf den Namen eines Readings auf der Perl-Ebene haben.
(R-self02-lgActionType vs .R-self02-lgActionType)

Das sollen nur einige Beispiele zur Verdeutlichung sein, kein Gemecker - aber mehr Standards wären gut. Man könnte leichter Devices unterschiedlicher Typen austauschen bzw. Routinen umfänglicher nutzen.

Für die eventuelle Umstellung eines Modul gibt es aktuell meines Erachtens ein sehr gutes Beispiel:

Code Auswählen Erweitern


2021.02.23 11:14:23.031 3: tempOFF is deprecated and will be removed in a next version. Please use tempMap and\or widgetTempRange
2021.02.23 11:14:23.033 3: tempON is deprecated and will be removed in a next version. Please use tempMap and\or widgetTempRange

Moin
Bernd

[xenos1984]

was ist daran einfach?

Das Beispiel beschreibt ein Gerät mit 3 Funktionen (binärer An/Aus-Zustand, Helligkeit, Farbtemperatur) und keine 20.

standardisierung bedeutet doch hier:
entweder "beschneide" ich die möglichkeiten, wenn nur noch 100 werte zulässig sind.
oder umgekehrt wird die bedienung "unmöglich" oder nicht mehr intuitiv, wenn ich zb 50% einstellen will. ausserdem müsste ich alles umstellen, was bereits seit 10 jahren möglich war.

Nein. Es will niemand etwas "beschneiden" oder unmöglich machen, was vorher möglich war. Das habe auch weder ich geschrieben, noch irgendjemand anders. Es geht darum, gemeinsame Eigenschaften auf eine gemeinsame Art und Weise über ein passendes Modul zu steuern. Wenn die eine Lampe mehr diskrete Stufen kann als die andere, ist das eben gerade keine Gemeinsamkeit, sondern ein Unterschied, und dann muss man eben diesen Unterschied abbilden.

Wenn ich 3 verschiedene Lampen habe, die diskrete Werte im Bereich 0-99, 0-100 und 0-255 verstehen, dann muss ich mich eben fragen, wie ich das abbilde. In dem Fall wäre dann z.B. meine Idee, es auf einer der beiden folgenden Weisen - oder sogar beide - abzubilden:

• Die erste Idee ist, dass der Anwender eine Möglichkeit bekommt, das Modul zu fragen, welches der minimale und maximale Wert sind und welche Zwischenschritte erlaubt sind. Dann kann der Anwender in seinem DOIF oder notify o.ä. bildlich gesprochen sagen: "set lamp brightness [lamp:maxBrightness]" und hat volle Helligkeit, und muss sich nicht erst fragen, ob er dafür 99, 100 oder 255 übergeben soll.
• Die zweite Idee wäre ein Zusatz zu der ersten, nämlich dass der Anwender zusätzlich zum Hersteller-definierten Bereich von diskreten Werten die Möglichkeit bekommt, einen beliebigen Gleitkommawert von 0 bis 1 anzugeben, und dann steuert die Lampe auf den diskreten Wert, der diesem am nächsten liegt. Wenn sich also der Anwender nur dafür interessiert, in 10 Stufen dimmen zu können, egal wie viele die Lampe kann, stellt er eben sowas wie "set lamp relativeBrightness 0.3" bei sich ein, und muss nicht erst rechnen, welchen Wert die Lampe dafür gerne hätte. Das wäre aber nur eine Zusatzfunktion - alle diskreten Level sollen nach wie vor ansprechbar sein.

demnächst kommt dann ein hersteller mit brightness 768. was dann?

Eben genau deshalb ja dieses Beispiel. Wenn alle meine DOIF sagen: "set lamp brightness 255" und ich auf einmal eine Lampe habe, die bei dem Befehl nur noch 1/3 Helligkeit liefert, ärgere ich mich, weil ich selektiv ändern muss, überall da, wo ich nun diese neue Lampe ändere.

Trotzdem beschneide ich nichts - ich kann ja nach wie vor jede der 768 Stufen einzeln ansprechen. Die API sagt mir nur, wie viele es sind. Und wenn ich eine Funktion haben will, die "gleitend" dimmt, indem sie die einzelnen Zwischenschritte macht, kann ich die so auch leichter implementieren.

da sollte doch eher das "übergeordnete" modul die standardisierung/das mapping vornehmen, um möglichst viele "zulieferer" bedienen zu können, denke ich. wenn dieses modul dann quasi zum standard wird, weil jeder es haben möchte, werden eventuell auch die "zulieferer" mehr und mehr von sich aus ihr modul anpassen/erweitern.

Was soll denn in dem Beispiel das "übergeordnete Modul" sein und was der "Zulieferer"? Hier würde doch so ein Mapping von z.B. 0-100 auf 100 Stufen der 768-Stufen-Lampe genau zu einer Beschneidung führen, und die ist ja gerade nicht das Ziel.

ich bin jedenfalls gegen jede "standardisierung", wenn diese zu beschneidungen an anderer stelle führt.

Da sind wir einer Meinung.

[Frank_Huber]

demnächst kommt dann ein hersteller mit brightness 768. was dann?

der ESP RGBWW Controller z.B. im RAW Befehl 0 bis 1023
*duckundweg*

[Beta-User]

demnächst kommt dann ein hersteller mit brightness 768. was dann?

Sowas ähnliches hatte ich schon: Da kam ein zigbee/mqtt-Gerät, das mV statt der üblichen V-Angabe lieferte.

Das Ergebnis in mqtt2.template sieht jetzt so aus, dass "alles irgendwie im Kreis" gemappt wird, um am Ende dann (auch) zwei standarkonforme Readings vorhanden sein sollten mit batteryVoltage und batteryPercent. Die "ursprünglichen" Reading-Namen sind verschwunden bzw. geändert zu "batterymV". Wenn ich (ohne Klimmzge) gekonnt hätte, hätte ich "batterymV" gelöscht, das hat gg. der (umgerechneten) batteryVoltage mAn. keinen Mehrwert.
Kann nicht erkennen, dass das "falsch" wäre oder ein Verstoß gegen Herstellervorgaben.

Dass ein Hersteller den Reading-Namen wirklich "hart" vorgibt, dürfte kaum vorkommen, er nennt ihn bestenfalls "in seiner App" anders. In FHEM sollte man es sich in der Regel (als Maintainer) aussuchen können, nach welchem Schema man was benennt.

Aber ein Dogma würde ich nicht draus machen, für mich sind "dim 99" noch verständlich, und ich gebe das dann auch via mqtt als "$base/$device/pct 99" ohne schlechtes Gewissen weiter...

Imo ist es gerade bei "schrägem Zeug" wie "brightness 768" die Frage, ob es Sinn macht, das auf der Userseite zu lösen. Was wir erleben, ist doch eher, dass dann allzuoft Unsinn (und Frust bzgl. FHEM) rauskommt...

Wenn es wirklich eine diskrete Angabe ist, muss es ja nicht unbedingt brightness heißen (ich übersetze brightness zwischenzeitlich immer mit: "hat 255 als Maximalwert"), sondern der Name könnte auch "lightLevel" (?) sein...?

Für die eventuelle Umstellung eines Modul gibt es aktuell meines Erachtens ein sehr gutes Beispiel:

Code Auswählen Erweitern


2021.02.23 11:14:23.031 3: tempOFF is deprecated and will be removed in a next version. Please use tempMap and\or widgetTempRange
2021.02.23 11:14:23.033 3: tempON is deprecated and will be removed in a next version. Please use tempMap and\or widgetTempRange

Meine Erfahrung:
Hinweise nur im Log lesen die wenigsten, und nicht einmal CHANGED wird wahrgenommen, selbst wenn jemand massive Probleme hat (habe das jüngst mit Heating_Control erlebt: > 1 Jahr Ankündigung (u.A. im Log beim Starten), und trotzdem hat es mind. einer verpaßt...

Von daher: Jeder User sollte die Wahl haben, "alte Welt" zu bekommen.

Was HM angeht: das ist sehr fein aufgegliedert, aber gerade da kommen "Herstellerspezifika" besonders stark zur Geltung. Das ist in anderen Modulfamilien/Technologien nach meiner Erfahrung deutlich weniger stark ausgeprägt (auch wenn es da teils massive (funktionale) Unterschiede zwischen Geräte- und Protokoll-Generationen gibt).

der ESP RGBWW Controller z.B. im RAW Befehl 0 bis 1023
*duckundweg*

Auch hier ist die Grenze und das Wording a) menschengemacht und b) gewissen technischen Gepflogenheiten folgend. Ad a) hatte ich schon was geschrieben, und ad b) ist anzumerken, dass da die Zahl der üblichen Varianten auch relativ überschaubar ist...

(Ansonsten: dim 50% kann bei unterschiedlichen Leuchtmitteltypen auch unterschiedliche Ergebnisse zeitigen, je nachdem, ob der Hersteller eher in Lux denkt oder in Leistungsaufnahme, oder in ...)
Ein weites Feld also...

[frank]

Was soll denn in dem Beispiel das "übergeordnete Modul" sein und was der "Zulieferer"? Hier würde doch so ein Mapping von z.B. 0-100 auf 100 Stufen der 768-Stufen-Lampe genau zu einer Beschneidung führen, und die ist ja gerade nicht das Ziel.

zb ein zusatzmodul, das dir deine gewünschte standardisierte schreibweise ermöglicht. quasi ein "setCmdProxy"-modul

Code Auswählen Erweitern

set lamp lightLevel [min|night|kuschel|eco|max|...]

da kann sich dann ein developer "austoben", ohne dass irgendwer etwas zu ändern braucht.
keine diskussionen sind nötig, zu jedem device können spezielle mappings erstellt werden, ... .
zb kann man auch berücksichtigen, dass nicht jeder dimmer mit jedem leuchtmittel bei der selben einstellung die selbe "helligkeit" erzeugt.

zulieferer wären dann alle module, die eine lampe schalten können.

das könnte man sogar noch weiter "verallgemeinern", so dass nicht nur ein übergeordnetes "lightLevel" cmd existiert, sondern allgemeiner zb ein "cmdLevel" bereitgestellt wird, dass gleichzeitig zb auch diverse laustärken mappen kann, oder was auch immer... .