Perhaps I had some other problem that I assumed was the GUI.
It doesn't bother me as all my rpis run headless and most have never even had a display plugged in. I burn Raspbian Lite and have a script that puts in the wifi credentials, host name, etc for me so I can just plug it in and do the rest via ssh.
Simon, we all know that you use SCRATCH for your reactor controls 
1 Like
I used to 
But I saw the light and moved onto Node-RED
Of course, I mainly use @BartButenaers Scratch inspired Blockly node for most of my logic so I never really switched
Detect number in Alexa received text
Transcode IR Signals
6 Likes
I propose to use DietPi on the Pi Zero. I have all my Node-RED instances running on it.
DietPi is optimized for small footprint (e.g. RAM) and easy installation processes, especially for headless applications.
See there:
DietPi comes with special "one-click" installers, also for Node-RED: Hardware Projects - DietPi.com Docs.
1 Like
Just to provide a data point: I have been running a fairly complex house automation system based on Node-RED for the last four years on a Pi2 without any performance or stability issues. I do try to keep message frequency low (how often do you need to check the water temperature?), but some things are polled at second intervals. Flow deployments take maybe 10-15 seconds, and both admin and dashboard UI feel responsive enough not to bother me. RAM usage is high; around 80%, but I think that's slightly misleading; Linux likes to use what RAM is available and there's no (or very little) swap being used. Despite running off a cheap 16 GB MicroSD mounted R/W, and having the occasional "sudden death", I have I have not experienced any reboot failures. I do have a beefy (18 Ah) lead-acid battery backed UPS power supply, but even that runs flat from time to time (mains power can disappear for days here).
Slow deployment can really be based on how fast nodes shutdown and start up. The shutdown event needs to be asynchronous behavior and then just allow NodeJS management of events to manage the final cleanup. If you are using sockets or other I/O on a limited environment, such as the pi-zero, it make sense to keep I/O close events away from the main flow of shutdown. For any nodes you have created, watch for close events and output some text to show the flow of shutdown so you can evaluate where the real slowdown is occurring. One of the ways to really make it slow is to forget to send back the "done()" call back from close.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
