FBJ
Members
-
Joined
-
Last visited
Reputation Activity
-
FBJ got a reaction from jumper in Settings for BSL and Sunsynk comboThat's what I thought made most sense - thanks @jumper
-
FBJ reacted to jumper in Settings for BSL and Sunsynk combo@Gerrieis correct, use the settings he suggested... these ones quoted above are incorrect, your absorption should always be higher than (or at least equal to) the float because the inverter will charge to the absorption voltage first and then go to float.
-
FBJ reacted to Sc00bs in Settings for BSL and Sunsynk comboAGM batteries are lead and as such have a very linear voltage between 13V full and 10V basically empty i.e. 11.5V is basically half full.
Lithium is very flat till it discharges to 20% and the voltage then drops of a cliff
That is why it is not possible for the inverter to know what the SOC is of a lithium battery without communication to the batteries BMS system.
Not all BMS's are created the same either. More expensive BMW's have a shunt that measures the amount of power flowing through it and do not use cell voltage for SOC measurement at all. They measure how much power has flowed though it vs the full capacity and work out what the capacity left is and tell the inverter the info via the CANBUS or RS485 connection.
-
FBJ reacted to Gerrie in Settings for BSL and Sunsynk comboI believe these above is the correct setting from BSL manual, but than there is another training video but I cannot remember where I found it that recommended the settings like below for 1 x battery. Batt Type must be Lithium, Batt capacity 125A. Discharge recommended current 90A.
I have set a 8 KW Sunsynk with 3x6.4KWH BSL’s like below and its been going fine since January.
float - 54.5V
Absorbtion - 55V
equalization - 54V
-
If the battery is connected with the comms cable, the BMS will override the settings.
-
FBJ got a reaction from system32 in Sunsynk reduces battery charge power when exporting to gridYes
-
FBJ got a reaction from system32 in Sunsynk reduces battery charge power when exporting to gridHi again. I have tested all the combinations in scenarios when there is either an excess of available PV or less PV than loads and possible battery charge rate
In all scenarios, the maximum battery charge rate is only achieved when export is disabled.
With export enabled, the closest you can get to the maximum battery charge rate is when you set Priority Battery and have the Timer limit at a higher SOC than your present SOC (e.g. set it at 100%) (A). When there is excess PV, you get almost max battery, then load, then export. As SOC increases (~>50%), the battery charge rate drops off more from the charge rate you would get with export disabled.
If it's possible to predict when you will definitely have excess PV and set the timer threshold accordingly, then the closest compromise you can get is (A) and then (C). The risk is (B) when there is low sun, then you get priority battery and import instead of load then battery.
The following sample shows those three modes (where the timer threshold is 80%), assuming export enabled. In all cases battery charge rate would also have been higher if export disabled.
In summary, I find: in all scenarios, enabling export means that the possible battery charge rate will not be maximised. There is no combination of settings that prioritise load, then max charge rate to battery, then export. Aside from when Priority Battery, and below the Timer Threshold, they will prioritise load, then split battery and export with a logic algorithm that is not clear. I suspect its a simple case of paralleling them with no prioritising. Unless someone can help me find a solution, I would suggest this is surely something that Sunsynk could improve.
Thanks in advance
FBJ
-
FBJ got a reaction from mzezman in Sunsynk reduces battery charge power when exporting to gridHi again. I have tested all the combinations in scenarios when there is either an excess of available PV or less PV than loads and possible battery charge rate
In all scenarios, the maximum battery charge rate is only achieved when export is disabled.
With export enabled, the closest you can get to the maximum battery charge rate is when you set Priority Battery and have the Timer limit at a higher SOC than your present SOC (e.g. set it at 100%) (A). When there is excess PV, you get almost max battery, then load, then export. As SOC increases (~>50%), the battery charge rate drops off more from the charge rate you would get with export disabled.
If it's possible to predict when you will definitely have excess PV and set the timer threshold accordingly, then the closest compromise you can get is (A) and then (C). The risk is (B) when there is low sun, then you get priority battery and import instead of load then battery.
The following sample shows those three modes (where the timer threshold is 80%), assuming export enabled. In all cases battery charge rate would also have been higher if export disabled.
In summary, I find: in all scenarios, enabling export means that the possible battery charge rate will not be maximised. There is no combination of settings that prioritise load, then max charge rate to battery, then export. Aside from when Priority Battery, and below the Timer Threshold, they will prioritise load, then split battery and export with a logic algorithm that is not clear. I suspect its a simple case of paralleling them with no prioritising. Unless someone can help me find a solution, I would suggest this is surely something that Sunsynk could improve.
Thanks in advance
FBJ
-
FBJ reacted to Bloubul7 in SunSynk - Inverter MonitoringGood day All,
Over the past couple of months I have received numerous requests to share my NodeRed flows used for monitoring the status of the SunSynk inverter. My initial idea was to package all of the flows into an easy to use package and user interface, however my work loads have not provided me the luxury of time to play around and make it a fool proof system.
Please note that the use of these flows are at your own discretion with no liability to either myself, this site nor any members of this site. Do not attempt implement these flows if you are unfamiliar with the working of the ModBus protocol or basic programming.
Brief overview of the flows:
LoadShedStatus - This flow determines the loadshedding status through a webscraper. I use this information to trigger a secondary set of settings to the inverter in case of load shedding. ModBusRead - This flow is responsible for reading information from the Inverter via the Modbus Flex getter ModBusWrite - This flow is responsible for writing settings back to the inverter via the Modbus flex getter Inverter Monitoring - This flow is responsible for obtaining all of the inverter monitoring values. The values are then send to Home Asssistant via MQTT as well as logged to an InfluxDB for monitoring via Grafana SSFormRead - This flow reads the current system settings from the inverter and display it via the NodeRed UI SSFormWrite - This flow writes any changes made to the system settings via the NodeRed UI back to inverter SSDSRead - This flow reads the "Default Settings" from storage and displays it via the NodeRed UI. I use the "Default Settings" to store my optimal system settings when there is no Load Shedding. SSDSWrite - This flow writes the "Default Settings" from the storage to the Inverter. The flow is also triggered automatically from the LoadShedding status flow SSLSRead - This flow reads the "Load Shedding Settings" from storage and displays it via the NodeRed UI. I use the "Default Settings" to store my optimal system settings when there is no Load Shedding. SSLSWrite - This flow writes the "Load Shedding Settings" from the storage to the Inverter. The flow is also triggered automatically from the LoadShedding status flow TimeMode - This flow triggers different settings on different days of the week. My PV Solar is currently not big enough to carry my whole house, I utilize this flow to feed electricity back into the non-essential loads on the days which my domestic worker is not working. This helps me to optimize my savings on certain days of the week while maintaining healthy battery levels. NodeRed Palettes required for the flows:
node-red-contrib-actionflows node-red-contrib-influxdb node-red-contrib-modbus node-red-contrib-queue-gate node-red-contrib-schedex node-red-contrib-simple-gate node-red-dashboard The next couple of posts have been reserved to further expand on the hardware requirements and basic set up of the monitoring.
The idea of sharing my flows is to contribute to the community, let us keep this going as a community project by assisting and contributing to project.
flows (5).json sunsynk_modbus.docx