How am I "supposed" to install an MQTTv2 (non "system"?) broker?

Setup, Configuration and Use Beginners
1

Hi!

Running:

Release = Raspbian GNU/Linux 10 (buster)
Platform = Raspberry Pi 4 Model B Rev 1.2

So… there appear to be many ways to get mqtt Integration, but I can’t figure out what I should use if I want to take full advantage of current and future features that openHAB(ian) offers - auto-discovery and configuration via GUI, (partial) compatibility with various smarthome brands… anything that helps me make less of a mess with all the things I’m planning to flash tasmota / espurna on or hotglue arduinos to would also be nice. Most importantly: I’d like to do it as “vanilla” as possible and reduce the amount of improvisation & witchcraft I do to get things running so I don’t have to hit my openhab with a hammer for 20 hours every time there is an update.

I guess I should not use a “system broker”, since:

“A system configured broker cannot be changed by this binding and will be listed as read-only system-broker”

I guess I should not use Moquette, because:

Attention: Moquette is no longer maintained upstream and this add-on is therefore considered deprecated in openHAB. It is recommended to switch to an external broker like mosquitto. The Moquette add-on will be removed in a future release of openHAB.

I should probably not use the openhabian config tool to install Mosquitto, because it says:

HEADS UP: Only proceed when you are aware that this will be in conflict with use of the MQTTv2 binding which will also be using the same ports.

Which might or might not have anything to do with “system” brokers and might or might not mean, that I also shouldn’t install Mosquitto (or anything on the same host) via apt probably?

  • Or is it enough to change the default port?
  • Does “system” Broker mean “any broker I installed on the system” (as in: installed by package manager / started through systemd / not the obsolete Mosquitto Binding) or what does it mean?
  • Also haven’t been able to find out what “read-only system-broker” means. What are the disadvantages? Sounds absolutely like something I don’t want, but what does it actually mean - “read only” what, where, in what context?
1 Like
2

Install Mosquitto.

I have no idea what the heads up is trying to warn about: unless I’ve seriously misconfigured my own working setup, the MQTTv2 binding doesn’t conflict with Mosquitto at all. In fact, you use the options made available to you in the MQTTv2 binding to connect to the Mosquitto application.

3

In this context, System Broker is a Thing that allows for limited communication about admin stuff between openHAB and some integrated but essentially independent broker service.
If you don’t use an integrated broker, you don’t want a System Broker Thing.
It has nothing to do with actual MQTT traffic.

4

The config tool warning probably needs to be updated. It’s not a conflict with the MQTT v2 binding itself, it’s a conflict when using the embedded Moquette broker. MQTT brokers by default use a standard networking port. If you try to run two brokers on the same machine there will be a conflict because they both can’t use the same port.

So what you want:

  • Install Mostquitto through openhabian-config
  • Install the MQTT v2 binding
  • Create an MQTT Broker Thing and configure it to connect to Mosquitto
  • Since you are using Tasmota, configure it to use the Home Assistant MQTT standard (see the Tasmota docs). This will allow openHAB to automatically discover and create the MQTT Things for you.

As rossko57 indicates, the System Broker is Moquette.

5

Thanks everyone!

Getting it running and discovering HA things with Mosquitto worked quickly.

The result isn’t so great though: I’m getting one “Thing” discovery per channel that way and 13 “Things” for each physical device is a bit much. Tried messing with Openhab and Tasmota for a couple of hours, did not manage to get any further.

Have not found many candidates for what could be going wrong. Somewhere in the logs, I found some:

/var/log/openhab2/openhab.log:2020-08-14 22:06:06.684 [WARN ] [mqtt.homeassistant.internal.CFactory] - Not supported
/var/log/openhab2/openhab.log: at org.openhab.binding.mqtt.homeassistant.internal.ComponentSensor.(ComponentSensor.java:51) ~[bundleFile:?]

And [mqtt][homeassistant] ComponentSensors (/BinarySensors) - Allow forced_update true · Issue #7063 · openhab/openhab-addons · GitHub says something about:

When added, configuration of the device is incomplete

… which might not be related to my problem at all, it’s just the first search result for the only mqtt related error message I found anywhere and where I stopped looking.

In the Tasmota console I see messages like this:

22:32:04 MQT: AWP07L_02/tele/SENSOR = {“Time”:“2020-08-14T22:32:04”,“ANALOG”:{“A0”:40},“ENERGY”:{“TotalStartTime”:“2020-08-14T21:22:49”,“Total”:0.000,“Yesterday”:0.000,“Today”:0.000,“Period”:0,“Power”:0 […]

( tried both %prefix%/%topic% and %topic%/%prefix% as “Full Topic” in Tasmota UI, not sure why, it changed nothing in Openhab that I could see. Deleted cache and discoveries between all attempts. )

I’m getting Discoveries like this in Openhab:

/var/log/openhab2/openhab.log:2020-08-14 22:40:10.166 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘mqtt:homeassistant_375367_5FANALOG_5FA0:b73c65c3:395267_5FANALOG_5FA0’ to inbox.

Which results in a ton of Things like:

AWP07L_01 ANALOG A0 (Sensor)
HomeAssistant MQTT Component
AWP07L_01 AWP07L_01 (Switch)
HomeAssistant MQTT Component
AWP07L_01 ENERGY ApparentPower (Sensor)
HomeAssistant MQTT Component

On the upside, also seeing ON/OFF events like this when I press the physical button:

mqtt:broker:b73c65c3:stat triggered {“TRIG”:“SINGLE”}
mqtt:broker:b73c65c3:stat triggered {“POWER”:“ON”}

… so I guess that part works.

Still: Can’t figure out how to get only one openhab Thing for each physical thing instead of 13, at least using the paper UI / auto discovery. Haven’t tried adding it manually yet and I’d like to avoid that if there’s a way to fix this.

6

Correct, I just fixed that.

2 Likes
7

Autodisovry is, as the name implies, is automatic. If you don’t like the way the devices are discovered, you will have to do it manually. Figure out which topics mean what and create Generic MQTT Things and the needed Channels on those Things.

I know a little about the Homie standard and I think it woks more like you might expect. I don’t know much about the Home Assistant standard but would not be surprised if it is not suitable to creating one Thing per device with multiple Channels.

8

Installed homeassistant (docker) on a spare raspie zero. There, the Tasmota device is recognized as one device with many channels, everything named correctly. This probably indicates that the json payload (?) for discovery is sent correctly by the Tasmota device and that the <object_id> (?) that should be used to create Things is present in the full topic (?) used by the Tasmota device? All channels that belong to the same physical device have the same device ID in their discovery payload(?) and are added to the correct devices accordingly, I think.

Anyway, auto discovery is working as expected and intended in the homeassistant docker.

Discovery in my openhab instance on the other hand is working neither as expected nor as intended: Having every single GPIO pin plus a few random internal variables discovered as a separate “Thing” is not what should be happening.

I checked wether the json transformation was installed in my openhab instance (it was, it is) - not necessarily because it makes sense; mostly because I remembered that I read “json” in several places and I ran out of better ideas. Not sure what to try next. I’d like to avoid reading or writing any java if at all possible, not sure if there’s a way around that.

Can someone confirm wether auto-discovered homeassistant devices (especially Tasmota) always look like that when auto-discovered in a (properly configured) installation of openhab? Maybe I missed something obvious somewhere.

9

There really isn’t anything you could have done to muck this up. It’s all done in the binding. There is no configuration that controls this. If the behavior you see appears to be incorrect, about all you can do is fine an issue on the binding.

10

Yes,I think I might have messed around with it for too long already. Created an issue here: