OH3 MQTT Command switch. not State

Charles_Judd · May 30, 2021, 1:58am

hello,
In OH2 I had inbound MQTT command messages that would drive a OH switch to toggle ON or OFF.

This was applied in the items file.
The channels line items shown in the example below is me trying out channels to migrate OH2->OH3.
Example OH2 item below

Switch KitchenLightSwitch1  "Kitchen 1" <light> (gAllLights,gAllKitchenLights) [ "Lighting" ]
                {channel = "mqtt:topic:pi4MqttBroker:KitchenLightSwitch1:light", 
                 channel = "mqtt:topic:pi4MqttBroker:Switchboard1:shieldA_switch_Relay1",
                 channel = "mqtt:topic:pi4MqttBroker:HMI:KitchenLightSwitch1",
                 channel = "mqtt:topic:pi4MqttBroker:HMI_listen_commands:KitchenLightSwitch1",
                autoupdate="false" ,mqtt="
                <[broker:myhome/kitchen/light/switch/row1/command:command:MAP(arduino.map)],]
                <[broker:myhome/kitchen/light/switch/row1/command:command:MAP(arduino.map)],
                >[broker:myhome/switchboard/switchboard1/command:command:ON:A,1,1],
                >[broker:myhome/switchboard/switchboard1/command:command:OFF:A,1,0],
                >[broker:myhome/HMI/page0/kitchen/light/switch/row1/state:state:ON:1],  
                >[broker:myhome/HMI/page0/kitchen/light/switch/row1/state:state:OFF:0], 
                <[broker:myhome/switchboard/switchboard1/shieldA/relay1/state:state:MAP(switchboard.map)],
                <[broker:myhome/switchboard/switchboard1/shieldA/relay1/state:state:MAP(switchboard.map)],"}

The example above shows an exernal Arduino client can send a MQTT COMMAND topic “:command”
it is inbound to Moquitto broker on OH server denoted by “<”

<[broker:topic:command:]
The inbound COMMAND message would drive the OH switch item to switch ON

The actual status of the switch (i,e.: glowing light bulb) would not change until the required state message had been received.

In OH3, I have been unable to work out how to send a command to command a switch to be ON or OFF.
I’ve only been able to get inbound messages to be received by the stateTopic.

I haved tried to create a Thing in OH3 and experimenting with the “isCommand=true” parameter… but my inbound messages to the stateTopic are only ever treated as a change of state, and the switch is never commanded “ON” or “OFF”

any advice on how I should correctly command OH3 switches from an external device appreciated.

YAML extract below from OH3 testing

UID: mqtt:topic:pi4MqttBroker:HMI_listen_commands
label: HMI _listen_commands .HMI_thing
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:pi4MqttBroker
location: HMI
channels:

id: KitchenLightSwitch1
channelTypeUID: mqtt:switch
label: KitchenLightSwitch1 .HMI_listen_commands
description: null
configuration:
retained: false
postCommand: false
formatBeforePublish: “%s”
isCommand: true
stateTopic: myhome/kitchen/light/switch/row1/command
off: “0”
on: “1”

ubeaut · May 30, 2021, 2:45am

Make the on and off like this:

ubeaut · May 30, 2021, 2:54am

You don’t have a MQTT command topic.
If you want to send a command via mosquitto it would look something like this:
mosquitto_pub -h 192.168.0.164 -t cmnd/coffee/POWER1 -m “ON”

Charles_Judd · May 30, 2021, 3:20am

I have intentially left commandTopic out of the Thing configuration as any reading i’ve done suggests “commandTopic” is outbound from OH3 only.
It is not used to receive MQTT messages.
Only the stateTopic can receive messages.

If only stateTopic can receive messages. How do you differentiate between which messages are command messages that can drive OH3 switches, such as COMMAND ON. Currently I can only change the state.

For testing/experimenting, I have now removed the stateTopic and left only the commandTopic

   Thing topic HMI_listen_commands "HMI _listen_commands .HMI_thing" @ "HMI" {
    Channels:
        Type switch : KitchenLightSwitch1      "KitchenLightSwitch1 .HMI_listen_commands" [ 
            commandTopic   ="myhome/kitchen/light/switch/row1/command", on="1", off="0",
            isCommand=true]

Now when publish MQTT messages to the topic, nothing happens.

When I now login to OH3 and open the Thing and toggle the analyse switch to test the Thing. Each time i swith the switch the commandTopic is seen in MQTT. Indicating the commandTopic is working… in its expected behaviour, outbound from OH3 only, towards devices/Things.

Charles_Judd · May 30, 2021, 3:23am

in the example you provided above… “cmnd/coffee/POWER1”… is that commandTopic OH3 receiving MQTT message to drive the OH3 item/thing switch?

Or is it OH3 publishing a message to drive the physical device/Thing that is the switch? The device external to OH.

ubeaut · May 30, 2021, 3:32am

The way I have it set up is the commands from external (mosquitto) I send as a command and the device reacts and it send OH the status of the state via the state topic

If you click the on off switch in OH it sends the command to the device.

Maybe someone else can clarify?

Charles_Judd · May 30, 2021, 3:38am

Thanks… will see what the community can help me with.
I’ve been using OH2.x for years… so have a pretty good grasp of what’s going on with MQTT and OH concepts. OH3 has put me on the learning curve again.

fyi, I have

Arduino devices touch screen switches ===> send command message ===>. OH2 receives on Command Topic ===> OH commands OH switch ON/OFF

The physical switch that turns ON/OFF is an Arduino controlled relay. Relay turns ON.
Arduino relay controller ===> sends STATE message = relay is now ON ===> OH ===> OH updates STATE of Item to indicate it is really ON (light bulb icon illuminates for example).
COMMAND ON, and STATE ON are now both ON.

I’m struggling todo the same with OH3 MQTT messaging.

ubeaut · May 30, 2021, 3:54am

Yes I have come from OH2.5 but I never used the files only for DSL rules etc.
I converted all my DSL to javascript when I swapped to OH3.

I just created a quick test thing and make the state topic and the command topic the SAME and see what happens.

I can send mosquitto commands to the test thing/item and it works with the state and command topics are the same.

Charles_Judd · May 30, 2021, 9:40am

continuing to experiment.
I have now added the parameter "postCommand=true" to the Thing file;

Thing topic HMI_listen_commands "HMI _listen_commands .HMI_thing" @ "HMI" {
Channels:
    Type switch : KitchenLightSwitch1      "KitchenLightSwitch1 .HMI_listen_commands" [ 
        commandTopic   ="myhome/kitchen/light/switch/row1/command", on="1", off="0",
        stateTopic   ="myhome/kitchen/light/switch/row1/state", on="1", off="0",
        postCommand=true]

YAML below

UID: mqtt:topic:pi4MqttBroker:HMI_listen_commands
label: HMI _listen_commands .HMI_thing
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:pi4MqttBroker
location: HMI
channels:

id: KitchenLightSwitch1
channelTypeUID: mqtt:switch
label: KitchenLightSwitch1 .HMI_listen_commands
description: null
configuration:
postCommand: true
retained: false
formatBeforePublish: “%s”
commandTopic: myhome/kitchen/light/switch/row1/command
stateTopic: myhome/kitchen/light/switch/row1/state
off: “0”
on: “1”

If I send a message to the stateTopic myhome/kitchen/light/switch/row1/state the switch activates, and COMMANDS it ON.

So in my mind, the stateTopic becomes an OH 2.5 style COMMAND capabile topic if this parameter is set.

I am still not clear on how to seperate the actual STATE of the switch from the action of COMMANDing it ON when the command to turn it ON is coming from an MQTT message.

i.e.: If a command a swtich to toggle on, and “auto update” of the state is false, it appears the

rossko57 · May 30, 2021, 10:56am

Yes. It’s a reverse of the usual data flow into openHAB.

What do you want to happen?

The autoupdate feature is enabled for each Item by default. This predicts the likely outcome of a command to an Item (from any source) and then usually updates the Items state.
If you don’t want that to happen, disable autoupdate on the Item.

If you want the Item state to be controlled by some other binding, you can link multiple channels to the same Item.

You can’t use the same MQTT channel with postCommand for that here, because you’ve repurposed the stateTopic part. You could make an additional different MQTT channel, and use that.

But normally, if you’re turning incoming messages into commands, it’s because you want openAB to simulate an actor device, and you’d have openHAB generate it’s own state updates by autoupdate or rule.

Udo_Hartmann · May 30, 2021, 9:51pm

The definition is completely wrong:

Switch KitchenLightSwitch1  "Kitchen 1" <light> (gAllLights,gAllKitchenLights) [ "Lighting" ]
                {channel="mqtt:topic:pi4MqttBroker:KitchenLightSwitch1:light",                                    // mqtt2 ch1
                 channel="mqtt:topic:pi4MqttBroker:Switchboard1:shieldA_switch_Relay1",                           // mqtt2 ch2
                 channel="mqtt:topic:pi4MqttBroker:HMI:KitchenLightSwitch1",                                      // mqtt2 ch3
                 channel="mqtt:topic:pi4MqttBroker:HMI_listen_commands:KitchenLightSwitch1",                      // mqtt2 ch4
                 autoupdate="false" ,                                                                             // do not autoupdate state
                 mqtt="                                                                                           // mqtt1 definition
                       <[broker:myhome/kitchen/light/switch/row1/command:command:MAP(arduino.map)],]              // syntax error (closing bracket), incomming topic but command
                       <[broker:myhome/kitchen/light/switch/row1/command:command:MAP(arduino.map)],               // line repeated
                       >[broker:myhome/switchboard/switchboard1/command:command:ON:A,1,1],
                       >[broker:myhome/switchboard/switchboard1/command:command:OFF:A,1,0],
                       >[broker:myhome/HMI/page0/kitchen/light/switch/row1/state:state:ON:1],                     // outgoing topic but state
                       >[broker:myhome/HMI/page0/kitchen/light/switch/row1/state:state:OFF:0],                    // outgoing topic but state
                       <[broker:myhome/switchboard/switchboard1/shieldA/relay1/state:state:MAP(switchboard.map)], 
                       <[broker:myhome/switchboard/switchboard1/shieldA/relay1/state:state:MAP(switchboard.map)], // liine repeated, odd comma
                 "
                }

At least, in openHAB3 there is no mqtt1 addon at all, so all stuff after (and including) mqtt=" is complete nonsense. And it’s unlikely that you needed mqtt1 and mqtt2 in openHAB2.
Another point: It’s very unusual to link more than one Channel to an Item, so it’s very likely that you messed up your mqtt generic thing in the first place.

This thing:

Thing topic HMI_listen_commands "HMI _listen_commands .HMI_thing" @ "HMI" {
Channels:
    Type switch : KitchenLightSwitch1      "KitchenLightSwitch1 .HMI_listen_commands" [ 
        commandTopic   ="myhome/kitchen/light/switch/row1/command", on="1", off="0",
        stateTopic   ="myhome/kitchen/light/switch/row1/state", on="1", off="0",
        postCommand=true]

is also messed up.
At least you can’t use a parameter twice (on and off). And I would recommend to use other names and labels, too, like this:

Thing topic HMI_listen_commands "HMI" @ "HMI" {
Channels:
    Type switch : KitchenLightSwitch1 "Kitchen Light Switch 1" [ 
                         commandTopic="myhome/kitchen/light/switch/row1/command", 
                           stateTopic="myhome/kitchen/light/switch/row1/state",
                                   on="1", 
                                  off="0",
                          postCommand=true]

The correct Item would be

Switch KitchenLightSwitch1  "Kitchen 1" <light> (gAllLights,gAllKitchenLights) [ "Lighting" ]
                {channel="mqtt:topic:pi4MqttBroker:HMI_listen_commands:KitchenLightSwitch1",
              autoupdate="false"}

ubeaut · May 30, 2021, 10:43pm

Shouldn’t the touch screen send the command directly to the device? Then the device sends the state to OH when the relay is changed.

For example the touch screen sends for example:
mosquitto_pub -h 192.168.0.164 -t cmnd/coffee/POWER1 -m “ON”
directly to the device.

The relay turns on and the device sends the state topic which OH receives.

Just like the screen shot I sent earlier.
That way the switch in OH changes when there is an external command sent to the device and you can also send commands to the device from the OH switch.
Is this what you want to do?

Charles_Judd · May 30, 2021, 11:55pm

Thanks Rossko,
I have reset my personal view of how I had visualised things working from OH2.x (the mind is a funny place) and think I’m on the right path for OH3.

My OH3 setup is now working 100%.

The key to getting this working;

I had all the stateTopic and commandTopic logic back to front.
Ensured all Things had both a stateTopic and commandTopic so none were read only (all my devices are read/write and need updates. Nothing is command only, state only, or stateless.).
Ensured all Things that I’m expecting to do something when they receive a state message (command from a device) have the “postCommand=true” set.

I’ll post my config files in the coming days when I can water them down, and support them with a diagram incase they are of use to someone.

All is working 100%. Thank you.

High level diagram of setup below… note;

My design criteria since I started on the home automation journey with OH2.x was to have all commands and processing to be done by OpenHab. Obenhab was to be the the source of truth for everything.
I don’t want any Things / devices / touch screens talking directly to each other. All processing must come though OpenHab.
I want all things (including touch screen buttons to be uniquely addressable. Hence, each button on custom code nextion touch controllers has a Thing with a linked Channel for each button on each page. This allows touch screens to be perfectly insync with OH at all times.

I’m not saying my logic is right, but it works

Charles_Judd · May 31, 2021, 12:40am

Thank you Udo_Hartmann.
All the MQTT statements you’ve highlighted are indeed from the OH2 configuration files for MQTT 2.
As far as I know/can tell, they are ignored by OH3 and are left there while I transition from OH2 => OH3 using Channels to manage the MQTT message definitions.

My follow up post to rossko57 describes success, and I can now remove all the “legacy” MQTT statements.

I appreciate your contribution. Thank you.

system · July 11, 2021, 4:40pm

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.