Hello,
I have read a lot about Node-RED and about its importance in IoT projects. I am going to use on my Raspberry server where Homebridge and MQTT servers are already running.
I understood all about programming and flows (I am a Python programmer).
However there are a couple of points that are not clear to me.
First, is what happens then when a flow has been written and deployed? Whats does deploy mean? Shall it be compiled and run as a stand alone software or? (always in a Raspberry environment).
For instance I want to get some values from MQTT and publish then somewhere. What shall I do after having written the flow?
Second question, this time in an HomeBridge environment. How can I integrate/import Node-RED flows into Homebridge?
For instance I want to create a new accessory called Toggle Switch that switches on an existing accessory if it is off and switches it off if it already on.
How shall I combine Node-RED with Homebridge?
Thanks for the clarifications,
Dan
Node-red it is not standalone but runs on the nodejs runtime (server based javascript engine).
When you deploy the flow is not being compiled, but more like re-initialised/instantiated and it is written in a "flows" file (which describes the type of nodes, location on the screen and it configuration).
Homebridge also runs on nodejs, but is a separate program, there is no such thing as "importing into homebridge" - it is more like working in conjunction with homebridge.
To simplify the concept of node-red: if you want "incompatible" devices to talk to eachother, you can use node-red to handle the translation/transcribing/executing of messages/events/actions. It is like a extremely powerful glue and sits in the middle (and definitely not only for IoT).
To use node-red with homebridge I would definitely recommend homebridge-mqtt and remove most (if not all) devices from homebridge and use homebridge-mqtt exclusively
But before you investigate that, first install node-red and try to get around in it.
3 Likes
You add a mqtt-in node which "listens" to (actually subscribes to) one or more MQTT topics. Whenever your MQTT broker updates a topic, all subscribers get notified and in the case of an mqtt-in node, that triggers a msg to be output from its output port. So whatever you have connected (other nodes) downstream of the mqtt-in node will start to get that msg, each node in turn unless one of the nodes blocks it.
It is far easier to play with than to describe 
1 Like
I use Rode-RED in a Raspberry environment.
What is not clear to me is what happens when I write a flow and then I deploy it. Let’s assume the flow checks the pin 5 of the Raspberry gpio and send its status to a database.
Does this piece of software run continuously in the background once deployed or has to be launched as every application?
Then what happens if I write several flows, do they run in parallel continuously?
And how to stop one flow from running?
Coming from software development (write code, compile and run), I am missing the basic concept of this infrastructure.
Can anyone please explain?
Thanks!
Dan
The Node-RED runtime is a long-running process in which all of your flows are constantly running. The runtime acts as an interpreter for the flow configuration the editor gives it. In an object-oriented view of the world, each node in the palette provides a subclass of a Node object. When a flow is deployed, the runtime creates an instance of each node in the flow and deals with the routing of messages between those nodes.
In the example you describe, with the GPIO pin, the flow doesn't do a one-off check of the state of the pin. Instead it listens for any change in state of the pin, and whenever the pin state changes it triggers the flow.
All of the nodes are running all the time - which is to say, they have all registered event handlers with the runtime for when there is a message for them to handle. The exception being the nodes at the start of the flow which will be listening for whatever external events they are triggered by (GPIO pin change, incoming HTTP request, etc) The nodes aren't constantly chewing CPU - they are waiting for the runtime to give them a message or the external event to trigger them.
To stop a flow from running you can either delete it from your workspace and redeploy, or disable the node (option in the footer of each node's edit dialog) and redeploy.
By default, when you deploy, the runtime will stop all nodes, discard them and then recreate new instances of all the nodes in the new configuration. But the deploy button has two other modes (click the drop-down arrow next to the deploy button to see them) - where the runtime will only restart things that have changed and leave unmodified nodes running, uninterrupted.
4 Likes
