SoC was 62% at the time, there was no heavy load (there was an ~80A load for 10 mins a bit before - but that was turned off 20 mins prior to the alarm time).
I actually did a test last week where I drained the battery all the way down to 10% SoC to test what would happen and it worked fine with no voltage alarms or anything.
It shows the alarm cleared after 9s, so it wasn’t a persistent thing and it seems to have continued on as normal after that.
Looking at my data in Home Assistant, I can see the battery voltage looks fine and was over 52v. However, there is a gap in the data from 22:47 to 22:51 (the alarm time shows as 22:50).
The Cerbo power is connected to the DC bus with the Multiplus and battery via a Lynx Distributor.
Is there any more logging to find out the sequence of events or why that might have happened or reason for a restart?
Is it possible the low battery voltage alarm is erroneous and just a side effect of the cerbo being rebooted and not actually a battery voltage issue at all?
As an aside, something else odd is why I wasn’t notified of the alarm. I have “automatic alarm monitoring” set to warnings and alarms and then I have notification settings for my user and when I click test notification I get a push notification on my iPhone and an e-mail - but I got nothing last night. Is that another side effect of the Cerbo rebooting? - as it was seemingly down for a few minutes it couldn’t send the notification and then when it came back the alarm cleared so there was no notification?
After posting this, I enabled SSH access and looked in the logs…
Jun 16 21:44:57 einstein daemon.err watchdog[431]: loadavg 10 8 7 is higher than the given threshold 0 10 6!
Jun 16 21:44:57 einstein daemon.err watchdog[431]: repair binary /usr/sbin/store_watchdog_error.sh returned 253 = 'load average too high'
Jun 16 21:44:57 einstein daemon.alert watchdog[431]: shutting down the system because of error 253 = 'load average too high'
Jun 16 21:44:57 einstein daemon.err watchdog[9116]: /usr/sbin/sendmail does not exist or is not executable (errno = 2)
Jun 16 21:44:59 einstein syslog.info syslogd exiting
Jun 16 21:49:20 einstein syslog.info syslogd started: BusyBox v1.36.1
Jun 16 21:49:20 einstein kern.notice kernel: klogd started: BusyBox v1.36.1 ()
Jun 16 21:49:20 einstein kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0
Jun 16 21:49:20 einstein kern.notice kernel: [ 0.000000] Linux version 6.12.23-venus-9 (oe-user@oe-host) (arm-ve-linux-gnueabi-gcc (GCC) 13.4.0, GNU ld (GNU Binutils) 2.42.0.20240723) #1 SMP Mon Mar 16 13:41:47 UTC 2026
So it seems the Cerbo rebooted due to high load!
(and I assume the low battery alarm was indeed not real and just some quick sensor oddity as it booted back up?)
The question is - why was the load high?
I’m not doing anything non-standard - I didn’t even have SSH enabled until now, i’m not running NodeRed or anything.
I do have the Home Assistant (“Victron GX”) integration, but that’s using MQTT and the metrics are presumably already being published so that shouldn’t cause any load.
Nothing that I know of was happening at that time.
10 8 7 is presumably the standard 1m/5m/15m load averages and that is pretty high - but right now it’s:
load average: 4.40, 4.71, 3.32
which is high for a 2 core system which shouldn’t be doing much… is that normal?
Any idea what would have caused my high load last night?
…and as I say, this is stock and shouldn’t be doing anything funky so it shouldn’t be getting to the point of high load and rebooting itself in normal operation?
I cant help with the cause for the reboot or high load, but i get these alarms too on some, but not all, reboots. So at least that part seems to be normal.
I think its related to the SOC rather than voltage. The SOC is sent to the VE.Bus system from the GX, so i think on certain boots it first sends a 0% SOC to the VE.Bus before actually having read the Canbus battery. Or something similar.
I was worried at first that it was a battery/cabling issue and then when I saw the Cerbo had rebooted that seemed bad, as if something had happened on the DC side, but alas it does seem to be a monitoring side effect rather than an actual issue.
