OH3: Shelly Bindings vs MQTT (Mosquitto vs embedded MQTT)

This is my first time using openHAB and also the first time that I am using any smarthome automation devices and software at all.

I got myself some Shelly 2.5s which are configured as roller shutters.
Right now I am reading around, creating+testing some configs and trying to understand everything.

One big decision I will have to make now (I guess) is Shelly Bindings vs MQTT.
1. Based on your experience, which one should I go with?

I already read that MQTT is much faster in terms of reaction times.
2. But apart from that which of the two bindings will give me the most information and control capabilities for my Shellys?

What I was also asking myself…
3. Should I use an external MQTT broker (f.e. Mosquitto) or the one that comes with OH3?
Which one is more future proof / more reliable?

4. If I am going to use the external MQTT broker: Can I install and run it on the same host my openHAB install runs on?

I hope you guys can answer my 4 questions. :+1:

I have tried both, but converted everything to the binding.
when I got my first Shellies, there was no binding, so MQTT was the only choice.
The biggest drawback ist the lack of co-existence of MQTT and the Shelly cloud.

The speed is more or less neglectible in the meantime after Shelly improved the CoAP implementiation a lot. The binding uses CoAP preferably.
With the binding, I have all I need.
MQTT might give you some more details.

There is no more embedded MQTT broker bundled with OH3 anymore. I recommend to use mosquitto which can be easily installed through openhabian-config.

Yes, no problem unless you run a very weak system.

3 Likes

A broker comes with OH3? I did not know that.
I know the one with OH2 had been abandoned to everybody moved to mosquitto. That is about all I know about MQTT & OH.

To clarify: no, it does not, as @Vogelrain said.

From the release notes:

The “Embedded broker” (Moquette) add-on has been removed due to Moquette being an abandoned project with major bugs that won’t be fixed anymore. Please use a separate MQTT broker like Mosquitto instead.

I fully agree with everything @Vogelrain mentioned! Additionally, the beauty with openHAB is that you can just try both approaches, and see which one you like best!

(Though, if these are the only devices you’re likely to use with MQTT, then I’d probably just stick to the binding - means you don’t have to install and maintain an additional thing separate to openHAB [not that Mosquitto has required any maintenance in my experience, but you get the point!])

2 Likes

There needs to be a big banner on this site that the forum is not a substitute for reading the Release Notes & documentation!

Thank you all for the input! Especially @Vogelrain!

@Bruce_Osborne Sorry I didn’t read the release notes, but as I said it is my first time using OH and all the guides out there are mostly still for OH2. This is way I was assuming that there is still a built-in broker.

I will go with the Shelly Binding for now as I did some additional research and as far as I can tell both CoAP and MQTT have their pros and cons. But none of them is to be considered bad.

I use MQTT for my shellies; I found it easier to batch-configure them via the .things and .items files and I already use MQTT for other devices on my network. Also, the major advantage is that the individual devices aren’t defined by their IP addresses. In my (rather sprawling) setup with many AP’s, subnets, etc. I didn’t want to deal with assigning static IPs for all the 70+ shelly modules and can simply refer to them via their name over MQTT. If there were some sort of address conflict, It would’ve been annoying to debug and fix, and with MQTT, debugging is trivial as I can just watch the traffic scroll by on any terminal.

The disadvantage is that the setup is slighly more complex and requires some understanding on how to parse json with mappings and it requires manual code to detect if one module has gone offline.