MQTT (2.5) Binding Questions - Homie & HomeAssistant etc

Add-ons Bindings
1

Hi,
I have finally converted over from MQTTv1 to MQTTv2.x. My setup is fairly large, so it took a lot of hours to complete the changes.
OH is running on a Pi4 and I use a Mosquito on another PI as the broker.
Everything seems to work as it should, but I have a few questions…

I have the following bundles running …
290 │ Active │ 80 │ 2.5.0 │ openHAB Add-ons :: Bundles :: MQTT Broker Binding
291 │ Active │ 81 │ 2.5.0 │ openHAB Add-ons :: Bundles :: MQTT Things and Channels
292 │ Active │ 82 │ 2.5.0 │ openHAB Add-ons :: Bundles :: MQTT HomeAssistant Convention
293 │ Active │ 82 │ 2.5.0 │ openHAB Add-ons :: Bundles :: MQTT Homie Convention
294 │ Active │ 80 │ 2.5.0 │ openHAB Core :: Bundles :: MQTT Transport

1. Is this what I should expect to see? What is the “MQTT Broker Binding” and why do I need it?

2. Why is the MQTT Homie and MQTT HomeAssistant bundles running?

3. I get a bunch of these log messages when I restart OH…

2020-01-12 12:57:56.023 [WARN ] [g.mqtt.handler.AbstractBrokerHandler] - Tried to unsubscribe org.openhab.binding.mqtt.homie.internal.discovery.Homie300Discovery@4fd0b4 from discovery topic homeassistant/# on broker mqtt:broker:venus_mqtt but topic not registered for listener. Check discovery logic!

Is that to be expected?

4. What is the best approach for defining things and channels - I have some custom devices (Arduino Megas) that manage parts of our off-grid house systems. These devices publish 40 - 50 different topics each. Should each of these be a separate thing OR should they just be channels under the controller thing?

5.After I edit and reload the MQTT.thing file, I get lots of these messages in the log…
[WARN ] [nhab.binding.mqtt.action.MQTTActions] - MQTT Action service ThingHandler connection is null!

Does anyone know what causes this?

I am grateful for any advice.

Thanks

2

You should have 1 thing per arduino with the channels in each thing

Do not use the things file, use the PaperUI. It’s longer in the begining but you only have to do it once and it’s (almost) error proof.

3

That’s generally the recommended advice, but 40-50 Channels? That might be excessive even for those who insist on defining MQTT Things in .things files.

Depending on the nature of the topic names and the data published to them, it could be a reasonable approach to do a wild card subscription and write a Rule to distribute it the value to the right Item This approach would be best deployed if it is ready to construct the Item name based on the MQTT topic. Than you just need a handful of lines of code to handle all the topics and items, potentially saving hundreds of lines of code or hundreds of Channels. That’s worth deviating from the usual advice I think.

@Hobohome, look at MQTT 2.5 Event Bus for an example.

I can’t help with the .things file problem. I don’t use them and don’t recommend them. But there are ways to do copy/paste/edit using REST API defined Things so you don’t have to click through PaoerUI to create everything.

I wore a good tutorial on how to do this a week or so ago and now I can’t find it. At a high level,

  1. Create an example Thing using PaperUI.
  2. Use the REST API docs to query for that thing
  3. Edit the JSON to add the rest of the Channels
  4. Use the REST API docs to update the Thing
  5. Edit the JSON with the information for a new Thing
  6. Use the REST API docs to add the new Thing based on your edited JSON.

You can very quickly generate dozens of new similar MQTT Things and not have any syntax errors or other problems that come with the use of.things files.

Though in those case, I’m not sure the usual “one Thing per device” makes a lot of sense, assuming you can get to an item name from the MQTT topic.

4

Thanks - I’ll look into using PaperUI (although I confess to being much more of a “edit the text file” type).

5

Thanks @rlkoshak I will look into that approach.
I could group the channels under logical things that have separate MQTT topics if you think that 40-50 channels on a single thing is a possibly a problem.

6

The only problem is that it will be a lot of work to create them and test them to make sure you didn’t make a mistake. As far as OH is concerned, it doesn’t care how many Channels a Thing has.

7

are these error messages with “Homie and HomeAssistant” now normal?

eg
Tried to unsubscribe org.openhab.binding.mqtt.homie.internal.discovery.Homie300Discovery@704a982d from discovery topic homeassistant/# on broker mqtt:broker:mqttbroker but topic not registered for listener. Check discovery logic!
Tried to unsubscribe org.openhab.binding.mqtt.homeassistant.internal.discovery.HomeAssistantDiscovery@119db310 from discovery topic +/+/$homie on broker mqtt:broker:mqttbroker but topic not registered at all. Check discovery logic!

1 Like
8

Have these messages too, also would like to get rid of them … how ?

9

+1
I have 3 openHAB servers, for all these warnings, I also want to get rid of them.

10

As with most anything, the best solution is to get it fixed. Open an issue.

Short of that, you can turn off the MQTT binding’s logging entirely, though you will fail to get logs for other types of errors. You can filter out the log statements for those error statements openHAB - Filtering event logs.