I was talking about the general case, how commands and updates flow through channels. Profiles, which are completely optional, allow some workarounds to the general scheme. That’s what they’re for, tailoring.
I don’t think profile is needed here at all, folk have been linking OH instances with MQTT before profiles were invented.
Absolutely right. MQTT just passes messages. Whether it gets handled as a command or as an update at the receiving openHAB is up to the way you’ve configured the MQTT channel.
Here’s a relevant discussion. The nitty gritty is MQTT-1, but the principles are the same.
Let’s take a step back, to clarify your objectives.
On Office-OH you have an Item XX with a “max” channel.
Any commands you issue, say by using a UI of Office-OH, will get passed to the device by the max channel. It’s not clear if your device responds with an update for the Item, but even if it doesn’t autoupdate will take care of that.
In the normal course of events, a command to Item XX will get passed to the device, and the Item will get updated shortly after. So far, so ordinary.
On a remote Home-OH you have an Item ZZ to mirror the office Item. You want to use the Home-OH UI to send commands to the office, so with Item ZZ on the sitemap in the usual way, you send commands to local Item ZZ.
Home Item ZZ needs an MQTT channel that listens for commands only, and sends a message to the office. You don’t want to send updates this way at all. That’s a pretty ordinary configuration (using commandTopic)
Home Item ZZ will also get updated by the local commands triggering autoupdate. If it were me, I’d disable that and rely on the remote update we get later.
Now you have to listen out for those messages at Office-OH, by having an MQTT channel set up. The unusual part of this channel is that you’ll use postCommand to trigger a command to Item XX instead of the usual update.
The command should end up going to the device via ‘max’ channel, and shortly cause an Item XX update same as a locally issued command.
All we have to do now is feed updates back from Office-OH to Home-OH, just so that you can see what’s what from home. I believe you will use a different MQTT topic for this backchannel.
You’d want an MQTT channel that listens for Item XX state updates, again this not the ordinary usage. You could do this MQTT1, but unfortunately the feature doesn’t yet exist in MQTT2 channels.
There is however a workaround using an MQTT action in rule. You’d trigger the rule from Item XX update. See
and the note about using OH 2.5
I believe trying to make this part work using a follow profile, in an effort to convert state updates into commands on the same Item, is going to lead to looping. Because commands usually provoke an update.
If you wanted to avoid OH2.5, I think you would need an additional dummy Item at Office-OH. Use follow profile or rule to convert update of Item XX into commands for dummy Item, have an MQTT channel on dummy Item sending messages on command in the ordinary way. The state of this Item is of no real interest.
Once you are sending messages from Office-OH, the Home-OH needs an ordinary channel updating state (stateTopic). Home Item-ZZ will therefore have two MQTT channels, “command-out” and “state-in” effectively.