After numerous encounters with having Node Red freeze (or the appearance thereof) and having not the faintest idea as to why, yet spending hour upon hours trying to resolve it, I thought I'd write this up in the hopes that I can help others avoid the long road of misery and understanding I've gone through. Full disclosure, I am not a programming genius by any stretch, I've been using NR for about 3.5 years now and have a better then basic understanding of it.
Usually when the issue occurs, if you open a terminal window and type
HTOP, you'll find
node is always at the top, using > 95% RAM memory. Even when you reboot you find NR either refuses repeatedly to launch or immediately "locks up" again. For reasons way above my pay grade the NR error messages didn't help at all.
When the problem occurs NR will completely ignore the command "
node-red-stop" and even the CLI command "
kill xxxx" (PID) has no affect. So I thought I'd provide some wisdom to others that I've learned via the school of frustration. If this does happen to you I suggest you look in the last location where you were adjusting code and look for the following issues (I'm sure there are others but these are the 2 that kept getting me).
First word of advice, be very, very careful when using loops like
for because NR will live in them forever without any hint to you as to being the reason the RAM just got chewed up and it refusing to run normally. All it takes is to forget the line "
++x" ,or put it in the wrong place, or a similar loop irregularity. I sure wish NR could detect this and tell me about my stupidity in the error messages.
This one may surprise you cause it did me. And it was very hard to track down. I have a bunch of GUI switches (well, buttons actually) that can have a number of modes (Sched ON, Sched OFF, Hard ON, Hard OFF, Offline, E-Save, Hydro Fail). They control BigTimer who sends MQTT messages to the switches and MQTT responses tell the switch what it should look like. If the switch (button) is active you can click it to change between the first 4 modes. It is easier than you'd think to have a loop be created through your MQTT broker when you start doing this kind of thing.
For this I suggest you consider using a delay node set to rate limit on your primary (or every) MQTT IN node. It will prevent NR running away in the loop and provides a visual indicator that something is very wrong.
In the example above you see the
delay node is set to
rate limit to 20 msgs per second. I recreated a fault on purpose to show you how the number appears below the node when msgs start to back up (I saw it go to +1200 once). While at times (like startup) a low number may appear, it should disappear quickly.
Using a delay node this way will prevent NR locking up and give you a visual indicator that you probably have an MQTT broker loop that just keeps sending and receiving stuff. Now you know where to look to resolve it.
(Writing this out is my bit of therapy for having to figure it out, twice).