MQTT stateTopic vs commandTopic

[twinotter1 (Twinotter)]

I’m using OH 3.0.1 on a Pi 4b. I have mosquitto. On a different Pi (it’s a zero) I’m running mopidy with Mopiqtt that is configured back to talk to the broker on the Pi 4. Everything is working…

Except, I’m trying to control playback state with an openhab Switch item. I’ve created a thing with the mqtt broker bridge. The tricky part is that the stateTopic payload and the commandTopic payload use different words for their state. Here’s my Thing:

    Thing topic mopidy_thing "Mopidy Server" {
        Channels:
                Type switch : plb [ stateTopic="mopidy/stat/plstate", on="playing", off="paused", commandTopic="mopidy/cmnd/plb", on="play", off="pause" ]
                Type string : plstate [ stateTopic="mopidy/stat/plstate" ]

                Type switch : voltoggle [ stateTopic="mopidy/cmnd/vol", commandTopic="mopidy/cmnd/vol", on="=20", off="=7" ]
                Type string : volume [ stateTopic="mopidy/stat/vol" ]
        }
}

From this you can see what I’m trying to do: have the state set using different payloads from what the command is using. Is there a way to do this? For what it’s worth, when I delete the command part, the switch updates correctly using the “playing” and “paused” payloads. If I don’t delete that part, the switch correctly controls the playback state, it just doesn’t update when something else controls the playback state.

Thanks!!
Rudy

[hafniumzinc (T)]

@twinotter1

Is there a way to do this?

Maybe split this into two separate Channels? Later, an Item can have links to two (or more) Channels if you want to control from a single Item.

[JimT (jimtng)]

Maybe use some sort of transformation, e.g. map or js for incoming state?

[rossko57]

@twinotter1

when I delete the command part, the switch updates correctly using the “playing” and “paused” payloads.

I think you are looking at the effect of Autoupdate feature there.

Autoupdate - a primer

I’ve found myself having to investigate and/or explain some of the features of autoupdate over time, and thought an in-depth view would be helpful. These notes apply to openHAB version 2.5 Overview Autoupdate is primarily a “speed up” feature for openHAB Items. Mostly we can ignore it, but sometimes you may get an unwanted or unexpected effect, or you may wish to exercise more control. To fully understand autoupdate, we must understand the difference between command and state of Items. If w…

[rlkoshak (Rich Koshak)]

I believe the order of operations the state transform and command transform will take place first before applying the on and off properties.

So you could apply a map transform on one of the two to normalize the word used before it gets to the on and off transformation.

Alternatively you can just use two MAP transforms, one on state and one on command, and abandon the on and off properties.