Moin
until last week our system works great in the nice weather. Unfortunately, the connection to the BMS has recently been interrupted again and again with alarm #67. When I restart the Raspi, it works again for a few minutes to hours, but then at some point the charge controllers disappear again. I have no idea how to proceed with the search for the fault.
To better narrow down the possible cause, here are the changes I have made recently:
a few days before the first glitch, I did an update from Venus from 3.54 to 3.55. Since the problems started a few days later, I went back to the saved backup firmware. => Error still occurs
3 weeks ago I tried to integrate a few Shellys PM3 mini for recording external inverters. The display is there, but without the current values. So it didn’t work. Apart from the empty display, this had no consequences
8 weeks ago I converted from a single-phase to a 3-phase system with 3 Multiplus II
our system:
3x Victron Multiplus-II 48/5000/70-50, firmware v556 in three-phase network
Charge controller 1(East) : Victron SmartSolar MPPT 150/35 with 2x3 modules Trina Vertex S with 410W
Charge controller 2 (West): Victron SmartSolar MPPT 150/35 with 2x3 modules Trina Vertex S with 410W
Unfortunately with unsupported batteries and the Pi, there isn’t much we can do to help.
It may well be related to the Pi as that combination isn’t officially tested, so I don’t mean to be unhelpful by suggesting you get a Cerbo. Your config isn’t too small, and you may find the environment will be stable on the tested Cerbo.
There have also been numerous issues reported with Seplos, if you do some searching.
For Pi, the modifications section is the best place for Pi specific questions as well.
Hope you get to the bottom of the issue.
After doing more research, I found that Cerbo users have had this same inexplicable problem. I found information stating that BMS communication can be disabled via VictronConnect. I did this, and now everything is working again. Now, a question arises: Why does the ESS need a BMS connection to the Victron system? The Multiplus can also read the battery’s state of charge (SOC).
ESS does not need it, it worked fine with “dumb” lead batteries.
Lithium is more particular in what it needs, how it charges and for safety and cell balancing.
With multiple chargers, needing to export power etc, you want to know what the battery wants given its current state, so it is the best practice.
Equally you could use a shunt, and use old fashioned voltage control, but this is less ideal for lithium given it has a fairly flat voltage curve.
You can connect it to the GX, tell DVCC not to use it for management, which will give you access to battery data in VRM but the system will be controlled by the inverter algo - all documented in the DVCC guide.
Okay, if I understand correctly, the battery’s BMS works autonomously and simply does not send data to the Victron system. The Multiplus recognizes the state of charge (SOC) from the voltage and thus knows when the battery is full. I also installed a NEEY-balancer in the battery to equalize the cell voltages.
Are there any disadvantages to this configuration compared to using the BMS data in the Victron system?
The benefit of the battery managing the victron system, is if there is a fault condition, the BMS can instruct the system to lower all the charge/discharge parameters, potentially also shutting off the system as a whole. As batteries charge/discharge they dynamically adjust their limits which the system can follow if it is managed, when manual you can’t do that, so you need to consider the right parameters when programming the devices.
You can still use DVCC to coordinate chargers and to set global limits or overrides.
There are plenty of people using the system this way, you may just need to do some fine tuning along the way.
Great! Then I can leave the system running until the problem is identified.
The battery is protected by its BMS.
Thank you very much for the quick answers.