[Diskussion] Objektdefinition Licht

[AlCalzone]

@Garfonso Wir sind noch eine Ebene tiefer derzeit. Sobald es was gibt, können wir das gerne an nem Beispiel diskutieren.

[Jey Cee]

@ThaBam sagte in [Diskussion] Objektdefinition Licht:

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 bin immer noch der Meinung das so viel wie möglich davon auf Adapter ebene Umgesetzt werden sollte, gerade die Objektdefinitionen sollten möglichst einheitlich sein. Sonst ist der Aufwand enorm das alles auf einen Standard zu vereinheitlichen. Umrechnungen sind da nochmal was anderes.

[carsten04]

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]

@AlCalzone Naja am Ende ist ein "licht" aber ein Set von Objekten mit definierten Rollen. Daher komme ich gerade

[AlCalzone]

@apollon77 Ich weiß

[Garfonso]

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

[Tirador]

Ich 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:

Code aus:
https://github.com/openhab/openhab-addons/blob/main/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/LightStateConverter.java

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!)

[el_malto]

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.

[Saschag]

@mic

Gibt es schon Fortschritte/Gedanken @Pittini -Skript (LightControl) und dein Adapter "zusammen" zu führen?

[Schmakus]

@saschag Aktuell ist ein eigener Adapter "LightControl" in der Entwicklung. Dieser läuft jedoch autark von SmartControl.

[apollon77]

@schmakus Das ist ja aber eher ein "Logikadapter" oder?

[Schmakus]

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

[Asgothian]

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

[apollon77]

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"

[Garfonso]

@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

[Pittini]

@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