[Frage] [CV 11.2] CV für LED mit 4 Farben

[Auweia]

Super, da freue ich mich aufs testen!

[StefanW]

Hallo Chris,

Von den verschiedenen Möglichkeiten ist eigentlich theoretisch nur xyY sinnvoll - ich befürchte aber, dass das quasi nicht eingesetzt wird. Außer in einem extrem professionellen Umfeld vielleicht.

Wir nehmen gerne xyY am Timberwolf Server an und rechnen das für das jeweilige Zielsystem um.

Die saubere Umsetzung für MQTT kommt dann im zweiten Schritt, da die CV zwar JSON mit mehreren Werten lesen kann, aber beim Schreiben aktuell auf einen Wert limitiert ist.

Mir wäre es lieber, wenn wir die Farbe in EINEM Wert bekommen und es damit auch nur EIN Objekt (eines entsprechenden Objekttyps ist).

Weil mehrere Werte in einem JSON bedeutet auch mehrere Objekte die dann auch mehrmals verknüpft werden müssen.

Wir können hier gerne ein Datenformat, gerne auch mit Kennung, vereinbaren.

z.B:

"xyY-0,4358-0,13589-0,80365"

würde dann stehen für

x=0,4358
y=0,13589
Y=0,80365

Das hätte den Vorteil, dass es als ein Wert kommt und als EIN Objekt mit EINEM (kombinierten) Wert intern weitergeleitet und verarbeitet wird.

Weil sonst hat man drei Objekte die hintereinander eintreffen und das führt dann zu drei Weiterleitungen und drei Trigger und so weiter, die ganze Kette wird damit dreifach belastet. Das ist jetzt für eine Wahl an einem Farbrad unerheblich, aber womöglich gibt es später Sequenzer und da würden wir kombinierte Formate bevorzugen, so wie das aich KNX richtigerweise macht.

lg

Stefan

[Chris M.]

Die saubere Umsetzung für MQTT kommt dann im zweiten Schritt, da die CV zwar JSON mit mehreren Werten lesen kann, aber beim Schreiben aktuell auf einen Wert limitiert ist.

Mir wäre es lieber, wenn wir die Farbe in EINEM Wert bekommen und es damit auch nur EIN Objekt (eines entsprechenden Objekttyps ist).

Weil mehrere Werte in einem JSON bedeutet auch mehrere Objekte die dann auch mehrmals verknüpft werden müssen.

Wir können hier gerne ein Datenformat, gerne auch mit Kennung, vereinbaren.

Bei KNX ist ja alles in einem Wert. Bei MQTT gibt's sicher viele Optionen. Alles in einen Wert ist grundsätzlich natürlich auch implementierber und auch für die Darstellung in der CV besser als wenn alles hintereinander kommt.

Wichtig wäre da aber zu wissen was denn "üblich" ist. Genau habe ich mich damit noch nicht auseinander gesetzt, das erste Stöbern hatte aber JSON gezeigt, z.B. https://www.home-assistant.io/integrati ... son-schema
Am Schluss soll das ja auch kompatibel zu HUE, ... sein.

[StefanW]

Hallo Chris,

Wichtig wäre da aber zu wissen was denn "üblich" ist.

Nach unserer Recherche ist nichts "üblich". Wir haben kein Datenformat gefunden, das alle benutzen.

Genau habe ich mich damit noch nicht auseinander gesetzt, das erste Stöbern hatte aber JSON gezeigt, z.B. https://www.home-assistant.io/integrati ... son-schema

Json ist nicht der Punkt, sondern wie die eigentlichen Daten aussehen, nicht in welchem "Container" diese verpackt sind.

Für uns - im Timberwolf Server - würde ein nackter String ausreichend sein, der den verbundenen Wert als eine Zeichenkette enthält. Eine solche Zeichenkette habe ich oben vorgeschlagen.

Wenn Du diesen einen String noch in ein Json einpacken willst, dann ist es eben ein String in einem String, aber damit muss der Nutzer die Selektion dafür auch angeben beim Verknüpfen. Wir würden den einen String unter einem vom Nutzer in der CV zugeordnetem TOPIC bevorzugen, weil es für den Nutzer einfacher ist.

Gerne, wie oben vorgeschlagen mit der Kennung im String mit drin, weil dann weiß der Nutzer eher, welches Objektformat er auswählen muss.

Am Schluss soll das ja auch kompatibel zu HUE, ... sein.

HUE kann drei Farbmodi

1. Farbton (hue [0..65535]), Sättigung (sat [0..254]) und Helligkeit (bri [0..254])
2. xy mit Helligkeit (bri [0..254])
3. Farbtemperatur (ct [154...500]) für tunable white

Am Ende wollen die Nutzer des Timberwolf Servers diese Farb- und Intensitätsinformation für die Lichtsteuerung mit so ziemlich allem verbinden wollen, was es so gibt. Es wird dann die Aufgabe der Logik (bzw. der automatischen Konvertierung) sein, das für das Zielsystem passend umzurechnen. Wir sind noch dabei, uns einen Überblick zu verschaffen, wie die jeweiligen Datenformate aussehen.


lg

Stefan