Item connected to several MQTT channels becomes read-only - desired behavior?

I am setting up an OpenHAB infrastructure for my home lighting using the great espmilight addon and connected hardware. With the move to OH3, I am trying to move my structure directly into MQTT topics and represent my infrastructure with corresponding state and command topics.

For that, I have set up an MQTT thing for every light group I use in the house that represents four remote controls currently used in the house to control the lights directly:

Bridge mqtt:systemBroker:MosquittoLocal {
   Thing topic MQTT_GF_Entrance_Light "Deckenlampe Eingang" @ "Flur" {
   Type switch : OnOff "Licht An/AUS" [stateTopic="milight/states/0xAAAA/fut089/1", commandTopic="milight/commands/0xAAAA/fut089/1", transformationPattern="JSONPATH:$.state", formatBeforePublish="{\"state\":\"%s\"}", postCommand="false", on="ON", off="OFF"]       
   Type dimmer : Level "Helligkeit" [stateTopic="milight/states/0xAAAA/fut089/1", commandTopic="milight/commands/0xAAAA/fut089/1", transformationPattern="JSONPATH:$.level", formatBeforePublish="{\"level\":\"%s\"}", postCommand="false", min=0, max=100, step=1] 
   Type switch : OnOff_2 "Dummy 2. FB AN/AUS"     [stateTopic="milight/states/0xBBBB/fut089/1", transformationPattern="JSONPATH:$.state"]
   Type dimmer : Level_2 "Dummy 2. FB Helligkeit" [stateTopic="milight/states/0xBBBB/fut089/1", transformationPattern="JSONPATH:$.level"]       
   Type switch : OnOff_3 "Dummy 3. FB AN/AUS"     [stateTopic="milight/states/0xCCCC/fut089/1", transformationPattern="JSONPATH:$.state"]
   Type dimmer : Level_3 "Dummy 3. FB Helligkeit" [stateTopic="milight/states/0xCCCC/fut089/1", transformationPattern="JSONPATH:$.level"]       
   Type switch : OnOff_4 "Dummy 4. FB AN/AUS"     [stateTopic="milight/states/0xDDDD/fut089/1", transformationPattern="JSONPATH:$.state"]
   Type dimmer : Level_4 "Dummy 4. FB Helligkeit" [stateTopic="milight/states/0xDDDD/fut089/1", transformationPattern="JSONPATH:$.level"]       

The first channel set is set up with a command topic and state topic so that it can be used to send a corresponding command to the mqtt server. The other channels are the other remotes which I want to use as read-only channels which update the item’s state whenever the physical remote control is used. Which triggers an update to the MQTT server’s state topic by external means

Now I am setting up a switch item and linking e.g. all the OnOff channels to this item. My hope would be that whenever the switch is used, the corresponding command of the OnOff channel is sent to the MQTT server, and the other channels would update the item’s state to match the physical state of the light.

Switch   GF_Entrance_Light                "Deckenlampe Eingang An/Aus"      <light>            (GF_Entrance, gLight)                                              ["Lighting", "Switchable"]   {channel="mqtt:topic:MosquittoLocal:MQTT_GF_Entrance_Light:OnOff", channel="mqtt:topic:MosquittoLocal:MQTT_GF_Entrance_Light:OnOff_2", channel="mqtt:topic:MosquittoLocal:MQTT_GF_Entrance_Light:OnOff_3", channel="mqtt:topic:MosquittoLocal:MQTT_GF_Entrance_Light:OnOff_4"}

Problem is, whenever I link one of the channels without command topic to my switch item, the item becomes read-only in the openhab gui. (if OnOff is linked only, the switch works fine, but as soon as e.g. OnOff2 is linked as well, the item is read-only) Is this a desired behavior?/How so? What other options do I have to create an item that can control one command channel but is updated by several MQTT state channels?

Many thanks for any pointers!!

I do not think so. Your use case sounds fine.
I wonder if you could circumvent this by linking the read-write channel last?

As we’re talking remotes, there might be a different approach by having incoming payloads trigger events instead of state updates. You would then need a rule to listen for those and convert to command.
It’s no better really than running two channels, one read/write and one read only and linking those to one Item with a follow profile.

This is an openHAB ‘feature’:

Thank you both for your help!!
@rossko57, putting the command channel last unfortunately didn’t work for me.
@hafniumzinc, too bad that this was closed without any change to the code… I think that guy’s case is valid as well and I don’t see why the current behavior makes sense.

The workaround was posted in the issue:

You can override this manually on the item with stateDescription=" " [ readOnly=false ] on the item (or with the

Yes, I think that was hasty too.
You can open another with your use case.
It may be that binding authors ought to be asserting readOnly=false in read/write channels instead of letting it default, or something.

That issue was posted in the UI section of GitHub. I suspect that the fact that readonly is shown as being true when using the API Explorer means that this is a core openHAB issue (or maybe a binding issue?), not a UI issue, hence the closure…