Forced charge SOC

[math2999]

I want to automate a forced charge but with a variable SOC (based on forecast weather/sun conditions). I can't see the add on maps the Forced Charge SOC values ? Or am I missing it ? Alternatively, thinking I can change the overall max SOC value prior to the forced charge time window (to effectively set the forced charge limit), and then restore it at the end of the window (to usual 100%), to achieve same outcome ?

[math2999]

Sorry, I realised how to do it (per the second part of my post)

[Gnarfoz]

Second idea works, but force power is also available:
Set "EMS mode" to "Forced mode", "Battery forced charge discharge cmd" to "Forced charge", and "Set forced charge discharge power in W" to your desired power.
It also obeys "Set max battery charge power in W" at the same time, so make sure to set that high enough.

[math2999]

Second idea works, but force power is also available: Set "EMS mode" to "Forced mode", "Battery forced charge discharge cmd" to "Forced charge", and "Set forced charge discharge power in W" to your desired power. It also obeys "Set max battery charge power in W" at the same time, so make sure to set that high enough.

Thanks mate. It did work (setting Max SOC to 80%), although Isolarcloud shows this odd result where SOC got to 100% then it drops to 80% at end of script execution, some hours later. Power draw suggests charge did only go to 80% though, so I assume this is just an odd thing isolarcloud is mis-reporting.

[Gnarfoz]

That's explainable: changing the maximum SoC value redefines which SoC the inverter shows as 100%.
If you set it to 80%, 100% at the inverter level will now mean 80% real battery SoC. In most places, iSolarCloud will show the values that take into account the configurable min. and max. SoC values.
Refer to the manual, section 3.3: https://info-support.sungrowpower.com/application/pdf/2024/08/15/SH8.0-10RS-UEN-Ver14-202405.pdf

So, your automation changes the max. SoC to 80%, the inverter charges the battery to this new "full / 100%" level, and when your 4 hour delay runs out, your automation sets the max. SoC back to 100%, which causes the graph to jump because the ceiling has changed back. Which means your battery was sitting at 80% real SoC and iSolarCloud was showing 100% because you told it to.

However! I'd strongly advise against permanently changing the max. SoC. Setting it to anything below 100% prevents the BMS from balancing the battery! (Which it does when it's getting close to full). Instead of manipulating the max. SoC, your automation could just enable a second automation that disables the charging once the current SoC reaches your set threshold. (Or if the timer runs out before the battery has reached your target, it disables it again.)

[math2999]

That's a great explanation, thank you. So are you saying that while this is working as implemented, it will cause harm to the battery over time (even though I revert max SOC to 100 each session) ? If so, I'll look to go down the path you suggest instead.

[Gnarfoz]

Actually, I think your workflow would probably be fine, since the balancing is done on the battery side. If the battery still gets charged to 100% regularly, I don't see an issue (apart from the SoC history looking weird).

The other thing you originally mentioned, trying to adjust the charging power so that the battery gets charged to 80% over 4 hours, is also technically possible, but probably more annoying than necessary.

What I meant would look something like this:

• Automation 1
  Uses your existing script (or some other way Home Assistant offers) to do these things:
  • Sets the EMS mode to forced, sets the forced charge power to some static value (should be high enough to actually be able to charge the battery to 80% within 4 hours, if that's your goal), etc. Thereby starting the charging process.
  • Enables automation 2.
  • After a delay: checks if EMS mode is still set to forced
    • if yes, returns everything to normal, stopping the charging process. Also disables automation 2.
• Automation 2
  • triggers based on the current SoC
  • if 80% is reached, turn off forced mode and return everything back to normal
  • disable itself, if that's possible

[math2999]

I want to thank you again for your advice, I took your alternate idea and got it working. Automations 1/2 are below FYI, and while I talked about an 80% SOC target, in reality I'm using the next day's cloud cover % as the target, so the battery tops up in advance of cloudy conditions. It just worked for a test now so will let it run at midnight and see how it goes. Thank you again friend.

alias: "11: Turn on charging"
description: ""
triggers:

• trigger: time
  at: "00:00:00"
  conditions:
• condition: template
  value_template: >-
  {{ states('sensor.battery_level') | float <
  states('sensor.home_cloud_cover_day_1') | replace('%', '') | float }}
  actions:
• target:
  entity_id: automation.soc_warning
  action: automation.turn_on
  data: {}
• target:
  entity_id: script.sg_set_forced_charge_battery_mode
  action: script.turn_on
  data: {}
• delay: "04:00:00"
• target:
  entity_id: script.sg_set_self_consumption_mode
  action: script.turn_on
  data: {}
  mode: single

alias: "MT: soc_warning"
description: ""
triggers:

• trigger: template
  value_template: >
  {{ states('sensor.battery_level') | float >
  states('sensor.home_cloud_cover_day_1') | replace('%', '') | float }}
  actions:
• action: notify.persistent_notification
  data:
  message: Battery level is above cloud forecast - ending charging
• data:
  title: Battery Charging reached target
  message: The battery is {{ states('sensor.battery_level') }}
  action: persistent_notification.create
• target:
  entity_id: script.sg_set_self_consumption_mode
  action: script.turn_on
  data: {}
• target:
  entity_id: automation.soc_warning
  action: automation.turn_off
  data:
  stop_actions: true
  mode: single