aaaargh - you did not want to apt install npm... now that is broken (1.4 is way too old) - please sudo apt-get purge npm nodejs to remove it (and any nodejs), then sudo rm /etc/apt/sources.list.d/nodesource.list to remove that old one, then re-run the upgrade/install bash command (without sudo)... and see which version we get... - it may well re-install 6 - in which case then yes a whole OS upgrade is the way forward.
1 Like
How do you properly install npm then ? As NR doesn't seem install it.
And sidenote, would be a good remark for the documentation how to install it if not installed.
the install script will install it. The version in the default debian repos has been stuck at 1.4 for ever as no one is willing to update it. Using the nodesource repos is the best way.
1 Like
I've just finished installing . . . Buster on the RPI.
Now I have to get the rest of the things installed too.
so if that is a clean Buster install - then run the bash install script (not as sudo) and you should be good to go (for Node-RED at least).
Ok, the story so far:
RPI - running Jessie - and was working with NR.
Something happened and now when I run NR, I am lucky if I get through one DEPLOY, then it locks up. (100% cpu load on going.)
Downloaded a buster image and wrote it to a new SD card.
(Painful. Took about 2 hours.)
Put card in Pi, and danced the dance as it installed. (This took about another 2 hours)
Machine: RasPi 3B with built in WiFi, bluetooth.
NR was already installed.
All sweet with machine. No 100% load. But why should there be? there is no flow yet.
Imported flow and had to install a few nodes to allow this.
100% CPU load.
Not to be out done, I deleted some of the nodes and went to the palette manager and disabled them. Is there a difference between that and actually removing them?
Even after that NR just runs at 100% cpu load. (That is nodes in disabled mode)
node-red-log doesn't really show much. (It is on the new machine. Now, I am not on that machine so can't post)
Quick question:
node-red-log..... That doesn't save anything anywhere so I can't plug the SD card in and copy/paste?
Running node-red --safe allows me 1 (maybe 2) DEPLOY and it is 100% CPU load and just hangs.
Ok, 1. Then when I do the second it just locks up.
This is confusing in that: it used to work. I updated it - and maybe with the wrong command, which may be the cause.
But when I get a new buster install with NR already installed and up to date (and so I don't run the command) and only install some extra nodes does it lock up again.
Something else is going on and I don't have the skills to see what it is.
(update)
On the RPI. (Painful slow)
I loaded NR and decided to try removing some/all of the extra nodes.
I started with one of them and went around editing them out.
Then went to the palette manager and deleted said node.
Still waiting for the browser to not be busy - on that tab.
Interestingly while this is happening, the flow is running, as part of it is to monitor CPU temperature and if it gets above a level, it turns on a fan. (as in to move air)
The fan has been turned on.
CPU load is at about 30 - 50%.
Browser still removing the node.
I'm running on Jessie just fine.
A good install on a Pi looks like:
- Install Rasbian and disable the desktop.
- Run Dave's script (not as SUDO).
That's it.
There are a couple of alternative approaches but if you aren't sure, use Dave's script or at least follow it manually so you understand what is going on.
Node.js should be a current LTS version, I'm still running 8.16.0 on my Jessie version. 8.16.1 on my Pi3 with Stretch. I'm running 10.15.3 on my Windows 10 dev machine.
Never upgrade npm!!!! Upgrade node.js, not npm. This has caused loads of problems over the years. node.js comes with a version of npm that works correctly (except the crappy broken version of node.js that Rasbian insists on installing). If installing node.js yourself, go to the node.js website and follow the instructions for getting their apt repo installed.
Never install anything using SUDO unless there is a good and documented reason. If anyone tells you to, ignore them. Well, unless it is Dave that is 
Use a clean, simple flow to check everything is working as expected.
If you follow the above and are getting excessive CPU, either your flow is causing an issue or you have overloaded your device and you need to chop some things out. Check to see if you are getting high swap rates or other I/O issues. Remember that storage I/O on a Pi is very slow as it uses the SD-Card interface.
Thanks for the reply Julian.
I have (now) moved myself to buster.
I am still watching NR "deleting a node". (How long has it been now? - rhetorical)
I didn't bother installing NR as it came with Buster.
All I did was add the extra nodes needed (yeah, well) for the flows.
Until I updated NR on the original Stret. . . Sorry, Jessie, it was working fine.
Something in that update messed things up.
I have NOT run the update script on Buster. But it is now showing the same problem as with Jessie.
I may have to delete the flow and start again.
Here's the latest (confusing) thing that is happening.
I tested NR with a basic flow and it seems to be ok doing simple things.
I loaded my flow and only installed the needed extra nodes. I went a bit overboard before and installed a lot of nodes I have on other machines which makes porting flows easier.
(But anyway)
Flow seems to be working, but for the Dashboard part of things.
Sorry I can't name the pictures any better, but I haven't got scrot working as good as I would like yet.
1 - shows a node on the dashboard with "MusicPi Telemetry" in the group name.
2 - a picture of the dashboard. I am only seeing the one shown. Note no side menu (top left) as there usually is if there are multiple tabs/screens.
3 - checking. They are enabled on the group tab..
Any ideas?
Sounds like the kind of problem now that’s posted about often on the forum. Something in your flow(s) is causing a strong hog of resources. If it works fine with a tiny flow, but not with yours, you start with an empty flow, then import your tabs one by one. After each deploy and see if it starts hogging. If so, stop importing tabs, delete the newest and import it again but node by node now. If it starts hogging resources now you can find the node causing it. Fix the issue and repeat, until your flow is functioning okay again.
Or import the whole flow, start with --safe and disable most of theflow tabs and deploy. Re-enable one at a time till you get the problem.
However a common cause of lockup like this is an MQTT loop, so I suggest first stopping your mqtt server temporarily and see if it stops the problem. If it does then that gives a big clue on where to look.
Even better!
@Trying_to_learn Did this problem start happening when you were working with the JSON/non-JSON payloads from your other topic? If so, definitely work through any potential MQTT problems first.
As far as I know they aren't related.
@Colin
Even starting in safe mode, I only get 1 working DEPLOY then 100% CPU load.
@afelix
I'm working on it.
All:
I suspect it is the ui_LEVEL node.
The only reason I am suspicious of that because I had it in one flow, and it kept throwing errors at me which I didn't understand.
I cut the node off and the flow/machine started to behave better.
(Just turned the machine on now - the BIG one - after nearly a day of re-building one on Buster or the RPI. A long way to still go with it.)
That is because as soon as you deploy it is running the flows. You need to disable most (or even all) the tabs before the first deploy.
Also have you tried stopping the MQTT server?
That problem is now resolved I hope. As I mentioned I had the ui_LEVEL node in the mix.
Took it out and all good.
And by that I mean I had to uninstall it.
Even if it was in the palette it seemed to be causing problems.
What if you install ui_level again, do you still get those errors? If it was the root cause of your problem, i'd like to investigate but without logs it will be nearly impossible.
Hi.
At this point I have two "dead" RPIs that won't run NR.
I am trying to get them working.
I shall put it in the queue to investigate, but sorry, can't do better than that at this point.
(Actually thinking about it, it may be 3 RPIs need work. I just updated one to Buster and haven't completed setting it up.)
The errors were something about invalid data type. I know that isn't the same words, but the ones used implied that to me.
But on that, for an instance - recently - I got an "output" from ui_LEVEL (I'm sure) but it was more text than graphic.
How do I know/why do I say that?
I loaded a dashboard and there was this unknown text output there.
I opened the editor window and tracked it down to ui_LEVEL.
I moved it to another screen and the said text moved too.
So: I'm guessing that was it.
But to be sure it didn't further complicate things, I deleted it as a matter of precaution.
Sorry. But when I get time I will test it out for you and see what happens.
Ok. I'm a gluten for punishment.
Though a side track this is now on a NUC - with a lot of &alls. A lot more than the RPI.
"Luckily" I had it installed on there too.
I loaded FF and looked. It is there. See the processor load.
Alas I can't snap the CPU load directly (top right of screen) as: as soon as I press the key, the display goes away.
However.
That aside.
Facts:
It has ui_level installed. NR is running - just.
I remove ui_level and the CPU load goes from 98% to about 40%.
Yes, I know it is not definitive proof, but I am calling it as I see it.
It seems to be holding true from the RPI point of view and also NUC stand point.
(oh, 2 RPIs.)
Pictures.
Ok, I know it is also not a "smoking gun" but what/who is this "packagekitd"?
It isn't there when I remove ui_level.
Are you launching these browsers locally on the machine itself or are you using 1 machine with a browser and reach the device/NR via the network ? packagekitd is something that belongs to gnome.
Based on earlier screenshots all NR machines run a full X server with desktop environment, plus VNC to get into them and run the web browser locally. Looks headless with desktop environment iirc.
1 Like
