Node-red 18.0.0 won't start (SOLVED, see post 24)

Third party integrations Node-RED
1

I updated Node-Red add on (18.0.0) and now Node-red won’t start.
Here is the log output. Any ideas to fix this would be appreciated.

> start
> node $NODE_OPTIONS node_modules/node-red/red.js --settings /etc/node-red/config.js

/opt/node_modules/@node-red/util/lib/util.js:772
                })
                 ^

SyntaxError: Unexpected token ')'
    at internalCompileFunction (node:internal/vm:76:18)
    at wrapSafe (node:internal/modules/cjs/loader:1283:20)
    at Module._compile (node:internal/modules/cjs/loader:1328:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1422:10)
    at Module.load (node:internal/modules/cjs/loader:1203:32)
    at Module._load (node:internal/modules/cjs/loader:1019:12)
    at Module.require (node:internal/modules/cjs/loader:1231:19)
    at require (node:internal/modules/helpers:177:18)
    at Object.<anonymous> (/opt/node_modules/@node-red/util/index.js:19:14)
    at Module._compile (node:internal/modules/cjs/loader:1364:14)

Node.js v18.20.3
[12:35:56] INFO: Service Node-RED exited with code 1 (by signal 0)
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service nginx: stopping
[12:35:56] INFO: Service NGINX exited with code 256 (by signal 15)
s6-rc: info: service nginx successfully stopped
s6-rc: info: service init-nginx: stopping
s6-rc: info: service nodered: stopping
s6-rc: info: service nodered successfully stopped

Home Assistant:
Core 2024.6.2
Supervisor 2024.06.0
Operating System 12.4
Frontend 20240610.0

1 Like
2

Have you tried removing it, full host restart not just HA, then reinstall

3

I hadn’t tried that yet. Since 18.0.0 is just a few hours old, I decided to restore it from the backup then wait to see if anyone else sees the same issue.

4

Same here.

5

FWIW, mine updated and does start. This time no errors.

6

Another data point: No issues after my upgrade.

7

I had the same error and had to rollback.

1 Like
8

At this point it looks like opening an issue on git maybe in order.

https://github.com/hassio-addons/addon-node-red/issues

9

I fixed this problem by disabling SSL again in the configuration tab. After the update installation it was set to Enabled.

After disabling SSL, Node Red 18 is working like a charm.

I hope this helps :wink:

1 Like
10

I checked my SSL setting in configuration and it was already off, however thanks for the idea, I checked a few other settings and eventually removed the init command and it started

2 Likes
11

Please explain. What “init” command?

12

Maybe this work around used in an old version of NR:

sed -i "772,775d" /opt/node_modules/@node-red/util/lib/util.js
4 Likes
13

Yeah, mine totally pooched as well. NR would start but would immediately shutdown. Reverted to backup.

Update: Fixed by removing sed -9i "772,775d" hack.

2 Likes
14

Anyone (everyone?) upgrading to Node-RED addon, V18.0.0 would be advised to note:-

This addon upgrade now includes the Milestone Release of Node-RED to v4.0.0
https://nodered.org/blog/2024/06/20/version-4-0-released

This NR update now includes the change to JSONata V2.x, and the way JSONata is being called.

From the NR 3.1 release last September, any JSONata expression call required a callback. This was flagged (for function calls that did not call with a callback ) with an error message, which itself was not fatal but generated a lot of noise in the logs. As a temporary patch, some have applied a fix to remove the relevant (log error warning) section from @node-red/util/lib/util.js

While this was OK at the time, the new update to V4.0.0 has removed the warning and made the error fatal.

Two implications:
1: Nodes that call JSONata without following the rules will now generate a fatal error (not a warning) that presumably stops Node-RED. (The HA Websocket nodes being an example of nodes that can call JSONata expressions). Nodes will naturally need to be up to date!

2: Anyone who applied the patch (see above) to pre-edit util.js on start up now needs to remove this patch, since the file has been modified, and continuing to remove the lines 772 to 775 will remove required code, leaving corrupt JavaScript.

You have been warned.

Please see the pre v4.0 on the left, and the v4.0 code on the right. You really do not want to be removing lines 772 to 775 anymore!

node red v4 makes jsonata changes in util
node red v4 makes jsonata changes in util1917×939 70.4 KB

2 Likes
15

Of the hundred or so nodes I have installed, how an I supposed to remember which nodes are installed, let alone which nodes call JSONata?

1 Like
16

If you restart node red under 17.0.13 (in HA) and view the log will it show any bad nodes?

If that’s not how – how can one do a quick search for non-conforming nodes?

17

The NR start failure error message you had in your original post can be explained (now I know that you probably had the sed -9i "772,775d" patch in place) very neatly by the fact that a section of - now essential - code was missing, resulting in a spare ) that the JavaScript parsing engine was not expecting.

I was hopefully closing this error off by matching the specific error with a rational cause.

Since there appear to be a rash of ‘my Node-RED addon has stopped working on update’ posts, I suspect that there may be other causes of failure. So, back to the release notes, and the JSONata update to v2 and call change will be a possible potential issue. It is commented as such in the release notes.

Since the requirement for JSONata expression calls to provide a callback was first introduced, I know that the WebSocket nodes have been updated to address this, and therefore they just need to be updated (which, of course, they should be in the latest addon).

JSONata is available throughout Node-RED, but the most like use is in the WebSocket nodes, followed by the Change node (and perhaps the inject node and the debug node). These are all standard package Node-RED nodes, so should all be fully compliant and tested.

It is indeed unlikely that nodes other than the WebSocket nodes are going to be problematic. However, the issue is that the warning messages that were being thrown to log by Node-RED when a node called JSONata without the correct approach, and which clearly indicate the node in question (as well as telling you what to do in such cases) was neatly (ever so neatly) removed by the patch.

So, whilst the patch was a nice idea to stop the error log from logging the error, in stopping the error from being logged you don’t know what the problem is anymore.

Therefore: anyone with the patch still applied should perhaps remove the patch first, and ensure that the WebSocket nodes are up to date, then run Node-RED for a bit and check the logs to see if any node throws up the specific error BEFORE updating.

Or, you can reverse the update, remove the patch, and look for any non-confirming nodes throwing the error!

I personally don’t expect any further problems with the JSONata update, expect perhaps for those updating independently to NR v4.0.0 (not an addon) with old versions of WebSocket nodes, for which I hope these posts provide assistance in the future.

3 Likes
18

My log, first post, shows no node errors. It shows a syntax error.

19

The whole thing has been a disaster for me.

1 The change to the SPLIT node is a Breaking Change.
I had to go through 20 flows to make changes.

2 The Home Assistant Sensor defaults to loading the topmost alphabetical Binary Sensor, which is very confusing and you have to use the ‘+’ sign to add a new entity.
However unless you have already noticed the default selection, instead of being a SENSOR is a BINARY SENSOR and this is where you inadvertently overwrite the binary sensor that was selected in the first stage. My question is why would you make these issues as default, it doesn’t make any sense. If you are going to add a new sensor then the previous version was the most sensible.

3 After all of that I left it all running and this morning there were no entities running in Home Assistant, not one, even though Node-red was churning out the data.
I reinstalled the previous version of Node-red, still nothing.

In the end a full restore of the previous Home Assistant and all the components was the only way forward, to go backwards, and I am back in operation.

So after a considerable number of hours spent attempting, to get up and running again, I shall be very wary of installing any new versions until I see what other users report.

20

Same issue here 18.0 does not start with the error message in the first post. Anyhow no WARN regarding the mandatory change discussed in the thread. What do I need to change to get the 18.0 update? The restore rescued me node-red not able to start anymore. The missing entities are strange. They are ALL there and now the automation also works.

Welcome to Node-RED
===================

24 Jun 12:54:12 - [info] Node-RED version: v3.1.9
24 Jun 12:54:12 - [info] Node.js  version: v18.20.3
24 Jun 12:54:12 - [info] Linux 6.6.33-haos x64 LE
24 Jun 12:54:13 - [info] Loading palette nodes
24 Jun 12:54:14 - [info] Node-RED Contrib Theme Collection version: v3.1.11
24 Jun 12:54:19 - [info] Dashboard version 3.6.5 started at /endpoint/ui
24 Jun 12:54:21 - [info] Settings file  : /etc/node-red/config.js
24 Jun 12:54:21 - [info] Context store  : 'default' [module=localfilesystem]
24 Jun 12:54:21 - [info] Context store  : 'memoryOnly' [module=memory]
24 Jun 12:54:21 - [info] User directory : /config/
24 Jun 12:54:21 - [warn] Projects disabled : editorTheme.projects.enabled=false
24 Jun 12:54:21 - [info] Flows file     : /config/flows.json
24 Jun 12:54:21 - [info] Server now running at http://127.0.0.1:46836/
[12:54:21] INFO: Starting NGinx...
24 Jun 12:54:21 - [info] Starting flows
24 Jun 12:54:22 - [info] Started flows
24 Jun 12:54:22 - [error] [api-current-state:virtDieleLicht] InputError: Entity could not be found in cache for entityId: input_boolean.helperdieleug
24 Jun 12:54:22 - [error] [api-current-state:Onkyo] InputError: Entity could not be found in cache for entityId: media_player.onkyo
24 Jun 12:54:22 - [error] [api-current-state:VM an] InputError: Entity could not be found in cache for entityId: button.becees10_sleep
24 Jun 12:54:22 - [error] [api-call-service:d0024dea261279fe] NoConnectionError
24 Jun 12:54:22 - [error] [api-current-state:Status Alarm] InputError: Entity could not be found in cache for entityId: input_boolean.alarm
24 Jun 12:54:22 - [error] [api-current-state:Alarm night?] InputError: Entity could not be found in cache for entityId: alarm_control_panel.alarmo
24 Jun 12:54:22 - [error] [api-current-state:Alarm away] InputError: Entity could not be found in cache for entityId: alarm_control_panel.alarmo
24 Jun 12:54:22 - [error] [api-current-state:Heizung an?] InputError: Entity could not be found in cache for entityId: select.gewunschter_betriebsmodus
24 Jun 12:54:26 - [info] [server:Home Assistant] Connecting to http://supervisor/core
24 Jun 12:54:26 - [info] [server:Home Assistant] Connected to http://supervisor/core
24 Jun 12:54:31 - [warn] [function:Store Wochentag] Wochentag:0
24 Jun 12:54:31 - [warn] [function:Store Uhrzeit] Uhrzeit:18