[Diskussion] Objektdefinition Licht
-
Liebe @Developer,
im Zuge der Ermittlung des IST Zustands bei der Objektdefinition für Beleuchtung in den Adaptern, hat sich gezeigt das hier noch zu viele Unterschiede herrschen. In diesem pdf findet ihr eine grobe Zusammenfassung. Betrachtet habe ich 30 Adapter, in dem ich den Quellcode Untersucht habe. Einige Adapter erzeugen die Objektdefinition dynamisch Anhand der Empfangenen Daten, deshalb gibt es keine greifbare Definition.
Über folgende Punkte sollten wir Diskutieren:
-
Roles: Es werden noch immer viele roles verwendet die nicht in der Offiziellen liste vorhanden sind. Welche davon sollen wir in die Liste aufnehmen, welche vielleicht sogar entfernen?
-
Einheiten und Wertbereiche: Sowohl bei den Einheiten als auch bei den Wertebreichen gibt es mehr oder weniger große Unterschiede. Hier gibt es in der roles Liste manchmal vorgaben, aber auch die sind nicht immer sinnvoll. Welche Einheiten und Wertbereiche machen Sinn und sind möglich?
-
Farbsysteme: Insgesamt werden 6 Unterschiedliche verwendet, mit Varianten sind es sogar 10. Welche davon sollen erhalten bleiben?
-
Objekt IDs: Viele Objekte die den gleichen Zweck haben werden in verschiedenen Adaptern unterschiedlich benannt.
Zum Beispiel Brightness: bri, bright, level oder auch einfach brightness. Ist es in unserem Sinn wenn wir feste vorgaben machen?
Zusammenfassung ist Zustand:
Die Zahl in der Klammer ist die Anzahl der Verwendungen in Adaptern. Alternative roles die Verwendet werden, aber nicht in der Liste sind.
level.dimmer:
- Vorgabe Einheit und Wertebereich: Nichts
- Wertebereiche: 0-255 (4), 0-254 (2), 0-100 (15), nicht definiert (7)
- Einheiten: % (11), nicht definiert (19)
- Alternative roles: dimmer.level (19), indicator.dimLevel (1), value (1), level.color.bri (1), state (2), keine (1)
level.color.temperature:
- Vorgabe Einheit und Wertebereich: °K, 2200-6500
- Wertebreiche: 0-100 (1), 153-500 (1), 0-5000 (1), 1200-6500 (2), 2200-6500 (1), 2500-9000 (1), dynamisch (1), nicht definiert (6)
- Einheiten: K (5), °K (2), Kelvin (1), % (1), nicht definiert (6)
- Alternative roles: indicator.colorTemperature (1), level.color.temp (1)
level.color.saturation:
- Vorgabe Einheit und Wertebereich: Nichts
- Wertebereiche: 0-255 (2), 0-254 (2), 0-100 (7), 0-x (1), nicht definiert (3)
- Einheiten: % (5), nicht definiert (9)
- Alternative roles: indicator.saturaion (1), level.cct.saturation (1)
level.color.hue:
- Vorgabe Einheit und Wertebereich: °, 0-360
- Wertebereiche: 0-255 (2), 0-360 (7), 0-65535 (1), 0-x (1), nicht definiert (2)
- Einheiten: ° (3), nicht definiert (11)
- Alternative roles: indicator.hue (1), level.cct.hue (1)
level.color.rgb:
- Vorgabe Einheit und Wertebereich: HEX farbcodes
- Wertebereiche: RGB (3), HEX (3), nicht definiert (6)
- Einheiten: keine
- Alternative roles: keine
level.color.red (-green, -blue, -white):
- Vorgabe Einheit und Wertebereich: Nichts
- Wertebereiche: 0-255 (5), 0-100 (1), HEX (1), nicht definiert (1)
- Einheiten: keine
- Alternative roles: state (1), level.color.[r/g/b] (1)
Nicht in der Liste vorhandene roles und ohne Alternative:
level.color.hex, level.color, level.color.rgbw, level.cct.cct, level.color.xy, level.color.xyz, light.color.hsv (value.hsb), level.cmy.[cyan/magenta/yellow], level.color.cmyk -
-
Meine Meinung zu den Punkten im ersten Beitrag:
Warum? Benutzerfreundlichkeit, Kompatibilität (IOT), weniger Chaos, einfachere Pflege
-
Aufnehmen: level.color.hex, ist im Web Standard und kann für jedes Farbsystem umgerechnet werden.
Entfernen: level.color.rgb, gibt es getrennt für jeden Farbkanal inklusive Weiß und ist damit Flexibler. Außerdem ist es für Benutzer einfacher einen Wert von 0 bis 255 ein zu geben, als heraus zu finden in welcher Form man die Werte für alle Kanäle ein zu geben. Oft wird ein Array erwartet, aber es gibt verschiedene Möglichkeiten ein Array ein zu geben: {255,255,255}, [255,255,255] oder einfach 255,255,255 -
Brightness und Dimmer machen im Zusammenhang Licht beide das Selbe, sie geben die Helligkeit an. Sie sollten vereint werden und die Einheit %, der Werttebereich 0-100 sein. Das ist für die Benutzung Logisch.
Saturation ebenfalls in % von 0-100.
Color Temperature ohne Einheit von 0-8000. Bei der Lichtfarbe ist das Problem es gibt viele Unterschiedliche Bereich den einzelne Lampen bieten. Wenn ein System feste Werte Liefert aber am anderen Ende unterschiedliche Lampen gesteuert werden kann der Bereich in ioBroker nicht festgelegt werden.
Der Maximale Bereich von Lichtfarben ist 1000-9000°K, um die Ansteuerung einheitlich zu halten bietet es sich an 8000 ohne Einheit zu verwenden.RGBW ohne Einheit von 0 bis 255.
-
Radikal reduzieren auf 2 HEX und RGBW.
-
JA. Für die Umrechnung von den anderen Farbsystemen in die erlaubten innerhalb der Adapter kann man ja eine Klasse bereitstellen.
-
-
Du sprichst mir aus der Seele da denke ich auch schon seit Monaten drüber nach, da der eine visu Adapter die Lampe erkennt und der andere nicht. Eine feste Basis an den sich alles halten MUSS ist da der einzig richtige Weg. Meine Idee wäre auch einen neuen Klasse einzuführen. Zum Beispiel states, Objekte und Geräte (definierte Gruppe aus states) wo dann nur klassifizierte Geräte enthalten sind wie Lampen Sauger Lüfter Rollladen Bewegunssensor Tür . Um ein Gerät zu erstellen müsste es dann muss daten wie bei Lampe an aus / an aus dimm haben und optional parameter wie Signalstärke oder Akku.
Ebenso muss festgelegt werden ob dimmbarr Lampen an/aus haben muss oder nur dim 0 für aus.
-
Die Einhaltung kann nur über das Stable repo durchgesetzt werden. Dabei muss dann auch entsprechend Unterstützt werden und es darf nicht zu Kompliziert sein.
@Meistertr sagte in [Diskussion] Objektdefinition Licht:
Meine Idee wäre auch einen neuen Klasse einzuführen. Zum Beispiel states, Objekte und Geräte (definierte Gruppe aus states) wo dann nur klassifizierte Geräte enthalten sind wie Lampen Sauger Lüfter Rollladen Bewegunssensor Tür .
Da bist du jetzt schon einen Schritt weiter. Ziel hier ist es die Basis zu bereinigen.
Das was du beschreibst wird der Devices Adapter übernehmen, der ist schon in Arbeit.@Meistertr sagte in [Diskussion] Objektdefinition Licht:
Ebenso muss festgelegt werden ob dimmbarr Lampen an/aus haben muss oder nur dim 0 für aus.
Ich bin für an/aus.
-
@Jey-Cee sagte in [Diskussion] Objektdefinition Licht:
Das was du beschreibst wird der Devices Adapter übernehmen, der ist schon in Arbeit.
Hallo, meinst du diesen?
-
@sigi234 ja, aber wie gesagt ist noch in Arbeit.
-
Da ich aktuell sehr viel mit lovelace arbeite, ist die von Euch beschriebene Problematik mir auch sehr aufgefallen. Aktuell löse ich diese Probleme mit meinem Adapter linkeddevices.
Was mir jetzt nicht so ganz klar ist, was ist denn der Unterschied zum devices adapter?Ich habe noch die Idee für den linkeddevices adpater, dort dem User die möglichkeit zu geben, z.B. ein Licht anzulegen. Dazu muss er dann vordefinierte Datenpunkte erstellen, so dass am Ende das von Euch beschriebene Gerät mit den entsprechenden Datenpunkten angelegt wird, inkl. aller notwendigen Attribute wie z.B. min / max Werte. Ich denke man müsste ja nicht noch etwas neues erfinden sondern könnte meinen Adapter für diese Zwecke entsprechend anpassen?
-
Das erinnert mich an meine Anregung zum Maping
Ich hatte das am Ende so verstanden als gäbe es bereits eine Vorgabe, diese würde nur nicht stringend umgesetzt?!?Bei Philips HUE Lampen gibt es sowohl "level (0-100)" als auch "bri (0-255)"
-
@Jey-Cee sagte in [Diskussion] Objektdefinition Licht:
@Meistertr sagte in [Diskussion] Objektdefinition Licht:
Ebenso muss festgelegt werden ob dimmbarr Lampen an/aus haben muss oder nur dim 0 für aus.
Ich bin für an/aus.
Ich finde an/aus erforderlich! Wie sonst soll man beim Wiedereinschalten den vorherigen Dimmwert wieder herstellen wenn dim = 0 gesetzt wurde...
-
@Thisoft es gibt Lampen bei denen ist aus helligkeit gleich 0. Das heißt es ist gar nicht möglich mit dem letzten wert ein zu schalten.
-
@Jey-Cee sagte in [Diskussion] Objektdefinition Licht:
@Thisoft es gibt Lampen bei denen ist aus helligkeit gleich 0. Das heißt es ist gar nicht möglich mit dem letzten wert ein zu schalten.
OK. Das ist ein Argument. Kannte ich bisher keine... Wenn das so ist, dann spricht das ja beinahe dafür An/Aus doch generell wegzulassen und das Wiederherstellen das alten Helligkeitswertes im Adapter (bzw. in der Klasse?) zu handeln damit das nach "außen" hin einheitlich ist.
-
@Thisoft sagte in [Diskussion] Objektdefinition Licht:
@Jey-Cee sagte in [Diskussion] Objektdefinition Licht:
@Thisoft es gibt Lampen bei denen ist aus helligkeit gleich 0. Das heißt es ist gar nicht möglich mit dem letzten wert ein zu schalten.
OK. Das ist ein Argument. Kannte ich bisher keine... Wenn das so ist, dann spricht das ja beinahe dafür An/Aus doch generell wegzulassen und das Wiederherstellen das alten Helligkeitswertes im Adapter (bzw. in der Klasse?) zu handeln damit das nach "außen" hin einheitlich ist.
Hi, ein Adapter wie linkedDevices oder Devices ( @Scrounger: Habe mich im Übrigen auch gefragt, ob das nicht genau auf das gleiche hinausläuft?) könnte sich ja auch den letzten LEVEL-Wert zwischenspeichern und beim Wiedereinschalten den gespeicherten Wert setzen. Das sollte programmiertechnisch nicht allzu schwer sein, denke ich.
Ich wäre doch stark dafür, den STATE ("ein/aus") getrennt vom LEVEL mitabzubilden!
VG
-
@Jey-Cee Im Augenblick sehe ich Dein Vorhaben eher skeptisch, auch wenn ich Deine Motivation verstehe. Insbesondere die Vorgabe von Namen für states und das Weglassen von level.color.rgb (bei mir ist rgb immer ein hex-Wert mit dem dann intern "weitergerechnet" wird), wäre Adapter technisch der overkill. Das wäre also überhaupt keine gute Idee. Wo ich eher Bedarf sehe wäre ein recht generischer Colorpicker für vis, der mit allen möglichen Arten der Farbwerte zurechtkommt. Ich glaube hier ist der Bedarf doch sehr groß.
-
@carsten04 ich verstehe nicht was du mit ovrekill meinst! jede schnittstelle hat andere parameter, die eine Hex werte die andere rgb, andere hue und und und. diese auf einen nenner bei den states zu bringen ist nur eine simple Umrechnung mit ein paar zeilen code..
Muss aber auch zugeben, dass in meinen Adaptern die Vorgaben nicht eingehalten sind. mihome-lamp war so zimlich mein erster Adapter und da hatte ich noch keine ahnung. Bei Yeelight meine ich mich zu erinner, dass ich nicht alles mit den Vorgaben abbilden konnte.
-
@carsten04 sagte in [Diskussion] Objektdefinition Licht:
Wo ich eher Bedarf sehe wäre ein recht generischer Colorpicker für vis,
Das halte ich für zu Kurz gedacht, es gibt auch andere Visualisierungen und daneben noch IOT. Die haben davon gar nichts.
Beim deConz Adapter habe ich versucht mich an das zu halten was vorgegeben ist. Aber auch wenn ich das zu 100% geschafft hätte, hilft das nichts wenn alle anderen was anderes machen.
Das Thema iot Kompatibilität ist dann immer wieder hoch gekommen. Also wollte ich wissen wie ich es denn jetzt richtig machen muss. Dabei kam dieses Thema heraus.
Es gibt Aktuell kein richtig, bestenfalls eine Praktisch orientierte Lösung damit es halt funktioniert.Als Entwickler finde ich es oft nervig mich an solche vorgaben zu halten, anderer Seits kann es die Entwicklung auch beschleunigen wenn man auf fertiges oder wenigstens gute Beispiele zurück greifen kann.
Als Nutzer wäre es mir schon zu blöd mich damit zu beschäftigen warum es mal Level zum Dimmen gibt und mal brightness.@Meistertr sagte in [Diskussion] Objektdefinition Licht:
Bei Yeelight meine ich mich zu erinner, dass ich nicht alles mit den Vorgaben abbilden konnte.
Das ist eine Sache die genau mit dieser Diskussion hier verbessert werden soll.
-
Ich bin auch für level.color.HEX color als Standard. Das würde saturation ja eigentlich überflüssig machen oder? Damit lässt sich ja eigentlich alles abbilden. Vll auch wie im Web mit Eingabe von blue, yellow... Ich hab keine rgbw Lampen welche states braucht man da zwingend?
Eine Tabelle wäre für die Übersicht doch nicht schlecht. Mit links Lampentypen oben states und in den Zellen die Vorgaben. Soll ich mich daran mal versuchen? -
@Meistertr sagte in [Diskussion] Objektdefinition Licht:
Soll ich mich daran mal versuchen?
Ja das wäre Hilfreich.
-
@Jey-Cee Der Anpassungsaufwand wäre bei mir schon ziemlich hoch. Dies liegt zum einen daran, dass bei Änderung von brightness, hue, satuation, RGB auch jeweils immer die korrespondierenden Werte angepasst werden und zum anderen der Adapter für diverse milight Bulbs funktioniert, d.h. white, RGB, rgbw, fullColor für die iBox1,2 in den Varianten 4 und 8 Channel und auch für den alten milight Adapter mit white, rgb und rgbw. Darüber hinaus müsste ich auch die App (pwa) die auf nuxt basiert (vue framework) an etlichen Stellen anpassen. Also mal eben nur ein paar Zeilen Code ändern, damit ist es definitiv nicht getan. Das gilt mit Sicherheit auch für einige der aufgezählten Adapter. Du solltest also eine mögliche Standardisierung sehr sorgfältig und mit Bedacht angehen, nicht das hinterher fast keiner der Adapter mehr richtig läuft.
-
Es gibt Adapter da hast du hue, sat, HEX und rgb als Eingabe das ist meiner Meinung nach vollkommen überflüssig. Naja zur Zeit braucht man es vieicht, weil das eine nur mit HUe und das andere nur mit HEX geht. Aber darum geht es ja hier, einen gemeinsamen Nenner zu finden.
-
@Meistertr Ich finde ein guter color-Adapter sollte immer die Möglichkeit haben mit RGB und HSV, also hue, saturation und brightness gleichermaßen umgehen zu können. Manchmal möchtest Du z.B. nur die saturation ändern, dann wäre es doch wenig hilfreich, wenn nur ein rgb-state da wäre. Beispiel lässt sich auch auf alle anderen Kombinationen anwenden.
