Node-RED Very Slow To Start

[Geoff Field]

Greetings all.

We have a Multi-Tech "Conduit" which runs Linux and has Node-RED 0.11 installed thereon.  It includes a "LoRa" long-range radio communications module which we're using to talk to some embedded modules we've been developing.  Here's the contents of /proc/version:

Linux version 3.12.27 (jenkins@frylock) (gcc version 4.8.2 (GCC) ) #1 Thu Nov 17 16:55:55 CST 2016

We had a Node-RED program set up to talk to the radios and communicate with the modules for data and control.  It was working well.

Recently, while trying to debug some new modules that seem to have faulty radios, we were advised to try updating a driver for the radio module.  Through my own arrogance and short-cutting, I ended up nearly bricking the module and had to re-install the operating system.

Fortunately, we had the Node-RED flows under version control, so that part wasn't lost.

However, trying to start the Node-RED editor is currently an extremely tedious waiting game.  Many minutes pass before the splash screen gives way to the bare bones of the editor screen.  Many 10s of minutes pass from then until any nodes are displayed (if at all).

When I think I've managed to re-load the flows, I hit "Deploy" and receive no evidence of the deployment occurring.  Nothing changes.  The radio nodes, which should indicate their status with "connected" or "error", tell me nothing at all.  The all-too-brief pop-up that indicates deployment status doesn't seem to appear.  (I might have blinked each time it happened.)

I have used the configuration file to set the flows directory and to set the debug level to "Trace".  Here's some of the resulting log file:

23 Jan 15:39:37 - [info] Node-RED version: v0.11.1
23 Jan 15:39:37 - [info] Node.js  version: v0.10.40
23 Jan 15:39:37 - [info] Loading palette nodes
23 Jan 15:41:48 - [info] Settings file  : /var/config/app/install/development/settings.js
23 Jan 15:41:48 - [info] User directory : /var/config/app/install/development
23 Jan 15:41:48 - [info] Flows file : /var/config/app/install/development/flows.json
23 Jan 15:41:48 - [info] Server now running at http://127.0.0.1:1881/
23 Jan 15:41:49 - [info] Starting flows
23 Jan 15:41:49 - [info] [lora out:LoRa Tx: J301] lora out node created
...
23 Jan 15:42:41 - [info] [lora out:LoRa Tx: J308] lora out node created
23 Jan 15:43:21 - [info] [lora in:LoRa Rx] lora in node created
23 Jan 15:44:32 - [info] Started flows
23 Jan 15:44:35 - [info] [lora out:LoRa Tx: J301] mcard: true
...
mts-mcard: Error: socket hang up
23 Jan 15:44:58 - [info] [lora out:LoRa Tx: J312] mcard: error
23 Jan 15:44:58 - [error] [lora out:LoRa Tx: J312] Lora mCard not found. Compatable mCards: MTAC-LORA-915,MTAC-LORA-868
mts-mcard: Error: socket hang up
23 Jan 15:44:58 - [info] [lora in:LoRa Rx] mcard: error
...
23 Jan 15:44:58 - [info] [lora out:LoRa Tx: J313] Connected to MQTT for LoRa out node.
Attempting to log in as: admin
Status code: 200
Attempting to log out using token: 23DBD79ED1631242F937B888F1124F2C

The mcard entries (many of them have been redacted here for brevity) tell me it's reading the flows and trying to talk to the hardware.  The socket hang-ups are not totally unusual, unfortunately.

The blank screen, on the other hand, tells me that something else is not right.

As of posting, it's now 16:30 with no update from the browser, although the log now shows a number of "connected" messages with times 16:30:24 to 16:30:29.

I note that our Node.js is one of the unsupported versions.  That's a pain, as I'm not sure our custom LoRa nodes will work with a more recent version.  On the other hand, they don't seem to be working now.

I'm also not sure about the procedure for upgrading the Node-RED version.  I'll discuss with the module vendor about this issue.  It's not an internet-connected module.

Any thoughts other than "upgrade" would be appreciated.  What I have installed is the latest supplied by the vendor.

Regards,

Geoff

[Dave C-J]

Hi, 

Not sure what's going on there. I know the conduit is slow, but after a factory reflash, is not too bad. What level did you reflash it to?

I think for now it is best to stick to the manufacturers version of build as at least that will be more supported.

[Geoff Field]

Thanks for the response Dave.

The manufacturer's reps seem to think it's a CPU load issue.  This morning, top shows the CPU usage as just under 21%, but things seem to be running today (apart from the radio not seeming to receive anything).  Their thought was that there might have been a lot of traffic over the LoRa channel resulting in a high CPU load, but we only have one client active and in range (all the rest are 1200+km away in the Outback).

After rebooting and watching top while starting Node RED, I'm seeing a CPU usage peaking at about 79%, usually in the range of about 66%.  The splash screen stage was a lot faster this morning, although the blank Node-RED editor phase is still pretty slow.

For others online, the platform is an ARM v5.

Official word from the manufacturer's rep is "No need to downgrade and no possibility of upgrade (processor hardware limitation)."

Regards,

Geoff

[Geoff Field]

Actually, I misread top.  CPU load is, indeed, 100% for most of the first 10 minutes of operation.  When I try to load the Node-RED web interface, it stays at 100% for quite a long time.

I'm pretty sure the CPU load had dropped substantially when I came in, but then I did a reboot.

Even a factory settings reset (followed by a user configuration restore) doesn't seem to amend this.

[Geoff Field]

Update: I manually edited the flows.json file to contain just [] and re-booted.  After a few minutes of operation, the CPU load was down to less than 50%.  I then re-imported our flows.json and re-deployed.  This time, a re-deploy only takes about 4 minutes.

I'm still not seeing radio signals, but part of that is due to the fact that somebody disconnected the other module.  The client is here with other modules, however, so I should see them.

[Julian Knight]

Sounds like you are pretty much on the limit of that device.

[Geoff Field]

Oddly enough, there was no indication of problems before I tried debugging the two failed units by replacing the radio network driver in the Linux set-up.