May also need to stop node-red, check that all node-red processes have gone away and then restart node-red.
You can simply stop node-red, delete the ~/.node-red/node_modules folder and then run npm install from the ~/.node-red/ folder before restarting node-red.
As suggested above, check to ensure that all node-red related processes have gone away before restarting.
It was what I have been doing. Or at least to node-red-safe.
I will try again. If node-red-safe is consuming a lot, what do you recommend?
(I have tried re-installing Nore-RED a couple of times since the problem Dave's script.)
Another question. Should I just stop and start NR, or should I do a complete reboot?
Firstly stop nr and check htop to make sure that all of the node-red processes have gone away.
Just going through that now!
node-red-stop - All node-red processes stop except node-red-log
Stopped node-red-log - all stopped
Don't think it is any of the 'other stuff' causing the problem. Down to NR and it's associated apps.
Let's try node-red --safe - node-red --safe
node-red-start - All the other 'phantom' processes are running...
EDIT!!! Original ong was in SAFE mode - this one is RUNNING!
All screenshots filtered with node-red
All looks OK until NR is 'activated', which I would assume is activating node.js
Nuclear Option is on Standby...
That is when it starts your flows. Almost certainly you have a loop in your flows somewhere. Try stopping mosquitto
sudo systemctl stop mosquitto
If that stops the overload then use MQTTExplorer to find what topic is being continually written to. Start mosquitto again obviously.
If it isn't an MQTT loop then disable flows and see which ones stop the overload.
After npm_modules delete and npm install
sudo systemctl stop mosquitto
mosquitto restarted but flow with MQTT IN and MQTT OUT (Single Node only connected to server)
Has to be in here - but this was running OK last week! No changes made.
It has to be in here - one of the original diagnoses. Let me go off and review again. I'll come back when fixed!!
Do you mean that stopping and restarting mosquitto fixed it, without any changes to the flow? If so then that means that it is a conditional loop that can be triggered by some event. Wait till it happens again and then use MQTTExplorer to find the topic.
Do you mean that you only have those two nodes in your complete set of flows, or that you have disabled everything else?
As a side note the 'out of memory' crash was likely a side effect of the processor overload. Node red was trying to do lots of stuff but could not keep up with events so queues of messages built up on nodes until eventually it ran out of memory and crashed.
Mosquitto STOP - see screenshot with sudo systemctl stop mosquitto above it. CPU usage went right down, still 'ghost' processes
Final screenshot shows ONLY MQTT In and MQTT out Nodes connected to server. There is only ONE MQTT In node and ONE MQTT Out node for all of my flows - I have a MQTT Master Out Flow which handles distribution of ALL MQTT messages.
Yup, I figured I was low on Processor Power and/or Memory, but, as I say, this was a stable reliable server until the WiFi Router failed and I 'lost' NR Server due to incorrect DHCP setting in my temporary fix (a far less capable Plusnet Hub One Router). DHCP error fixed (disabled) and all is where it should be in the Network.
Going through MQTT 'Routing' Nodes/Tree now.
I am not sure that is good idea.
I haven't seen any evidence of that. You have a conditional loop triggered by some condition. When it happens again use MQTTExplorer to find the culprit.
Yes, just ticking off the easy to test things.
I don't know that it really makes any difference to be honest.
I use something similar - though I tend to do it at the flow tab level rather than universally. And typically have 2 mqtt-out's, one for retained topics and one for not retained.
But really, everything goes through one set of code and a single loop eventually I think?
Interesting. The 2 MQTT Out(s) is something I hadn't though of. My understanding is that NR is a flow and so you wouldn't get MQTT In or Out messages colliding, but then I am way down the Tech Chain! I just recall some posts suggesting fewer MQTT or Telegram Connections to reduce problems, so that is what I have done.
I think I have located the Link Out to the MQTT Sender causing the problem. Need to confirm and then find out why!
Enable Debug 35 and exercise all your lights etc. At some point you will likely see the debug become flooded with output.
Since you are subscribing to # then every time you output to MQTT you will get it back via the MQTT In node. One of those is not being correctly filtered in the switch and ends up outputing to MQTT again, or perhaps there is more than one topic involved, writing to A comes back via the In node, and causes a write to B, which comes in and causes a write to A again, and so on.
You won't, but having two out nodes, one for retained and one for not makes it easy to see from the flow which ones are retained. I generally do the same as Julian, each flow has two (if required) Out nodes configured as described. The topic is passed via msg.topic.
There is no significant overhead in using many in and out nodes as they all use the same mqtt config node so there will still only be one connection to the server.
Enable debug 35 and you will see the topics being written to.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
