MDT Glastaster 2 smart

Der Taster erwartet hier in 1-byte-Telegramm, 9.007 ist aber ein 2-byte-Telegramm.

Seltsam, denn Luftfeuchte ist DPT 9.007 und viele andere Werte, die man würde anzeigen wollen, sind auch 2-byte Fließkommawerte.

H bei HSV ist eigentlich ein Farbwinkel. Winkel werden eigentlich nicht in Prozent angegeben...

Prima, lass uns Haare spalten. Wie wird ein Winkel denn angegeben, in Grad oder doch lieber in Radiant? Mit den Prozent vom Vollkreis ist die Sache doch hinreichend klar definiert und dafür gibt's den passenden Dimm-Typ. Wenn du es (mal wieder) ganz anders machen möchtest, schreib eine Petition an die KNX Association. Die haben ja sonst nix zu tun.

[netzlaff]

Versuch mal DPT 9.007, damit funktioniert Luftfeuchte aus OpenHAB bei mir in der ETS und anderen Geräten.

Habe ich mal eben getestet, leider ohne Erfolg. Der Taster erwartet hier in 1-byte-Telegramm, 9.007 ist aber ein 2-byte-Telegramm.

[ewfwd]

H bei HSV ist eigentlich ein Farbwinkel. Winkel werden eigentlich nicht in Prozent angegeben... Bei den anderen beiden passt es. Bei H aber nicht.

mit dem DPT-Angaben in OpenHAB2 habe ich schon gespielt, DPT 5.001 oder 5.004.

Versuch mal DPT 9.007, damit funktioniert Luftfeuchte aus OpenHAB bei mir in der ETS und anderen Geräten.

[netzlaff]

Ich bräuchte auch nochmal Hilfe. Ich bin gerade dabei Statuswerte auf den Standy-Bildschirm anzuzeigen. Auf Statuswert 1 habe ich die Außentemperatur in °C gelegt. Also alle meine Taster zusammen in eine Gruppenadresse für Statuswert 1 (Temperatur) und ein weiteres für Statuswert 2 für %. Statuswert 2 möchte ich gern die Luftfeuchte in % anzeigen. Die Werte für 1 und 2 speise ich über OpenHAB2. Außentemp funktioniert, Luftfeuchte in % leider nicht. Ich kann den Wert übergeben, ETS zeigt mir im Gruppenmonitor dann aber einen ganz falschen Wert an und der Taster dann auch. Beispielsweise 74 übergeben, auf dem Taster steht dann 29%. Da steh ich total auf dem Schlauch, mit dem DPT-Angaben in OpenHAB2 habe ich schon gespielt, DPT 5.001 oder 5.004. Bei einigen DPTs wird dann gar nichts übergeben. ETS zeigt DPT 5.001 empfangen an. Manuel per ETS den Wert schreiben funktioniert korrekt (5.001). Was mache ich falsch?

Wie "konform" es ist wird man dann sehen wenn die KNX-Association da vielleicht doch einen eigenen Datentyp für definiert. Diese Möglichkeit besteht halt dass sowas irgendwann mal passiert.

Wozu?
Der DPT 3.007 definiert ein relatives Dimmen von 0-100% in Schritten, das passt doch für die Komponenten von HSV ebenso perfekt wie für RGB oder andere Farbmodelle.

Siehe auch hier:
http://www.knx.org/fileadmin/templat...king_E1209.pdf

[ewfwd]

Wie "konform" es ist wird man dann sehen wenn die KNX-Association da vielleicht doch einen eigenen Datentyp für definiert. Diese Möglichkeit besteht halt dass sowas irgendwann mal passiert.

[enertegus]

Liegt zwar Nahe dass so zu machen wie MDT und Enertex doch so ganz KNX-konform ist es nunmal nicht wenn man es genau nimmt.

Warum? Natürlich ist es (Enertex, wohl auch MDT) konform und von der Konnex abgesegnet.
Der Vorteil der HSV Ansteuerung ist für mich: Man gibt eine Farbe (H), ein Helligkeit (V) und einen Weißlichtanteil (S) vor. Man "denkt" ja eben eher: Ich will orange, mit 60% Helligkeit, und nicht 30% Rot, 30% Grün.

[Andreas1]

Wie kommt ihr auf "tausende Telegramme" ist das einfach mal aus dem Bauch heraus gesagt?

Nein.

Kann die Rechnung nicht nachvollziehen. Normales Dimmen vs. HSV-Dimmen dazwischen müsste nur der Faktor 3 liegen an Telegrammen weil es vergleichbar damit ist als wenn du 3 Leuchten gleichzeitig relativ dimmen würdest.

Du kannst nicht statt HSV einfach RGB relativ dimmen.

Beispiel, welche Telegramme soll der Taster denn auf den Bus schicken, wenn ich 10 Sekunden auf H+ drücke?

Normales Dimmen vs. HSV-Dimmen dazwischen müsste nur der Faktor 3 liegen an Telegrammen weil es vergleichbar damit ist als wenn du 3 Leuchten gleichzeitig relativ dimmen würdest.

Das wäre so, wenn der Taster beim relativen Dimmen die Prozentwerte im Taster hochzählen und laufend auf den Bus senden würde. So ist es aber nicht. Der Taster sendet beim relativen Dimmen nur zweimal auf den Bus: Beginn und Ende des relativen Dimmens. Das Hoch-/Runterzählen geschieht im Aktor.

[ewfwd]

Es gibt nun mal eben innovative Unternehmen wie MDT und andere, die sind dem Standard voraus.

Aber wo ist für dich jetzt genau der Unterschied dazwischen dass jeder sein eigenes Süppchen kocht oder man dem "Standard voraus" ist. Die Formulierung ist irgendwie dämlich, du weißt schon was ein Standard ist?
Sowas macht man eben damit nicht jeder so macht wie er meint und am Ende geht nix.

Liegt zwar Nahe dass so zu machen wie MDT und Enertex doch so ganz KNX-konform ist es nunmal nicht wenn man es genau nimmt.

Würde jetzt der Taster ein relatives HSV-Dimmen in absolute RGB-Werte umrechnen, dann gäbe es nicht zwei Telegramme, sondern Tausende, für jeden Zwischenschritt nämlich die Absolutwerte für R, G und B

Kann die Rechnung nicht nachvollziehen. Normales Dimmen vs. HSV-Dimmen dazwischen müsste nur der Faktor 3 liegen an Telegrammen weil es vergleichbar damit ist als wenn du 3 Leuchten gleichzeitig relativ dimmen würdest.
Wie kommt ihr auf "tausende Telegramme" ist das einfach mal aus dem Bauch heraus gesagt?

[Andreas1]

Also der einzige Kritikpunkt der mir einfällt ist, dass es im Handbuch nicht ganz optimal formuliert ist.

Also, das Genörgle sollte an anderer Stelle passieren.

Beim relativen Dimmen gibt es Start- und Stopptelegramm. Wenn der Dimmer (EVG) nur R, G und B relativ dimmen kann, dann kann er eben nur das. Kann der Dimmer HSV, dann können eben H, S und V relativ gedimmt werden. Bei H durchschreitest du den Farbkreis, bei S die Sättigung und bei V die Farbe. Bei allen Dreien gibt es auch hier das Start- und beim Loslassen das Stopp-Telegramm.

Würde jetzt der Taster ein relatives HSV-Dimmen in absolute RGB-Werte umrechnen, dann gäbe es nicht zwei Telegramme, sondern Tausende, für jeden Zwischenschritt nämlich die Absolutwerte für R, G und B.

[MatthiasS]

Der Enertex RGBW-Aktor kann das inzwischen auch - dank Firmware-Update.

Es gibt nun mal eben innovative Unternehmen wie MDT und andere, die sind dem Standard voraus. Das war und wird immer so sein. Schaut mal die Großen an, als Beispiel Gira: gibt es da einen Tastsensor, mit welchem man Farbe mit Feedback vorgeben kann?

Also, das Genörgle sollte an anderer Stelle passieren.

[gbglace]

Bei DMX geht es eben weil der Datendurchsatz auf dem Bus eine vielfaches vom KNX-Bus und DALI Bus ist. Wenn ich es noch richtig im Kopf habe bei KNX zu DMX etwas größer Faktor 50. Da kann man auch mal drei Farbwerte durchscrollen.

Also der einzige Kritikpunkt der mir einfällt ist, dass es im Handbuch nicht ganz optimal formuliert ist.
Warum man aber mit seinen Tastern nu dumm da stehen soll wenn in 5 + x Jahren mal ein anderer DPT von der Konnex definiert ist und dann ggf der GT2 nicht mit den dann rauskommenden Aktoren, die HSV nur via dem neuen HSV-DPT ansteuern, reden können, kann ich nicht erkennen. Aber was interessiert das jetzt? MDT hat einen Controller der mit der bisherigen Lösung HSV regeln kann und hat auch den passenden Taster dazu.

Wenn hier noch einer einige Jahre warten möchte bis er sich eine HSV Bedienung seiner Farb-LED einbaut, ja mei da wollen wir niemanden dran hindern.