Control Battery via Inverter

[mikaelmaingard]

I am trying to build an optimization mechanism for a theoretical hybrid plant (pv+battery+inverter). The main idea is to 1) compute an optimal schedule for battery charge/discharge considering the environmental forecasts [pv, load, and loadshedding (grid on/off)], and then 2) program the inverter such that it charges and discharges the battery according to the schedule from step 1.

I am happy with step 1 (see the attached example battery schedule), but I am stuck on step 2 and would love some direction from the community. What would I need to communicate to a typical inverter (e.g., Deye/Sunsynk) for it to be able to control a battery according to a schedule?

I have two main ideas:
1) Program the inverter ahead of time with the scheduled charge/discharge times such that it charges the battery when scheduled to charge and discharges the battery when scheduled to discharge.

Or, 2) Implement an external control system that communicates with the inverter to set (on-the-fly) the battery charge/discharge rate such that the battery SOC tracks the scheduled SOC.

Feel free to call out any naivety on my part, but please couple it with some sound wisdom. Thanks!

 

[SeaGal]

Or, 2) Implement an external control system that communicates with the inverter to set (on-the-fly) the battery charge/discharge rate such that the battery SOC tracks the scheduled SOC.

this ^^^^. Would give you better control of your system. Many inverters support real-time integration with external control systems either via RS485 modbus comms or, if not, you could implement a MITM process between battery and inverter comms.

 

[mikaelmaingard]

@SeaGal, thank you for your response. Appreciate your direction on this!

What would the control signal be for this strategy? Would it be the power setpoint (i.e., charge/discharge current)?

 

[SeaGal]

The way I do it is by setting the appropriate CANbus messages.

One message will control the inverter's charge and discharge current.
The other message tells the inverter what the battery's SOC is. Because the inverter is set to 'force-charge' when the SOC is less a particular value (I think I set mine to 5%), then by intercepting the real SOC and telling the inverter the SOC is only 1%, that forces the inverter to start charging (at the rate specified in the other CANBus message).

With those two simple parameters you have a fine control.

I based my code on the project detailed here

DIY Battery via Smart shunt to inverter integration (Solis etc)

Hi All, I've taken some code that handles Victron's VE.Direct protocol (Smart Shunt) and added in CAN Bus / PylonTech protocol connections, this allows the State of Charge, Voltage, Amps etc all be sent to the inverter - any one that supports the PylonTech protocol. I have it connected to a...

diysolarforum.com

Also, see my posting here, which may be of interest:-

Science based discussion on charging LiFePO4 below 32°F

It wouldn't be hard for an engineer designing a BMS to scale charge current with temperature and state of charge. Seems like it could be done in firmware. For example: 10A@-10°C, 15A@-5°C, 20A@0°C, 30A@5°C, 40A@10°C, 100A@20°C. This would allow them to better protect the battery from damage at...

diysolarforum.com

 

[mikaelmaingard]

Thanks for your informative response @SeaGal!

If I understand this correctly, to control the battery during a scheduled charge block, I would send:

• 1 CANbus message telling the inverter the battery SOC is below threshold (e.g., 1%), and
• 1 CANbus message setting the power/current (for charge)

Likewise, to control the battery during a scheduled discharge block, I would send:

• 1 CANbus message telling the inverter the battery SOC is above threshold (e.g., 100%), and
• 1 CANbus message setting the power/current (for discharge)

Would I not be able to achieve the same outcome by sending 1 CANbus message that would effectively set a positive power/current for discharge and a negative power/current for charge? Aplogising for my lack of knowledge beforehand. Many thanks!

 

[DougfromdaUP]

The things you're looking for are an innate capability of the Deye inverter, aren't they?

You can specify how low it will drain the battery based on SOC and when it will charge from the grid based on many different, user adjustable time period.

You can specify maximum charge/discharge current, but I don't know if that's easily variable by time, but I don't see the utility of that unless you want to throw away (not use) pv power generated.

You didn't mention grid functions, so I assume selling back isn't a concern.

 

[mikaelmaingard]

The things you're looking for are an innate capability of the Deye inverter, aren't they?

You can specify how low it will drain the battery based on SOC and when it will charge from the grid based on many different, user adjustable time period.

You can specify maximum charge/discharge current, but I don't know if that's easily variable by time, but I don't see the utility of that unless you want to throw away (not use) pv power generated.

You didn't mention grid functions, so I assume selling back isn't a concern.

@DougfromdaUP, thanks for your response. Yes, according to my knowledge, with a Deye inverter you can program general configurations (e.g., time slots for charge/discharge), but what I'm looking to do is slightly more nuanced than that, the logic for which is programmed into the scheduling algorithm.

An example would be: if I know that tomorrow's loadshedding is forecasted for 12:00-14:00 and peak demand is scheduled for 14:00-15:00, I want 1) have some power during loadshedding and 2) reserve enough capacity to shave peak demand during the 14:00-15:00 block to minimize my demand related grid cost.

Please correct me if I'm wrong, but I'm not certain the available configs would enable me to implement such a prioritization?

 

[fmeili1]

Instead of communicating directly with the inverters and batteries directly via modbus protocol (RS485 or RS232) you may use an already existing solution to act as a bridge. The software Solar Assistant (SA) is able to communicate with a lot of different inverters and batteries and supports a lot of inverter/battery protocols. SA has an MQTT connector to be able to communicate with usual smart home solutions (e.g. OpenHAB, Home Assistant, etc.). So it's a lot easier to not hassle with the specific modbus protocols but just use it's MQTT connector to be able to monitor and control on a much higher logical level.

I use SA together with OpenHAB rules to control and monitor different states of my solar system. Here are some examples - but there many other possible use cases:

• In case the batteries SOC is dropping below a specific value (optional also the battery voltages seen by the inverters can be used also), the smart home rule sends an MQTT message to SA to bring the inverters in grid mode to recharge the batteries (and back if a configurable SOC will be reached). This can either be achieved by e.g changing the inverters/AIO mode from SBU (Solar Battery Utility) to USB or by changing the "back to grid" setting to a value to initiate grid usage (charging).
• Before the AIO's switch to grid usage, I activate with a different smart home rule a contactor to connect the AIO's to the grid (this is just to save grid energy usage, because typical AIO's consume about half of their idle/self power from the grid, if it's just connected - even not used!)
• An other rule controls a mini split to cool the AIO's, depending of the inverter temperatures.
• I can reduce the load in case the batteries drop below a specific SOC and if the new solar production is not far away to be able to stretch the time until new solar production begins (e.g. using solar forecast data in the smart home and depending on the time when the specified SOC has been reached, I can change the heat pump temperature setting to reduce the load for a while; an other option is to disconnect the electrical water heater with a remote WiFi contactor, etc, etc.)
• All important state changes will be sent via messenger (e.g. WhatsApp, Telegram, etc.) via smart home rule to my mobile phone.
• In case a camera will detect smoke (motion / changes in the picture), I will get a message
• etc.

The possibilities are endless and it's very flexible to be able to control the solar system with an external system. If you combine this with a smart home system makes it much more valuable.

 

[mikaelmaingard]

Thanks @fmeili1 ! I appreciate your input on this!

 

[SeaGal]

Instead of communicating directly with the inverters and batteries directly via modbus protocol (RS485 or RS232) you may use an already existing solution to act as a bridge. The software Solar Assistant (SA) is able to communicate with a lot of different inverters and batteries and supports a lot of inverter/battery protocols.

Why "instead"... surely SA does that via RS485 / modbus anyway, which is exactly what I suggested in my post #2 when I said...

Many inverters support real-time integration with external control systems either via RS485 modbus comms

Or does SA communicate using a different protocol?