I’m not a real “programmer”. I learn to hack things as I go, therefore I approach new names, systems and environments with a big hesitation. It’s often a daunting task to start the new language from a scratch not knowing if your venture ends up being useful at all. For this reason, I have been avoiding clicking on NodeRED server icon. Frankly speaking, I didn’t know what to expect, or even what the NodeRED is. Until one day…
I pressed the damned button… I got hooked instantly!
This is the first part of the 7 part series: NodeRED for beginners other parts will be available here:
NodeRED for beginners -NodeRED server vs ad-hoc
If you are a professional code cruncher (why are you even reading this?) you will find the NodeRED probably restrictive. To me, NodeRED is a perfect blend of “I don’t know how to code“, “I found this script online“, “if I connect these two will it work?” approaches. Driven by a purely graphical interface, NodeRED eases you into the world of node.js.
It starts with drawing a line between “nodes” to achieve a simple outcome. Once you master connecting the dots, each node opens a world of customisation, user-generated versions and pure function editors to unleash your inner (amateur) programmer. NodeRED can be as simple as you want it to be and as sophisticated as you can imagine.
The best thing is: You can run it on virtually anything. A microwave would run NodeRED server. But why buy a microwave when you can use Raspberry Pi Zero to run a completely capable server for $5? This leads me to the next question: Why would you need a server in the first place?
Why Server architecture?
The world figured out a long time ago that the server structure will be always superior to anything else (apart from niche, edge case scenarios). You could continue your personal crusade of introducing ad-hoc connectivity to every new device, but I want to argue my case against it. The sooner you jump to server organised structure, the easier your life becomes.
But don’t take my word for it! Let me show you a simple example. A long time ago I have created a Wake on LAN project to control my Desktop PC as the years went by, I scrapped the original ad-hoc style solution and rebuild the WOL system with a NodeRED server architecture. Here are key points to consider:
WOL – wake on LAN example
Waking up a desktop PC using a mobile device.
In your typical ad-hoc configuration – a phone would send the magic packet with correct details to the IP of the device you want to wake *(I’m using WOL app). If you want to have a feedback once the device is online, the target device has to be configured to notify the phone issuing the WOL request.
For each phone/user/computer, this process has to be configured separately on every device.
In this approach, another device (server) is introduced. You may be thinking that it creates an unnecessary cost and complication for a relatively simple task. Your thinking would be correct if you only consider the server use for a single task. The server is a (cheap) investment. You can take a look at one of the ways of doing it here. The Amazon Dash method will be also covered later on!
The WOL request is sent to the server, where once processed the magic packet is sent to the correct device. If a feedback is required the target device is configured to talk to the server only. The server will handle the feedback and send the notification back to the phone or all devices required.
Each phone/user/computer has to be configured once. In addition to that input devices only need to issue HTTP requests rather than have designated WOL software.
Instantly, you will notice the benefit of this approach. The server architecture is scalable, more flexible and easier to maintain. You can introduce new devices without recreating entire setup. As long as you send the correct information, the server will know what to do.
At this point, I can use virtually anything to be the trigger. I’m no longer limited to a single device (or device type) or what causes the WOL request to be sent.
Lastly, your NodeRED server will continue to operate, even if the internet is down. As long as you have no issues with your local network – your flows won’t be affected. Bear in mind that services in use that require internet access (like speed test, voice control) won’t work offline on their own.
It’s true, setting up a NodeRED server for your first home automation task may sound like a lot of work, but give it a go. With time, I can assure you, that you won’t regret your decision. If you already feeling comfortable with NodeRED – check my other projects out:
Otherwise, stay tuned for part 2 where I’m going to talk about getting your NodeRED up and running.