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

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

#11

Beitrag von JNK77 »

Noch ein Nachtrag zu 251.600:

Es scheint da Verwirrung (auch bei der KNXA) gegeben zu haben, was die Kodierung der Werte angeht. Ältere Versionen der ETS senden für 100% 0x64, neuere 0xFF. Und zumindest bestimmte Produkte von MDT (und anderen Herstellern ?) erwarten auch als maximalen Wert 0x64. Das ist aber m.E. ganz klar falsch, weil die Spec als Auflösung 0.4% nennt, und das geht nur, wenn man 100% auf 0xFF mappt.

Ich wüsste spontan nicht, wie man da einen Workaround für basteln sollte (außer mit einem „erfundenen“ DPT wie bei HSV).
Benutzeravatar

Chris M.
Reactions:
Beiträge: 1190
Registriert: Sa Aug 11, 2018 10:52 pm
Wohnort: Oberbayern
Hat sich bedankt: 234 Mal
Danksagung erhalten: 853 Mal
Kontaktdaten:

#12

Beitrag von Chris M. »

Der neue ColorChooser der CometVisu nutzt intern auch xyY, weil nur so die Farbe eindeutig festgelegt ist. Daher kann der auch den xyY-DPT :) Und den "verbogenen" HSV DPT.

Für das Umrechnen der Farben, gerade wenn auch noch ein Weiß-Kanal zusätzlich dabei ist, braucht es schon ein Farbmanagement. Daher lassen sich beim neuen ColorChooser auch die xy-Koordinaten der einzelnen Komponenten angeben (alternativ auch die Wellenlängen der drei Farben und die Farbtemperatur des weißen Kanals). Denn nur in xyY (bzw. im XYZ) lassen sich die Mischfarben korrekt berechnen.

Gepullt ist der noch nicht, da mir ausgerechnet das HSV momentan Ärger bereitet - gerade wegen der 4 Kanäle und einem Weiß dass eben nicht zwingend der 1:1:1 Mischung der Farbkanäle entspricht so wie der nötigen Bijektivität.
Das Lab bzw. v.a. LCh funktioniert dafür schon sehr gut und ist für eine exakte Farbwahl deutlich angenehmer als ein HSV, dass im Vergleich eigentlich nur für krachige Effekte taugt.
CometVisu Entwickler - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.

TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache

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

#13

Beitrag von StefanW »

Hi Chris,

lass uns dann mal bitte abstimmen, wie wir ein verbundenes Datenformat für xyY hinbekommen, das über MQTT dann bei uns von der CV reinkäme.

Spontan würde ich sagen, wir nehmen einfach drei Zahlen die wir intern in dreimal 16 Bit bekommen, also jeweils Werte von 0...65535 für x, für y und für Y (ja, ich weiß dass es Abhängigkeiten gibt und die Fläche unter dem "Hufeisen" nicht jeweils den vollen Wertebereich erlaubt).

Ich fände es toll, wenn wir zwischen CV-via-MQTT und dem TWS-Dispatcher-Farb-Datenformat keine (oder keine aufwändige) Umrechnung bräuchten. Falls das KNX Format hier brauchbar ist, können wir auch das nehmen für die MQTT Variante.

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

#14

Beitrag von Dragonos2000 »

Irgendwas läuft beim MDT mit den valid Flags auch falsch. Da scheint mir meinen letzten Tests zufolge die Bit-Reihenfolge verdreht zu sein:
Mit dem W-Flag wird bspw. der R-Kanal geschrieben und mit dem R-Flag der W-Kanal.

Ansonsten geht das bei mir von 0x00 bis 0xFF sowohl ETS seitig, als auch was der Dimmer erwartet/ausführt.
Zuletzt geändert von Dragonos2000 am Di Nov 09, 2021 7:17 pm, insgesamt 1-mal geändert.
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
Benutzeravatar

Chris M.
Reactions:
Beiträge: 1190
Registriert: Sa Aug 11, 2018 10:52 pm
Wohnort: Oberbayern
Hat sich bedankt: 234 Mal
Danksagung erhalten: 853 Mal
Kontaktdaten:

#15

Beitrag von Chris M. »

StefanW hat geschrieben: Di Nov 09, 2021 7:11 pm lass uns dann mal bitte abstimmen, wie wir ein verbundenes Datenformat für xyY hinbekommen, das über MQTT dann bei uns von der CV reinkäme.
Da bin ich komplett offen. Sobald da etwas Sinn macht kann ich es implementieren.
StefanW hat geschrieben: Di Nov 09, 2021 7:11 pm Spontan würde ich sagen, wir nehmen einfach drei Zahlen die wir intern in dreimal 16 Bit bekommen, also jeweils Werte von 0...65535 für x, für y und für Y (ja, ich weiß dass es Abhängigkeiten gibt und die Fläche unter dem "Hufeisen" nicht jeweils den vollen Wertebereich erlaubt).
Können wir gerne so machen. Bei xyY ist es ganz normal, dass es Werte für Farben gibt, die nicht existieren - und erst recht nicht physikalisch dargestellt werden können.
StefanW hat geschrieben: Di Nov 09, 2021 7:11 pm Ich fände es toll, wenn wir zwischen CV-via-MQTT und dem TWS-Dispatcher-Farb-Datenformat keine (oder keine aufwändige) Umrechnung bräuchten. Falls das KNX Format hier brauchbar ist, können wir auch das nehmen für die MQTT Variante.
Das KNX Format ist halt immer ein Binär-Format. MQTT nutzt dagegen gerne Strings.

Bei der CometVisu hängt es vom konfigurierten Backend ab welche Umrechnungen sinnvoll sind. Daher muss die Umrechnung für KNX und MQTT (und OpenHAB) getrennt implementiert werden. Das sind aber nur ganz wenige Zeilen Code, also alles kein großer Aufwand.
CometVisu Entwickler - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.

TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache

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

#16

Beitrag von Dragonos2000 »

Kurzes Update zum DPT 251.600 im Zusammenhang mit MDT LED-Aktor:
MDT hat die Bit-Reihenfolge der Valid-Flags gegenüber der offiziellen Spec verdreht, also MDT hat implementiert...
1=rot
2=grün
4=blau
8=weiß

Richtig wäre lt. Spec...
1=weiß
2=blau
4=grün
8=rot
Zuletzt geändert von Dragonos2000 am Mi Nov 10, 2021 11:32 pm, insgesamt 2-mal geändert.
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
Antworten

Zurück zu „Docker Container: OpenHAB“