Switch Item with KNX and MQTT channel

Setup, Configuration and Use Items & Sitemaps
1

Hello, I asked this before in a German openHAB forum, because I am not a native English speaker and some of the technical details I found in this official forum are not easy to understand in the complete depth. I got there some nice support, but actual not a solution so I hope that perhaps someone here can support to find the reason for my problem.

I had a working openHAB 2.5.4 installation where the most items are connect with the KNX binding. Now I want to export the item status over MQTT and also be able to control with MQTT, too.

So i installed additional the MQTT binding 2.5.4 and installed the Mosquitto broker inside the linux machine, where also my openHAB installation runs. I used Mosquitto, because I found some threads with the information, that the openHAB MQTT Broker will get no future development.

My mqtt.things file:

Bridge mqtt:broker:mosquitto    "Mosquitto MQTT Broker" @ "openHAB"   [
    host="localhost",
    port=1883,
    secure=false,
    clientID="openHAB"
] {
    Thing topic mqtt_bj_reg_1_1_2_dg "(MQTT KNX 1.1.2)" @ "Treppenhaus Büro" {
        Channels:
            Type switch : mqtt_d1_a2_k1 "Deckenlampen 1 Büro" [ stateTopic="openHAB/KNX/1/4/16/state", commandTopic="openHAB/KNX/1/4/16/command", on="1", off="0", postCommand=true, retained=true ]
    }
}

First I had no mapping in the Channel switch and openHAB wrote to the topic “0” and “1”. So I tried to map this. I found this information inside some other threads. The item looks this this inside my knx.items file:

Switch s_dg_buero_deckenleuchten_1 "Deckenleuchten 1 Büro" <light> (gBuero_N, gLicht, gSchalter) { channel="knx:device:bridge:bj_reg_1_1_2_dg:d1_a2_k1", channel="mqtt:topic:mosquitto:mqtt_bj_reg_1_1_2_dg:mqtt_d1_a2_k1", alexa="Switchable" [category="LIGHT"] }

Now what I actual have is:

  • I can switch the lights with the physical switches and the virtual switches of the Basic UI
  • I have inside the Paper UI two virtual switches, one for the KNX channel and one for the MQTT channel. Both of them are synchron and represent “ON” and “OFF” correct. And they can also used to switch the light.
  • I have also one topic openHAB/KNX/1/4/16/command with “0” or “1” inside Mosquitto, the topic “openHAB/KNX/1/4/16/state” will not be written like I had hoped.

The main problem is, that I got over the command Topic the status, but can’t change the light over writing inside the Topic. I made some additional test today with a Node-RED installation. There I used also openHAB2 Nodes to connect to my installation. Writing here “0” and “1” did not switch the light, “ON” and “OFF” do this. So I read and convert in Node-RED the MQTT status from “0” to “OFF” and “1” to “ON” and could switch the lights over MQTT. But this needs to much rules. So I hoped to find a solution that openHAB do the same without Node-RED or other external help.

For me it is also not clear, why openHAB write himself “0” and “1” instead “ON” and “OFF” to MQTT.

Finally i hoped that I had described fully understandable what I have and what it is my problem. Be sure that I had read and searched a lot the last days, but I did not found the final solution.

2

This is what you asked for in your MQTT channel
... on="1", off="0" ...
These on/off settings are used for both in and out.

It’s not completely clear what you want to happen. Are you trying to make some MQTT topic “follow” a KNX Switch?

You are probably going to find this easier if you create separate Items representing the KNX and MQTT services.

Don’t really understand.

Maybe we should review your MQTT channel.

[ stateTopic="openHAB/KNX/1/4/16/state", ..., on="1", off="0", postCommand=true, retained=true ]

This part means -
The binding will subscribe to topic openHAB/KNX/1/4/16/state
When a message comes, the payload 0/1 will be converted to ON/OFF
Then the message will be sent to the openHAB Item as a command.
(That is unusual, you would normally want an Item state update)

[ ..., commandTopic="openHAB/KNX/1/4/16/command", on="1", off="0", ..., retained=true ]

This part means,
When the openHAB Item is sent a command, it gets published to topic openHAB/KNX/1/4/16/command.
But first ON/OFF will be converted to 0/1
The published messagewilbetagged for the broker to retain it.

3

Ok, i will try to explain with your answer (this is what i comment before, not native English speaker and technical details :flushed:)

It’s not completely clear what you want to happen. Are you trying to make some MQTT topic “follow” a KNX Switch?

Yes, I have this working Items connected with the KNX Binding. And now I want to export and import also the “ON” and “OFF” over MQTT from this Items, too. When the Item status changed, I want to export this new status and when I wrote over an external MQTT client to the Topic, I want to change the Item inside openHAB.

These on/off settings are used for both in and out.

This would be fine. And I added the string “…, on=“1”, off=“0”…” today while testing. Before it was not inside my configuration and openHAB wrote also “0” and “1” to the Topic. So the behavior did not change with or without this part.

The binding will subscribe to topic openHAB/KNX/1/4/16/state

I had suspected this, but hoped, that openHAB creates this Topic also for the Item status/value.

When a message comes, the payload 0/1 will be converted to ON/OFF

This is what I want. The payload of the Topic was all the time “0” and “1”. See above, with and without this part in the configuration.

Then the message will be sent to the openHAB Item as a command .
(That is unusual, you would normally want an Item state update)

Ok, this part is confusing and unclear. Is a command not also an update of an Item? The target is to write an “1” as the payload to the Topic and the part of the Item definition should convert this to an “ON”, so that the KNX channel part send this over the KNX Binding to the Actuator to switch the light.

When the openHAB Item is sent a command, it gets published to topic openHAB/KNX/1/4/16/command.
But first ON/OFF will be converted to 0/1

This was the most important information. At the end I had thought that openHAB write to status what the Item has done and listen to the command Topic. So it’s the other way around. The Topic “openHAB/KNX/1/4/16/state” did not exist and to test I send manually with MQTT-Explorer an payload “0” and “1” to it and the light was switching. Perfect. But…

… i had now the idea to combine status and command, so that the topic exists and I can overwrite the value to switch. I tried the following:

Type switch : mqtt_d1_a2_k1 "Deckenlampen 1 Büro" [ stateTopic="openHAB/KNX/1/4/16", commandTopic="openHAB/KNX/1/4/16", postCommand=true, retained=true ]

The result was, that openHAB now not create the Topic anymore but a manual write to the Topic switches the light. Seems that status and command must are two different Topics?

4

No, these are very different things inside openHAB, and you do need to understand this to achieve what you want.

Items have state. A Switch could be ON, a Dimmer could be 50%.

When you click on UI for example, it sends a command to the Item. For a Switch that could be ON, for a Dimmer it could be iNCREASE.
Note - while Switch has similar names for command-ON and state-ON, for a Dimmer command-INCREASE isn’t much like state-50%

When you command an Item, the command gets passed to any bindings that are linked.
Usually, that would get sent in its turn to some remote device.
Note that there is nothing there about changing the Items state.

Later, the remote device might respond with its new status - “on” or “50%” etc.
The binding takes that and makes it into a state update on the openHAB Item.

Understand this basic work flow, and you are halfway there.

Of importance to you … state changes of openHAB Items do not usually end up doing anything at the binding.
You probably need to re-evaluate if you want to send states or commands out over MQTT.

5

Ok, then correct me again if necessary, but then I want to command over MQTT my light. I have changed the MQTT channel Item now to this:

Type switch : mqtt_d1_a2_k1 "Deckenlampen 1 Büro" [ stateTopic="openHAB/KNX/1/4/16", commandTopic="openHAB/KNX/1/4/16/status", postCommand=true, retained=true ]

I have tested an can:

  • switch the light over MQTT “ON” and “OFF” when I send a payload “1” or “0” to the Topic openHAB/KNX/1/4/16
  • get an “0” for “OFF” and “1” for “ON” in the Topic openHAB/KNX/1/4/16/status

That is nearly what I want. The final question is, can I general send a state message to the Topic when openHAB first time starts? In the moment the Topic will created when I switch the light on or off.

And the mapping inside the configuration

, on=“1”, off=“0”,

seems not to be necessary, because I did not change the behavior in this example?

6

No.
You can write a rule to send a command when openHAB starts.

7

I thought that everything was working, but finally I had a problem with the actual status feedback of the commandTopic. I found out that this Topic will only updated, if I use the switches in the Paper UI / Basic UI. When I actual use the physical switches or an MQTT command over the stateTopic, the light switches, but the commandTopic is unchanged. So I can’t check the status of the light, what was the goal. :cry:

8

In an MQTT channel, commands sent to the Item/channel are published to the commandTopic. That is it, that is all.

I still do not know what you are trying to achieve.

What physical switches? Do these report to openHAB in some way? If so, what way?

What light? Is this connected to openHAB in some way? If so, what way?
I could guess that is the KNX device linked to your openHAB Item, but let us not guess.

I would still recommend that you would tie yourself in fewer knots if you used two Items, one for KNX and one for MQTT, and linked them with a rule.

9

A “physical” switch is a switch on the wall, you can operate (with your hand). This is, what I meant.

What I have is a switch item connected to the KNX bus with the KNX binding over the channel. The channel is configured to change the light and got an status update from the actuator. The item was used in the Basic UI, too. So I can use the (physical) switch on the wall, the Basic UI switch and the Paper UI switch to change the light. Because of the status update from the actuator, the state of the item represent the correct status of the light.

Then I have the idea to use an external script engine for automating openHAB. I did not want to learn the old engine and understand actual not the next generation rule engine. So I think how can I connect this external script engine to openHAB and MQTT seems to be a good way to do this. To give commands I need the status of the light (which is also the status of the item, right?) and I need a way to command the light over MQTT. To get this work, the item must be connected to the KNX channel and the MQTT channel and both should be synchronized.

After misunderstanding the Topics of the MQTT Binding (I would say, my view was from openHAB to MQTT, but the design seems to work from a MQTT device to openHAB), I reconfigured the mqtt.things like described.

My problem is, that the KNX part works like before, but only when I used the switch from the Basic UI or Paper UI, the commandTopic will change. When I use the switch on the wall, the the commandTopic is not set new and also when I switch the light over the MQTT Topic on or off, I get no feedback. So at the end, I did not have what I want, because I have no secure status from the light in the MQTT Topic and can not use it for scripting.

10

Like I said, you will have less trouble if you use two Items here. It is possible to do it all one Item, but complex, and you risk creating a feedback loop.

So,
your “real” Item
Linked to KNX (only), commands the light, reflects the light state.
Use this in your rules and UI

a “proxy” Item
Linked to MQTT, set commandTopic to the topic you want to publish changes to
set stateTopic to the topic you want to listen for instructions from your mystery rule engine.
set autoupdate disabled on this one

Make two openHAB rules

One listens for state changes on the “real” Item.
If the proxy Item is not already in that state, send it a command.
(that will go out on MQTT)

The other rule listens for state changes on the “proxy” Item.
If the real Item is not already in that state, send it a command.
(that will go out on KNX)