Wenn man in der Lage ist, eine halbwegs vernünftige Softwarearchitektur zu "basteln", dann stellen sich solche Fragen nicht.
Dann entwirft man an der Basis für alle Gerätetypen, die man unterstützen will, abstrakte Geräte (Lampe, Schalter, usw.) und alle vorkommenden Funktionen für diese Geräte. Die abstrakten Geräte stellen Möglichkeiten, diese Funktionen vollständig umzusetzen als leere Hülle zur Verfügung, tun also nichts weiter. Weiterhin müssen diese abstrakten Geräte in der Lage sein, dem "Drumherum" mitzuteilen, was sie können. Bei AVM ist das die "FunctionBitmask" und mit ZigBee und HANFUN kommen noch UnitTypes und Interfaces dazu. Wie auch immer. Die Implementierungen der physikalisch vorhandenen Endgeräte (z.B. DECT 500 oder Hue Bulb) basieren auf diesen abstrakten Basisgeräten und füllen deren leere Hüllen mit Leben (z.B. bei einer Lampe den Code, um sie ein-/oder auszuschalten, die Helligkeit zu regeln usw).
Wenn man dann einen physikalischen Schalter implementiert (egal ob Hue oder AVM 440), dann teilt die Implementierung des Schalters dem "Drumherum" zumindest mit, daß er 4 Tasten hat (oder der 440 pro aktivem Screen 4 Tasten). Wenn der Benutzer sich im "Drumherum" dazu entscheidet, daß dieser Schalter (oder beim 440 ein aktiver Screen mit 4 Tasten) zum Ansteuern von Leuchtmitteln verwendet werden soll, dann ist das, was man den 4 Tasten zuweisen kann immer gleich. Denn NICHT die Implementation des phyiskalischen Schalters entscheidet, was hier möglich ist, sondern das "Drumherum", weil es kennt den Leuchtmitteltyp, den es mit dem Schalter anzusteuern gilt. Denn auch die Glühbirne / das Leuchtmittel (oder Gruppe von Leuchtmitteln), das man mit dem Schalter ansteuern will, hat das "Drumherum" darüber in Kenntnis gesetzt, was es kann (An-/Ausschalten, Helligkeit und Farbe regelbar). Bei Gruppen von Leuchtmitteln nimmt man den kleinsten gemeinsamen Nenner. Also stellt das "Drumherum" dem eher dummen Schalter einen Satz von Basis- und Komfortfunktionen zur Verfügung, die man per Tastendruck auslösen kann. Wenn man an der Basis alles richtig gemacht hat, dann ist das alles total unabhängig vom Hersteller des Schalters - das hat das "Drumherum" nicht zu interessieren, es muß eigentlich nur wissen, wieviele Tasten ein Schalter hat.
Bei farbigen Leuchtmitteln sollte das Leutmittel das "Drumherum" auch noch in Kenntnis darüber setzen, welchen Farbraum es unterstützt (hier wird oft das "Gamut" verwendet, welches ein Dreieck in einem "zungenförmig" aussehenden Farbraum darstellt).
Jede Taste eines jeden Schalters hat eine eindeutige ID und wann man eine Taste drückt, dann sagt die Taste dem "Drumherum" "Hallo, ich wurde gedrückt, meine ID ist..." . Das "Drumherum" schaut dann nach, was beim Drücken dieser Taste zu erledigen ist und führt es dann aus. Ggf. ist auch für manche Tasten + Funktionen ein "Autorepeat" (evtl. pro Taste konfigurierbar) auszuführen, der mit dem Loslassen dieser Taste beendet wird.
Kurz: Wenn man alles halbwegs richtig gemacht hat, dann kann man jedem Schalter - egal wer der Hersteller ist - dieselben Funktionen anbieten, die man auf eine Taste legen kann. Nicht der Schalter entscheidet, was möglich ist, sondern die "Basis" unter Kenntnis des Lampentyps, den man ansteuern will.
Wenn man in der Basis Abfragen wie "Wenn Schaltertyp = AVM, dann mach dies / Wenn Schaltertyp = ZigBee, dann mach etwas anderes" drinnen hat, dann hat man es völlig falsch gelöst und nicht verstanden, wie man so erwas vernünftig löst.
Aber leider ist der Source Code nicht öffentlich.
, selbst Komfortfunktion schalten einer Gruppe gelingt mir nicht mehr...
