[Diskussion] Objektdefinition Licht
-
Du sprichst mir aus der Seele da denke ich auch schon seit Monaten drüber nach, da der eine visu Adapter die Lampe erkennt und der andere nicht. Eine feste Basis an den sich alles halten MUSS ist da der einzig richtige Weg. Meine Idee wäre auch einen neuen Klasse einzuführen. Zum Beispiel states, Objekte und Geräte (definierte Gruppe aus states) wo dann nur klassifizierte Geräte enthalten sind wie Lampen Sauger Lüfter Rollladen Bewegunssensor Tür . Um ein Gerät zu erstellen müsste es dann muss daten wie bei Lampe an aus / an aus dimm haben und optional parameter wie Signalstärke oder Akku.
Ebenso muss festgelegt werden ob dimmbarr Lampen an/aus haben muss oder nur dim 0 für aus.
-
Die Einhaltung kann nur über das Stable repo durchgesetzt werden. Dabei muss dann auch entsprechend Unterstützt werden und es darf nicht zu Kompliziert sein.
@Meistertr sagte in [Diskussion] Objektdefinition Licht:
Meine Idee wäre auch einen neuen Klasse einzuführen. Zum Beispiel states, Objekte und Geräte (definierte Gruppe aus states) wo dann nur klassifizierte Geräte enthalten sind wie Lampen Sauger Lüfter Rollladen Bewegunssensor Tür .
Da bist du jetzt schon einen Schritt weiter. Ziel hier ist es die Basis zu bereinigen.
Das was du beschreibst wird der Devices Adapter übernehmen, der ist schon in Arbeit.@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.
-
@Jey-Cee sagte in [Diskussion] Objektdefinition Licht:
Das was du beschreibst wird der Devices Adapter übernehmen, der ist schon in Arbeit.
Hallo, meinst du diesen?
-
@sigi234 ja, aber wie gesagt ist noch in Arbeit.
-
Da ich aktuell sehr viel mit lovelace arbeite, ist die von Euch beschriebene Problematik mir auch sehr aufgefallen. Aktuell löse ich diese Probleme mit meinem Adapter linkeddevices.
Was mir jetzt nicht so ganz klar ist, was ist denn der Unterschied zum devices adapter?Ich habe noch die Idee für den linkeddevices adpater, dort dem User die möglichkeit zu geben, z.B. ein Licht anzulegen. Dazu muss er dann vordefinierte Datenpunkte erstellen, so dass am Ende das von Euch beschriebene Gerät mit den entsprechenden Datenpunkten angelegt wird, inkl. aller notwendigen Attribute wie z.B. min / max Werte. Ich denke man müsste ja nicht noch etwas neues erfinden sondern könnte meinen Adapter für diese Zwecke entsprechend anpassen?
-
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).
