Hi there. Decided to create this topic, as I greatly impressed by capabilities, which Node-RED brought to my smart home when I migrated to it from OpenHAB Rules. It’s a kind of continuation of this topic.
The idea is simple - Node-RED is a great visual tool, designed by IBM, which allows creation of aka IFTTT rules. It is based on MQTT and thus event-oriented message-passing behaviour across different nodes. E.g. message triggers execution of the node, as it passes from one node to another along the lines. Each node can perform some action on the message - block it, change it, delay, route to another path or perform some Javascript.
Node-RED designed to provide connectivity for IoT world, therefore it’s like a competitor to OpenHAB in this sense, but I don’t propose to utilize it as connectivity tool - I think OpenHAB has a great value here, by having all those connectivity bindings. Instead I propose to use Node-RED as purely hardware-independent rules and scripting engine.
E.g Openhab works as a gateway to convert all possible protocols to (logical) MQTT protocol and vice-versa. And Node-RED uses these MQTT messages as inputs and outputs of the rules.
Just some example - following rule realizes motion-controlled light with darkness detection and brightness, controlled by luminance sensor.
All graphical. No programming, Java, Lua or Python.
But there are more nice features in Node-RED:
Easiness of debugging. Just place inject and debug nodes anywhere in message flow, connect them, and you can easily simulate all functionality without any I/Os, by clicking on the squares near blue nodes - this will generate test messages and whole algorithm can be easily verified without any risk to destroy your boiler or disturbing your house-mates by moving rollershutters all day.
HW Independency - as I/O interface for Node-RED is MQTT, designed in Node-RED rules can work with any type of sensors - Z-wave, KNX, Arduino and even not only Openhab but any Home Automation Software, which supports MQTT.
Sharing - Node-Red provides simple JSON-based copy-paste functionality, so that everyone can share it’s algorithms. For example algorithm above is available here for immediate download.
Stability - for 2 months of usage and after 4 deployed rules I had no problems with stability of Node-RED, or exception issues - it just works.
So I propose just to try it - the installation is easier than Openhab. I’m thinking of creating some tutorial, if anyone shows more interest, but typical steps are: install Node-RED, install MQTT Broker(Mosquitto, for example), install and setup MQTT event bus Binding in Openhab and you are done.
I think this posting, with a little minor reformatting, i.e. present it as a step by step installation, configuration, and test procedure, would make an excellent article in the Tutorials and Examples section. @ThomDietrich, what do you think?
I’m curious to know how well it handles some of those tricky edge cases that keep popping up, though I’ve far too much on my plate to try it out myself right now.
New to openHab here but it’s likely I’ll need to use Node-Red to integrate a legacy system which doesn’t have a binding.
I have a 15 year old comfort alarm system which has a lot of logic control, inputs, outputs etc. It functions as an alarm, voicemailbox, lighting control system, IR blaster etc. etc. It’s possible to connect to it via serial, USB Ethernet etc. (I have the serial connection). The idea is that I’d like to use a lot of the existing sessors and functions from Comfort but integrate it into my openHab setup. No point in reinventing the wheel, right?
User Cab123 on the Comfort forums has published a driver of sorts in perl that retrieves data from the Comfort bus and publishes it to MQTT. From there, it’s loaded up into Node-Red where functions are used to parse the Comfort protocol and convert them to more meaningful payloads that are passed back to MQTT and into openHab for processing.
Looking at all of this, I see node-red as part of a toolchain that helps openHab rather than a direct replacement for its rules engine but you never know, as I get more involved, I might find other uses for it (it’s got inbuilt twitter sentiment analysis - imagine running devices in your home based on the tone of tweets at particular twitter users!!!)
Anyway, I have openHab set up in a windows VM on unRAID. I’ve already interfaced this with the comfort system over a serial connection and intend running the perl driver there as well. I’ve set up MQTT and Node-RED as dockers on the same unRaid system.
I’ll be writing up my progress on my HA blog but would be happy to contribute to any articles here as well once I figure it all out.
Well, my dream is a portability of rules. Rules should be a kind of ecosystem or library, where everyone could pick up interesting things, try them and integrate into his automation with minimum effort. To make it evolving and getting bigger , these rules should be HW independent and run on any kind of platform - in controller or in cloud. Node-RED suits these needs quite well.
I currently have light control above, simple thermostat and couple of dimmer rules. Next step is to bring there good roller/shutter control and more intelligent thermostat.
Hello @Artyom_Syomushkin,
this sounds quite promising. I Iooked into Node-RED some time ago but wasn’t sure what’s the benefit and how far the provided blocks go. I’m very interested in the Inject and Debug possibility and the programmable blocks (as a last resort).
Where would you see the limitations of Node-RED when it comes to, as @rlkoshak said, the “tricky edge cases”?
Did you compare the execution speed betweenthe following two?
Sensor—openHABRuleEngine—Actuator
Sensor—openHAB—MQTT—NodeRED—MQTT—openHAB—Actuator
Is there a better way to integrate NodeRED, other than by MQTT? Was a better way proposed, which upsides would a deeper integration offer?
I woud encourage you to extend your article into a Tutorial and also move it to the according section! The chapter on installation can be pretty short. A few more examples showing the different possibilities would be great.
Well, it’s @rlkoshak said, not me. I also would like to know, what are those cases.
My impression from openHABRuleEngine was that it is slow when it’s throwing different exceptions. MQTT—NodeRED—MQTT path can be easily profiled by logging MQTT messages. Currently I observe maximum of 10ms delay in Node-RED processing. In my case I have also panels connected to MQTT directly, so here Openhab is eliminated.
Anyway I don’t see any problems with latency here. Z-wave has it much bigger.
MQTT looks like a very preferable way, as in OH you can setup event bus binding, so that all items and commands are pushed or read to/from MQTT Broker automatically. In this case you don’t need to write any binding in individual items. This greatly simplifies things, as such configuration should be done only once for whole project.
Sure. I have already made tutorial in russian. Just need to translate.
The kinds of things I’m thinking of and have had to deal with:
timing issues where events trigger rules very close together that need to use the same resources; mitigations include sleeps, locks, sequential execution as opposed to parallel execution
changing behavior based on multiple combinations of states, complex state machines
latency sensitive operations like manually implemented dimming of lights
events that occur too quickly and need to be filtered to avoid conflicts or hitting rate limits on an API (e.g. hitting weather REST APIs, Nest API, etc)
unexpected/invalid values, input validation, verification and cleansing
unexpected error handling
There are more but I would have to scour my rules and the forum to find them. NOTE: OH doesn’t do a particularly good job with all of these either. But there are workarounds. My experience with these graphical coding environments is they work great in the regular case but as soon as you hit one of these edge cases they either can’t handle them at all or handling them is way more complicated than just writing the code as text in the first place.
I wouldn’t expect a getting started like tutorial that we are all talking about to cover these things in depth, but given that about 80% of coding time and >50% of total code is spent dealing with theses types of issues it is important to understand.
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.
So downsides:
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.
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…
Yes, you need an MQTT bridge for all your devices, or be willing to write one. Again, developer centric here.
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.
Thanks Michael for your description. Very interesting to hear, how you bind everything to MQTT, but what is your particular usage of Node-RED? Do you have any algorithms running already there?
From an automation perspective, not too much. Mostly just some time based events for making sure lights and fans are off during the day, that the garage is closed at night, etc. From a command standpoint, MQTT is a message queue, so all the normal concerns around a distributed system and message order apply here. I could, for instance, totally setup something that turns lights on when a motion detector signals, and a timed event that turns them off at that time and they will conflict. I’m sure I could whip something up with the existing system I have to handle that, but it would basically mean adding real persistence and state comparisons that I don’t do right now.
There are persistence nodes you can integrate so you could conceivably create things like last state change tracking and such (i.e., event says trigger, logic in event says the door was opened less then 5 minutes ago, so don’t close garage door, etc.). Right NOW my system is pretty stateless, except for the MQTT persistence (i.e., a new client connects and it gets sent the last published message for every device topic, meaning the current state).
Just for info. It’s hard to resist user-friendliness of Node-Red also in bindings.
I just wanted to have an event on sunrise and sunset for my rules.
In Openhab I have to install Astro Binding, configure location on openhab.cfg, and define event items (hopefuly copy-paste). So one command and 2 file edits.
In node-red - just install suncalc library and you get nice block with all needed configurability right away. And it’s shows current status right under block for debugging! Cool!
This thread proved most interesting to me. As it happens, I have been using Node-Red too along with MQTT. However, rather than try and replace OpenHab (of which I’ve been very happy), I use it to send state data via the Persistent MQTT plug-in, to a Microsoft Azure IoT Hub. Currently the only thing I do with all this data is dump it into a database. Lack of time. I find that the free IoT Hub is adequate for this.
To accomplish this I threw together a Node-Red module that would understand OpenHab MQTT state input and convert it to JSON for Azure IoT which allows one to run Stream Analytics against the input. It’s smart enough to interrogate OpenHab for the device type so that can be included with the device name and state.
Should anybody be interested in the code, the Node-Red module is on GitHub. Code is reasonable but it is not packaged as an npm. You can find it here: https://github.com/markrad/OH-AzureIoT.
I had been planning to write my own scheduling utility to work with OH, but it looks like I can leverage Node-RED for everything I need (the node-red-contrib-schedex node looks perfect for my needs).
Artyom, thanks for great topic. I’m newbie in OH but already could feel all pain with debugging rules. Installed NR and it looks great, but there is something not clear in my mind
How will item definition look if i want to combine custom protocol with MQTT? Below use cases:
Item gets event from outside and should forward it to MQTT. I described item as below
As result, item state is updated correctly by event from custom binding, but OH doesn’t forward change status to MQTT. If i change item state via UI then i get messages in MQTT. Should i forward change status to MQTT by rules in this case?
The same scenario in opposite direction - NR made a decision and now i should send a command to device via MQTT-OH-custom binding.
Can you shed light on details of such configuration?
There is no need to bind every item individually - you just use Event bus binding configuration, as described in https://github.com/openhab/openhab/wiki/MQTT-Binding
E.g in my openhab.cfg file I have following definitions for MQTT:
Mosquitto broker in my case runs on the same machine.
As a result all events automatically appear as MQTT messages and you can send commands to /myhome/command/${item}/state topic - and these will be processed by OpenHab
Michael, any chance you can (after removing security stuff) share you Alexa flow?
Or if you copied it from somewhere can you send a link to the material you used?
