For a few days, I experience unexpected low voltage alerts at a time near sunset. No shutdown of the AC inverter, no other side effects known. Alarm threshold for 15s should be 46,5 Volt and VRM always shows well above 48V with SOC >20%. Load to battery is only moderate. DeviceList->Pylontech does not show any alarms and the alarm disappears without charging. Also lowest cell voltage is well above 3,2 Volt. Disbalance difference is only 4mV at the moment.
Is there any way to find out if the alarm is triggered by own meassurement of Multiplus or if it comes over CAN bus from Pylontech, or over serial from the smart shunt? Maybe reading the Pylons by battery view?
Yes, array is 180kWh, busbar 30x10=300mm², total charge currents might exceed 1kA. Diagram shows currents at the MP2 not at battery. MP2 feeds to grid 24/7 why the current is always negative. The installation worked almost 2 years without that problem before.
The low battery pre-alarm is 48V. VRM charts are averaged over an interval, the charts shown are not far from the warning threshold, so it is quite likely you’re triggering the inverter warning.
I would also check min/max cell voltages just to be sure one pack doesn’t have a cell that is too low.
Basic troubleshooting would be to check for tightness on all terminals in case they have loosened over time.
Multiplus low voltage is listed as low battery voltage even though it is multiplus input terminals unless you have wired up battery sense cables.
VRM is at best 1 minute sampling intervals and can easily miss short term transients, especially when plotted over long time frames as averaging occurs.
I never changed the DCL and never reach that current. Available loads are limited to 30kVA while charging is frequently up to the double. No inductive loads or inrush currents in that size. Loads are 9xMP2-5000 in ESS configuration and a single separate MP2-3000 for air conditioning.
Its the same installation than here. Before changing the watchdog setup, I never observed that kind of alerts. Just to mention this as some specialists might have better overview about internal operations but voltage can hardly depend from the watchdog.
DCL will always lower towards the bottom of battery capacity, if the VRM chart shows it isn’t lowering or is well above required loads then that isn’t an issue, especially if all packs are showing on the GX as online.
Low battery alarms can have various causes, some already mentioned above.
Your latency is higher than normal but should not be the end of the world.
Never saw any CAN bus problems, 0 errors, 0 packets dropped, all batteries online. Yesterday evening, the SOC was about 52% and disbalance 14mV when alert happened why I doubt, the low voltage is physically true.
Warning happened again this evening. VRM DCL shows sudden drops for unknown reason. If zooming in, the trace, shows spurious drops down until zero what possibly explains a switch off for the dfets in the pylons. On the other hand, DC voltage trace shows 49,5 Volt for this time.
If DCL drops to zero that would trigger the alarm.Hence why I asked.
At low SOC, transients can easily trigger that behaviour. might be time for batteryview.
Alarms increasing now while SOC=30%, U=49,5V (value from MP2) but battery charging with 3-400 Amp. No discharge in this moment. AC feed showed a short drop from 30 to about 5kVA but going back soon.
With pending alarm, I never saw the alarm in DeviceList->Pylontech->Alarms. Always only in the “Notifications” screen beside Overview. Not in menu and not by the LED on front panel. The DCL value always comes from CAN bus (?) I disabled NR and examine if I see something with battery view.
I am going to trace the AC feed with external instrument in 10 sec intervall too. From about 7 to 10am, the SOC was intentionally lower than 10% what is reflected in the DCL trace.
Vrm has been having some issues.
I would consider getting batteryview out and pulling logs from the pack, see if any of the bms’s are complaining. If you find something that can be used with pylon support.
12:40 I disabled NR. Few minutes later some AC values changed. AC consumption does not show any more peaks. As this L1 is a ari conditioner and L2 is a Windows PC, the later values are probably true and peaks before not understood. Meanwhile I also checked all MP2 DC terminals. None of them is hot and everything tight.
Anyway, the drops and alarms also occur without any NR.
The latest event can be confirmed at the independend AC grid trace. Total power drops @13:45 from about 34kVA to 8kVA for a short time. Long enough to see it at the VRM trace too.
Not much too see with battery view, exept any suspicious syserror. Battery has over 90% SOC, 49,8Volt, lowest cell voltage 3,3Volt, hardly any disbalance. Low Voltage Alerts gets more and more. Never any alarm in the device list, only in notifications. Power production really drops with the alerts and battery is charging a few seconds and a few hundred watts only until grid setpoint comes back.
Night time worked with a few low voltage warnings. In the morning, solar yield was suspicious low, battery charging with only small current. Mppts were throttled. After this, I found notifications “BMS connection lost” but device list showed 32 of 32 Pylontechs online, 0 blocking at the same time.
Later I saw error #67 what is the MPPT complaining about lost BMS connection. This is another CAN bus than battery CAN. Reboot of LV hub did not change anything. Reboot of Cerbo brought back full MPPT power, full inverter power and battery charging.
What is diffrent than before: Lowest and Highest cell temp and voltage reads null from dbus and do not appear in the device list anymore. Probably I should try to reboot all batteries? Seems to run now in any emergency mode without proper BMS communication.
Current versions addressed known issues that could contribute to this, so if you’re up to date, I wonder if you’re having resource issues that is causing timeouts.
Venus is v3.54 from spring 2025 not too old. ESS is in production but situation gets worster and worster without doing anything. I guess the aggregation was already wrong before as I was not able to assign the highest and lowest value indicated by venus dashboard to the stack address indicated by battery view. Inside one stack, the displayed address was not consecutive to the physical cabled chain but 1,3,5,6,7,8,.. ..2,4,6,9,10,11..16.
Assume all, the Pylon “Protocol” is missing any error corrections, enumeration depends from unknown things and link and transport layer are not implemented like NMEA or CanOpen is doing this. I am going to try a reboot of all 34 Pylons with the suggested procedure “wait for beep 3 times, then plug in the cable”.
