Took NodeReds html page with menue->ManagePalette->Install what seems something more comfortable than terminal command line. Therefore I now dont know where its located in the file system.
To be honest: Above NaN problem is not solved. Running NodeRed causes my system to reboot every few hours not reproducable. This triggers my external watchdog hardware what switches off public grid connection. Therefore connection to my ABB grid meter is lost what results in the NaN problem again.
Never saw such unexpected reboots of that installation before I used NodeRed. Probably only my PID Node with the feedback loop is responsible therefore. Loop speed is now only 2sec but the dashbaord already seems to cause high cpu load as I can already recognize about up to one second jitter in debug window output.
While writing the answer, I noticed my mistake. The target system is far away and not the host system where I use the browser to access NodeRed. I have to login by ssh first:
jv@JamesWebb:~$
jv@JamesWebb:~$ ssh root@10.10.20.149
root@10.10.20.149's password:
Last login: Wed Jul 9 07:33:12 2025
root@einstein:~#
root@einstein:~# cd ~/.node-red
-sh: cd: /home/root/.node-red: No such file or directory
root@einstein:~# ls
Settings package-lock.json result
node_modules package.json
root@einstein:~# cd node_modules
root@einstein:~/node_modules# ls
javascript-state-machine node-red-contrib-state-machine
root@einstein:~/node_modules# cat node-red-contrib-state-machine|more
cat: read error: Is a directory
root@einstein:~/node_modules# cd node-red-contrib-state-machine
root@einstein:~/node_modules/node-red-contrib-state-machine#
root@einstein:~/node_modules/node-red-contrib-state-machine# ls
LICENSE package.json state-machine.js
README.md state-machine.html test.js
root@einstein:~/node_modules/node-red-contrib-state-machine# cat state-machine.js|more
/*****
node-red-contrib-state-machine - A Node Red node to implement a state machine us
ing javascript-state-machine
(https://www.npmjs.com/package/java-script-state-machine)
MIT License
Copyright (c) 2018 Dean Cording <dean@cording.id.au>
Nevertheless, your PID node is not found in this directory and the state machines are not part of my current installation. Maybe I had them installed formerly before I started with own state machine. Here is what is currently installed at the palette. The basic nodes, Victron nodes and dashboard are in use. Modbus, Pid and vrm are not used. VRM is Victrons remote database service what collects and visualises historical installation data.
Found a preinstalled version of NodeRed within the Venus OS here in use. Venus is the Victron Energy Unix System what comes with a headless 24/7 solar controller model "Cerbo GX". There are several contributions here in the Forum for that system. After update to the Venus large image, NodeRed appears in the menue where it can be enabled/disabled or reset to factory setup. The venus http server can the be accessed using port 1881 while the Venus solar menue system uses normal port 80 + 443.
I have choosen NodeRed to control my solar installation as Venus needs to run 24/7 anyway and pre installed NodeRed comes with many Victron Nodes what allow access to the CAN, USB Modbus RTU peripherals what are mirrored at the dbus. Up on now, the Venus sysem was very reliable for two years. I also tried FHEM before where it is possible to access the Venus dbus system by Modbus TCP or MQTT. There are many disadvantages of that approach beside the need to run another control PC 24/7.
BTW: The flow works with mit PID Node now for over 8 hours doing what it should do without any problems. This is not long enough to be proven but possibly there were any orphaned msg in the memory processed later and caused problems again.
root@einstein:/data/home/nodered/.node-red/node_modules/node-red-contrib-pid# cat pid.js|more
/**
* Copyright 2016 Colin Law
....
module.exports = function(RED) {
"use strict";
...
Seems very sophisticated code from what I understand less than half.
The "locking integral" seems something similar to what I introduce yesterday as saturation of integral value. My process works long time at the limit (saturation) of regulator. As NodeRed seems to use long integers, the integral sum grows to very high values. This will be reversed if deviation is reversed but also takes a very long time until regulator works again. This saturation seems what you have implemented with the proportional band and integral lock?
Up on now, I do not use the derivative term at all. The setup needs more optimizations but I am lucky to have more than 12 hours operation now. Many thanks for your nice PID toy and the insights on how to find installed library nodes.
Yes that is what integral lock is for, to prevent saturation of the integral.
For most systems derivative is not required. Get it working without and only worry about derivative if it proves necessary. For derivative to work well the process sampling needs to be fast compared to the reaction time of the process, and, critically, the resolution (the resolution, not the accuracy) of the sensor needs to be very good. For the majority of applications those conditions are not met.
Operation is now over 24 hours stable with only minor changes at the flow and no further changes of the PID node. The reason for occasional reboots and unexpected behaviour was not the flow runtime but hardware ESD problem for using inputs at 3Volt levels. The board is any Raspi derivate without optocouples for the inputs. Using the HW inputs and NodeRed was same time but assumption for the reason of unstability was not NodeRed nor my flow.
Nevertheless, JS made some trouble with variable types what does not need to be defined before using. Beside the described NaN problem, I found another location in the flow with unexpected behaviour of the HW inputs. There was a string what should indicate a HW switch position but this string could be empty. If so, the previous node writes the msg object with curly braces into the string and following node cannot process the content.
Anyhow, heap or stack exhaust of NodeRed / node.js runtime must not lead to the Linux reboot as the memory management should protect the tasks. The empty string attracted my attention to the HW inputs and those were 3,3V level only. For real world, one should never connect any sensors to such input levels. Simply want to spot here, that I am lucky with NodeRed again. Its doing everything what it should including the PID node. Compared with C, its a pleasure to create a NodeRed dashboard.
