[Diskussion] Objektdefinition Licht
-
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.
-
im Prinzip gibt es ja auch garnicht so viele verschiedene Typen,
es sind ja nur:
-Standard- Standard mit dimm
- Standard mit dimm und ct
- Rgb
- Rgbw
- Rgbww
und das dann natürlich mit zahlreichen Sonderfunktionen
-
@Meistertr sagte in [Diskussion] Objektdefinition Licht:
im Prinzip gibt es ja auch garnicht so viele verschiedene Typen,
es sind ja nur:
-Standard- Standard mit dimm
- Standard mit dimm und ct
- Rgb
- Rgbw
- Rgbww
und das dann natürlich mit zahlreichen Sonderfunktionen
Milight hat noch
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). -
@Meistertr sagte in [Diskussion] Objektdefinition Licht:
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?
Dem kann ich so nicht zustimmen. Sofern eine Hardware nicht selber eine saubere Umrechnung von RGB auf HSV und CT macht, und dabei die Wellenlängen der einzelnen LED's berücksichtigt bedeutet ein Entfernen von HSV Datenpunkten das Lampen unterschiedlicher Hersteller sich nicht ohne weiteres auf die gleiche Farbe einstellen lassen.
Das ist aktuell schon so, da nicht jeder Hersteller da sauber arbeitet, aber ich denke wir sollten im ioBroker keine unnötigen Grenzen einfügen die dieses Problem verschärfen.
-
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? -
@Jey-Cee Man kann das aber auf Adaperebene implementieren.
Adapter merkt selbst, was da (bevor auf 0 gesetzt wurde) stand und dann bei "ein" wieder gespeicherten Wert setzten.
Habe sogar irgendwo so implementiert -
Участник @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.
-
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#L101Dazu 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.
