UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[TIPP] HSV für OpenHAB auf KNX sowie DPT 251.600

Alles rund um OpenHAB im Allgemeinen und den entsprechenden Docker-Container für den Timberwolf Server im Speziellen.
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln

Ersteller
Dragonos2000
Reactions:
Beiträge: 2181
Registriert: So Aug 12, 2018 1:38 pm
Wohnort: Karlsruher Raum
Hat sich bedankt: 481 Mal
Danksagung erhalten: 889 Mal

HSV für OpenHAB auf KNX sowie DPT 251.600

#1

Beitrag von Dragonos2000 »

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:

Code: Alles auswählen

Type color: Licht_HSV        "Control Switch"        [ hsb="232.60000:11/3/142+<11/4/142", switch="1.001:1/0/142+<1/1/142"]
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!
Zuletzt geändert von Dragonos2000 am Di Nov 09, 2021 1:16 pm, insgesamt 2-mal geändert.
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#2

Beitrag von StefanW »

Hey Jan, willkommen hier bei uns. :bow-yellow:


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
Zuletzt geändert von StefanW am Di Nov 09, 2021 8:40 am, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ersteller
Dragonos2000
Reactions:
Beiträge: 2181
Registriert: So Aug 12, 2018 1:38 pm
Wohnort: Karlsruher Raum
Hat sich bedankt: 481 Mal
Danksagung erhalten: 889 Mal

#3

Beitrag von Dragonos2000 »

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- :lol: ) und testen.
Implementierungsseitig hat das komplett @JNK77 gemacht (Ehre wem Ehre gebührt). Ich trigger' ihn mal- weiß nicht, wie oft er hier reinschaut.
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit

JNK77
Reactions:
Beiträge: 3
Registriert: Sa Nov 06, 2021 6:22 pm
Hat sich bedankt: 2 Mal
Danksagung erhalten: 1 Mal

#4

Beitrag von JNK77 »

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).
Zuletzt geändert von JNK77 am Di Nov 09, 2021 11:33 am, insgesamt 1-mal geändert.

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#5

Beitrag von StefanW »

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
Zuletzt geändert von StefanW am Di Nov 09, 2021 11:44 am, insgesamt 2-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ersteller
Dragonos2000
Reactions:
Beiträge: 2181
Registriert: So Aug 12, 2018 1:38 pm
Wohnort: Karlsruher Raum
Hat sich bedankt: 481 Mal
Danksagung erhalten: 889 Mal

#6

Beitrag von Dragonos2000 »

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...
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit

Ersteller
Dragonos2000
Reactions:
Beiträge: 2181
Registriert: So Aug 12, 2018 1:38 pm
Wohnort: Karlsruher Raum
Hat sich bedankt: 481 Mal
Danksagung erhalten: 889 Mal

#7

Beitrag von Dragonos2000 »

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.
Zuletzt geändert von Dragonos2000 am Di Nov 09, 2021 12:24 pm, insgesamt 2-mal geändert.
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#8

Beitrag von StefanW »

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
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ersteller
Dragonos2000
Reactions:
Beiträge: 2181
Registriert: So Aug 12, 2018 1:38 pm
Wohnort: Karlsruher Raum
Hat sich bedankt: 481 Mal
Danksagung erhalten: 889 Mal

#9

Beitrag von Dragonos2000 »

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...
Zuletzt geändert von Dragonos2000 am Di Nov 09, 2021 12:44 pm, insgesamt 1-mal geändert.
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit

JNK77
Reactions:
Beiträge: 3
Registriert: Sa Nov 06, 2021 6:22 pm
Hat sich bedankt: 2 Mal
Danksagung erhalten: 1 Mal

#10

Beitrag von JNK77 »

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.
Antworten

Zurück zu „Docker Container: OpenHAB“