Standardisierung FHEM, wo wollen wir hin

[xenos1984]

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

Code: [Auswählen]

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, ... .

Diesen Ansatz halte ich eher unrealistisch. So ein "Super-Übersetzer-Modul" müsste nicht nur an alle vorhandenen Geräte angepasst werden, und damit wissen, welche Lampe welche Helligkeiten unterstützt etc., sondern auch noch an die Wünsche der Anwender. Wie soll man denn z.B. "night" standardisieren, wenn ein Anwender sein Nachtlicht gerne etwas heller hätte, ein anderer etwas dunkler, und wieder ein anderer den roten U-Boot-Modus bevorzugt?

zb kann man auch berücksichtigen, dass nicht jeder dimmer mit jedem leuchtmittel bei der selben einstellung die selbe "helligkeit" erzeugt.

Auch dafür sehe ich an dieser Stelle und auch generell schwarz. Wenn ich z.B. eine Deckenleuchte und einen Dimmaktor habe, dann hängt die Helligkeit nicht nur von der Einstellung des Dimmaktors ab, sondern auch davon, welches Leuchtmittel ich in der Leuchte einsetze. Davon weiß aber weder der Dimmaktor etwas, noch hat die Software / der Programmierer eine Ahnung davon, wie viel Lux meine Lampen maximal liefern, geschweige denn, welche Einstellung ein für mich angenehmes Nachtlicht realisiert.

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... .

Ich denke aus o.g. Gründen, das ist der falsche Ansatz einer Standardisierung, weil sie eben nicht darauf abzielt, gemeinsame Eigenschaften auf ein gemeinsames Interface abzubilden, sondern verschiedene Dinge in einen Topf wirft, die so nicht vereinbar sind. Man kann weder die Präferenzen der Anwender standardisieren, noch physikalische Eigenschaften, die gar nicht durch die Software abgebildet werden, wie den Zusammenhang zwischen Dimmer-Stellwert und tatsächlicher Helligkeit. An der Stelle muss einem Anwender die Möglichkeit gegeben sein, diesen Zusammenhang selbst zu konfigurieren. Ein Standard kann ihm nur helfen, dass die Art und Weise, wie er diese Konfiguration vornimmt, unabhängig davon ist, von welchem Hersteller er seine Hardware bezieht und wie sie eingebunden ist, bzw. welches Modul sie ansteuert.

[Per]

Wobei gar nicht gesagt ist, dass ich von meiner alten Lampe die 50% übernehmen will, wahrscheinlich muss ich da die Werte eh anpassen, weil die Neue viel heller ist...

[frank]

Diesen Ansatz halte ich eher unrealistisch. So ein "Super-Übersetzer-Modul" müsste nicht nur an alle vorhandenen Geräte angepasst werden, und damit wissen, welche Lampe welche Helligkeiten unterstützt etc., sondern auch noch an die Wünsche der Anwender. Wie soll man denn z.B. "night" standardisieren, wenn ein Anwender sein Nachtlicht gerne etwas heller hätte, ein anderer etwas dunkler, und wieder ein anderer den roten U-Boot-Modus bevorzugt?

immerhin schon mal ein anfang, aber etwas mehr fantasie bitte. 

meine idee war ja, dass der "markt" nun eine art standardisierung einleitet.

es gibt ja ein paar zusatzmodule, die ihre clienten/devices automatisch identifizieren und sich daran "andocken".
für den anfang würde es ja genügen, dass der entwickler dieses moduls seine bedürfnisse befriedigt, indem er seine speziellen devices/devicetypen integriert.
über attribute kann man auch devices markieren, wenn sie nicht so schon über devicehash infos zu identifizieren sind.
über eine anpassung der attribute durch den user sind auch persönliche einstellungen einfach möglich.
entwickler, die an dieser standardisierung interessiert sind, werden sicherlich fehlende infos bereitstellen.

[xenos1984]

immerhin schon mal ein anfang, aber etwas mehr fantasie bitte. 

Ich fürchte, ich gehe solche Dinge lieber mit Realismus und Pragmatismus an. Die Methode hat sich bewährt.

Mir klingt dieses Super-Übersetzer-Modul-Konzept zu abstrakt. Konkrete Punkte zu suchen wo man Dinge vereinheitlichen kann halte ich für zielführender.

[frank]

Ich fürchte, ich gehe solche Dinge lieber mit Realismus und Pragmatismus an. Die Methode hat sich bewährt.

ich bin gespannt auf die ergebnisse.

[xenos1984]

ich bin gespannt auf die ergebnisse.

Ich auch. Meinen Ansatz habe ich ja oben erläutert.

[sven.scherf]

Hi,


wie ich hier sehe gibt es viele Bedenken und geht nicht, kann man nicht, sind Einschränkungen.

Mhh irgendwie seltsam diese Aussagen. Wir machen doch hier Software dies habe ich so verstanden.

Viel besser ist es doch sich Gedanken zu machen wie löse ich diese Herausforderung einen Standard einzuhalten oder wie kann ich diese Herausforderung umsetzen.
In meinem Berufsleben habe ich viel gehört von geht nicht und kann man nicht.
Wenn man dies dann aber hinterfragt hat kamen dann doch Lösungen heraus die tragbar waren, denn ein geht nicht gibt es nicht.
In Software geht alles zu lösen

Wenn man ein neues Device von 0 - 768 oder 0 - 65535 einstellen kann kann dies über fhem doch in 0 - 100% umgesetzt werden.
Sollte der Modulentwickler dann hier der Auffassung sein es ist zu gering, na dann bitte schön kann dies in RAW Commands implementiert werden.

Bitte hier nicht falsch verstehen wir nutzen und entwickeln hier fhem doch alle(so denke ich) in unserer Freizeit und es ist unser Hobby :)Es ist keine Kritik, ich bin selber froh und dankbar hier Lösungen und Module zu finden die meine Aufgabenstellung lösen.

In meinen eigenen Softwareentwicklungen ist es oft so, dass man sich nach Jahren fragt warum habe ich dies so gelöst ??
Gerade wenn ein Projekt wir hier fhem mit der Zeit wächst und immer mächtiger wird macht es Sinn Lösungen zu hinterfragen und eventuell umzustellen.

Wer fängt nun wo an mit Standardempfehlungen und Umsetzungen ?

 

Viele Grüße

Sven