MQTT device discovery payload

Development Misc
, ,
1

Hi there,

I’m developing a MQTT adapter for my heatpump. I can already send data from various sensors as one JSON message. I manually added a MQTT binding thing to my OH 5.0.1 instance and linked the channels to various items. So far so good…

Now I’d like to send out auto discovery message(s). According to MQTT - Home Assistant it should be possible to “send a discovery payload to expose all components for a device“ in just one config message. In this case the config message should be send to a topic, where “the part in the discovery topic must be set to device”.

In my case the topic would be: homeassistant/device/OVUM-AC312P/config

The config message itself looks as follows:

{
  "dev": {
    "ids": "OVUM-AC312P",
    "name": "Ovum AC312P",
    "mf": "Ovum",
    "mdl": "AC312P"
  },
  "o": {
    "name": "mira2mqtt",
    "sw": "0.1"
  },
  "cmps": {
    "Cmp-OutdoorTemp": {
      "uniq_id": "OutdoorTemp",
      "p": "climate",
      "dev_cla": "temperature",
      "state_class": "measurement",
      "unit_of_meas": "°C",
      "val_tpl": "{{ value_json.OutdoorTemp }}"
    },
    "Cmp-OutdoorTempCurrent": {
      "uniq_id": "OutdoorTempCurrent",
      "p": "climate",
      "dev_cla": "temperature",
      "state_class": "measurement",
      "unit_of_meas": "°C",
      "val_tpl": "{{ value_json.OutdoorTempCurrent }}"
    },
  },
  "stat_t": "OVUM-AC312P/state"
}

But messages to this topics get logged as error by OH:

[WARN ] [nal.discovery.HomeAssistantDiscovery] - HomeAssistant discover error: invalid configuration of thing OVUM-AC312P component device: Failed to process discovery config for device: ValueError: ('Unknown component type %s’, ‘device’)

Is such a device discovery just not possible in OH 5.0.1 and I need to send out individual config messages for the various components i.e. channels?

Benjamin

2

So what does the thing config look like?
There is a %s in there probably.

3

There is no thing (at least not for the config message I posted). The purpose of auto discovery is to enable OpenHAB to automatically discover devices based on these types of messages and then this device should pop up in your inbox and one can create the device using the defaults from the config message.

I guess, that the newer Home Assistant style of device discovery is not supported at the moment. So I need to send out discovery config messages for each component (or channel in OH speak). In doing so I’ve got auto discovery somehow working, but it’s still flawed.

I’m sending now messages as follows for each sensor component:

{
  "stat_t": "mira2mqtt/47f3a0aae2e4/state",
  "name": "OutdoorTemp",
  "uniq_id": "47f3a0aae2e4-OutdoorTemp",
  "dev_cla": "temperature",
  "state_class": "measurement",
  "unit_of_meas": "°C",
  "val_tpl": "{{ value_json.OutdoorTemp }}",
  "device": {
    "ids": [
      "47f3a0aae2e4"
    ],
    "mf": "Ovum",
    "mdl": "AC312P",
    "name": "Ovum AC312P",
    "via_device": "mira2mqtt"
  }
}

Now the device is discovered successfully and a new entry pops up in my inbox which can be added as thing. The YAML thing configuration looks as follows:

UID: mqtt:homeassistant:ohserver:41fe3f98401a
label: Ovum AC312P
thingTypeUID: mqtt:homeassistant
configuration:
  topics:
    - climate/41fe3f98401a/EnvironmentPower
    - climate/41fe3f98401a/HeatingEnergy
    - climate/41fe3f98401a/HeatingMode
    - climate/41fe3f98401a/HeatingPower
    - climate/41fe3f98401a/HeatingTargetTemp
    - climate/41fe3f98401a/HeatingTemp
    - climate/41fe3f98401a/HotWaterEnergy
    - climate/41fe3f98401a/HotWaterMode
    - climate/41fe3f98401a/HotWaterTargetTemp
    - climate/41fe3f98401a/HotWaterTemp
    - climate/41fe3f98401a/NetworkEnergy
    - climate/41fe3f98401a/NetworkEnergyWithDefrosting
    - climate/41fe3f98401a/NetworkPower
    - climate/41fe3f98401a/NetworkPower2
    - climate/41fe3f98401a/OutdoorTemp
    - climate/41fe3f98401a/OutdoorTempCurrent
  basetopic: homeassistant
bridgeUID: mqtt:broker:ohserver

But I don’t have any channel. The information for creating these should have been taken from the config messages. So what am I missing here?

4

Update regarding my original issue:

Device discovery is indeed not supported at the moment. See here: [homeassistant] Support new "device" discovery · Issue #17888 · openhab/openhab-addons · GitHub

But as I already changed my code to send out individual discovery messages, I don’t need to wait for the solution of this feature request. For now, I just need to figure out, why the channels don’t get created…

5

I’d still call it component. A Home Assistant component might map to multiple openHAB channels (and indeed, climate components always do). When this happens, the component becomes a channel group.

For many other component types, if they only end up with one channel, they just get a single channel named for the component, not in any group.

Are you sending your configuration messages as retained? The openHAB Home Assistant binding needs to see the configuration messages multiple times - once as part of discovery, and then each time the Thing comes online. If the messages aren’t sent retained, you’d have to be sending them multiple times. This works much better when you use the “device” style configuration, but alas, as you pointed out, that’s not implemented yet.

6

Thank you for your explanation. Indeed I’m sending the config messages as retained, but not the state message. With MQTT Explorer I can see, that the config messages are retained.

As you mentioned that I would have to send the config messages multiple times (if they were not retained): how many messages or long does it take to get the thing configured correctly. Maybe I’m not giving it enough time when testing…

7

Just an FYI that I’ve been working on this on a branch, and I at least have unit tests working for a new thing populating all the channels from a device config, but it still has a lot of work to do with persisting the device config somewhere so that re-initializing an already existing items (either disabling/re-enabling, or after an openHAB restart) works quickly, and for handling changes to the device config (in particular, removing channels that should no longer exist). I don’t anticipate being done with this by the final 5.1 release next week (nor would I expect it to be merged even if I was), but I may find time over the break to finish it and get it in early in the 5.2 snapshots. Though I’m hopeful I’ll be taking delivery of some long-preordered smart devices this week, so I might be too busy installing those! I don’t currently have any devices that even support doing discovery like this, but I’m also not completely ignoring it on the off chance a “big” one like Zigbee2MQTT starts using it, I don’t want to be tooooo behind the ball.

2 Likes