MQTT Cover Configuration state_topic

Development
, ,
1

I wrote an integration thing-a-ma-bob that uses MQTT to control covers. I’m getting error messages in the logs and I need help understand what could be wrong.

The error message is:

Logger: homeassistant.components.mqtt.cover
Source: components/mqtt/cover.py:372
Integration: MQTT (documentation, issues)
First occurred: 08:27:03 (12 occurrences)
Last logged: 08:27:03

Payload is not supported (e.g. open, closed, opening, closing, stopped): "Stop"

It could be that I’m understanding the documentation incorrectly but in the MQTT discovery cover documentation there is “state_topic” which I point to my topic with the values. It also says State topic can only read (open, opening, closed, closing or stopped) state. which is clearly where the error is coming from. I do not have those values. I have values “Up”, “Down”, and “Stop”. So I also fill out state_opening: Up, state_closing: Down and state_stopped: Stop which I would assume HASSIO would then use those values to map the state and not the ones required. Am I understanding this incorrectly? If so then what is the purpose of the state_ options?

Here is an example of the config I send

{
  "name": "Office Blinds",
  "command_topic": "smartfriends2mqtt/sf_11716/rollingShutter/set",
  "state_topic": "smartfriends2mqtt/sf_11716/state",
  "qos": 0,
  "availability": {
    "topic": "smartfriends2mqtt/bridge/state"
  },
  "device": {
    "identifiers": [
      "sf_11716"
    ],
    "manufacturer": "Alfred Schellenberg GmbH",
    "model": "RollingShutter",
    "name": "Office Blinds",
    "via_device": "SmartFriendsBox"
  },
  "device_class": "shutter",
  "json_attributes_topic": "smartfriends2mqtt/sf_11716",
  "unique_id": "sf_11716_cover_smartfriends2mqtt",
  "position_topic": "smartfriends2mqtt/sf_11716/position",
  "position_template": "{{ 100 - value | int }}",
  "set_position_topic": "smartfriends2mqtt/sf_11716/position/set",
  "set_position_template": "{{ 100 - position }}",
  "state_stopped": "Stop",
  "state_opening": "Up",
  "state_closing": "Down",
  "payload_stop": "Stop",
  "payload_open": "Up",
  "payload_close": "Down"
}
2

No one can tell me what is going on?

3

I don’t know how helpful I will be, but I took a look at this some over the weekend, and here is what I did:

I used HA to publish an MQTT message to itself. This is the MQTT Discovery message I setup:

service: mqtt.publish
data:
  topic: homeassistant/cover/sf_11716_cover_smartfriends2mqtt/config
  payload: >-
    {
      "name":"Office Blinds",   
       "command_topic":"smartfriends2mqtt/sf_11716/rollingShutter/set",
       "state_topic":"smartfriends2mqtt/sf_11716/state",
       "qos":0,
       "availability":{"topic":"smartfriends2mqtt/bridge/state"},
       "device":{
           "identifiers":["sf_11716"],
           "manufacturer":"Alfred Schellenberg GmbH",
           "model":"RollingShutter",
           "name":"Office Blinds",
           "via_device":"SmartFriendsBox"
       },
       "device_class":"shutter",
       "json_attributes_topic":"smartfriends2mqtt/sf_11716",  
       "unique_id":"sf_11716_cover_smartfriends2mqtt",
       "position_topic":"smartfriends2mqtt/sf_11716/position",
       "set_position_topic":"smartfriends2mqtt/sf_11716/position/set",
       "state_stopped":"Stop",
       "state_opening":"Up",  
       "state_closing":"Down",
       "payload_stop":"Stop",
       "payload_open":"Up",  
       "payload_close":"Down"
    }

Note1: The two template topics are missing as I could not convince HA that these were part of a JSON message, as HA thought it was an actual template that it should use prior to publishing and it would fail to publish.
Note2: I removed the space after each “:”

This created the Office Blinds device successfully.
Note: As I don’t have an actual device, the state of the Office Blinds is always unavailable

I next published a “Stop” message to the state topic:

service: mqtt.publish
data:
  topic: smartfriends2mqtt/sf_11716/state
  payload: Stop

Using the UI: Config->Devices->Office Blinds->Device info->MQTT Info I see:
o smartfriends2mqtt/sf_11716/state
1 most recently received message(s)->Expand it:
Received 9:53:33 PM
QoS: 0
Payload: Stop

I checked the Logs and there were no error messages.

As another check, I created an automation to trigger on receiving the mqtt Stop message on the state topic and when the Stop was received, the automation was triggered.

4

I’m sorry I really haven’t had time to look at this further until now. I do appreciate that you took the time to do a test.

I figured out what the problem was. I send the MQTT message content type as “application/json” so the value of a json string is like "Stop" with the double quotes. HA doesn’t seem to care what you say the message content type is for something like this and it just reads the raw string value, which means of course Stop != "Stop". I have to send raw values instead of the application/json formatted values.

5

If it receives a payload in JSON format, your template should use value_json to reference a key in the payload.

For example, if the JSON payload contains a position key, it can be referenced with value_json.position

If it’s not JSON, you simply use value which gets the entire payload.

6

I feel like I really shouldn’t be sending an MQTT topic with the string formatting anyways. That’s kind of an HTTP pattern and not really MQTT. So I think for my add-on thing-a-ma-bob the better solution is that I detect if my value is structure data or not and if it is not structure data then it needs to be the raw value.

7

This is the first time you mentioned that you are creating an “Add-on”. Are you creating an actual add-on for Home Assistant (or did you simply misuse the term)?

8

What? The very first post of this thread I wrote.

9

An integration is not an add-on.

The two terms represent different concepts in Home Assistant.

10

Except for my question it doesn’t matter what I call it and that is still clear that I am the author of the software that I am having problems with. The issue was with how I implemented it in MQTT discovery and the question was about that.

11

You’re certainly free to misuse terminology. However, that doesn’t make it easier for others to understand what you’re talking about.

For example:

There is no “content type” directive for an MQTT payload so it’s unclear why you thought it was possible or how you were attempting to achieve it.

An MQTT payload can be published containing pretty much anything and it’s up to the subscriber to handle it correctly. In Home Asssistant’s case, it attempts to automatically detect if the payload contains a string in JSON format and if it doesn’t then it’s simply handled as-is (raw).

12

Why are you even replying here? You’ve added nothing to the conversation. The only reason I posted back was because I wanted the person who spent time writing a helpful reply to know it wasn’t for nothing and I appreciated the help and that the issue was my fault.

I went back and fixed my posts, I no longer use the wrong term when referring to the thing-a-ma-bob I wrote.

As for content type and MQTT, if this were 2020 you would be correct, but MQTT v5 added content type to the message packet. Since this is late 2021/early 2022, I didn’t bother checking what MQTT version HA was using and just kind of assumed it was paying attention to the content type. It does not and I will adjust accordingly.

13

To rectify the mistakes you made in your posts. Clearly some value was added because you corrected them.

That’s wonderful, however …

Will you be sharing your “integration thing-a-ma-bob” with the community?

14

I already have, the latest version’s download stats are a few hundred. I’ll push this fix today or tomorrow.