ElabNET Technik Forum

Ich habe die letzten Tage Kontakt zu Jan N. Klug (@JNK77 )bekommen, der im OpenHAB Umfeld einige Bindings geschrieben/weiterentwickelt hatte, die jedoch leider so nicht im offiziellen Repo enthalten sind. Besonders interessant sind für mich seine Erweiterungen des KNX-Bindings. Die letzten Tage haben wir rund um RGBW und HSV getestet und Dank seiner Erweiterung kann OH auf dem KNX nun:

RGBW via DPT 251.600
HSV via DPT 232.60000 (kein Schreibfehler!)
DPT 242.600

DPT 232.60000 ist in dem Fall kein offizieller DPT der KNX Assoc. Wir haben diesen Subtype gewählt, weil >=60000 als Hersteller spezifischer Bereich definiert ist und bspw. MDT da durchaus einen eigenen Weg geht, HSV via DPT 232.600 zu übertragen. Denn DPT 232.600 ist offiziell eigentlich als RGB definiert und nicht als HSV, weshalb OpenHAB dann auch RGB Werte auf den Bus schreibt und kein HSV. Was dann aus dem Dimmer herauskommt ist dementsprechend alles andere als gewollt. Entweder muss man dann mit RGB arbeiten und büßt den Weißkanal ein, oder die Komponenten H, S und V einzeln übertragen, was dann bei den Statusrückmeldungen wieder gewissen Ärger bereitet.

Die Thing-Konfiguration für HSV sollte in etwa so aussehen: Den Position-Channel kann man weglassen, wird in dem Fall nicht gebraucht.

Die Bindings werden als Artefact in OpenHAB eingebunden. Bei mir funktioniert es, indem ich die *.kar Dateien einfach in den Addon-Folder kopiere. Dann werden sie automatisch installiert und auch wieder beim löschen deinstalliert. Ansonsten auf die OpenHAB/Karaf Konsole verbinden und wie unten beschrieben installieren.

Anleitung: (Vorlage von Jan)
Für alle Versionen:
Original Binding deinstallieren (über UI oder addons.cfg, jenachdem wie es installiert wurde). KEINE Things löschen. Die Konfiguration ist vollständig kompatibel.

Für openHAB 3.1/3.2:
https://repo1.maven.org/maven2/org/smar ... -3.2.7.kar
in den addons-Folder und feature:install smarthomej-binding-knx.

Für openHAB 3.0:
https://repo1.maven.org/maven2/org/smar ... -3.1.7.jar
https://repo1.maven.org/maven2/org/smar ... -3.1.7.jar
in den addons-Folder. Falls es dann nicht geht, fehlt das serial-transport Bundle. Also noch feature:install openhab-transport-serial.

Doku zu seinem Fork findet sich hier:
https://docs.smarthomej.org/3.2.7/org.s ... g.knx.html

An dieser Stelle einen großen Dank und ein herzliches Willkommen @JNK77 bei uns im Forum!

Hey Jan, willkommen hier bei uns.


Yeah,

sehr schön.

Das wollen wir im TWS auch. Wir arbeiten derzeit an Planungen, die gesamte Farbsteuerung auch im TWS zu implementieren und in den Logikmodulen abzubilden (das ist dann im Vorgriff auf den angedachten Szenenmanager).

==> Zu den Details, gerade mit den MDT-spezifischen Farbinformationen könnte ich Unterstützung gebrauchen

Jochen und Jan, würdet Ihr mir da zu Hand gehen mit Infos? (anderen Faden, gerne auch im DEV-Unterforum, würde Jan dann dort reinholen).

lg

Stefan

Kann gerne einsteuern was ich weiß, gerade in Bezug auf die MDT, beim Entkäfern (aus irgendeinem Grund finde ich immer recht Zielsicher irgendwelche Bugs -oder die mich- ) und testen.
Implementierungsseitig hat das komplett @JNK77 gemacht (Ehre wem Ehre gebührt). Ich trigger' ihn mal- weiß nicht, wie oft er hier reinschaut.

Tricky ist hauptsächlich 242.600 (xyY), weil es keine allgemeingültige bijektive Konvertierung gibt. Ob das überhaupt irgendein Gerät unterstützt, weiss ich allerdings nicht. Wenn was ist, unterstütze ich aber gerne.

Bei den HSV muss man Hue 0-360° auf 0-255 (also ein Byte) mappen, das gleiche für 0-100% für Saturation und Value/Brightness. Die Zuordnung ist dann H -> R, S -> G, V/B -> B. Sonst ist da nichts geheimnisvolles bei.

251.600 ist meiner Meinung nach bei MDT kaputt, laut DPT-Beschreibung kann man for RGBW getrennt über Flags im letzten Byte angeben, welche Werte "valid" sind. Meiner Meinung nach müsste dann RGB valid und W invalid für das setzen des Farbchannels und " valid und RGB invalid für das setzen des White-Channels möglich sein, sonst würde ein getrenntes Valid-Flag keinen Sinn machen.Das funktioniert aber wohl nicht (ich habe kein Gerät).

Hallo Jan, danke sehr.

Unser favorisierter Gedanke ist, sämtliche Farbinformationen die über alle Technologien hereinkommen (das ist nicht nur KNX, sondern kann auch MQTT, Rest-API, Philips HUE usw. sein) jeweils intern für unseren Dispatcher auf xyY umzurechnen, in der Logik behandeln und so auszutauschen. Erst beim Übergang auf die jeweilige Technologie würde man das interne xyY dann spezifisch für die Ausgabe wandeln.

Das mit dem Valid ist eine interessante Sache, da müssen wir noch darüber nachdenken, wie wir dann dort die Umrechnung vornehmen, da müsste man dem Kunden ja fast die Möglichkeit geben zu bestimmen, welche Farbkanäle bedient werden sollen. Puh.

Ich melde mich nochmal, wenn wir das tiefer ausbaldowert haben

lg

Stefan

Das angesprochene "kaputt" vom DPT 251.600 beim MDT ist mir beim Testen aufgefallen, allerdings noch nicht mit anderen Revisionen verglichen (ich hab mehrere im Einsatz). Eventuell muss ich auch nur den Dimmer zurücksetzen, weil er beim Testen auch mal die falschen Daten auf sein KO bekommen hat und deswegen womöglich im Nirvana hängt. Das muss ich mir nochmal genau ansehen...

StefanW hat geschrieben: ↑Di Nov 09, 2021 11:43 am Das mit dem Valid ist eine interessante Sache, da müssen wir noch darüber nachdenken, wie wir dann dort die Umrechnung vornehmen, da müsste man dem Kunden ja fast die Möglichkeit geben zu bestimmen, welche Farbkanäle bedient werden sollen. Puh.

Du kannst auch das letzte Byte stets auf FF setzen, dann übernimmt er stets alle gesendeten Werte (sollte er zumindest). Ebenso, wie sich zwischen HSV und RGB hin und herrechnen lässt, kann man auch zwischen RGB und RGBW rechnen, wenn man den W-Kanal einbeziehen möchte.Das macht aber nur Sinn, wenn die verwendeten Stripes dann auch über alle Farben ausgewogen sind. Die günstigen RGB+W Stripes haben oft einen sehr dominanten W-Kanal und dann passt das nicht so ohne Weiteres.

Der andere Weg ist RGB und W separat zu behandeln.

Hallo Jochen,

Dragonos2000 hat geschrieben: ↑Di Nov 09, 2021 12:19 pmDu kannst auch das letzte Byte stets auf FF setzen, dann übernimmt er stets alle gesendeten Werte (sollte er zumindest).

Der Punkt bei der Sache ist, dass es keine allgemein gültige - zumindest uns bislang nicht bekannte - Umrechnung von Farbwerten in mehr als drei Kanäle gibt.

- Wie rechnet man einen Farbwert nun in RGBW um (insbesondere wenn man die Farbtemperatur der LEDs für W nicht kennt)?

- Wie rechnet man einen Farbwert auf RGBWW oder RGBWAF um (insbesondere, wenn man die Farbtemperatur von W und die Farbe von F nicht kennt)?

Mit drei Kanälen oder TunableWhite ist das noch halbwegs klar und einheitlich geregelt, aber das Ansteuern mehrerer Farbkanäle ist eine Herausforderung


Womöglich machen wir uns da aber zuviele Gedanken. Interessenten werden kaum nach solch ausgefeilten Eigenschaften suchen


lg


Stefan

So grobe Umrechenbeispiele für 4 Kanäle zwischen den Farbmodellen RGB, RGBW und HSV finden sich ja eigentlich im Netz. Ich kann bei Bedarf gerne mal ein paar Infos verlinken. Als ich noch DMX genutzt habe, hatte ich das auch mal implementiert und funktioniert ganz gut.

Aus der Erfahrung heraus:
Ich denke an der Stelle braucht Ihr nicht die perfekte Lösung suchen, denn da gibt es viel zuviele Einflussgrößen. Schon wenn Du du auf die emittierten Wellenlängen der RGB LEDs schaust gibt es unterschiede, die W-Kanäle können farbstichig sein, die Leistungsanpassung der Kanäle ist unausgewogen. Dazu kommen dann noch Dimmkurven, Dimmauflösung, etc...
Da muss dann also ohnehin sehr viel im Dimmer selbst passieren, um gewisse Dinge halbwegs zu kompensieren und ohne, dass Ihr das auf Ansteuerungsseite alles beeinflussen könntet. Und dann halt die Stripes selber.

Enertex hat mittlerweile einen 5 Kanal Dimmer im Programm, der TW auf dem Weißkanal macht, also RGBCCT. Der soll das auch aus RGB errechnen können. Ich hab gerade einen hier und wollte das testen. Allerdings hat er auf Seite der Sequenzen einen Haken, daher weiß ich nicht so recht...

Weil RGBW aus HSB schwierig ist, habe ich das für 251.600 ja als Colorpicker für RGB und separater Dimmer für W realisiert.Das setzt nur voraus, dass man die auch getrennt setzen kann.

Das Umrechnungs-Problem ergibt sich schon bei xyY nach RGB/HSB, weil es vom Farbraum und Weisspunkt abhängig ist. Hier habe ich mich nach Diskussion im Deconz-Entwickler-Discord für folgendes https://github.com/smarthomej/addons/bl ... rUtil.java entschieden. Ob das der Weisheit letzter Schluss ist, weiss ich auch nicht. Aber es ist zumindest halbwegs sicher in beiden Richtungen.