Node.js update breaks Node-RED restore feature

[Beno]

EPIC firmware 3.3.1 updated versions of both Node-RED and Node.js

Turns out, any nodes that compile or download a native library binary (usually C or C++ code compiled for the local system) when being installed will likely no longer work after upgrading to 3.3.1, which as I said, has a newer version of Node.js.
It looks like the Node.js guys occasionally change something called NODE_MODULE_VERSION, which “refers to the ABI (application binary interface) version number of Node.js, used to determine which versions of Node.js compiled C++ add-on binaries can be loaded in to without needing to be re-compiled.”

The fun comes when you do a groov EPIC Node-RED restore (or update the firmware which keeps flows and nodes and then restores them for you) the bump in Node.js version upsets the compiled flag and so you get the error that @grant1 shows below.

[grant1]

After upgrading our first of several EPICs to 3.3.1, we found that Node-RED will attempt to start but cannot remain running. We see this:

and then it stops and repeats (as you can see by the number of restarts). I am happy to blow away all of my flows as I have copies of the logic elsewhere that I can re-create. Below is a portion of the console log. Perhaps the logs indicate some bad node? (node-red-contrib-serial-modbus?)

9 Nov 18:56:45 - [info] Node.js version: v12.22.1

9 Nov 18:56:45 - [info] Linux 4.1.15-rt18-nxtio-2.1.0+g74af60a arm LE

9 Nov 18:56:47 - [info] Loading palette nodes

9 Nov 18:56:51 - [warn] [RED.events] Deprecated use of “nodes-started” event from “/home/dev/.node-red/node_modules/node-red-contrib-groov/build/src/config-handler.js:82:20”. Use “flows:started” instead.

9 Nov 18:56:53 - [info] Settings file : /usr/share/nxtio/services/node-red/settings.js

9 Nov 18:56:53 - [warn] Use of httpRoot is DEPRECATED. Use httpNodeRoot/httpAdminRoot instead

9 Nov 18:56:53 - [info] Context store : ‘default’ [module=memory]

9 Nov 18:56:53 - [info] User directory : /home/dev/.node-red

9 Nov 18:56:53 - [warn] Projects disabled : set editorTheme.projects.enabled=true to enable

9 Nov 18:56:53 - [info] Flows file : /home/dev/.node-red/flows.json

9 Nov 18:56:53 - [info] Server now running at http://127.0.0.1:1880/node-red/

9 Nov 18:56:53 - [info] Starting flows

9 Nov 18:56:53 - [warn] [modbus-read:303 Dew Point] Client → open node 34e6695c.d99736undefined

9 Nov 18:56:53 - [warn] [modbus-client:USB0] Client → fsm init state after new

9 Nov 18:56:53 - [warn] [modbus-client:USB0] Client → first fsm init in 500 ms Serial@/dev/ttySer0:19200bit/s default Unit-Id: 3

9 Nov 18:56:53 - [info] Started flows

9 Nov 18:56:53 - [info] [inject:228b155b.304ada] repeat = 60000

9 Nov 18:56:54 - [red] Uncaught Exception:

9 Nov 18:56:54 - Error: The module ‘/home/dev/.node-red/node_modules/node-red-contrib-modbus/node_modules/@serialport/bindings/build/Release/bindings.node’

was compiled against a different Node.js version using

NODE_MODULE_VERSION 64. This version of Node.js requires

NODE_MODULE_VERSION 72. Please try re-compiling or re-installing

the module (for instance, using npm rebuild or npm install).

at Object.Module._extensions…node (internal/modules/cjs/loader.js:1057:18)

at Module.load (internal/modules/cjs/loader.js:863:32)

at Function.Module._load (internal/modules/cjs/loader.js:708:14)

at Module.require (internal/modules/cjs/loader.js:887:19)

at require (internal/modules/cjs/helpers.js:74:18)

at bindings (/home/dev/.node-red/node_modules/bindings/bindings.js:112:48)

at Object. (/home/dev/.node-red/node_modules/node-red-contrib-modbus/node_modules/@serialport/bindings/lib/linux.js:2:36)

at Module._compile (internal/modules/cjs/loader.js:999:30)

at Object.Module._extensions…js (internal/modules/cjs/loader.js:1027:10)

at Module.load (internal/modules/cjs/loader.js:863:32)

at Function.Module._load (internal/modules/cjs/loader.js:708:14)

at Module.require (internal/modules/cjs/loader.js:887:19)

at require (internal/modules/cjs/helpers.js:74:18)

at Object. (/home/dev/.node-red/node_modules/node-red-contrib-modbus/node_modules/@serialport/bindings/lib/index.js:14:22)

at Module._compile (internal/modules/cjs/loader.js:999:30)

at Object.Module._extensions…js (internal/modules/cjs/loader.js:1027:10)

at Module.load (internal/modules/cjs/loader.js:863:32)

at Function.Module._load (internal/modules/cjs/loader.js:708:14)

at Module.require (internal/modules/cjs/loader.js:887:19)

at require (internal/modules/cjs/helpers.js:74:18)

at Object. (/home/dev/.node-red/node_modules/node-red-contrib-modbus/node_modules/serialport/lib/index.js:2:17)

[grant1]

UPDATE: I deleted the Node Red Project and everything works again (albeit with no more of my previous flows, but I can rebuild them).

[Beno]

@grant1 Thanks for the update. As you know, we install the vanilla Node-RED, so I was about to dig into the Node-RED forums and GitHub updates to try and see what the core issue might have been.
The Modbus node does push things a bit from what I hear.
The other interesting thing is the way we monitor and restart Node-RED if it crashes. We (Opto) might need to take a look at how we detect and restart Node-RED in conditions like this.
Thanks for the details/log/etc.

[grant1]

@Beno Thanks for the info. So I re-built my first flow using Modbus TCP to fetch some values from a Yokogawa temperature controller. No problems.

Then I re-built second flow which uses the same Modbus Read node, but instead of Modbus TCP, this flow uses a Serial Modbus that uses an RS-485 to USB dongle plugged into the EPIC’s USB port. When I built that second flow and deployed, I got the same behavior as before (Initializing…Stopped…etc.). So again I cannot get back to the Node-Red editor. I can provide current logs if that helps, but here seems to be some indication of what is wrong…

9 Nov 21:32:49 - [warn] [modbus-read:#303 Dew Point] Client → open node 48bb29e23d08d0b0undefined

9 Nov 21:32:49 - [info] Started flows

9 Nov 21:32:49 - [red] Uncaught Exception:

9 Nov 21:32:49 - Error: The module ‘/home/dev/.node-red/node_modules/node-red-contrib-modbus/node_modules/@serialport/bindings/build/Release/bindings.node’

was compiled against a different Node.js version using

NODE_MODULE_VERSION 64. This version of Node.js requires

NODE_MODULE_VERSION 72. Please try re-compiling or re-installing

[Beno]

So, that’s saying you restored a the node from a different hardware architecture than what you are running on.
Did you do a restore or a ‘manage palette install’ from fresh?

[grant1]

I did not do a restore. All I did was update the firmware of the EPIC to the latest version and then tried to run Node-RED. Because it would not launch, I deleted the Node-RED project and started clean. Once clean, I updated the Buffer-Parser nodes & Node-Red-Contrib-Modbus nodes, all using the palete manager. Perhaps I should not have done that? I can delete the project and try again, but this time skip the updates to the nodes.

[Beno]

Just hang on for that.
All we did was update from Node-RED 1.x to 2.0.6. I have done it on my Windows PC with a pretty massive flow file and had no issues, but granted no Modbus nodes.
Its getting late in SoCal, let me check into it in the morning and see what I can find. As I said, its vanilla Node-RED so its just a matter of digging into the Node-RED forums and GitHub.

[grant1]

Thanks Ben. It does not take me long to rebuild these flows, so I will continue to play around some more and will post tomorrow.

[Beno]

Update to this thread.
Opto can reproduce Grants issue and are looking into resolving it or finding a workaround ASAP.

[grant1]

I deleted my Node-RED project, re-installed the 3.3.1 firmware update, rebuilt all the flows and they now work.

[Beno]

Yes, that’s because the reinstall recompiled all the nodes using the latest Node.js, so yeah, very clean, but we are looking into it.

Thanks for letting us know your up and running.
I guess if you have the flows, just putting the nodes you need back in is not toooo bad, but yeah…