123SmartBMS #558
Replies: 5 comments
-
Those settings does not look correct for if you want the BMS to control the GX. |
Beta Was this translation helpful? Give feedback.
-
The 123\SmartBMS Victron software is currently only for monitoring the BMS on the display and via VRM - we have not a full "BMS" implementation. That is probably why not every value is ON. We are working on full BMS control as it would be a nice feature. I suppose DVCC - on the Cerbo/Venus - needs to be turned on for this. |
Beta Was this translation helpful? Give feedback.
-
Yes, DVCC needs to be on. All the GX is in control off is how much current it can charge or draw from the battery and at what voltage this is allowed. And these parameters come from the driver/BMS. |
Beta Was this translation helpful? Give feedback.
-
This sounds great. Yes, the BMS physical relay as last resort/critical disconnect is a general feature people should be encouraged to have, whether directly supported by the BMS or achieved via Victron included ports or compatible add-ons. My current experience with the Victron settings and DVCC suggest that the inverter/charger assistant code will take-over many settings. In residential use the "ESS Assistant" appears mandatory (from Victron documentation and the fact the old "hub" assistants are marked "depreciated"). This introduces an additional layer of complexity. I hope that the complete DVCC support will work but wonder if both projects might need a custom assistant, like a "DBUS Virtual Switch", to fully cover the minimum and maximum allowed charge/discharge conditions from all sources, i.e. solar charger, DC-DC converter (generator) or inverter/charger (multi/quattro). Error messages and tooltips for greyed out settings I've seen in various places confirm the assistant becomes the "master" once configured. |
Beta Was this translation helpful? Give feedback.
-
The ESS Assistant do have to be included for a grid tie setup and it does run the GX and all the linked Victron devices. But it does this with the guidelines the BMS gives. So what my driver does is read the BMS to get the cell info. It will use the cell count to set the Charge Voltage Limit(CVL) and Discharge Current Limit(DCL). This tells the GX to charge the battery till you get to the CVL and to stop draining the battery below DCL. If it does go past these limits then the BMS protections will kick in, but the GX wil now try and stay in these limits. Futher it will also limit the current draw to what the driver tells it in the Charge Current Limit(CCL) Now the hole Victron ecosystem will use these limits. If you use MPPTs to change the battery in will limit the PV input to keep to those limits. So while the battery still accept charge the MPPTs will go at full speed, and as soon as the battery is full it will ramp down and the MPPTs will only generate power for the consumption. The "Distributed" in DVCC meand it comes from the battery and not the GX settings (something else (the battery) is setting it). If the system is off grid, then it will have these features |
Beta Was this translation helpful? Give feedback.
-
The 123electric 123SmartBMS has a similar DBUS serial integration in early stages of development which I am currently trying to test:
https://github.com/123electric/smartbms-venus
But currently it appears unclear how the charge and discharge enable is controlled. Could somebody here please help by confirming what the "System status" screen should look like with your DBUS integration for other BMS systems. As displayed below the solar and BMS control state/ability appear to be disabled:
Can your solution/other BMS show all as "On" or is this normal and the charge/discharge is controlled via some other API, or only ever by physical cables?
Beta Was this translation helpful? Give feedback.
All reactions