Shutting down the system - load average too high - since 3.53

Hi,
since 3.53 (large), gui v2, on a cerbo gx i got near daily:

Jan 28 14:42:25 einstein daemon.err watchdog[564]: loadavg 9 7 5 is higher than the given threshold 0 6 6!
Jan 28 14:42:26 einstein daemon.err watchdog[564]: repair binary /usr/sbin/store_watchdog_error.sh returned 253 = ‘load average too high’
Jan 28 14:42:26 einstein daemon.alert watchdog[564]: shutting down the system because of error 253 = ‘load average too high’
Jan 28 14:42:26 einstein daemon.err watchdog[564]: /usr/sbin/sendmail does not exist or is not executable (errno = 2)

i use node red only simple for a temperature control of relay 2.

i have now startet a “top” in batch mode to see whats happen before the gx will shutdown.

Thanks
Thomas

How did you define the flow for that temperature control?

Wild guess:
A/D converters always return thermal noise on their lower bit(s).
A naive approach for a conversion logic is to just cut off (mask) some of the lower bits, they’re not needed for the intended accuracy and getting rid of them nicely this stabilizes the output value… unless the input temperature is at a level where not only the masked lower bits oscillate, but as of how binary numbers work they also flip the non-masked least significant bit.

Would the input be configured as “send message on change” instead of “every x seconds” (which usually is fine, as temperature usually doesn’t fluctuate on a millisecond basis) this might accidentally trigger a storm of messages should the LSB of the raw value start to oscillate from what I described above, as the input will change with every read…

2 Tempsensor Input Nodes connected to a function node followed by a delay node with 1msg/s connected to the relay node.
i have activated “roundet to zero digits”.

Are there any third party mods, nodes and customisations loaded beyond the standard components loaded by the large image?
Typically this is seen with custom drivers etc - Shelly was a big cause.
Just running node red should not cause this behaviour, my node red does a lot of stuff and I have never seen a load related restart, nor should anyone else with a standard build.

i have installed in node red:
node-red-contrib-s7
node-red-dashboard
but both is not used at the moment, the flows are disabled.
the most load i have about 20% is gui-v2

If thats all, then it should not be restarting. It sometimes helps to reflash it with the reset to factory defaults process documented in the manual.

today was no reboot, i waiting :-).
the gui-v2 process eates sometimes 32% CPU. i have also connected a gx touch 50.

How is the temperature of the GX?

Outside of the Cerbo GX 24 Degrees. Inside i found no value …
i had a reboot again today:
31% /opt/victronenergy/gui-v2/venus-gui-v2
25% {dbus_systemcalc} /usr/bin/python3 -u /opt/victronenergy/dbus-systemcalc-py/dbus_systemcalc.py
10% node-red
7% {vrmlogger.py} /usr/bin/python3 -u /opt/victronenergy/vrmlogger/vrmlogger.py (vrm is disabled on my device, i don’t know why this service is needed)
6% dbus-daemon --system --nofork
6% {localsettings.p} /usr/bin/python3 -u /opt/victronenergy/localsettings/localsettings.py --path=/data/conf
6% /opt/victronenergy/venus-platform/venus-platform
5% python /data/BatteryAggregator/battery_service.py
4% {dbus_generator.} /usr/bin/python3 -u /opt/victronenergy/dbus-generator-starter/dbus_generator.py
and some smaller …

if the gx touch 50 is not in sleep mode the gui-v2 eates 30% cpu, it thinks from the animations ?

should i test to switch back to gui-v1 ?

Thanks
Thomas

Rolling back to the old UI or to the previous, backup OS version is a good test.

i runs now 1 day with gui-v1 without reboot and lower cpu consumption.

after switch to gui-v1 no problemes and no reboots.