Macht es Sinn, Aktoren zu "virtualisieren"?

[Wuppi68]

Liebe Entwicklergemeinde

Macht es Sinn Autoren entsprechend zu Virtualisieren, damit die Protokollabhängigkeit aufgelöst wird? So ähnlich wie beim Apple HomeKit?

Mir schwebt das ungefähr folgendes Konstrukt vor:

V-Switch
hat folgende Aktionen: On, Off, On-For-Timer, Off-for-Timer
und "nur" den normalen STATE

V-Dim
hat folgende Aktionen: On, Off, On-For-Timer, Off-for-Timer, percent
und "nur" den normalen STATE

Bei den virtuellen Devices werden die Befehle dann entsprechend in den Attributen angelegt.
z.B
define VirtSchalter VIRTUAL Switch FS20_Abstellkammer   # Virtueller Schalter wird auf FS20_Abstellkammer abgebildet
attr VirtSchalter HAL_ON set $$ on
attr VirtSchalter HAL_OFF set $$ off
attr VirtSchalter HAL_STATE $$:STATE

So richtig spanned wird es wenn die Hardwaredevices gänzlich unterschiedliche Befehlssätze haben (RGB vs. HSV ....)
Nicht existierende Funktionen können dann in dem V-Device entsprechend hinterlegt werden (Timer ...)

Die Programmierung wird dann im ganzen etwas einfacher werden, da alle Devices dann einen gewissen Standard haben. Für Spezialfälle kann man ja noch auf das Basisdevice zugreifen

Vorteile:
Apps haben es leichter, da nicht so viele Widgets zu erstellen sind und die Schnittstelle deutlich einfacher zu gestalten ist
Basis um für die Zukunft vielleicht einen "GUI Baukasten für Bedingungen und sonstiges" zu entwickeln
einfacherer Support für Code Snippets

Nachteile:
mehr Ressourcenverbrauch
komplexer für das Verständniss (Perl und FHEM aber auch )

Na, wie schaut's aus?

Ideeninput ist gerne gesehen

PS: Habe natürlich auch schon abgestimmt

[klaus.schauer]

Hierzu gibt es schon mindestens ein gutes Model u. a. zur Beschreibung der Daten und Aktionen, siehe: https://www.enocean-alliance.org/fileadmin/redaktion/enocean_alliance/pdf/GenericProfiles_V1_Extract.pdf. Aber... Die Idee gibt es schon seit mehreren Jahren; durchsetzen konnte es sich bisher nicht. Na ja, ich habe es dennoch in das EnOcean-Modul integriert. Natürlich parallel zu den klassischen Profilen, die immer mehr werden.

Auch bei der Fhem-Gemeinde habe ich den Eindruck, dass man an solche und ähnliche Ideen nicht ran will. Schon die Erweiterung von Readings um eine Variable zur Beschreibung von Einheiten geht scheinbar gar nicht.

[rudolfkoenig]

Macht es Sinn Autoren entsprechend zu Virtualisieren, damit die Protokollabhängigkeit aufgelöst wird?

Alte Diskussion (Stichwort Interface).

Und meiner Ansicht nach wird sowas nicht demokratisch entschieden, genausowenig wie Lottozahlen oder mathematische Ergebnisse.

[Wuppi68]

Alte Diskussion (Stichwort Interface).

Und meiner Ansicht nach wird sowas nicht demokratisch entschieden, genausowenig wie Lottozahlen oder mathematische Ergebnisse.

Hallo Rudi,

es soll auch keine demokratische Entscheidung sein - nur eine Abfrage, ob es Sinn macht

Durch das FHEM Framework, sollte es eigentlich relativ einfach sein so eine Zwischenschicht einzuführen - OHNE am FHEM selber dran gehen zu müssen Es würden halt nur ein "paar" Informationen mehr durch fhem.pl geschleust werden

[Dr. Boris Neubert]

Hallo,

im Developer-Forum hatten wir das Thema vor längerer Zeit intensiv diskutiert und als grundsätzlich wünschenswert definiert. Es gibt auch Grobkonzepte dazu. Die Umsetzung ist eine Aufgabe für Helden. Sie erfordert intensive konzeptionelle Vorarbeiten und umfangreiches Prototyping mit mehrfachen Iterationen und Wegwerflösungen. Man braucht einen langen Atem, bis ein API soweit ist, dass es sichtbaren Nutzen stiftet. In anderen Worten: das macht einfach keinen Spaß und deswegen hat's noch keiner fertiggebracht.

Viele Grüße
Boris

[justme1968]

ganz allgemein: ja. es ist wünschenswert so etwas zu haben und über kurz oder lang werden wir das auch schaffen.

in der alten diskussion ging es hauptsächlich um readings, einheiten und deren darstellung. in deinem vorschlag geht es hauptsächlich um kommandos. beides hat zwar miteinander zu tun, läuft aber nicht aufs gleiche raus.

für die kommando geschichte braucht es glaube ich zumindest zwei dinge:
- das 'was bist du für ein device' -> abstrakte device typen
- das 'welche komamndos kannst du' und wie verhalten sie sich zu den möglichkeiten des abstrakten device

bei dieser Übersetzung gehen entweder Eigenschaften und möglichkeiten verloren oder das abstrakte device ist so komplex und hat so viele möglichkeiten das vieles von den echten devices nicht umgesetzt wird. das ist eine Gratwanderung.


speziell zu deinem vorschlag: du hast dir genau die beiden devices mit den wenigsten problemen rausgesucht schalter machen in fhem (fast) gar keine probleme da sie fast alle on und off unterstützen. monochrome dimmer sind auch noch recht einfach. es gibt im prinzip nur zwei varianten.

wie du schon bemerkt hast wird es bei farbigen lampen langsam schwieriger. unter anderem weil neben den unterschiedlichen kommandos auch noch unterschiedliche farb modelle und farb räume dazu kommen.

noch schlimmer ist es mit dingen wie schlössern und fenster oder für öffnern. die geräte unterscheiden sich in feinen aber bedeutsamen details schon innerhalb einer herstellerfamilie und zischen herstellern sind manchmal schon die konzepte unterschiedlichen. von der funktionalität ganz zu schweigen.

homekit ist hier tatsächlich ein gutes beispiel. im guten weil wir mit dem mapping und der fhem integration schon ein paar erfahrungen gesammelt haben und ich noch ein paar ideen habe wie man das ganze noch deutlich genereller machen kann. aber auch im schlechten da homekit zwar eine sehr mächtige und abstrakte möglichkeit bietet geräte zu beschreiben, leider haben sie aber an ein paar entscheidenden stellen 'vergessen' auf wichtige unterschieden einzugehen oder dinge optional zu machen. (beispiel thermostate: es gibt die modi manuell, heizen, kühlen und auto. leider in dieser reihenfolge, was es unmöglich macht im ui kühlen weg zu lassen.)

übrigens gibt es durchaus frontends die mit (fast) beliebigen neuen devices klar kommen. fhemweb ist hier ein sehr gutes beispiel. manche app ist ein sehr schlechtes beispiel da nur bestimmte devices fest kodiert funktionieren. auch hier kann man sich dinge abschauen. die guten und auch die nachteile. z.b. das es einfacher ist wenn die module mit spielen oder das die flexibilität zum teil mit mehr aufwand für den endanwender verbunden ist. vor allem wenn sie es nicht tun.

das ganze kann durch aus spass machen. ist aber deutlich komplexer als es auf den ersten blick erscheint. vor allem wenn tatsächlich alles in der zwischenschicht gerade gebogen werden muss. bei manchen punkten wäre es deutlich einfacher und effizienter direkt in den modulen für etwas mehr einheitlichkeit zu sorgen.

je weniger aufwand für die module und je mehr fertiger und allgemein benutzbarer code mit so einem vorschlag verbunden ist um so größer ist vermutliche die chance das daraus etwas wird .

gruss
  andre