MQTT Switch channel on/off state string override works only on some things

I have my MQTT things and channels defined in .things files. Ever since I upgraded from OH2, the MQTT binding seems to ignore the on/off overrides on all channels on certain things, but not on others.

I have these two things right next to one another:

Thing mqtt:topic:gate-opener-se (mqtt:broker:27f53c46) @ "MQTT" {
  Channels:
    Type number : temperature        [ stateTopic="gate/opener-061313/temperature" ]
    Type number : humidity           [ stateTopic="gate/opener-061313/humidity" ]
    Type switch : relaych1           [ commandTopic="gate/opener-061313/relaych1", on="1000", off="off" ]
    Type switch : relaych2           [ commandTopic="gate/opener-061313/relaych2", on="1000", off="off" ]
    Type contact : status1           [ stateTopic="gate/opener-061313/status1", on="0", off="1" ]
    Type contact : status2           [ stateTopic="gate/opener-061313/status2", on="0", off="1" ]
}

Thing mqtt:topic:gate-sensor-se (mqtt:broker:27f53c46) @ "MQTT" {
  Channels:
    Type switch : light              [ commandTopic="gate/sensor-0f0c06/light-cmnd", on="1", off="0" ]
    Type contact : sensor1           [ stateTopic="gate/sensor-0f0c06/status1", on="0", off="1" ]
    Type contact : sensor2           [ stateTopic="gate/sensor-0f0c06/status2", on="no", off="ffo" ]
}

The first one works, the second one doesn’t, which is confirmed by the generated code in the administration web UI. For the first one it says:

UID: mqtt:topic:gate-opener-se
label: Generic MQTT Thing
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:27f53c46
location: MQTT
channels:
  - id: temperature
    channelTypeUID: mqtt:number
    label: Number Value
    description: null
    configuration:
      retained: false
      postCommand: false
      step: 1
      formatBeforePublish: "%s"
      stateTopic: gate/opener-061313/temperature
  - id: humidity
    channelTypeUID: mqtt:number
    label: Number Value
    description: null
    configuration:
      retained: false
      postCommand: false
      step: 1
      formatBeforePublish: "%s"
      stateTopic: gate/opener-061313/humidity
  - id: relaych1
    channelTypeUID: mqtt:switch
    label: On/Off Switch
    description: null
    configuration:
      commandTopic: gate/opener-061313/relaych1
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      off: off
      on: "1000"
  - id: relaych2
    channelTypeUID: mqtt:switch
    label: On/Off Switch
    description: null
    configuration:
      commandTopic: gate/opener-061313/relaych2
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      off: off
      on: "1000"
  - id: status1
    channelTypeUID: mqtt:contact
    label: Open/Close Contact
    description: null
    configuration:
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: gate/opener-061313/status1
      off: "1"
      on: "0"
  - id: status2
    channelTypeUID: mqtt:contact
    label: Open/Close Contact
    description: null
    configuration:
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: gate/opener-061313/status2
      off: "1"
      on: "0"

While the second one looks like this:

UID: mqtt:topic:gate-sensor-se
label: Generic MQTT Thing
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:27f53c46
location: MQTT
channels:
  - id: light
    channelTypeUID: mqtt:switch
    label: On/Off Switch
    description: null
    configuration:
      commandTopic: gate/sensor-0f0c06/light-cmnd
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
  - id: sensor1
    channelTypeUID: mqtt:contact
    label: Open/Close Contact
    description: null
    configuration:
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: gate/sensor-0f0c06/status1
  - id: sensor2
    channelTypeUID: mqtt:contact
    label: Open/Close Contact
    description: null
    configuration:
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: gate/sensor-0f0c06/status2

Before upgrading to OH3, on/off overrides worked on all things.
Anyone has any ideas what could have gone wrong here?

Try temporarily changing this to

on="AAN", off="AF"

and saving it. Check the generated YAML in the UI. Then change it back to the original and resave, then check in the UI.

What version of OH3 are you running?

Is there any difference after a restart of openHAB?

I’ve changing on/off in both things, and interestingly, the YAML didn’t change at all. Even if I changed the thing that does have on/off config in the YAML, it stayed the same. It looks like as if the on/off configs got loaded from the things file when I upgraded from OH2, and now they stay that way. However, if I change stateTopic or commandTopic, those changes get reflected in the generated YAML.
I should probably mention, that I tried creating new things in the file, and on/off doesn’t work on new things, either.

I’m currently running 3.4.2, but I had this issue ever since I upgrade to OH3, maybe at the time of version 3.1. So I had a couple restarts since then, it doesn’t make a difference.

I’m pretty sure it’s still the case that some bindings, MQTT among them, need a restart of OH to pick up changes to .things files.

Dang! It actually works. I never would have figured that out myself. I’ve been struggling with this issue for quite a few months now. What blew my mind was that without a restart, it does pick up some parameters, like stateTopic and commandTopic, but not others, such as on/off.
Thanks a lot, I really appreciate your help.

So this wasn’t true?

I’m sorry, I got you wrong. Apparently it wasn’t true. It never occurred to me that it would only pick up some changes/parameters on restart, and I expected it to magically start working after a restart as I thought it should work.

I don’t recall how I tested it, but I probably made some changes, saw that it didn’t work, reverted those changes, and then restarted OH. In retrospect, I feel like an idiot.

The way Rich put it made me understand what’s going on.

Once again, I’m sorry about that.

It is irritating having to restart openHAB whenever making changes to configuration files. I use the following trick instead: