Node-Red continually fails and restarts

#1

I have been running Node-Red on a raspberry pi for over a year without any issues however today I noticed that I was unable to access the dashboard.

I found that Node-Red continually fails and restarts with the following errors:

Starting as a systemd service.
Started Node-RED graphical event wiring tool..
29 Jan 20:36:22 - [info]
Welcome to Node-RED
===================
29 Jan 20:36:22 - [info] Node-RED version: v0.18.4
29 Jan 20:36:22 - [info] Node.js version: v6.14.1
29 Jan 20:36:22 - [info] Linux 4.14.79-v7+ arm LE
29 Jan 20:36:24 - [info] Loading palette nodes
29 Jan 20:36:30 - [info] Dashboard version 2.12.2 started at /ui
29 Jan 20:36:31 - [warn] ------------------------------------------------------
29 Jan 20:36:31 - [warn] [node-red-contrib-google-home-notify-volume-adjustable/google-notify] 'googlehome-notify' already registered by module node-red-contrib-google-home-notify
29 Jan 20:36:31 - [warn] ------------------------------------------------------
29 Jan 20:36:31 - [info] Settings file : /home/pi/.node-red/settings.js
29 Jan 20:36:31 - [info] User directory : /home/pi/.node-red
29 Jan 20:36:31 - [warn] Projects disabled : set editorTheme.projects.enabled=true to enable
29 Jan 20:36:31 - [info] Flows file : /home/pi/.node-red/flows_node-red-prod.json
29 Jan 20:36:31 - [info] Server now running at https://127.0.0.1:1880/
29 Jan 20:36:32 - [info] Starting flows
29 Jan 20:36:33 - [info] Started flows
29 Jan 20:36:33 - [info] [mqtt-broker:a8987a82.eda008] Connected to broker: mqtt://192.168.20.40:1883
29 Jan 20:36:33 - [info] [mqtt-broker:6c25225c.ec514c] Connected to broker: mqtt://192.168.20.40:1883
29 Jan 20:36:33 - [info] [mqtt-broker:d0ab341d.792168] Connected to broker: mqtt://192.168.20.40:1883
29 Jan 20:36:33 - [info] [mqtt-broker:30808c8d.7772b4] Connected to broker: mqtt://192.168.20.40:1883
29 Jan 20:36:33 - [info] [mqtt-broker:ffd144c3.6880a8] Connected to broker: mqtt://192.168.20.40:1883
29 Jan 20:36:33 - [info] [mqtt-broker:f540f85d.d48ce8] Connected to broker: mqtt://192.168.20.40:1883
29 Jan 20:36:35 - [red] Uncaught Exception:
29 Jan 20:36:35 - TypeError: Cannot read property 'getHours' of undefined
_ at bigTimerNode. (/home/pi/.node-red/node_modules/node-red-contrib-bigtimer/bigtimer.js:197:26)_
_ at emitOne (events.js:96:13)_
_ at bigTimerNode.emit (events.js:188:7)_
_ at Timeout.onTimeout (/home/pi/.node-red/node_modules/node-red-contrib-bigtimer/bigtimer.js:859:9)
nodered.service: Main process exited, code=exited, status=1/FAILURE
nodered.service: Unit entered failed state.
nodered.service: Failed with result 'exit-code'.
nodered.service: Service hold-off time over, scheduling restart.
Stopped Node-RED graphical event wiring tool..
Started Node-RED graphical event wiring tool..
29 Jan 20:36:38 - [info]

The first time it fails after it is started it mentions an error with Bigtimer however subsequent failures/restarts log the following -

29 Jan 20:36:50 - [red] Uncaught Exception:
29 Jan 20:36:50 - TypeError: Cannot read property 'getHours' of undefined
nodered.service: Main process exited, code=exited, status=1/FAILURE
nodered.service: Unit entered failed state.
nodered.service: Failed with result 'exit-code'.

Can anyone please shed any light on what the cause of the failure could be?

#2

Yes it looks like a problem with the bigtimer node. (the error after restart is the same)

But given you haven't upgraded in over a year, it might already be fixed.
I'd suggest running the script on the raspberry pi page in the docs, to get on the latest version of Node-RED and a newer version of nodejs (v6 is end-of-life in April https://github.com/nodejs/Release#release-schedule)
and then upgrade your added nodes following the instructions on the Raspberry Pi page in the docs

#3

Also that suggests you have installed two different nodes that conflict: node-red-contrib-google-home-notify-volume-adjustable and node-red-contrib-google-home-notify. You should probably uninstall one of them.

#4

Thank you ukmoose and Colin for the suggestions.

I've updated as per the nodered raspberry pi doco to the latest versions however I still get the same errors.

Can I stop nodered from starting the Bigtimer node?

I upgraded Bigtimer to the latest version a few days ago.

I will correct that google home node error once I get nodered working correctly.

#5

Check your version number against the version listed on flows.nodered.org. if it isn't the same install it on the command line from within your .node-red directory.
I'd also suggest that you add a comment on the big timer post on Pete's website.

#6

If you definitely are using the latest version of bigtimer then your problem indicates a deficiency in that node as even if you give it bad data it should not crash node-red, so an issue should be raised against the node.
However, once you have checked that you are using the latest then I suggest you sort out the google home error. If you have a problem that you do understand then fix that before worrying about the ones you don't understand, even if it appears to be unrelated. So many times in my career I have had similar issues and ignored the 'obvious' minor issues and concentrated on the more tricky ones, only to discover it was actually the apparently minor issue that was triggering the trickier problem. Perhaps, for example, the problem with the duplicate node is causing bad data to be generated which then confuses bigtimer.

#7

After checking you have the latest version you could disconnect all the input wires to any bigtimer nodes you have. That would at least stop you passing in messages that may be confusing it.

I've lost control of Node Red, how can I control it back?
#8

It isn't possible to check the Bigtimer node version or to remove the connected wiring as I need to access the Dashboard....NodeRed crashes every 10-20 seconds.

The same goes for correcting the dupe google home nodes.

It seems to me that a solution would be to backup the currently installed flows folder and settings file and to reinstall NodeRed.

#9

no need to go that far.. you can either
start node-red with new blank flow node-red newflow.json - then open the existing flow in a text editor - copy it to clipboard - then menu - import from clipboard... and then edit the flow to remove the bigtimer before deploying...

or - carefully manually edit your flow_(somename).json file in your user directory (usually ~/.node-red) - preferably after backing it up... then search and remove the whole bigtimer node.

#10

Look at the node's files in node_modules/node-red-contrib-bigtimer to see what version it is

#11

In fact the easiest way is
npm list node-red-contrib-bigtimer

#12

I opened the file flows_node-red-prod.json in a text editor and I could see all of my flows.

I considered changing the field "disabled":true in each flow which used the Bigtimer node however I ended up creating a new empty flows_node-red-prod.json file after renaming the old one and restarting NodeRed.

NodeRed restarted successfully with all my flows present - I expected to have no flows at all and then having to copy / paste the existing flows as suggested.

Problem solved but I can't understand why.

I expected no flows after starting with a new empty flows_node-red-prod.json .

#13

Thanks Colin - I was one version behind with Bigtimer.

#14

There are some circumstances under which node-red will automatically load the backup flows file that is saved each time you deploy. I wonder whether it did that. If so then you will have the file from before the last time you deployed it. If it now works ok that suggests that whatever you did at the last deploy caused the problem. Unless you have also done something else such as updating bigtimer at the same time.

#15

I had the same issue after upgrading to the latest BigTimer. I just uninstalled it and then when Node-Red restarted, went to the Palette and reinstalled it.

#16

That may suggest that upgrading the bigtimer node does not correctly handle upgrading the node settings, or something similar. Perhaps this should be reported to the author.

#17

@scargill Flagging this for you since it seems a number of us had issues with the latest version

#18

FYI: When a flow is causing NR to crash, I prefer to use --safe flag...

It leaves your flow(s) present and editable. Once you make your corrections and deploy, they start working again.