MQTT Homeassistant: How to setup homeassistant device for ebusd

1

I have a vaillant gas heating connected to an ebus adapter. The corresponding ebusd reports the heating values to a mqtt broker using several topics starting with “ebusd/”.
The ebusd is configured using the following parameters:

EBUSD_OPTS=“–scanconfig --accesslevel=* --latency=80 -d enh:192.168.178.58:9999 --enablehex --address=ff --mqtthost localhost --mqttport 1883 --mqttint=/etc/ebusd/mqtt-hassio.cfg --mqttjson”

I already use the connection to the mqtt broker for several things in my openhab 5.1.0, this works fine.
Now I want to integrate the vaillant heating into openhab using the Home Assistant Binding. Can anybody help how I have to setup the Home Assistant Device?

2

You don’t. HomeAssistant Things are automaticalyl discovered. Assuming you have the HomeAssistant add-on installed, and the MQTT topics and messages being published follow the HomeAssistant standard, there should already be a Thing discovered in your inbox. You just need to go to the inbox and accept it.

3

You’re right, thank you. I got 4 things in my inbox. But:
I created things for them but they did not disappear in the inbox and the state of the created things is “UNKNOWN”.
Do you know why?

4

How did you create the Things for them?

Did you click on them and “Add as Thing” from the Inbox, “Copy the Thing file definition” and paste that into a file, or something else?

5

I used the button “add as thing” and changed the name (not the label) in the following dialog.
This is the view of the created things:

grafik
grafik1467×437 35.9 KB

and this is the inbox after thing creation:
grafik
grafik1465×735 43.3 KB

6

You mean the ID? OK, that explains why the Things are still in the inbox. I wish it were smarter about this but it uses the ID to determine if the Thing has been created or not. If you changed the ID that means the inbox still thinks the one in the inbox is a new Thing. You can select them and ignore them.

But this should not break the Things that were created.

Do you see any errors in the logs?

Do the Things remain UNKNOWN if you refresh the page?

7

Yes. And even disabling and enabling the thing again doesn’t change their state.

I also tried to create a thing again without changing the id. the thing disappears in the inbox but the newly created thing also has state UNKNOWN.

Another hint:
In the channels tab I get the folloging message:

This thing has no channels. Either the thing type doesn’t define channels, or they may be detected and appear later.

189 MQTT Config Topics but no channel.

8

I found the following log entries for home assistant:

openhab.log:2026-01-05 21:06:28.467 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘homeassistant:device:mosquitto-localhost:ebusd’ to inbox.
openhab.log:2026-01-05 21:06:54.817 [WARN ] [nal.discovery.HomeAssistantDiscovery] - HomeAssistant discover error: invalid configuration of thing ebusd_430_PumpEnergySaveCalculatedTimeMonitor_value component sensor: Failed to process discovery config for sensor: MultipleInvalid: The unit of measurement min is not valid together with device class energy
openhab.log:2026-01-05 21:07:04.998 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘homeassistant:device:mosquitto-localhost:ebusd_5F430’ to inbox.
openhab.log:2026-01-05 21:07:05.005 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘homeassistant:device:mosquitto-localhost:ebusd_5Fbai’ to inbox.
openhab.log:2026-01-05 21:07:14.804 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘homeassistant:device:mosquitto-localhost:ebusd_5FBroadcast’ to inbox.
openhab.log:2026-01-05 21:08:27.330 [WARN ] [nal.discovery.HomeAssistantDiscovery] - HomeAssistant discover error: invalid configuration of thing ebusd_430_PumpEnergySaveCalculatedTimeMonitor_value component sensor: Failed to process discovery config for sensor: MultipleInvalid: The unit of measurement min is not valid together with device class energy

9

OK, well that tells you the problem.

Failed to process discovery config for sensor: MultipleInvalid: The unit of measurement min is not valid together with device class energy

What ever is publishing this message has a malformed discovery message.

One of the problems with the HomeAssistant “standard” is it really isn’t a standard. It’s not really documented. It changes on a whim. We used to have a reverse engineered add-on to handle it but now we just pull in the HomeAssistant code itself to process it.

All is not lost though. It will be more work but you can use a Generic MQTT Thing or Things and the JSONPATH transformation to create the Channels that you need.

10

I wanted to avoid this because then I have to find out the meaning of the values I get.
Example: ebusd/bai/Status01 returns

{
“temp” : {
“value” : 57.0
},
“temp_1” : {
“value” : 50.0
},
“temp_2” : {
“value” : -4.75
},
“temp_3” : {
“value” : null
},
“temp_4” : {
“value” : null
},
“pumpstate” : {
“value” : “on”
}
}

How can I find out the description of temp, temp_1, temp_2 and temp_3?
Wouldn’t it be better to use the ebus-binding?

11

If the ebus binding will work that’s what I’d use.

Even if the Thing were correctly discovered by HomeAssistant, the Channels would still be just temp_1, temp_2, etc. It can’t invent information that isn’t there.,

12

My mqtt broker receives topics like homeassistant/sensor/ebusd_bai_Status01_temp/config. What do they describe?

13

:person_shrugging:

You don’t post the JSON published there so who knows. What ever is being published there isn’t compatible with the HomeAssistant standard as implemented by OH. That’s about all we can say.

14

I don’t think that it helps but nevertheless:

The topic ebusd/bai/Status01 returns

{
“temp” : {
“value” : 52.0
},
“temp_1” : {
“value” : 47.0
},
“temp_2” : {
“value” : 0.062
},
“temp_3” : {
“value” : null
},
“temp_4” : {
“value” : null
},
“pumpstate” : {
“value” : “on”
}
}

15

and the correspondig topic homeassistant/sensor/ebusd_bai_Status01_temp_2/config returns

{
“unique_id” : “ebusd_bai_Status01_temp_2”,
“name” : “Status01 temp_2”,
“device” : {
“identifiers” : “ebusd_bai”,
“manufacturer” : “ebusd.eu”,
“name” : “ebusd bai”,
“via_device” : “ebusd”,
“sw_version” : “25.1”,
“suggested_area” : “Heating”
},
“value_template” : “{{value_json["temp_2"].value}}”,
“state_topic” : “ebusd/bai/Status01”,
“unit_of_measurement” : “°C”,
“state_class” : “measurement”,
“device_class” : “temperature”
}

16

I successfully created a MQTT thing for my Vaillant heating using custom channels.
But now I have a transformation problem with a date received from the ebusd in topic “ebusd/430/MaintenanceDate”. The json I get is like

{
  "value" : {
    "value" : "01.05.2018"
  }
}

I created a channel with incoming value transformation “JSONPATH:$.value.value”.
Based on that channel I created an Item of type DateTime with the state description pattern “%1$td.%1$tm.%1$ty”.
But I get the following error:
openhab.log:2026-01-22 10:59:40.555 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '01.05.2018' from channel 'mqtt:topic:mosquitto-localhost:Th_Gastherme:Ch_MaintenanceDate' not supported by type 'DateTimeValue': 01.05.2018 is not in a valid format.
Does anybody know what my fault is?

Thanks in advance
Hermann

17

This message shows it - it cannot transform 01.05.2018 into Date and Time automatically, it needs to parsed.

I’m just curious you want to convert this String into DateTime and then again the DateTime into the same String format again. Wouldn’t it be better fit to declare the channel and item as String?

18

DateTimeType (the state that a DateTimeItem carries) only supports date time strings in ISO8601 format or RFC3339 format. This string is neither.

You will need to transform that String to one of the supported formats using a Script transformation. You can chain transformations on the MQTT Channel.

The script would look something like:

(function(input){
  const split = input.split('.');
  return time.LocalDate.of(parseInt(split[2]), parseInt(split[1]), parseInt(split[0])).toString();
})(input)