OH3: How does an Arduino talking MQTT fit into the model?

Setup, Configuration and Use Beginners
1
  • openhabian install with openhab 3.3.0 on rPi4

(starting with OH3, but coming from text-based v2 run as v1)

I am building my model and have a few questions:

It seems I need a thing to get channels?!
E.g. a binding exposes channels.
However, my controllers are mostly Arduinos (UNO, MEGA) talking MQTT via Ethernet wired.
How do I get these into the model or OH in general?
Is there an Arduino thing?
Or is it one MQTT thing with tons of channels?
Or is it multiple MQTT things; e.g., one per controller, and adding a channel per topic?

What about MQTT topics that convey different messages?
I have a topic called inof, which will send firmware version, and status messages for the device.
I am parsing the update to an item via a rule.
Would OH3 required channels that only send one topic?

Any hints appreciated.

2

There is a mqtt binding. With the binding you can add multiple things (e.g. one device = one thing) and the thing can have multiple channels (e.g. firmware version, status message, etc)

There is a generic mqtt thing and the thing can represent any mqtt topic.

1 Like
3

Close.

A binding implements a connection to some technology, API, or protocol. A Thing represents the configuration of the binding. Often you’ll have a “bridge” Thing with the connection information (e.g. for MQTT that has the configuration to connect to the MQTT broker). Then each “device” would be represented with a separate Thing “under” that bridge.

Most of the time those Things are automatically discovered. For MQTT, only devices that follow one of the supported standards can be automatically discovered so you’ll need to manually create Generic MQTT Things.

Forget about that. The model represents how your home is physically laid out from the end user’s perspective. End users don’t care that it’s Zwave, Shelly, MQTT, Arduino, ESP8266, or any of that. What they care about is “this switch controls the light above the kitchen sink.” That’s what your Items should labeled. That’s how they should be put into the Semantic Model.

The technologies they use is irrelevant to the Items and the Semantic model.

Now for the Things, that stuff does matter. But even here, the fact that they are Arduinos doesn’t matter. What matters here the most is how the MQTT topics are laid out. If you are using LWT on your Arduinos, you will probably want one Generic MQTT Thing per Arduino because you can configure the Thing to go OFFLINE if it receives the LWT message.

If that Arduino represents different logical devices, you’d create multiple Equipment from its Channels. For example, one RPi controls both of my Garage doors. I’ve one Thing for that RPi and I’ve created two Equipment from it’s Channels, one for each door.

Note that Items for one Equipment can come from multiple Things too. I have one Front Door equipment which has Items from the smart deadbolt (Zwave), and the open/close sensor (MQTT).

Forget about the model. First just worry about the MQTT Things. Then you can add the Items linked to the Channels in what ever way makes sense. The technical details concerning protocols and technologies do not matter to the model nor the Items.

  1. Create the MQTT Bridge Thing.
  2. Create as many Generic MQTT Things that make sense given how the MQTT Topics are laid out and whether you have your devices configured with LWT. Note if you’ve messages that represent momentary events (e.g. a button press) you probably want to create event Channels for those which can trigger rules directly instead of being linked to Items.
  3. Now think about the logical layout of the home. Create Equipment for those “devices” that, to the end user, would logically be considered a single device. Use “add equipment to model” from the Channels tab of the appropriate Thing and select those Channels that would logically be considered a part of that equipment. If you’ve Channels from a different Thing that are also part of that Equipment, use “add points to model” which will let you add Points to an existing Equipment.

No, that wouldn’t make sense.

Either. It depends on what makes sense to you. Were it me, I’d probably have one Thing per Arduino, but I’d also have my Arduinos registering a LWT.

That’s a little more challenging and IMO an antipattern for MQTT. But see MQTT 2.5 M1+ How to implement the equivalent to MQTT1 REGEX filters. The MQTT binding (and a few others) allow one to chain transformations. So for one Channel you can check for a regex match first and ignore those messages that don’t match. Then you’d have a different Channel(s) for the other messages, each with their own different regex.

You could keep doing that too.

No.

1 Like