Node-RED on a RPi 3b+ (and death of a micro SD)

General
1

Hello everyone,

I'm working on a garden automation project and it was going rather well. I designed a modest weather station using pieces from my Arduino starter kit that uses Serial.print() for sending data. On the Arduino I can see data on the serial monitor and the data is in CSV format for simplicity.

On my Pi 3B+ running Buster and an older Node-RED installation, I had several gauges and graphs running from the CSV data from serial. Worked nicely (if a little non-performant). The Pi crashed and I found that the microSD card was bad so I replaced it and installed the latest RPi OS Lite 64-bit from the RPi installer utility onto a new SD. Booted, did an apt update/upgrade, etc and then did an install of Node-RED using the script on the NR page for RPi.

bash <(curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/deb/update-nodejs-and-nodered)

Started up NR, connected to 1880 no problem. NR sees the Arduino on /dev/AMA0 but there is no data appearing in debug.

image

image

node-red-log shows:

<--- JS stacktrace --->
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb712a4 node::Abort() [node-red]
 2: 0xa93f08  [node-red]
 3: 0xd3bb10 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node-red]
 4: 0xd3bce0 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node-red]
 5: 0xf1a26c  [node-red]
 6: 0xf1aed4 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node-red]
 7: 0xf2b424  [node-red]
 8: 0xf2bfe8 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node-red]
 9: 0xf2d1b4 v8::internal::Heap::FinalizeIncrementalMarkingIfComplete(v8::internal::GarbageCollectionReason) [node-red]
10: 0xf3078c v8::internal::IncrementalMarkingJob::Task::RunInternal() [node-red]
11: 0xe154b0 non-virtual thunk to v8::internal::CancelableTask::Run() [node-red]
12: 0xbd3ad4  [node-red]
13: 0xbd6f08 node::PerIsolatePlatformData::FlushForegroundTasksInternal() [node-red]
14: 0x15e098c  [node-red]
15: 0x15f2ac8  [node-red]
16: 0x15e13f4 uv_run [node-red]
17: 0xac1ad0 node::SpinEventLoop(node::Environment*) [node-red]
18: 0xbb0698 node::NodeMainInstance::Run() [node-red]
19: 0xb309e4 node::LoadSnapshotDataAndRun(node::SnapshotData const**, node::InitializationResult const*) [node-red]
20: 0xb3414c node::Start(int, char**) [node-red]
21: 0x7f82615e18 __libc_start_main [/lib/aarch64-linux-gnu/libc.so.6]
22: 0xac0000  [node-red]
nodered.service: Main process exited, code=killed, status=6/ABRT
nodered.service: Failed with result 'signal'.
nodered.service: Consumed 6min 18.297s CPU time.
nodered.service: Scheduled restart job, restart counter is at 129.
Stopped Node-RED graphical event wiring tool.
nodered.service: Consumed 6min 18.297s CPU time.
Started Node-RED graphical event wiring tool.
14 Sep 12:04:52 - [info]
Welcome to Node-RED
===================
14 Sep 12:04:52 - [info] Node-RED version: v3.1.0
14 Sep 12:04:52 - [info] Node.js  version: v18.17.1
14 Sep 12:04:52 - [info] Linux 6.1.21-v8+ arm64 LE
14 Sep 12:04:54 - [info] Loading palette nodes
14 Sep 12:04:58 - [info] Settings file  : /home/sean/.node-red/settings.js
14 Sep 12:04:58 - [info] Context store  : 'default' [module=memory]
14 Sep 12:04:58 - [info] User directory : /home/sean/.node-red
14 Sep 12:04:58 - [info] Projects directory: /home/sean/.node-red/projects
14 Sep 12:04:58 - [info] Server now running at http://127.0.0.1:1880/
14 Sep 12:04:59 - [info] Active project : Garduino
14 Sep 12:04:59 - [info] Flows file     : /home/sean/.node-red/projects/Garduino/flows.json
14 Sep 12:04:59 - [info] Starting flows
14 Sep 12:04:59 - [info] Started flows
14 Sep 12:04:59 - [info] [serialconfig:8ff5956d95db737e] serial port /dev/ttyAMA0 opened at 9600 baud 8N1
14 Sep 12:08:22 - [info] Stopping flows
14 Sep 12:08:24 - [info] serial port /dev/ttyAMA0 closed
14 Sep 12:08:24 - [info] Stopped flows
14 Sep 12:08:24 - [info] Updated flows
14 Sep 12:08:24 - [info] Starting flows
14 Sep 12:08:24 - [info] Started flows
14 Sep 12:08:24 - [info] [serialconfig:8ff5956d95db737e] serial port /dev/ttyAMA0 opened at 9600 baud 8N1

Under Buster (before it got busted) things worked swell. But a fresh install on Bullseye is causing untold amounts of heartburn. I did notice that the systemd process runs node-red and not node-red-pi. Behavior is the same, however, when I manually run node-red-pi --max-old-space-size=256. A quick look at these NR scripts suggests that they are not RPi aware.

So that's the story and the problem. Could I trouble the forum for some thoughts?

-GG

2

Most likely you configured the Input fields from the serial node different then in your busted installation.
Try setting it like this, you should have at least some output.
Capture

3

Thank you for your assistance. The Split Input setting was set "on the character \n" so I've adjusted the input block to match your suggestion. Sadly, no changes after that update.

But all is not lost! Your advice prompted me to poke around with the serial node some more. I found that there are now two serial devices that show up when configuring a new serial node:

image

I originally had /dev/ttyAMA0 configured. When I went back in to serial configuration now see /dev/ttyACM0. When I created a node for /dev/ttyACM0 I saw the serial data.

image

This confused me since I don't recall seeing /dev/ttyACM0 when I configured the serial node initially. My Google-Fu is not so good but I did find an article at RPi Serial Connection - eLinux.org that had a small annotation for RPi 3:

The Raspberry pi 3 has changed things around a bit: ttyAMA0 now refers to the serial port that is connected to the bluetooth.

Apparently "ACM" in the device name stands for "Abstract Control Mode" which looks to be a communications standard. Based on this post, /dev/ttyACM0 is ephemeral and can disappear on a reboot so my fingers are crossed that this doesn't happen too often.

At this point my eyes are crossing and I've realized that I'm not ready to dive too deep into this. I can see data and my meager brain will accept this as a win.

Thank you for directing my focus to the serial node.

-GG

4

Have a look at this;

1 Like
5

Do yourself a favour and track down the more fixed name for the device you want to manage. The problem with the generic serial port names is that they can easily change on reboot which is super confusing.

Here is an example from my live server. I use the more complex but reliable form:

/dev/serial/by-id/usb-RFXCOM_RFXtrx433_A1Y06XVZ-if00-port0

To track down the correct name, you can usually get away with just getting to a command line and doing:

ls -l /dev/serial/by-id/

You should get output that looks something like this:

image
image888Ă—86 5.06 KB

If the names don't make sense, try issuing the sudo dmesg command and wade through the startup messages looking for your serial port startup's You should spot the device you are interested in.

2 Likes
6

This information is going to be quite handy when I move to more permanent fixtures and putting things onto the Pi's pins. Thank you!

7

I've been around Linux since '93 and I did not know the by-id trick. I'm learning a lot today!

image

I've updated my serial node to use this device now and things look good.

image

The only issue that vexes me now I suppose is the constant process restarts and OOM. I expect this behavior when running on a Pi but I can run Minecraft on it so Node-RED should be okay too. I might have Node-RED scaled too small for this Pi model. It's got ~500GB free of ~1GB. I'll try running it without the --max-old-space-size=256 set in the parameters.

Thank you much for your help!

-GG

8

Try removing the max-old-space parameter, it shouldn't generally be needed with newer versions of Node.js anyway. I ran Node-RED and a ton of other stuff on my RPi 3b+ for years without problems.

1 Like
9

Station Garden Gnome is back on the air! :sun_behind_rain_cloud:

image
image966Ă—681 29.5 KB

Thanks for the help!

-GG

10

Dropped that parameter and have had zero issues. Running fine for a couple hours now!

-GG

11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.