MDT Glastaster 2 smart

[Gast]

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.

[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?

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

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

[Gast]

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

[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?

[Gast]

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.

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

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

[Gast]

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.

[Gast]

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.

[BadSmiley]

... schreib eine Petition an die KNA Association. Die haben ja sonst nix zu tun.

An die KN AA? Hihi..

[netzlaff]

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

Laut MDT Handbuch Seite 37, Prozentwerte 0...100% (DPT 5.001). So habe ich das parametriert. Eben habe ich mit knxtool groupwrite mal direkt etwas getestet, also open OpenHAB etc. Dabei ist mir aufgefallen, dass wenn ich in HEX ff schreibe 100% angezeigt wird, somit die die Skala 0-255 und nicht 0-100. Da stimmt doch was nicht, oder?

[Gast]

Laut MDT Handbuch Seite 37, Prozentwerte 0...100% (DPT 5.001). So habe ich das parametriert. Eben habe ich mit knxtool groupwrite mal direkt etwas getestet, also open OpenHAB etc.

Das sind aber Ganzzahl-Prozentwerte für Dimmer oder Rollo, die habe ich als KO eines Luftfeuchtesensors noch nicht gesehen. Üblich und sinnvoll für Luftfeuchte ist Fließkomma DPT 9.007.

Dabei ist mir aufgefallen, dass wenn ich in HEX ff schreibe 100% angezeigt wird, somit die die Skala 0-255 und nicht 0-100. Da stimmt doch was nicht, oder?

Doch, das stimmt so. Dieses Dokument hilft dir weiter, Seite 17.
http://www.knx.org/fileadmin/templat...king_E1209.pdf

[netzlaff]

Ok alles klar, dann muss ich den Wert auf 255 skalieren und als Hexwert übergeben. Das scheint zumindest manuell schon zu funktionieren. Danke für die Hilfe.