UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[AlCalzone]

Ich habe nicht alles gelesen, aber grundsätzlich ein paar Gedanken.
Hue/Sat/Bri ist für Menschen intuitiver als RGB und sollte wenn möglich bevorzugt werden. Hex (0-FF) ist zwar wiederum ein web standard, aber auch wieder unintuitiver als 0-255.

0-254 für Helligkeit ist durch die Protokolle vorgegeben (zwave und zigbee), gerade bei zwave wird tatsächlich aber nur 0-99 genutzt.
Hier macht ein mapping Sinn, allerdings sollte dann vernünftig gerundet werden.
Beim runden (zb wenn alles auf 0-100% soll) muss man wiederum aufpassen, dass die Genauigkeit nicht leidet. Es gibt sicher Anwendungen wo mehr als 8 bit für Farben nötig und sinnvoll sind.

Gegenfrage: ist es ggf sinnvoll die Umrechnung zwischen % und absolut dem controller zu überlassen? Sofern die datenpunkte sauber mit min (=0%) und max (=100%) versehen sind, sollte das unkompliziert gehen.

Bei der vorgabe eines schemas sollte wiederum beachtet werden dass es immer Spezialfälle geben wird, die zb Hardwarebedingt nicht 100% passen werden. Ggf sollte man hierfür eine konvention vorsehen, zb einen raw channel o.ä.

[cash]

@Jey-Cee Grundsätzlich kann ich es verstehen und halte es auch für sinnvoll. Wichtig wäre halt das ein einheitliche Benennung nicht irgendwelche Sachen einschränkt die zwar von Hue vorgesehen sind aber eben nicht von anderen Anbietern. Ich bin aber nicht so tief in der Materie um mir da ein Urteil zu erlauben.

Als Anwender erwarte ich es nicht. Guck Dir die Autobranche an. Überall ist es Allradantrieb nur heißt es bei Audi Quadro, bei Mercedes 4matic und bei BMW noch einmal anders.
D er. Kombi heißt Avant oder. T-Modell. Für jeden Quatsch (im positiven Sinne, da ich all die Helferein sehr schätze) hat Mercedes eigene schöne Namen.

Einheitlich ist nicht. Ich fände es sehr komisch wenn die Datenpunkte z. B. bei Homematic anders lauten würden als ich Sie selber per Script auf der ccu abfragen kann und dort benutzen muss. Eigentlich sollte das dann auch für alle anderen Adapter gelten.

Evtl sollte es also einmal die Rohdaten geben also org das wie der Hersteller die Daten liefert und einmal einheitlich?

Ja natürlich ist das ein Problem für VIS. Die Frage ist halt wo das zu lösen ist.

Ich nutze VIS nur sehr eingeschränkt und schalte eigentlich nicht damit, da bei mir alles automatisch passiert.

[Zefau]

Wurde auf Basis dieser Diskussion eigl. bereits irgendein Adapter angepasst?

[Mic]

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

[Mic]

Nachtrag

Natürlich wäre es deutlich besser, wenn alle Adapter dieselben Objektdefinitionen hätten, aber ich denke, das dauert Jahre und wir werden immer Ausnahmen haben.
Aber das kann auch zur Endlos-Diskussion führen, und letztendlich kann ja hier jeder Adapter-Entwickler frei entscheiden.

Daher die Idee eines Moduls / einer Klasse, die auf Basis eines definierten "Standards" viele bzw. möglichst alle Adapter vereint.

---

Alternativ / bzw. als weitere Idee:
Dieses Modul geräte-basierend und Adapter-übergreifend zu gestalten, und somit auch nutzbar für die Adapter selbst. Also z.B. der Entwickler vom hue-Adapter nutzt diese Klasse, und lässt über sie quasi fast selbständig die Datenpunkte usw. generieren, in dem er die verfügbaren Infos, die die Geräte als Objekte liefern, in die Klasse reinkippt.

[Garfonso]

@Mic hast du dir mal den type-detector angeguckt? Der sagt dir zumindest schonmal, mit welchem Datenpunkt du ein "Licht" steuern kannst bzw. was es kann (ok, es sind dann verschiedene Geräte).

Das min/max im Datenpunkt steht, finde ich in Ordnung. Von [0-255] auf [0-100] umzurechnen ist inline möglich... auch auf [0-100] auf [min-max], die man aus dem Objekt ausliest.

Aber klar, das könnte man nochmal kapseln, wenn man möchte (also type-detector + min/max Umrechnung, ggf noch Einheiten für Farbtemperatur und verschiedene Farbwerte -> im Grunde hab ich das in lovelace auch alles implementiert).

Das mit den Szenen halte ich für zu speziell, als das es in einer generellen Lichtsteuerung etwas zu suchen hat. Außerdem würde ich die Szenen eher direkt über ioBroker Geräteübergreifend umsetzen wollen als in jedem Adapter einzeln. Also im ioBroker irgendwo "entspannen" einschalten und dann werden halt die Lichter so gesetzt, wie ich die da gerne hätte (also volle pulle magenta :-) ). Da brauche ich doch keinen Support für die Szenen vom Hersteller.

[apollon77]

Vllt macht es ja doch sinn das ganze Thema mit der Devices Idee generell zu verbinden?

Am Ende bräuchte man eine "Erstelle ein Licht" Klasse die man instanziiert und einen channel Namen mitgibt. Und man gibt die Lampenfeatures mit (also welcher lampentyp, welche features und sowas). Am Ende stellt die Klasse dann ein Interface zur verfügung um die relevanten Werte zu setzen und die Klasse erzeugt die nötigen Objekte und erlaubt "onChange" trigger zu definieren.

Das kann dann sowohl der Devices Adapter wie auch andere Adapter nutzen.

Und die Klasse kann dann auch "kompatibiltätsschichten" zb für den iot Adapter anbieten ... Alexa kann zb nur RGB und HS(V), viele UIs haben es auch mit RGB viel einfacher als mit anderen typen. Also könnte man auch einen rgb state bei einer HSV Lampe anbieten und dann halt umrechnen - ja unter akzeptanz von Unterschieden, aber am Ende ist das denke nicht das mega Thema ...Einfachheit der Bedienung ist für 99% der User das A und O in meinen Augen

[AlCalzone]

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

[Garfonso]

@AlCalzone
Wo bastelt ihr denn daran? Braucht ihr noch code für die Farbraum-Konvertierung? Oder andere Unterstützung / Input?

[Pittini]

@Garfonso sagte in [Diskussion] Objektdefinition Licht:

@AlCalzone
Wo bastelt ihr denn daran? Braucht ihr noch code für die Farbraum-Konvertierung? Oder andere Unterstützung / Input?

Falls code für die Farbkonvertierung benötigt wird, guggt mal da, das verwend ich in meinem Skript, evtl. ja auch hier brauchbar:
https://github.com/Qix-/color-convert

[TheBam]

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.

[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?