OpenHAB as binding to MQTT?

1

While studying ESP8266 I liked MQTT Protocol - very simple solution to exchange data between sensors without binding to specific data transfer medium. There are a lot of realizations, free C stacks available. MQTT Server, or Broker was easily set up on Rapberry(Mosquitto) and among all debug features, it generates very nice logs of all messages. By the way message delivery is guaranteed.
Mainly because of that I’m looking into totally new topology of my home automation, which build around MQTT and modularity, not Openhab. The main tasks of all peripherals here - is just a translation of all possible protocols to MQTT messages aka event bus and backwards. E.g. there should be many gateways or bridges: Z-wave <-> MQTT, HTTP <->MQTT , Arduino <->MQTT etc, which communicate with MQTT Broker. On which hardware they all will work - actually doesn’t matters. It can be same Raspberry, or Synology NAS, or Linux Station. The nice thing there is that I can update software on all of them independently and problem in gateway will not shut down whole network.
And for home automation I can use any software which will just work with MQTT messages. It can be Openhab, FHEM and others. Important here is that home automation software is now fully independent of bindings. So I can easily upgrade it without any issues. Furthermore I can use my recorded MQTT Logs to simulate MQTT activity and see how my automation software reacts as many times as I need.
Finaly network setup looks much easier in such approach. I just need a text editor to setup appropriate topics in each node and everything starts to work. I can also make centralized system, where all sensors publish into one topic, and all commands from home automation go to another topics. Or I can do a distributed system, where actuator can be subscribed to sensor topic directly.
What do you think about that?

2

I love MQTT and use it all over the place in my HA system. However, writing a bunch of bridges between different protocols (e.g z-wave <->MQTT) seems like reinventing the wheel. One of the main purposes of openHAB and one of its major strengths is that it already implements a bridge between different technologies. The only advantage that I see is that you won’t be dependent on openHAB as your hub. Seems like a whole lot of work (I know that Chris has spent a ton of effort creating and maintaining the z-wave binding which you would reproduce) for very little benefit.

But perhaps there is some benefit I’m not seeing. But on first glance it looks like a lot of duplicated work to produce what may feel like a more modular architecture but provide no additional capabilities.

3

I would not go this way if I would knew, that there are no bridges available. But hopefully they are. I know, that many bridges already exist (at least required for me) and for the rest I can even use OpenHAB as a bridge for a moment.
My final Idea - I want to isolate rules and actions engine from bindings and communications using MQTT.

4

Just to play skeptic, when I see statements like this I always want to ask "why? Can you state some concrete benefits or is this just a “feels better” architecture?

I agree, separating rules from the communications is a good idea. That is probably why openHAB was built that way with its Event Bus. To me, ignoring this functionality, “THE base service of openHAB,” feels like a case of “Not Invented Here” rather than something that provides actual benefit.

I’m not trying to be mean or defend openHAB’s honor. I want you to think hard about what benefits are you trying to realize, what problem are you trying to solve, and are you actually providing that benefit or solving that problem better than what already exists? Right now, I’m not seeing the benefit nor the problem you are trying to solve.

5

Well, from some point it is like “feels better” architecture.
Basically there are several ideas behind this:

  1. Easiness of setting up the network. The task of binding is just to publish messages to MQTT topic and react on subscribed topics. So I can debug and setup each binding separately just by working with MQTT. Problem of OpenHAB in this case is that it sometimes crashes when binding is not configured correctly, and it’s hard to find the reason.
  2. Different versions conflicts. Let’s say, I have a Z-Wave binding v. 2.1 on OpenHAB v. 1.8. Everything works. And suddenly new OpenHAB version 2.0 realised, but it has Z-Wave binding v. 2.5, which doesn’t work with my network. So I can not upgrade openHAB in this case. With MQTT I have no version conflict - I can use same Z-Wave binding version as long as it works for me and update OpenHAB as much as I want. Version conflict will be resolved using standard interface.
  3. Rules Engine - sorry, but in OpenHAB it’s bad. Real-time performance is not super - I wanted to have exactly 1s delay, and received something like 1-1,3. I guess it’s because of cron. No graphical design, a lot of programming, own language, no easy debugging. The home automation is evolving from year to year. What should I do after couple of years, when I want to add some new feature? I forget everything! Start from scratch?
    So here I would definitely start thinking about some standard way of programming. We could select one of the IEC 61131 PLC programming languages. A lot of ways, simulation capability and finally automatic code generation. Another solution - MATLAB/Simulink - graphical design, simulation, C-code generation. All this is possible if separate engine from communication.
  4. Redundancy - I still think about that. In case of MQTT, the broker can run on one hardware, rule engine on another and bindings on third one. And for example if engine stops working, the nodes can automatically reconfigure itself to emergency distributed operation - e.g. actuators start directly listen to sensors.

All this off course possible if appropriate bridges are easily configurable - I want to check this first.

6

So in short, you don’t like openHAB so you want to use the community.openhab.org forum, a forum intended to help users of openHAB, to help you create something completely new that will compete with openHAB.

You don’t want to use openHAB’s communication bus. You don’t want to use openHAB’s rules engine, and you don’t want to use openHAB’s bindings. There isn’t much else left.

You will probably have better luck getting advice from some other forum. Something more generic. I do not think you will find much advice in this forum.

But I also see some misunderstandings about openHAB.

  1. I’m not sure moving the bindings to a separate service or script that publishes to MQTT buys you much. There will still be errors and crashing if not configured correctly whether or not it is running in openHAB. Also, in my pretty extensive experience, I can say that when an openHAB binding crashes, only that binding crashes. The rest of the addons work just fine.

  2. That isn’t how openHAB versioning works. The addons have the same versions as the core of openHAB. For example, if you are running 1.7.1, the latest stable version of openHAB, all of the addons should also be version 1.7.1. A new version is only released after the core and all of the addons have been tested to ensure they work together. So you would never have a situation where you would be using a 2.1 z-wave binding with openHAB 1.8. Also it is important to realize that openHAB 2 is a complete rewrite of openHAB’s core and bindings so any binding that is a 2.x version will not work with 1.x anyway.

  3. In my experience publishing everything over MQTT is only going to make the real-time performance even worse. And I’ve yet to see or hear about a home automation use case where a third of a second actually makes any sort of real difference when using cron. When using triggers from other items on openHAB’s event bus, on my machines, I’m seeing delays in the 50-100 msec as the longest delays, around 20 msec on average. But my MQTT messages can take 200-500 msec from publishing by the publisher until the subscribers receive it.

There is a graphical rule designer as part of HABmin. It uses Scratch its basis.

If you don’t like programming in Xtend then you can use the JSR223 Engine and write your rules in Python or Javascript. You don’t need a separate engine from communication or from oepnHAB to write in a different and more standard programming language.

I agree, debugging is a challenge and it is one of the major focuses of OH 2.

  1. Running the different parts on the system doesn’t give you redundancy. That gives you load balancing. If you want redundancy you need to run more than one instance of each part of your system which really isn’t feasible for all types of technologies (e.g. there is no way to have a secondary z-wave controller that you can fall back to if the primary one fails).
3 Likes
7

As update - for rules engine I’m looking to Codesys - they have a run-time for Raspberry for just 35$ and free development suite with all kind of PLC programming languages and simulator.
Connection to OpenHAB can be established using Modbus TCP or MQTT - some clients available.