So I actually moved off OpenHAB to Node-Red a while back. I have actually started writing my own automation system based on MQTT before I found it, and frankly, it has replaced my plans to do anything like that because it ended up being so good. I even have Alexa talking through it and controlling everything fairly easily.
Haven't played with the UI / Dashboard stuff though, so thanks for pointing that out.
Just wanted to share my approach as I'm rather fond of it here... I just use a Pi 3 for this.
- Install Rasbian Jessie lite on a card. Expand the file system, set a static IP, etc. as normal.
- Install node / npm, and docker.
- Install docker image rpi-mosquitto and setup to read from /srv/mqtt for config, logs, etc.
- Install docker image rpi-nodered and setup to read from /srv/node-red for config, logs, etc.
- Set up auth on the mosquitto server and the node-red instance. SSL as well is a good idea, but only strictly required on mine because of Alexa.
The next part is you have to get MQTT bridges together for all your devices and start configuring it all. Some of mine:
- Z-Wave I'm using another PI running ZWay / Razberry board. Used a second PI so I could just run their SD image without having to deal with software installations, etc. There software is decent, actually supports secure devices and ZWave plus correctly, but it's limited. Interface is better than most, but admittedly the project needs some work. Still a better ZWave only controller for my setup than anything else out there IMO. One big reason I chose it: there is an MQTT plugin for it that Just Worked.
- Alexa. Ok kind of proud of this one. I built the complete pipeline of the logic involved in standard nodes available in Node-Red. There's some tutorials out there, but if you understand basic web api programming, it isn't difficult.
- Ademco security panel integrated using an ad2pi (again, I favor standalone appliances for this, but you could conceivably run the ad2usb software on the host as well). Also, again, built the entire handling of this using existing nodes in node-red, and one add-on node that handles stream parsing from the socket node. Had this running in ten minutes or so.
- Harmony was a little harder. There were some harmony to mqtt implementations out there, but frankly they left a lot to be desired in my case. So I wrote my own. I'm a .NET dev, so it just runs as a Windows service on one of my servers. It's up on Github somewhere.
- Denon, again, I wrote my own Windows service that handles this. Really only use it for volume adjustment via Alexa, as you can direct set volume levels that way.
- My fish tank. Again, wrote a Windows service for this, that connects to by aqua controller, which I had to write a library to control. Nice during water changes and such when I don't want to touch buttons cause my hands are wet or disgusting, I can just tell Alexa to turn on sump pumps, etc.
I am completely willing to answer questions or help with documentation reviews. OpenHAB would really just replace some of the latter integrations in my setup, but couldn't handle specific pieces for me (secure ZWave devices, etc.)
I will say this: I am completely sold on MQTT being a GREAT standard for interdevice communication and control. Decoupling the device command translation from the core system, lets me use whatever libraries handle that best... regardless of if they are written for my system, in Java, Python, JS, C#, whatever, doesn't matter. I get to choose the BEST implementation regardless of design principles.
My system isn't prolific, but performance, which I've seen a few people ask about, has been a non-issue for me. Reliability has been 100% so far in the two months I've been running this way.
1. If you are not a developer this is probably a non-starter for you. You'll need to be able to at least stumble through some basic JS.
2. It's a lot of configuration. You'll be mapping a lot of MQTT topics to things all over the place, not to mention to logic you will be manually building. Debug logging isn't ALWAYS straight forward to say the least..
3. Yes, you need an MQTT bridge for all your devices, or be willing to write one. Again, developer centric here.
4. As this is my ENTIRE system now, it means that all my phone clients, etc., now integrate to the system by just working against the MQTT server it self as clients. Problem: pretty much ALL MQTT mobile clients leave a LOT to be desired. I've kicked the idea of writing my own, since none of the available ones are open source from what I can find so I can't just add the missing features.
While I would say it's much more powerful than anything else out there for this sort of thing, it's very, very much a developer focused tool.