KNX-Dimmer steuert thunable white MQTT-Lampe ?

[TorstenE]

Hallo Mitstreiter,

wie ich mit OH einen KNX-Dimmer steuern kann ist mir bekannt und funktioniert auch bereits.
Jetzt geht es darum, den sogenannten Spieß umzudruchen.

Wie steuere ich eine MQTT-(thunable white)-Lampe von KNX aus.

Mich interessieren in diesem Zusammenhang nur die OH-Things und Items.
Wie müssen diese eingerichtet sein, damit ich die o.g. Lampe aus KNX steuern kann ?

Danke für die Hilfe

Torsten

[udo1toni]

Die Lampe hat ja zwei für die Steuerung wesentliche Channel, zum einen die Helligkeit, zum anderen die Farbtemperatur. Beide Werte werden mutmaßlich am besten über Dimmer gesteuert.
Von knx aus kommt es darauf an, welche Geräte Du verwendest. Ich habe hier z.B. Gira TS2 plus, welche Ein- oder Zweiflächenbedienung beherrschen.
In diesem Fall braucht man also zwei Dimmer-Steuerungen, um beide Funktionen voneinander unabhängig bedienen zu können. Die besagten Taster senden bei kurzem Tastendruck auf einem KO DPT1.001 1 bzw. 0, bei langem Tastendruck auf einem anderen KO DPT3.007 1xxx bzw. 0xxx (xxx ≠ 000). Und schon geht es los, man kann den Taster mit Telegrammwiederholung oder mit Start-Stop-Dimming betreiben. Beide Wege sind möglich, erfordern aber unterschiedliche Konfiguration auf openHAB-Seite. Das Stop-Telegramm in DPT3.007 ist 1000 bzw. 0000.
Nehmen wir an, Du hast die dre GA 1/1/1 (DPT1.001, Kurzzeit An/Aus), 1/1/2 (DPT3.007, Langzeit Dimmen) und 1/1/3 (DPT3.007, Langzeit Dimmen) und die letzte GA soll für die Farbtemperatur zuständig sein. Dann sieht ein passendes knx Thing so aus:

Thing device taster "knx Wandtaster" {
    Channels:
    Type dimmer-control : dim  "Dimmer mqtt Lampe"     [ switch="1/1/1",increaseDecrease="1/1/2", frequency=300 ]
    Type dimmer-control : temp "Temperatur mqtt Lampe" [ increaseDecrease="1/1/3", frequency=300 ]
}

Der Parameter frequency=300 ist nur dann notwendig, wenn der Taster mit Start-Stop-Dimming arbeitet. das knx Binding erzeugt dann selbst die passenden Telegramme, bis die Taste losgelassen wird (hier alle 300 Millisekunden eines)
Weil als Type dimmer-control genutzt wurde, wird openHAB jedes ankommende Telegramm auf den GA 1/1/1 bis 1/1/3 als Befehl werten und auch so an den openHAB Bus weiterleiten. Wenn die mqtt Lampe die Befehle INCREASE und DECREASE auf den beiden Channels versteht, reicht es, die beiden zueinander gehörenden Channel mit dem selben Dimmer Item zu verlinken und der Befehl wird direkt durchgereicht.
Wenn die Lampe die beiden Befehle nicht versteht, muss openHAB aus dem relativen Dimmbefehl einen absoluten Dimmbefehl erzeugen, mittels Rule. Z.B. über die DSL als Textkonfiguration:

rule "Dimmbefehl weiterleiten"
when
    Item meinKNXTasterZumDimmen received command
then
    switch(receivedCommand) {
        case ON      : meineLampe.sendCommand(ON)
        case OFF     : meineLampe.sendCommand(OFF)
​        case INCREASE: meineLampe.sendCommand((meineLampe.state as Number)+5) // Dimme in 5-%-Schritten)
​        case DECREASE: meineLampe.sendCommand((meineLampe.state as Number)-5)
​    }
end

Der Channel dim des Things ist hier mit dem Dimmer Item meinKNXTasterZumDimmen verlinkt.
Eine gleichartige Rule kann dann auch für die Farbtemperatur verwendet werden, nur ohne die Fälle ON und OFF.

Sollen mehrere gleichartige Lampen in dieser Form angesteuert werden, wird es sinnvoll sein, die Items mit klug gewählten Namen zu versehen und zu gruppieren, dann kann man mit einer einzigen Rule für alle Taster und Lampen auskommen.

Es gibt auch modernere Wandtaster, welche direkt mit Absolutwerten dimmen können, also einen Zahlenwert 0 - 100 über ein KO DPT5.001 (0 %- 100 % in 256 Schritten) senden, damit kann man sich dann den ganzen Aufwand sparen und einfach position mit dem entsprechenden KO über die passende GA verbinden. Anschließend reicht es dann, die beiden Dimmer Channel mit dem selben Dimmer Item zu verlinken.

[TorstenE]

Soweit habe ich es verstanden Udo, muss es jedoch noch nachbauen.
Wird die Lampe direkt in OH über den MQTT-Channel gesteuert, werden die Änderungen über die -control Channel auch an KNX gemeldet, damit z.B. bei einem Raumcontroller die Dimmanzeige nachgeführt wird ?

[udo1toni]

Wenn die entsprechenden GA eingetragen sind, ja. Zu beachten ist hierbei, dass der Dim-Level (in openHAB Parameter position) dann mit zwei GA versehen werden muss, nämlich der GA um die aktuelle position zu melden und eine GA, um den Dimmer zu steuern. Und es gilt auch bei dimmer-control Channels: die erste angegebene GA pro Parameter ist die einzige, über die openHAB etwas versendet. Also ein Channel

Type dimmer-control : dim "Dimmer" [ switch="1/1/1", position="1/1/5+1/1/6", increaseDecrease="1/1/2", frequency=300 ]

reagiert auf alle angegebenen GA, er sendet die Position aber ausschließlich über 1/1/5.

[TorstenE]

Der Raumcontroller sendet den Helligkeitswert über DP 7.600 als absoluten Wert in Kelvin. Kann in einem KNX-Channel hier auch mit max und min gearbeitet werden, dass der Wert für OH in Prozent umgerechnet wird ?

[udo1toni]

Soweit ich den Java Code des Addons glaube verstanden zu haben unterstützt openHAB derzeit den DPT7.600 nicht (wäre aber sicher kein Ding, das zu integrieren... ist schließlich nur eine Zeile Code...)
Eine direkte Umsetzung von min-max nach PercentType wird vermutlich nicht funktionieren, man könnte aber einen number Channel anlegen und über ein Profile den number Channel mit einem Dimmer Item verlinken. Im Profile definiert man dann zwei "Umrechnungs-Scripts", welche die Farbtemperatur in Prozent umrechnen und umgekehrt.
Solange 7.600 nicht direkt unterstützt wird, kann man 7.000 als DPT angeben, 2-Byte unsigned Integer ist es ja so oder so, fehlt halt nur die Einheit.

[TorstenE]

DTP 7.600 geht definitiv mit einem NumberType, so hole ich mir den Wert. Danach rechne ich den Wert in einer 1. Rule einmal in Prozent um und gebe es an das Dimmer-Item weiter.
Umgekehrt in einer 2. Rule rechne ich den Wert in den Helligkeitswert um und übergebe es an das Nummer-Item und damit wieder zurück an KNX.

[udo1toni]

Ja, aber der Wert wird halt nicht als Farbtemperatur interpretiert, weil 7.600 nicht in der Liste der bekannten DPT aufgeführt ist. Ist auch etwas doof, weil der DPT selbst in der offiziellen DPT-Liste nicht direkt eingeordnet ist, sondern hinten bei den Erweiterungen steht. Entsprechend wurde er (bisher) nicht im Code berücksichtigt.
Dass der Zahlenwert als solcher ankommt, ist aber schon mal gut.

Die Umrechnung könntest Du auch gut über das Profile erledigen - in openHAB4 kann man getrennte In- und Out- Regeln definieren, in denen dann die Umrechnung erfolgt. Die Regeln können in jeder unterstützten Scriptsprache definiert werden (selbst als DSL Code...) das erspart Dir im Zweifel ein Item (Der Code wird natürlich so oder so gebraucht, allerdings setzt er an anderer Stelle an und hat eventuell weniger Impact auf den Bus.

[TorstenE]

Ja, aber der Wert wird halt nicht als Farbtemperatur interpretiert, weil 7.600 nicht in der Liste der bekannten DPT aufgeführt ist. Ist auch etwas doof, weil der DPT selbst in der offiziellen DPT-Liste nicht direkt eingeordnet ist, sondern hinten bei den Erweiterungen steht. Entsprechend wurde er (bisher) nicht im Code berücksichtigt.
Dass der Zahlenwert als solcher ankommt, ist aber schon mal gut.

Die Umrechnung könntest Du auch gut über das Profile erledigen - in openHAB4 kann man getrennte In- und Out- Regeln definieren, in denen dann die Umrechnung erfolgt. Die Regeln können in jeder unterstützten Scriptsprache definiert werden (selbst als DSL Code...) das erspart Dir im Zweifel ein Item (Der Code wird natürlich so oder so gebraucht, allerdings setzt er an anderer Stelle an und hat eventuell weniger Impact auf den Bus.

Und wie geht so eine Profil, damit hab ich noch nie was gemacht. Also irgend eine Beispiel Profil wie das umgesetzt wird. ?

[udo1toni]

Das Profile ist Teil des Links zwischen Item und Channel. z.B. so:

Dimmer ColorTempDimmer "Farbtemperatur" {channel="knx:device:bridge:Taster:colerTemp"[profile="transform:JS", toItemScript="k2dim.js", toHandlerScript="dim2k.js"​][

Nun brauchst Du noch die beiden Scripte k2dim.js und dim2k.js, das eine zum Wandeln der Farbtemperatur in K nach Dimmer in Prozent, das zweite in umgekehrter Richtung, in diesem Fall als JavaScript Script. Natürlich kannst Du auch andere Scriptsprachten verwenden, auch die DSL steht zur Verfügung. Siehe Doku:
https://www.openhab.org/docs/configu...ormations.html da ist das ganz gut erklärt. Die Scripte kannst Du über die UI anlegen, oder alternativ auch direkt im transform-Ordner.

[TorstenE]

Das Profile ist Teil des Links zwischen Item und Channel. z.B. so:

Dimmer ColorTempDimmer "Farbtemperatur" {channel="knx:device:bridge:Taster:colerTemp"[profile="transform:JS", toItemScript="k2dim.js", toHandlerScript="dim2k.js"​][

Nun brauchst Du noch die beiden Scripte k2dim.js und dim2k.js, das eine zum Wandeln der Farbtemperatur in K nach Dimmer in Prozent, das zweite in umgekehrter Richtung, in diesem Fall als JavaScript Script. Natürlich kannst Du auch andere Scriptsprachten verwenden, auch die DSL steht zur Verfügung. Siehe Doku:
https://www.openhab.org/docs/configu...ormations.html da ist das ganz gut erklärt. Die Scripte kannst Du über die UI anlegen, oder alternativ auch direkt im transform-Ordner.

Das mit den "toItemScript" und "toHandlerScript" kannte ich nicht, DANKE

Jetzt noch die Königsdisziplin.

Jetzt hast Du ja in Deinem Beispiel den KNX-Channel beschrieben. Lässt sich für dieses Item jetzt noch ein MQTT-Channel hinzufügen. Der Transform sollte aber nur für KNX gelten, bzw. im JavaScript lässt sich abfragen ob KNX oder MQTT ?

[udo1toni]

Das Profile wird einzeln pro Link definiert, Du kannst beliebig viele Items mit einem Channel und beliebig viele Channel mit einem Item verlinken, die beiden Elemente (Item und Channel) müssen lediglich zueinander passen (unter Berücksichtigung des Profiles)

[TorstenE]

Das Profile wird einzeln pro Link definiert, Du kannst beliebig viele Items mit einem Channel und beliebig viele Channel mit einem Item verlinken, die beiden Elemente (Item und Channel) müssen lediglich zueinander passen (unter Berücksichtigung des Profiles)

Ja, aber bei so einer Kombination

Dimmer KuecheLampe "Lampe Küche"  <light> {channel="mqtt:topic:Lampe_09:Brightness, knx:device:oh_aktoren:LD_E03_01_Dimmer"}

kann ich ja das Profil nicht expliziet für den KNX-Teil angeben

[udo1toni]

Diese Form der Konfiguration ist eigentlich nicht die empfohlene Variante, auch wenn sie funktionieren mag. Korrekt wäre:

Dimmer KuecheLampe "Lampe Küche" <light> {channel="mqtt:topic:Lampe_09:Brightness", channel="knx:device:oh_aktoren:LD_E03_01_Dimmer"}

Und in dieser Form kann man ganz normal pro verlinktem Channel ein Profile definieren

[TorstenE]

Diese Form der Konfiguration ist eigentlich nicht die empfohlene Variante, auch wenn sie funktionieren mag. Korrekt wäre:

Dimmer KuecheLampe "Lampe Küche" <light> {channel="mqtt:topic:Lampe_09:Brightness", channel="knx:device:oh_aktoren:LD_E03_01_Dimmer"}

Und in dieser Form kann man ganz normal pro verlinktem Channel ein Profile definieren

So habe ich es dann auch gemacht. Am Anfang haben die Profile nicht funktioniert. Nach einem Neustart von OH dann doch.
Funktioniert wie gewünscht.

Danke