MQTT: Command 'true' not supported by type 'OnOffValue'

[ErikDB (Erik)]

Triggered by a post by @Spaceman_Spiff, I thought it was finally time to tackle this MQTT stuff. After some searching, I was able to get the “MQTT Explorer” working:

This was after I did some edits to the Flood GUI:

I then changed Spaceman’s .things file accordingly:

Thing mqtt:topic:localhost:shellyflood "Shelly Flood (MQTT)" (mqtt:broker:mosquitto_broker) [
        availabilityTopic="shellies/shellyflood/online", payloadAvailable="ONLINE", payloadNotAvailable="OFFLINE"
    ]
{
  Channels:
    Type switch : online        "Online"            [ stateTopic="shellies/shellyflood/online",          on="true", off="false" ]
    Type switch : flood         "Flood"             [ stateTopic="shellies/shellyflood/sensor/flood",    on="true", off="false" ]
    Type number : battery       "Battery"           [ stateTopic="shellies/shellyflood/sensor/battery",         unit="%"]
    Type number : temperature   "Temperature"       [ stateTopic="shellies/shellyflood/sensor/temperature",     unit="°C"]
    Type number : error         "Error"             [ stateTopic="shellies/shellyflood/sensor/error"]
    Type string : wake_reasons  "Wakeup reasons"    [ stateTopic="shellies/shellyflood/sensor/act_reasons"]
}

Alas:

After disabling and enabling it again, these are the logs:

22:04:19.081 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:topic:localhost:shellyflood' changed from OFFLINE to UNINITIALIZED
22:04:19.087 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:topic:localhost:shellyflood' changed from UNINITIALIZED to ONLINE
22:04:19.095 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:topic:localhost:shellyflood' changed from ONLINE to UNINITIALIZED (DISABLED)
22:04:21.781 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:topic:localhost:shellyflood' changed from UNINITIALIZED (DISABLED) to INITIALIZING
22:04:21.795 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:topic:localhost:shellyflood' changed from INITIALIZING to OFFLINE
22:04:21.795 [WARN ] [hab.binding.mqtt.generic.ChannelState] - Command 'true' from channel 'mqtt:topic:localhost:shellyflood:availability#shellies_2Fshellyflood_2Fonline' not supported by type 'OnOffValue': No enum constant org.openhab.core.library.types.OnOffType.true

Does anyone have a hint?

The broker thing seems to work:

This is the code of the MQTT Thing:

UID: mqtt:topic:localhost:shellyflood
label: Shelly Flood (MQTT)
thingTypeUID: mqtt:topic
configuration:
  payloadNotAvailable: OFFLINE
  availabilityTopic: shellies/shellyflood/online
  payloadAvailable: ONLINE
bridgeUID: mqtt:broker:mosquitto_broker
channels:
  - id: online
    channelTypeUID: mqtt:switch
    label: Online
    configuration:
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: shellies/shellyflood/online
      off: "false"
      on: "true"
  - id: flood
    channelTypeUID: mqtt:switch
    label: Flood
    configuration:
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: shellies/shellyflood/sensor/flood
      off: "false"
      on: "true"
  - id: error
    channelTypeUID: mqtt:number
    label: Error
    configuration:
      retained: false
      postCommand: false
      step: 1
      formatBeforePublish: "%s"
      stateTopic: shellies/shellyflood/sensor/error
  - id: wake_reasons
    channelTypeUID: mqtt:string
    label: Wakeup reasons
    configuration:
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: shellies/shellyflood/sensor/act_reasons
  - id: battery
    channelTypeUID: mqtt:number
    label: Battery
    configuration:
      retained: false
      postCommand: false
      unit: "%"
      step: 1
      formatBeforePublish: "%s"
      stateTopic: shellies/shellyflood/sensor/battery
  - id: temperature
    channelTypeUID: mqtt:number
    label: Temperature
    configuration:
      retained: false
      postCommand: false
      unit: °C
      step: 1
      formatBeforePublish: "%s"
      stateTopic: shellies/shellyflood/sensor/temperature

[rlkoshak (Rich Koshak)]

@ErikDB

  payloadNotAvailable: OFFLINE
  availabilityTopic: shellies/shellyflood/online
  payloadAvailable: ONLINE

This is why the Thing is OFFLINE.

According to your screen shot, shellies/shellyflood/online is true not ONLINE. payloadAvailable needs to be true and payloadNotAvailable needs to be false.

Furthermore, the message published there needs to be retained. I can’t tell from the screenshot if it is or not. Usually it is. Otherwise, OH would have to be online and able to receive the true message when the Shelly happened to come online on. Otherwise, it gets no message at all and assumes the shelly is offline.

[ErikDB (Erik)]

@rlkoshak

According to your screen shot, shellies/shellyflood/online is true not ONLINE. payloadAvailable needs to be true and payloadNotAvailable needs to be false.

Aha. I actually was thinking in that direction, but since it’s the same device, I expected @Spaceman_Spiff’s configuration to work. I should have tested it, or course…

@rlkoshak

Furthermore, the message published there needs to be retained.

I didn’t know what that meant, but your explanation makes it clear. I assume it’s the checkbox on the Shelly GUI?

[Spaceman_Spiff (Sebastian)]

@ErikDB

Aha. I actually was thinking in that direction, but since it’s the same device, I expected @Spaceman_Spiff’s configuration to work. I should have tested it, or course…

Sorry for the confusion.

The device publishes to online when it’s online and ready to receive commands / settings. This is only a couple of seconds so your thing will be mostly offline and of not much help for you.

I have a rule that tracks the wakeup and publishes to another topic if the device reported online in the last 24 or 48 hours.
I edited the topic to match the original one but forgot that I must have changed the online message, too.
So for your case you can

• either implement the same rule and use it in the thing config
• use the expire binding e.g. on the battery level to track if the device is online and not use the online state in the thing config

@ErikDB

I didn’t know what that meant, but your explanation makes it clear. I assume it’s the checkbox on the Shelly GUI?

Retain means that all messages are “cached” by the mqtt broker, so you get them directly after you connect to it.
For stateful topics (e.g. online/offline topic) this is sometimes nice to have, however the danger is always that you get old values which are no longer correct.
However in your case this will not change anything.
You can change the retain flag in the shelly GUI.

[ErikDB (Erik)]

@Spaceman_Spiff

I have a rule that tracks the wakeup and publishes to another topic if the device reported online in the last 24 or 48 hours.
I edited the topic to match the original one but forgot that I must have changed the online message, too.
So for your case you can

• either implement the same rule and use it in the thing config
• use the expire binding e.g. on the battery level to track if the device is online and not use the online state in the thing config

I’m afraid I don’t exactly understand… A few follow-ups

• What’s the point of your rule?
• What’s the ‘expire binding’? It seems discontinued as from OH3?
• Why would I need something like it?

@Spaceman_Spiff

You can change the retain flag in the shelly GUI.

To be clear: you mean uncheck it again, right?

[Spaceman_Spiff (Sebastian)]

The device sleeps a lot because it’s a battery device.
Once a day it wakes up. Then it sends “true” on the online topic.
After a couple of seconds it sends “false” and goes back to sleep.

If you use the online topic for your thing status the thing will be “OFFLINE” all day and then change to “ONLINE” for only a couple of seconds.
That’s of no use for you because you probably want to see if the Shelly Flood is online which means it’s reporting values once a day.

My rule listens to the online topic and when the device reports “true” it publishes “ONLINE”.
It also starts a countdown so it will report “OFFLINE” after 48h of no “true”.
Since I use the topic of the rule for the thing status, I now see the thing as online even though it’s currently sleeping.

It’s not required to use the online/offline topic for the thing.
Then the thing will always be online.
The simple way to check if it still works would be to use expire with e.g. 48h on the battery level.
Expire is no add on but a core functionality in OH4.
It’s still there, check the docs for expire.

@ErikDB

To be clear: you mean uncheck it again, right?

Depends, do you want to retain the topics or not

[ErikDB (Erik)]

@Spaceman_Spiff

My rule listens to the online topic and when the device reports “true” it publishes “ONLINE”.
It also starts a countdown so it will report “OFFLINE” after 48h of no “true”.
Since I use the topic of the rule for the thing status, I now see the thing as online even though it’s currently sleeping.

This sounds good. Would you mind sharing your rule? (I found @rlkoshak’s advice on a similar topic, but you might have a different setup?)

@Spaceman_Spiff

@ErikDB

To be clear: you mean uncheck it again, right?

Depends, do you want to retain the topics or not

If I understand your previous statements about it correctly, I would think it makes sense for the Shelly Flood?

[Spaceman_Spiff (Sebastian)]

@ErikDB

If I understand your previous statements about it correctly, I would think it makes sense for the Shelly Flood?

I think you can answer that yourself:
If you start openHAB what state will the device have - online “true” or “false” or “don’t know”?

@ErikDB

This sounds good. Would you mind sharing your rule? (I found @rlkoshak’s advice on a similar topic, but you might have a different setup?)

I’m using HABApp and the rule does a little bit more, pushover notifications and logging.
So it might not be what you are looking for. If you are still interested I’m happy to share.

[rlkoshak (Rich Koshak)]

@Spaceman_Spiff

For stateful topics (e.g. online/offline topic) this is sometimes nice to have, however the danger is always that you get old values which are no longer correct.

For a normal status topic with LWT configured, the status topic should never go stale. When the device comes online it publishes the online message to the status topic. When the device goes offline the broker publishes the offline message to the status topic.

But these battery powered Shelly devices don’t work like that that so @ErikDB another option is to just eliminate the availabilityTopic and payload properties entirely. Then the status of the MQTT Thing will follow the status of the MQTT broker. But of course you won’t know when/if the device ever does go offline in that case. But it’s a viable option, and for some bindings that’s typical behavior.

[ErikDB (Erik)]

@rlkoshak

But these battery powered Shelly devices don’t work like that that so @ErikDB another option is to just eliminate the availabilityTopic and payload properties entirely. Then the status of the MQTT Thing will follow the status of the MQTT broker. But of course you won’t know when/if the device ever does go offline in that case. But it’s a viable option, and for some bindings that’s typical behavior.

I went with this, and a rule that updates a DateTime item everytime the online channel is updated.

Thanks to you both for your quick and elaborate help!