I have located the error down to a no longer used piece of code. Trying to work out how it loaded the Computer. Lost some logging for now, but might be able to find out a little bit more tomorrow. We are getting ready as we will have Family with us for the next 3 days.
The error is extinguished for the moment, need to revisit some of my original Nodes. More news as and when...
THANK YOU all for your Input and Help!!
Colin J
I don't think you ever would. Node.js is single-threaded after all and node-red is not, yet at any rate, using other threading techniques as far as I am aware.
Hmm, if you are doing that, it can be quite bad. Don't do it unless you really need to. And what purpose does it serve?
I do this as well. I have a flow on the 1st tab that updates quite a few things related to the sun and moon every minute(using the node-red-contrib-sun-position nodes). Typically for this kind of thing, I update MQTT and update a global variable for the best of both worlds (events and in-memory data).
Ha, been doing that myself over the last few days! 
I had the same issue recently when I added one function with an infinite loop to accommodate SQLite data and manage properties with my dynamic page navigation system. When I deployed the function, NodeRed stuck and crashed; then I had to delete the function from the JSON file and start again; than works. I noticed that the function was pulling almost 95%GB RAM when NodeRed crashed. Then I manage all my start-up type nodes; I have put some time intervals for all my functions, which I need to initialize during startup. And it helps a lot with my memory management and works very well and smoothly.
I traced the problem to a Node causing the JS overflow/100% CPU usage. It had MQTT coming in, but no MQTT out, although it did connect to a page which uploads data to InfluxDB.
I 'rewrote' some of the contents of this Function Node, basically picked up a value I needed from a different source (because I had recently - over 2 weeks ago, written a flow to pick the same data from a different API). After this change of global.get(), I carried out a FULL Deploy, and all was OK. (Always do a Full Deploy on the 'Production' Server, feel safer, even if it is only psychological!)
My question. When NR does a Full Deploy, every single piece of data/script within every flow overwrites what was there before. True?
My worry is that I had a rogue piece of code caused by the shenanigans of the failure of my Access Point at the weekend (power on/off of the server without proper shutdown).
Other than this I have absolutely no explanation of what has been causing the problem. Bascally, I have done nothing other than this change of global.get in a Function Node. The call to the original data point is still there and doing the same job, creating a global.set() for this original point, along with other data. Besides, they are both HTTP API calls, one REST, the other GraphQL and carried out in different flows.
Now things have settled down, I have also changed the MQTT subscriptions, changing the MQTT In # for individual subscriptions to top level topics.
Thank you all for your help, I have learnt a little more about the inner workings of Node-RED and your sage advice led me to the problem. Even if I/We have no explanation of exactly what was wrong.
I've not tested this but I don't think that is quite true. Node-RED starts node processing in several steps. The first step is simply to load the modules that define the nodes. This happens before (of course) the flows start. Node modules may specify all sorts of processing for this phase. This happens once per node (not per node instance). When you do a full deploy, the flows are all stopped (which, I think calls the close callback if specified in the node) and then restarted, this is the 2nd stage where the node definition callback is executed for every node instance. This 2nd stage should, if correctly coded, reset all of the node instances data but it will not reset any data specified at the module level.
If you read through the code in the following, it should hopefully be clearer.
The upshot being that "reset" of data for a node does depend on how the node's module is coded.
At least that is what I think is true!
Thou doth credit me with too much knowledge Sire!
I am really only thinking about my flows and the nodes within those flows. This is where Terminology of Nodes and Nodes within Flows gets confusing when discussing things. (I do get that they are all in the interconnectedness of things).
My simple theoretical model shows Node-RED as a black box to which I input my flows. It is my flows and their contents that I am talking about. Now I understand that the two are 'interlinked', but the Editor and Flow Chart give an Interface that 'suggests' my flows and a Node-RED box that are distinct from each other. Simplistic, I know, but that is how my mind works for this current scenario.
Unless I have a unique NR Node in one of my flows causing a problem, I am thinking that a single Node within one of my flows might cause a problem. This is the reason for clarifying if ALL the Nodes, and their data, within my flows are rewritten.
From what you are saying, I think that some Nodes within my flows might not get rewritten, even if there is no change within that Node. If there is a change, it will be rewritten (I would hope!)
I am thinking of a scenario where the contents within a Node within one of my flows got corrupted during an unscheduled Power Down and when power was restored, that corruption remained,
Hypothetical, in your dreams, not possible, I know, but I HATE faults that are cured with no explanation! ..and no, I am not looking for anyone to find the cause for me. Just figuring out how NR works.
To keep it simple then, if you have not restarted Node-RED, there IS a possibility that not everything in memory will have been cleared down correctly. Not necessarily a high possibility, but non-zero at least. Some of that is down to the node's author(s).
In the case of unexpected power loss, the main danger is that something was in memory that should have been written to disk before close-down. Either that means data loss or data corruption (if data was partially written). Generally, systems work quite hard to avoid corruption for obvious reasons. Though something like a Raspberry Pi has a slightly higher chance than, lets say, a more expensive server or a laptop.
Operating System level corruption can often be checked for with operating system tools. And really should be once or twice a year in home environments where power supplies might be more variable.
At a node.js level, it also tries quite hard to do safe file writes and actual corruption is, in my experience, extremely unlikely, even on a Pi.
Frankly though, I think all of this is not really relevant to your recent issue. It is for background only.
The most likely reason for your issue would be some slight change to the data in some unexpected way that caused something to loop. Reducing the scope of MQTT subscriptions will likely mean that you won't get the problem again. But hey, who knows! Life is more interesting with the occasional system problem to deal with!
Don't like it, but as you say, some things in life just ain't worth the effort!
At least I have a possible, if unlikely explanation for the problem. I blame the Neutrinos!
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
