I have a Greenrock system from the insolvent Austrian supplier Bluesky with LTO batteries (Carbocab). As they "forgot" to add a proper BMS with balancing to the batteries I added it myself and have it connected via RS485 using the Beaglebone running VenusOS. I got rid of the Smart1 EMS and the BMS was included, as it did only monitor the complete stack.
Running 4 batteries in parallel I wanted to connect the remaining 3 and aggregate the batteries on dbus for controlling everything.
I cannot reconstruct the exact steps, but I ended up with a Multiplus showing state Off in VRM:
The ET340 grid meter is working fine (from what I see) and the BMS is also showing good values with 1 second update rate:
As soon as grid fails (or I switch it off) the Multiplus starts inverting supplies the critical loads from batteries but stops after the relay tests and wait time after grid is back.
Interesting is that in the VRM online portal I see the grid meter as N/A, while the AC-loads are getting their power values from the grid meter:
In System Settings I have chosen the MP2-internal Battery Monitor to be used, but also with the serial BMS it shows the same behavior.
I tried
- VenusOS 3.0 and 3.10~8
- Multiplus Firmware 485 and 502
- Fresh installation of the VenusOS
- With and w/o serial BMS connected
- I checked several similar questions and the FAQ 4:
Q4.1:grid meter connected, and reporting data in ~1 Hz, also with ESS/Grid meter = Inverter/Charger I have the same
Q4.2: my BMS is not CAN-connected but RS485, as it is in VenusOS probably the same I checked that I have regular update, by setting the System setting/BatteryMonitor to the serial one I also see the SOC in the overview, so I guess the first picture above is only due to the off state of the MP2 - even though the SOC of the MP2 battery monitor is showing in the online VRM portal.
Q4.3:
N/780473368955/battery/4/Info/MaxDischargeCurrent {"value": 35.0}
N/780473368955/battery/4/Info/MaxChargeCurrent {"value": 8.0}
N/780473368955/battery/4/Alarms/HighChargeCurrent {"value": 0}
N/780473368955/battery/4/Alarms/HighDischargeCurrent {"value": 0}
N/780473368955/battery/0/Alarms/HighChargeCurrent {"value": 0}
N/780473368955/battery/0/Alarms/HighDischargeCurrent {"value": 0}
N/780473368955/battery/0/Info/MaxChargeCurrent {"value": 8.0}
N/780473368955/battery/0/Info/MaxDischargeCurrent {"value": 35.0}
N/780473368955/system/0/Control/MaxChargeCurrent {"value": true}
N/780473368955/system/0/Control/SolarChargeCurrent {"value": 1}
N/780473368955/vebus/288/BatteryOperationalLimits/MaxChargeCurrent {"value": null}
N/780473368955/vebus/288/BatteryOperationalLimits/MaxDischargeCurrent {"value": null}
N/780473368955/vebus/288/Dc/0/MaxChargeCurrent {"value": 35.0}
N/780473368955/settings/0/Settings/SystemSetup/MaxChargeCurrent {"value": -1}
Q4.4: Don't see any reason for discharge disallowed.
Q4.5: I did not change any grid code settings (don't have the password, it's Germany) and have the AUX in open (I guess - never touched it)
Q4.6: no change in Mains wiring and it worked perfectly for months. In VEConfigure I did not see any suspicous error in the IP (NS) protection log on the grid code page.
Other settings that might be important:
- ESS assistant active in VEConfigure
- ESS config in Venus:
And now I am out of ideas, how I could get the Mutliplus2 again into the state to regulate to the grid setpoint and would appreciate any idea of what I could try or show to solve the issue.
Thanks in avdance.
Rapha
