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
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?
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
My log, first post, shows no node errors. It shows a syntax error.
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.
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
Ok, found the “error” on myself. Calling the ID before everything was up and running. Now it looks better. Try 18.0 again
Welcome to Node-RED
===================
24 Jun 14:00:00 - [info] Node-RED version: v3.1.9
24 Jun 14:00:00 - [info] Node.js version: v18.20.3
24 Jun 14:00:00 - [info] Linux 6.6.33-haos x64 LE
24 Jun 14:00:01 - [info] Loading palette nodes
24 Jun 14:00:02 - [info] Node-RED Contrib Theme Collection version: v3.1.11
24 Jun 14:00:07 - [info] Dashboard version 3.6.5 started at /endpoint/ui
24 Jun 14:00:09 - [info] Settings file : /etc/node-red/config.js
24 Jun 14:00:09 - [info] Context store : 'default' [module=localfilesystem]
24 Jun 14:00:09 - [info] Context store : 'memoryOnly' [module=memory]
24 Jun 14:00:09 - [info] User directory : /config/
24 Jun 14:00:09 - [warn] Projects disabled : editorTheme.projects.enabled=false
24 Jun 14:00:09 - [info] Flows file : /config/flows.json
24 Jun 14:00:09 - [info] Server now running at http://127.0.0.1:46836/
[14:00:09] INFO: Starting NGinx...
24 Jun 14:00:09 - [info] Starting flows
24 Jun 14:00:10 - [info] Started flows
24 Jun 14:00:14 - [info] [server:Home Assistant] Connecting to http://supervisor/core
24 Jun 14:00:14 - [info] [server:Home Assistant] Connected to http://supervisor/core
The error after upgrade to 18 is still the same. Need to make a rollback
[14:13:51] INFO: Starting Node-RED...
> 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
oh, man. I am also one of the idiots not removing the “sed” command from the init_command in HA. Now everything is fine…
What init_command?
Home Assistant > Settings > Addons > Node-RED > Configuration > init_commands
These are commands run at initialization (hence init_commands) as Node-RED starts up.
If you still have the ‘patch’ from last year, then this command must be removed.
2 Likes
This won’t help anyone having issues right now but having been burned a few times on NR major releases I have found it to be best practice to wait until a x.0.1 release before attempting the upgrade. I am all about cutting edge adoption but NR is a pivotal part of my automation environment so I wait.
1 Like
.
.
.
.
.
2 Likes
This did the trick for me:
Removing “sed -i “772,775d” /opt/node_modules/@node-red/util/lib/util.js” from ‘init_commands’
1 Like
do not forget to update node-red-contrib-home-assistant-websocket
The update (version: 18.0.1) also started correctly for me after Removing “sed -i “772,775d” /opt/node_modules/@node-red/util/lib/util.js” from ‘init_commands’
THIS deserves way more upvotes. I just forgot about the initial command we had to add some months ago. Thanks!
Give credit where credit is due.
I did not apply the patch myself last year and could not make sense of the OP error message until @d_tech and @walberjunior posted, so they should get the credit. 
Does 18.0.3 correct this or does it still require the change to init commands? I don’t believe I ever entered that work around but didn’t want to find out after I updated if it can be avoided.
My understanding is the init command was a workaround for people who didn’t want to fix the issue “right”, and so is not anything that will be fixed. But I could be wrong.
FWIW I instralled 18.0.3 last night and had no issues (but I also had not edited the startup sequence).
If you have this command in your configuration, it needs to be removed. It was a temporary fix for a certain problem. If you are using the addon, goto the configuration tab on the addon page.
Scroll down to init commands, do you have an entry for sed -i “772,775d” /opt....? No you can upgrade without worrying about this. If it is there upgrade NR and then remove the command from the configuration and restart.