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

[Bluefox]

Участник @s-bormann написал в [Diskussion] Objektdefinition Licht:

Hi, ein Adapter wie linkedDevices oder Devices ( @Scrounger: Habe mich im Übrigen auch gefragt, ob das nicht genau auf das gleiche hinausläuft?)

Ist tatsächlich das gleiche. Nur:

• "linkeddevices" hat die Logik in einem Adapter drin
• "devices" hat die logik in js-controller 2.x über aliases. (Da wird es nicht möglich ein/aus Logik zu implementieren).

BTW: in devices kann man die Geräte auch mit linkeddevices Adapter erzeugen.

Ich bin der Meinung, dass die Adapter die ein/aus Logik mitbringen müssen, falls es geht. Weil z.B. bei mqtt, modbus, opc, snpm, s7, .. wird es nicht möglich sein.

[Bluefox]

Also. Die Liste mit wie ein Gerät (und welche Geräte) aussehen muss, gibt es.
Allerdings, das ist aktuell nicht in Form von einer Liste, sondern wie Regex Rules.

Man muss nur diese Tabelle lesen können:
https://github.com/ioBroker/ioBroker.type-detector/blob/master/index.js#L101

Dazu es gibt roles für states und für channels/devices. Die sollte man auch nicht vermischen. Allerdings, die channel roles werden aktuell nirgendwo verwendet.

[s.bormann]

@Jey-Cee sagte in [Diskussion] Objektdefinition Licht:

RGB + W (entweder rgb oder w, aber nicht beides zusammen) - und das RGB darf nur vollgesättigte Farben enthalten (nur die Farben, die im hue Farbkreis enthalten sind).

RGBW lässt sich halt sehr Flexibel mit den getrennten werten r, g, b, w darstellen, deshalb ist mein Vorschlag ja auf den verketetten rgb(w) zu verzichten. Was das jetzt für auswirkungen auf vollgesättigte Farben hat ist mir nicht klar.

Außer der bisherigen Diskussion geht für mich hervor das es Sinnvoll ist RGBW und HSL zur verfügung zu stellen.
HSL ist für mich Komplex und RGBW eher einfach. Damit sollten sich doch die meissten fälle Abdecken lassen?

Hi,
nur noch mal der Vollständigkeit halber die Erklärung zu Milight: In der Version 5 beherrschen die Lampen nur vollgesättigte Farben, d.h. man KANN gar nicht alle RGB-Farben darstellen. Z.B. #FFFF00 geht, aber #FFFFBB geht nicht, weil nicht voll gesättigt. Einfach gesagt, es dürfen maximal zwei der drei Farben R, G und B gleichzeitig aktiv sein. Warum es diese Einschränkung gibt, ist mir nicht klar - ich vermute aber mal, dass das Protokoll technisch lediglich einen HUE-Wert und keine Sättigung überträgt.

LG

[s.bormann]

@Jey-Cee sagte in [Diskussion] Objektdefinition Licht:

RGB + W (entweder rgb oder w, aber nicht beides zusammen) - und das RGB darf nur vollgesättigte Farben enthalten (nur die Farben, die im hue Farbkreis enthalten sind).

RGBW lässt sich halt sehr Flexibel mit den getrennten werten r, g, b, w darstellen, deshalb ist mein Vorschlag ja auf den verketetten rgb(w) zu verzichten. Was das jetzt für auswirkungen auf vollgesättigte Farben hat ist mir nicht klar.

Außer der bisherigen Diskussion geht für mich hervor das es Sinnvoll ist RGBW und HSL zur verfügung zu stellen.
HSL ist für mich Komplex und RGBW eher einfach. Damit sollten sich doch die meissten fälle Abdecken lassen?

Noch mal Hi,

zum Thema HSL:
Ich finde HSB (oder HSV, das ist das Gleiche) deutlich sinnvoller als Licht-Farbraum.

Bei Bildschirmfarben mag das anders sein, da geht HSL gut, aber bei Licht würde der "L"-Regler für volle Farben immer bei 50% stehen müssen. In die eine Richtung wirds schwarz (das wäre aber ja aber schon bei den meisten Lampen über den LEVEL-Datenpunkt abgedeckt = Dimmer!) und in die andere Richtung wirds weiß (was wiederum eine Überschneidung mit dem Sättigungs-Regler bedeutet).

Bei HSB oder HSV hat man Hue, Saturation und Brightness = Value = Dimmer oder LEVEL, was ziemlich genau der Funktionsart der meisten RGB-Lampen entsprechen dürfte.

LG!

[Zefau]

Auf Basis des Issues von @Jey-Cee im hue-extended Adapter (siehe https://github.com/Zefau/ioBroker.hue-extended/issues/1#issue-492034971), ergeben sich folgenden Änderungen.

1. Umbenennung von bri in brightness Entfernen des Datenpunkts bri (brightness) (zur Steuerung verbleibt dann level)
2. Umbenennung von sat in saturation
3. Entfernen des Datenpunkts hue (Wert von 0 bis 65535) und Umbenennung von hue_degrees (Wert von 0° bis 360°) in hue
4. Alle Datenpunkte für die Farbräume entfernen (_rgb, _hsv, _cmyk und xyz)
5. Einzelne Datenpunkte des RGB-Farbraums aufnehmen (red, green und blue )
6. Umbenennen von _hex in hex

https://forum.iobroker.net/topic/24207/neuer-adapter-hue-extended/239

[Jey Cee]

@Dr-Bakterius sagte in [Neuer Adapter] hue-extended:

Für mich würden diese Änderungen passen weil ich diese Datenpunkte nicht verwende. Aber falls jemand die Datenpunkte in Skripten eingebaut hat, bedeutet das Arbeit.

@cash sagte in [Neuer Adapter] hue-extended:

Gegen die Umbenennung spricht nichts aber mir persönlich scheint es vollkommen egal ob ein Punkt nun sat oder saturation heißt. Grundsätzlich finde ich es natürlich sinnvoll nutzlose oder nicht benötigte Datenpunkte zu löschen.

@Spegeli sagte in [Neuer Adapter] hue-extended:

Bitte keine Datenpunkte Entfernen.
Das war für mich überhaupt erst einer Gründe auf diesen Adapter Umzusteigen, da ich hier so ziemlich jeden Datenpunkte habe den es gibt.
Lieber haben und nicht brauchen, als brauchen und nicht haben.
Einen (spürbaren) performance boost du die paar wegfallenden Datenpunkte hätte man doch ohnehin nicht.

@Jey-Cee sagte in [Neuer Adapter] hue-extended:

Hier mal der Hintergrund für die von mir angestoßene Diskussion bzw. den Vorstoß.
Bis jetzt ist es so das jeder macht was für ihn gerade gut passt, aber das macht die Verwendung oft unnötig Kompliziert. Ein gutes Beispiel sind die Color Picker, da bedarfs x Unterschiedlicher in VIS um alles ab zu decken. Jetzt gibt es aber auch andere Visualisierungen und daneben noch die Smarten Assistenten, die alle damit Klar kommen sollen.
Um das zu Gewährleisten muss jeder Entwickler der Visualisierung macht für jeden fall etwas bereit stellen.
Ganz davon abgesehen das man sich als Anwender immer in jeden Adapter neu einfinden muss wenn man eine Lampe steuern will.
@cash sagte in [Neuer Adapter] hue-extended:

mir persönlich scheint es vollkommen egal ob ein Punkt nun sat oder saturation heißt

Es ist auch vollkommen egal wie der Datenpunkt heißt, nur kann man als Anwender doch erwarten das ein Datenpunkt der das selbe tut auch in allen Adaptern gleich heisst oder nicht?
Ich erwarte das sogar als Anwender.
@Spegeli sagte in [Neuer Adapter] hue-extended:

Das war für mich überhaupt erst einer Gründe auf diesen Adapter Umzusteigen, da ich hier so ziemlich jeden Datenpunkte habe den es gibt.

Es soll nicht die Funktionalität eingeschränkt werden, lediglich eine Einheitliche Basis geschaffen werden zur Steuerung. Unter dem Gesichtspunkt das nicht jede Lampe/Licht das selbe Farbsystem verwendet soll der Adapter dann im Hintergrund die Umsetzung auf die jeweiligen Farbsysteme vornehmen. Was ohnehin schon in manchen Adaptern passiert.

[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).