openhabforum.de

Hallo Mitstreiter,

Vorab Info:

Switch-ITEM (Lichtschalter) ist mit 2 Channel angebunden.

MQTT - zum Licht selbst (Glühbirne)
KNX - zu einer KNX-Gruppenadresse

Ich würde gerne folgendes gerne lösen:
Wenn z.B. der KNX-Taster gedrückt wird, dann lässt sich das Licht
nicht direkt schalten.

Zwar reagiert das Item (Switch) auf den KNX-Taster, aber das "Item" leitet
diese Aktion nicht an MQTT weiter.


Im Augenblick habe ich es über eine Regel gelöst (Regel-Varianten symbolisch)

WENN SwitchItem received command ON, LichtItem.sendCommand(ON)
WENN SwitchItem received command OFF, LichtItem.sendCommand(OFF)
oder
WENN SwitchItem reveived command, LichtItem.sendCommand(reveivedCommand)
oder
Wenn SwitchItem reveived update, LichtItem.sendCommand(SwitchItem.status)


Aber vielleicht gibt es ja noch eine elegantere Art, diese beiden
Welten miteinander zu verbinden.

Ach und wenn es doch geht, dann bitte doch gleich ein Bespiel mit einem Dimmer/Jalousiesteuerung, das
geht dann bestimmt schon Richtung Königsklasse

Danke

Torsten

Wenn Du alles korrekt definierst, ist das kein Problem
Punkt 1: Definiere einen knx switch-control Channel und trage dort die GA ein, die knx sendet. Ich gehe von einem DPT 1.001 aus, es geht ja um einen Schalter.
Punkt 2: Definiere einen mqtt switch Channel, in dem Du das commandTopic setzt, außerdem muss der Befehl ON/OFF von diesem Channel korrekt ausgeführt werden.
Punkt 3: verlinke beide Channel mit dem selben Switch Item. Definiere sonst nichts (insbesondere kein Profile!)

Dies funktioniert seit openHAB2.2 (da gab es noch gar keine Profiles, aber das knx2 Binding mit den control Channels war brandneu)-

Hallo Udo,

zu 2.

was meinst Du mit "... außerdem muss der Befehl ON/OFF von diesem Channel korrekt ausgeführt werden... " genau ?

Danke

Torsten

Das habe ich ebenfalls entdeckt

....
postCommand: If true, the received MQTT value will not only update the state of linked items, but command it. The default is false. You usually need this to be true if your item is also linked to another channel, say a KNX actor, and you want a received MQTT payload to command that KNX actor...
MQTT Things and Channels Binding

TorstenE hat geschrieben: ↑6. Sep 2023 13:19 was meinst Du mit "... außerdem muss der Befehl ON/OFF von diesem Channel korrekt ausgeführt werden... " genau ?

Damit meine ich: Ein Switch Channel muss auf ON und OFF reagieren und diese Kommandos passend weiterleiten.
Es kann z.B. sein, dass Dein Gerät die Befehle true/false braucht.
Dann musst Du trotzdem (zwingend) einen Switch Channel verwenden und für onValue und offValue die passenden Werte eintragen. Du darfst keinesfalls einen String Channel nutzen.

Wenn sich das MQTT Gerät mit dem Switch Channel steuern lässt, dann reicht es, ein Switch Item zu verlinken und einen switch-control Channel auf knx-Seite mit dem selben Item zu verlinken (habe ich bei mir seit Jahren in Betrieb, unter anderem auch mit mqtt und knx)

Das knx Binding ist das einzige Binding, welches extra Control-Channel bietet (jedenfalls kenne ich kein anderes Binding, bei dem das so gelöst ist), es ist aber auch das erste gewesen, was diese Funktionalität geboten hat.

Man könnte auch versuchen, mit dem follow-Profile auf mqtt-Seite zu arbeiten, das ist aber aus verschiedenen Gründen suboptimal.

*-control Channel werden von openHAB als Befehl empfangen, umgekehrt wird der Status an den Channel gesendet, das gilt auch für postUpdate(), ist also ein sehr vom openHAB Standard abweichendes Verhalten, es ist aber sinnvoll.
Grundsätzlich ist openHAB im Zusammenspiel mit Bindings eine Art Fernbedienung, Alles was zum Binding gesendet wird, ist ein Befehl, alles was empfangen wird, ist ein Status. Mit dem *-control Channel wird dieses Verhalten umgekehrt, was empfangen wird ist ein Befehl, was gesendet wird, ist ein Status. Damit kann dann ein knx Schalter ohne weitere Umwege die Hardware eines anderen Bindings steuern, also genau, was Du erreichen willst.

Mit dem follow-Profile funktioniert es anders, das Item, welches auf follow steht, betrachtet ankommende Status Updates als Befehl und leitet sie entsprechend weiter, das ankommende Event ist aber lediglich ein Update, kein command.

Wenn Du im mqtt Channel is command = true setzt, dann wird ein eingehender Status als Befehl weitergegeben, also genau das gleiche, was auch mit den *-control Channels bei knx erreicht wird. Nur ist das genau das Gegenteil von dem, was Du erreichen willst. isCommand wäre interessant, wenn Du einen Schalter an einem mqtt Client anschließt und diesen Schalter verwenden willst, um ein anderes Gerät ein- und auszuschalten.

udo1toni hat geschrieben: ↑6. Sep 2023 20:44 ...
Wenn sich das MQTT Gerät mit dem Switch Channel steuern lässt, dann reicht es, ein Switch Item zu verlinken und einen switch-control Channel auf knx-Seite mit dem selben Item zu verlinken (habe ich bei mir seit Jahren in Betrieb, unter anderem auch mit mqtt und knx)
...

Das bedeutet, das ein Item mit einem Channel Richtung MQTT und mit einem anderen Channel Richtung KNX verbunden ist ?

Ja, geht ja nicht anders, wenn das Steuersignal von knx nach mqtt soll (ohne Umweg über eine Rule)

So,

1.
wenn ich den KNX-Schalter betätige, reagiert die MQTT-Lampe wie gewünscht. Das gemeinsame Switch-Item zeigt in OH auch korrekt ON/OFF an.

2.
Wenn ich das Switch-Item in OH schalte, reagiert die MQTT-Lampe ebenfalls korrekt

aber:

3. wird das Switch-Item in OH manuell betätige, reagiert zwar die MQTT-Lampe, aber der KNX-Schalter wird nicht aktualisiert, d.h. er zeigt
den falschen Status an.

Vielleicht ein Hinweis: Das Schalten erfolgt auf der GA 1/1/0 und die Status-Abfrage auf der GA 1/4/0, vielleicht hängt es damit zusammen.

Da fehlt noch eine Kleinigkeit.

Hast Du bei der Itemdefinition darauf geachtet, dass die GA in umgekehrter Reihenfolge stehen?

TorstenE hat geschrieben: ↑9. Sep 2023 12:42Das Schalten erfolgt auf der GA 1/1/0 und die Status-Abfrage auf der GA 1/4/0

Eine Status-Abfrage gibt es per Definition nicht.
knx sendet einen Schaltbefehl über 1/1/0 an openHAB, openHAB sendet den aktuellen Status über 1/4/0. Ein < Zeichen hat bei switch-control (und auch allen anderen -control Channels) keine Auswirkung, da per Definition openHAB "Aktor" ist, also auch die Hoheit über den Status hat. Es kann gar nicht in knx nach dem Status fragen.

In knx gibt es die Regel, dass man mehrere GA pro KO eintragen kann, das KO reagiert dabei auf alle GA (so das KO überhaupt auf eintreffende Telegramme reagiert, also das S-Flag gesetzt ist), ist das KO selbst in der Lage zu senden (Ü-Flag/L-Flag gesetzt), so sendet es ausschließlich auf der ersten angegebenen GA, welche auch als Haupt-GA bezeichnet wird. Hat man mehrere GA in einem KO hinterlegt, kann man per Kontextmenü(?) eine beliebige der verlinkten GA als Haupt-GA setzen, woraufhin diese dann an die erste Stelle rückt... Das openHAB knx Binding verhält sich hier also exakt so, wie man es erwartet, gesendet (auch der Status...) wird immer ausschließlich auf der ersten angegebenen GA eines Parameters.

Perfekt, GA in OH umgedreht und es funktioniert - SUPER