NEWS
[Diskussion] Objektdefinition Licht
-
@Garfonso Wir sind noch eine Ebene tiefer derzeit. Sobald es was gibt, können wir das gerne an nem Beispiel diskutieren.
Konvertierungen mache ich in meinem Adapter (milight-smart-light) auch. Die states für rgb, hue, satuaration, brightness, on, off werden immer synchron gehalten. Das sollte auch so sein, damit es z.B. in vis oder anderen UI nicht zu komischen Effekten kommt (zB. ausschalten vio on/off-State, aber brightness noch > 0).
-
@apollon77 sagte in [Diskussion] Objektdefinition Licht:
"Erstelle ein Licht"
Siehe Diskussion in Telegram, @AggroRalf und ich basteln gerade an sowas. Die erste Stufe wären da die Objektdefinitionen, d.h. "Erstelle ein Object für ein Licht".
Im Endeffekt sollte das in adapter-core wandern (oder zumindest darüber auch exportiert werden), dann steht es allen Adaptern (auch dem Devices-Adapter) zur Verfügung.@AlCalzone Naja am Ende ist ein "licht" aber ein Set von Objekten mit definierten Rollen. Daher komme ich gerade
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@AlCalzone Naja am Ende ist ein "licht" aber ein Set von Objekten mit definierten Rollen. Daher komme ich gerade
-
Also ich denke auch diese Konvertierung ist vielleicht eine Sache für den devices Adapter. So das jeder Entwickler wie bisher seinen eigenen klüngel machen kann und wenn man das ganze dann per iot oder einheitlich haben will über den devices deklarieren.
Ich denke da halt an so Themen wo iobroker quasi als Gateway genutzt wird. Wo man halt mit den eigentlichen Werten arbeiten muss weil diese benötigt werden z.b. oder wenn jemand etwas messen will und dadurch genauer arbeiten will geht halt mit 0-255 besser als mit 0-100% weiterhin ist es halt auch schwer neue Dev an so Richtlinien zu binden.
@ThaBam said in [Diskussion] Objektdefinition Licht:
Ich denke da halt an so Themen wo iobroker quasi als Gateway genutzt wird. Wo man halt mit den eigentlichen Werten arbeiten muss weil diese benötigt werden
Ja, genau an der Aufgabe arbeite ich im lovelace Adapter. Der muss alles was in ioBroker so möglich ist in die fest definierte Welt von HomeAssistant übersetzen (und zurück). :-)
Man muss sagen, dass der type-detector (bzw. devices-Adapter) da schon einen ziemlich guten Job macht. Aber klar, wenn man auf adapter-Ebene das Erstellen von solchen Devices vereinfacht, ist das eine super Idee. Dann basteln sich nicht alle Entwickler was selber und man erhält automatisch einen (quasi) Standard. Vieles wird ja auch aus Ahnungslosigkeit einfach mal irgendwie implementiert und passt dann nicht so richtig zum Rest. -
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.cmykIch finde die Diskussion angestoßen durch @Jey-Cee super und eine Vereinheitlichung / Abstraktion der zahlreichen "States" für den Anwender "sehr" wünschenswert.
Ich war vorher mit Openhab unterwegs. Dort hat man den "Komfort", dass man nur wenige Operationen auf "Geräten" ausführen kann. Lichter werden über einen "Color" Datentyp strukturiert und haben nur folgende Optionen:
- An / Aus
- Helligkeit über Dimmen in Prozent
- Setzen Farbe / Sättigung
Das ganze wird in jedem Adapter "gemapped", d.h. der Benutzer muss sich nicht jeweils selbst, um die Konvertierung kümmern.
Intern wird das ganze über ein "Objekt" gekappselt: Das HSBType-Objekt!
HSBType HSB string values consist of three comma-separated values for hue (0-360°), saturation (0-100%), and brightness (0-100%) respectively, e.g. 240,100,100 for "maximum" blue.Beispiel zum Setzen der Farbe , Helligkeit und Sättigung durch den Anwender:
new HSBType(new DecimalType(360), new PercentType(1), new PercentType(1))Im Hue-Adapter erfolgt dann das interne Mapping auf ct, hue, xy in diversen Klassen:
Man könnte ja die bestehenden Adapter mit ihren zahlreichen einzelnen Datenpunkten erhalten (auch aus Kompatibilität (und weil es immer wieder Sonderfälle geben mag) und anfangen eine "normalisierte" Welt daneben zu stellen in der es abstrakte Datentypen gibt.
Kleine Anmerkung zu diesem "Lichtproblem" und einem noch generalisierterem Ansatz: Die Normalisierung der Datentypen gilt in Openhab für alle Arten von Zuständen (ich habe öfter auch schon mit 0/1, true, false und On/off gekämpft in IOBroker. In Openhab heisst das Switch und ist klar definiert!)
-
-
Hat sich in der Richtung eigentlich schon was ergeben bzw, wurde von einigen Devs und Admins im Hintergrund was "weiter verfolgt" oder diskutiert?
Eine "einheitliche" Steuerung verschiedener Leuchtmittel wäre wirklich super. Im Moment braucht man ja für viele Leuchtmittel noch extra Skripte für umrechnen und um diese passend steuern zu können.Würde sowas auf jeden Fall befürworten.
-
Update - 03.11.2020
Ich hole mal diesen sehr wichtigen Thread wieder hoch :-)
Das Thema ist nach wie vor sehr aktuell, und die Implementierung in JS oder Adapter gestaltet sich aufgrund der unterschiedlichen Objektdefinitionen echt sehr mühsam.
Siehe z.B. JS-Vorlage - Light Control von @Pittini (Lichtsteuerung für Leuchtmittel unterschiedlicher Hersteller), er versucht da schon mal einiges abzufangen, Auszug:
LightGroups[0][0][2] = ["zigbee.0.ec1bbdfffe32de48.colortemp", 250, 454]; // Id für Farbtemperatur - min. Wert - max. Wert
Aber das muss natürlich der Anwender selbst konfigurieren, also erst mal versuchen herauszufinden, wie sich das bei jedem Hersteller/Adapter verhält, in diesem Beispiel die Farbtemperatur zwischen 250 und 454.Umsetzungsvorschlag - JS-Klasse/Modul bereitstellen
Mein Vorschlag ist, ein gekapseltes Modul (Klasse) zu schaffen, in das wir möglichst ALLE Adapter/Hersteller integrieren. Beispiel (Achtung, nur hier so runter getippt):
let ShellyLight = new LightConverter('shelly.0.SHRGBW2#xxxxxx#1'); // LightConverter wäre also die Klasse ShellyLight.bri = 50; // Setze Helligkeit auf 50% ShellyLight.bri = {val:60, delay: 10000}; // Setze Helligkeit nach 10s auf 60%Und das zuverlässig. D.h. Wenn ein Adapter wie 'deConz' 0-255 für Helligkeit erwartet und nicht 0-100, wird intern in der Klasse entsprechend einer "Matrix"/Konfiguration entsprechend konvertiert, damit ein Setzen von 50 bei deConz dann bewirkt, dass der deConz 127,5 in seinen Datenpunkt gesetzt wird, und nicht 50.
Ebenso den Einbau von bekannten "Szenen". Beispiel hue-Adapter, Szene "Entspannen" (wobei Philips Hue hier unterschiedlich je nach Beleuchtungs-Typ ist), Beispiel einer Philips-Birne, wenn "Entspannen"-Szene gesetzt ist.
Im Idealfall dann (ausgehend vom JS von oben):
ShellyLight.scene = 'Entspannen';Hier muss dann in der "Matrix"-Konfiguration des Moduls für "Shelly RGBW2-Controller" hinterlegt sein, wie die Szene "Entspannen" zu schalten ist.
Da sind sicherlich alle Anwender gefragt, Input für alle möglichen Adapter, Schaltungsmöglichkeiten, und Szenen zu liefern :-) Vieles ist denke ich auch schon im www verfügbar, etwa auch auch Github.
Wir bräuchten wohl einen ioBroker-Werkstudenten bzw. Studentin für eine Recherche :grin: :sunglasses:Mein Beitrag ist nicht ohne Eigennutz :grinning: Mein Smart Control Adapter schreit förmlich nach einer Lichtsteuerung, @Pittini hatte mich auch schon kontaktiert, weil er obiges JS derzeit entwickelt und angesprochen wurde wegen möglicher Synergien/Integration.
Nach Review von @Pittini 's Script wird für mich mehr als deutlich, dass wir da ein Modul brauchen, um das zu vereinfachen. Das kann ich keinem Anwender antun, sämtliche Lichter auf Grenzwerte min/max zu testen usw. als Konfiguration.
Und "Lichtszenen" ist auch ein großes Thema.Was meint ihr dazu?
Freue mich über weiteren Austausch sowie Vorschläge :) -
-
@saschag Aktuell ist ein eigener Adapter "LightControl" in der Entwicklung. Dieser läuft jedoch autark von SmartControl.
@schmakus Das ist ja aber eher ein "Logikadapter" oder?
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@apollon77 Ja genau. Der Adapter "versucht" jedoch, eine Standardisierung rein zu bringen. Um wieder auf die Diskussion einzugehen, wäre jedoch ein gewisser Standard bei der Adapterentwicklung wünschenswert. Das betrifft die min/max Werte, Benennungen und Umrechnungen.
Wären demnach die Rollen und Einheiten einheitlich, würden sich User wesentlich einfacher tun.Klassisches Beispiel ist die Farbtemperatur. Hier gibt es in der Adapterwelt viele unterschiede. Sinnvoller wäre alles in K (2200 - 6500) anzugeben. Ebenso die Helligkeit. Die geht manchmal von 0-255 oder 0-100. Auch hier wären m.M. 0-100% am sinnvollsten.
Bei den Rollen bin ich auch immer etwas verwirrt. level.color.rgb Dies könnte einmal [0,0,0] oder #FFFFFF sein. Für letzteres wäre level.color.hex sinnvoller.
Dev of LightControl Adapter, Contributor of HUE and DoorBird Adapter
-
@apollon77 Ja genau. Der Adapter "versucht" jedoch, eine Standardisierung rein zu bringen. Um wieder auf die Diskussion einzugehen, wäre jedoch ein gewisser Standard bei der Adapterentwicklung wünschenswert. Das betrifft die min/max Werte, Benennungen und Umrechnungen.
Wären demnach die Rollen und Einheiten einheitlich, würden sich User wesentlich einfacher tun.Klassisches Beispiel ist die Farbtemperatur. Hier gibt es in der Adapterwelt viele unterschiede. Sinnvoller wäre alles in K (2200 - 6500) anzugeben. Ebenso die Helligkeit. Die geht manchmal von 0-255 oder 0-100. Auch hier wären m.M. 0-100% am sinnvollsten.
Bei den Rollen bin ich auch immer etwas verwirrt. level.color.rgb Dies könnte einmal [0,0,0] oder #FFFFFF sein. Für letzteres wäre level.color.hex sinnvoller.
@schmakus sagte in [Diskussion] Objektdefinition Licht:
@apollon77 Ja genau. Der Adapter "versucht" jedoch, eine Standardisierung rein zu bringen. Um wieder auf die Diskussion einzugehen, wäre jedoch ein gewisser Standard bei der Adapterentwicklung wünschenswert. Das betrifft die min/max Werte, Benennungen und Umrechnungen.
Wären demnach die Rollen und Einheiten einheitlich, würden sich User wesentlich einfacher tun.Klassisches Beispiel ist die Farbtemperatur. Hier gibt es in der Adapterwelt viele unterschiede. Sinnvoller wäre alles in K (2200 - 6500) anzugeben. Ebenso die Helligkeit. Die geht manchmal von 0-255 oder 0-100. Auch hier wären m.M. 0-100% am sinnvollsten.
Bei den Rollen bin ich auch immer etwas verwirrt. level.color.rgb Dies könnte einmal [0,0,0] oder #FFFFFF sein. Für letzteres wäre level.color.hex sinnvoller.
Wäre es ? Was ist mit den Lampen die als hex #ffaabbcc erwarten ?
Das mit der Farbtemperatur sehe ich generell anders.
In vielen Bereichen ist die Farbtemperatur nicht in Kelvin sondern in mired Standard. Hier auf den Kelvin Standard zu Setzen bedeutet das entsprechend oft umgerechnet werden muss- in einigen Fällen sogar doppelt.
Auch der Bereich 2200 - 6500 ist nicht gut gewählt. Nicht alle Hardware kann diesen Bereich abdecken. Da wird es dann Probleme geben wenn in einer Szene die gewünschte Farbtemperatur nur von 50% der Lampen erreicht wird. Wobei da die Umrechnung noch relativ einfach ist. Das müsste der Adapter für alle Lampen übernehmen.Bei Farbe sieht die Sache schon schwerer aus:
- Umrechnung zwischen den verschiedenen Farbmodellen funktionieren nur dann “sauber” wenn die Hardwareparameter bekannt sind. Das macht eine ioBroker-zeitig vorgegebene Umrechnung komplex.
- RGB als Standard hat den Nachteil das die Helligkeit da mit drin steht (rgb 880000 ist ein reines rot, ff0000 ist der gleiche Farbton in anderer helligkeit)
- HSV wird nur von einem Teil der Lampen akzeptiert
- xy ist an anderer Stelle im Einsatz.
Insbesondere wenn Leuchtmittel unterschiedlicher Hersteller mit Farbe benutzt werden gibt es oft interessante Effekte.
- die gleichen RGB (HSV / xy) Werte bei unterschiedlichen Leuchtmittel geben verschiedene Farben.
- viele Lampen können nur einen Teil des RGB Farbraums abbilden - und oft nicht den gleichen.
- viele Lampen haben “Löcher” im Farbraum, sprich es gibt Farbtöne in der Mitte die nicht effektiv abgebildet werden können.
- Umrechnung Farbtemperatur zu Farbwert passt fast nie.
-
Ich hatte es im Telegram schonmnal geschrieben: Ich sehe es auch sinnvoll für Visus und "Alexa&Co" hier ws einheitliches zu haben (falls die alle was einheitlichen haben). und ich persönlich hätte die Idee (not proofed) das Aliases mit den Umrechnung optionen vllt ein Weg sein könnten. Aber ja auch da gibt es aktuell das Limit das ein Alias Wert nur mit Werten EINES gegenobjektes arbeiten können - alos wenn ein Gerät Daten auf zwei Datenpunkten hat, aber am ENde einer rauskommt gehts wieder schieff.
Also ja... wir sind noch nicht da wo wir hin müssen - wäre wieder ein "da muss sich mal ein Team finden die was ausarbeiten und vorstellen und diskutieren" :-)
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
Ich hatte es im Telegram schonmnal geschrieben: Ich sehe es auch sinnvoll für Visus und "Alexa&Co" hier ws einheitliches zu haben (falls die alle was einheitlichen haben). und ich persönlich hätte die Idee (not proofed) das Aliases mit den Umrechnung optionen vllt ein Weg sein könnten. Aber ja auch da gibt es aktuell das Limit das ein Alias Wert nur mit Werten EINES gegenobjektes arbeiten können - alos wenn ein Gerät Daten auf zwei Datenpunkten hat, aber am ENde einer rauskommt gehts wieder schieff.
Also ja... wir sind noch nicht da wo wir hin müssen - wäre wieder ein "da muss sich mal ein Team finden die was ausarbeiten und vorstellen und diskutieren" :-)
@apollon77
bei Alias (und auch Lokig/Visu Adaptern) kommt man an die Grenze, wenn mehrere States im Spiel sind, z.B. RGB in 3 States einzeln oder HSV in 3 States einzeln. Für eine Umrechnung zwischen den Farbräumen braucht man in dem Fall immer alle drei States. Da muss man als externer Adapter immer irgendwie fummeln (entweder wartet man Zeit X oder man rechnet bei jedem Statechange um, muss dann aber aufpassen, dass das nicht wieder zurück ans Gerät läuft usw.) um zu entscheiden, wann die drei States jetzt im Endzustand sind.Insofern wäre eine Library, die direkt im Geräte-Adapter die Umrechnung in einen ioBroker Standard (oder alles, mir egal ;-) ) durchführt schon nett. Zumindest für das Thema Farbe.
Das mit dem Team machen wir dann, wenn die dev-doku mal steht. versteckt sich
-
@apollon77
bei Alias (und auch Lokig/Visu Adaptern) kommt man an die Grenze, wenn mehrere States im Spiel sind, z.B. RGB in 3 States einzeln oder HSV in 3 States einzeln. Für eine Umrechnung zwischen den Farbräumen braucht man in dem Fall immer alle drei States. Da muss man als externer Adapter immer irgendwie fummeln (entweder wartet man Zeit X oder man rechnet bei jedem Statechange um, muss dann aber aufpassen, dass das nicht wieder zurück ans Gerät läuft usw.) um zu entscheiden, wann die drei States jetzt im Endzustand sind.Insofern wäre eine Library, die direkt im Geräte-Adapter die Umrechnung in einen ioBroker Standard (oder alles, mir egal ;-) ) durchführt schon nett. Zumindest für das Thema Farbe.
Das mit dem Team machen wir dann, wenn die dev-doku mal steht. versteckt sich
@garfonso sagte in [Diskussion] Objektdefinition Licht:
Insofern wäre eine Library, die direkt im Geräte-Adapter die Umrechnung in einen ioBroker Standard (oder alles, mir egal ) durchführt schon nett.
Ich verwende in meinem LightControl Skript das hier (abgespeckt und nicht als npm Modul), rechnet alles in alles um: https://github.com/Qix-/color-convert
Support us
311
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge