Repository navigation
Victron Support #2846
Description
Currently trying to integrate Victron with charge/export freeze support. Using the HACs Victron MQTT integration. Whilst my setup is non-standard, it's the Victron controls that I struggle with, control options as follows:
Grid Set Point (W) - number.victron_mqtt_(victron id)_system_0_system_ac_power_set_point (positive pulls from grid, negative sends to grid)
Min battery SoC (%) - number.victron_mqtt_(victron id)_system_0_system_ess_min_soc_limit
AC Input Limit (%) - number.victron_mqtt_(victron id)_)_system_0_system_ac_input_limit
AC Export Limit (%) - number.victron_mqtt_(victron id)_system_0_system_ac_export_limit
Inverter Mode - select.victron_mqtt_(victron id)_vebus_276_vebus_inverter_mode
Options:
ID Value Display Name
- Charger Only - 1 Charger Only
- Inverter Only - 2 Inverter Only
- On - 3 On
- Off - 4 Off
Lots more configuration/sensors available as documented by the project here:
https://github.com/tomer-w/victron_mqtt?tab=readme-ov-file
My system uses another inverter manufacturer for solar, hence not including details here (simple sensor to connect) I also had to consolidate a few sensors/calibrate, hence the VRM sensors. Historic data in the apps.yaml is in KWH
current apps.yaml is
pred_bat:
# Home Assistant API connection
ha_url: http://XXX.XXX.XXX.XXX:8123
ha_key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
module: predbat
class: PredBat
# Home Assistant entity prefix
prefix: predbat
# Timezone for scheduling
timezone: Europe/London
# Custom inverter type code 'VC' (Victron Custom)
inverter_type: "VC"
num_inverters: 1
# Currency symbols
currency_symbols:
- '£'
- 'p'
# Thread configuration
threads: auto
# Historical data sensors
load_today:
- sensor.vrm_equiv_1_ac_loads_daily_complete
import_today:
- sensor.vrm_equiv_1_grid_import_daily_complete
export_today:
- sensor.vrm_equiv_1_grid_export_daily_complete
pv_today:
- sensor.vrm_equiv_1_solar_daily_complete
# Power sensors
battery_power:
- sensor.dc_battery_power_inverted_predbat
pv_power:
- sensor.vrm_equiv_1_solar_power_complete
load_power:
- sensor.vrm_equiv_1_ac_loads_complete
grid_power:
- sensor.victron_mqtt_(enter victron ID)_grid_32_grid_power
# Grid power is negative for import, positive for export
grid_power_invert:
- true
# Battery configuration
soc_percent:
- sensor.victron_mqtt_(enter victron ID)_battery_512_battery_soc
soc_max:
- 87.36 # 1824Ah * 48V / 1000 = 87.36 kWh
battery_rate_max:
- 20000 # 2 x 15kW inverter max (MultiPlus-II 48/15000)
battery_voltage:
- sensor.victron_mqtt_(enter victron ID)_battery_512_battery_voltage
# Grid setpoint control
charge_rate:
- number.victron_mqtt_(enter victron ID)_system_0_system_ac_power_set_point
discharge_rate:
- number.victron_mqtt_(enter victron ID)_system_0_system_ac_power_set_point
# ESS Minimum SOC (Reserve) Control
reserve:
- number.victron_mqtt_(enter victron ID)_system_0_system_ess_min_soc_limit
# Inverter Mode Control
inverter_mode:
- select.victron_mqtt_(enter victron ID)_vebus_276_vebus_inverter_mode
# Inverter output limit in Watts
inverter_limit:
- 25000
# PV forecasts (Solcast)
pv_forecast_today: sensor.solcast_pv_forecast_forecast_today
pv_forecast_tomorrow: sensor.solcast_pv_forecast_forecast_tomorrow
pv_forecast_d3: sensor.solcast_pv_forecast_forecast_day_3
pv_forecast_d4: sensor.solcast_pv_forecast_forecast_day_4
### Octopus rates and integration
# Using manual rates for testing
# metric_octopus_import: "sensor.octopus_energy_electricity_(account_Info)_current_rate"
# metric_octopus_export: "sensor.octopus_energy_electricity_(account_Info)_export_current_rate"
# Fixed manual Octopus Cosy import rates (p/kWh)
rates_import:
- start: "00:00:00"
end: "04:00:00"
rate: 27.69
- start: "04:00:00"
end: "07:00:00"
rate: 13.58
- start: "07:00:00"
end: "13:00:00"
rate: 27.69
- start: "13:00:00"
end: "16:00:00"
rate: 13.58
- start: "16:00:00"
end: "19:00:00"
rate: 41.54
- start: "19:00:00"
end: "22:00:00"
rate: 27.69
- start: "22:00:00"
end: "23:59:59"
rate: 13.58
# Manual export rates (15p/kWh flat rate - adjust to your actual rate)
rates_export:
- start: "00:00:00"
end: "23:59:59"
rate: 15.0
# Octopus saving session configuration
octopus_saving_session: 're:(event.octopus_energy_([0-9a-z_]+|)_octoplus_saving_session_events)'
octopus_saving_session_octopoints_per_penny: 8
# Octopus free session configuration
octopus_free_session: 're:(event.octopus_energy_([0-9a-z_]+|)_octoplus_free_electricity_session_events)'
# Carbon Intensity data
carbon_intensity: 'sensor.carbon_intensity_westmidlands_current_rating'
carbon_intensity_forecast: 'event.carbon_intensity_westmidlands_current_day_rates'
# Historical data configuration
days_previous:
- 7
days_previous_weight:
- 1
forecast_hours: 48
# Notification devices
notify_devices:
# ==========================================
# CUSTOM INVERTER DEFINITION
# ==========================================
inverter:
VC:
name: "Victron MultiPlus-II ESS"
has_rest_api: false
has_mqtt_api: false
# Power control configuration
output_charge_control: "power"
has_charge_enable_time: false
has_discharge_enable_time: false
has_time_window: false
charge_control_immediate: true
# SOC and reserve configuration
has_target_soc: false
has_reserve_soc: true
soc_units: "%"
# Inverter mode support
has_ge_inverter_mode: false
inverter_mode_options:
- "On"
- "Inverter Only"
- "Charger Only"
- "Off"
# Freeze mode support
support_charge_freeze: true
support_discharge_freeze: true
# Technical settings
num_load_entities: 1
charge_time_format: "S"
charge_time_entity_is_option: false
time_button_press: false
clock_time_format: "%Y-%m-%d %H:%M:%S"
write_and_poll_sleep: 2
current_dp: 0
Activity
gcoan commentedon Oct 31, 2025
I don't know if its the way you pasted your apps.yaml in to github, but a lot of your YAML appears to be misaligned
e.g.
instead of
it should be
each sub entry should be indented by a further two spaces
But getting back to your request. Unless there is another victron user here that has got the inverter working we're not easily going to be able to help you.
The first thing you need to do is to work out how to manually control your inverter from HA, to start and stop charging to a % limit, start and stop exporting, return to Eco mode or equivalent.
Once you have worked out how to do this then we can translate those into predbat commands.
If you want to create the series of commands in an automation script then predbat can execute the script if that's easier.
AlexCPU commentedon Oct 31, 2025
There a discussion on this #798
When I've got a bit more time I'll try and write up a template using the HACS MQTT integration, but I'm currently using a modbus TCP implementation using the raw modbus component as the HACS one didn't exist when I started.
Below is an extract from my apps.yaml. Obviously you'll need to find your appropriate entities. The important bit is the home assistant automations that control the battery. Mine won't be helpful as they're ModbusTCP, but the only two settings I'm changing are the grid set point to 24000W to force charging, and change the inverter mode to charger only for freeze discharge.
My automations are effectively:
Start charging:
Stop charging:
Freeze discharge:
I haven't looked at forcing discharge, as none of the maths for my usage says it's worth giving up my FIT for, but I'll try and look at it as part of writing a template, hopefully within the next couple of weeks.
Lanmate commentedon Jul 12, 2026
To help someone else figure this out in future, I have come up with the following for my own use.
System
Entities
Cerbo GX
Inverter
Common Settings
Modes
Normal Running (Demand)
For use with charge_stop_service and discharge_stop_service
Inverter will power house loads, excess solar will charge the battery, grid will top up house load if needed.
Charging (Max Power)
For use with charge_start_service
Grid will power house loads, inverter will charge the batteries at the maximum rate.
Discharging (Max Power)
For use with discharge_start_service
Inverter will power house loads, remaining inverter capacity will be used to export to the grid up to the maximum rate.
Freeze charging
For use with charge_freeze_service
The behaviour of this changes depending on AC vs DC solar:
Freeze exporting
For use with discharge_freeze_service
The behaviour of this changes depending on AC vs DC solar:
Notes
AC power setpoint could be set to a small positive number e.g. 10, to stop leak back to grid from battery in normal operations.
I specifically avoided using the "Inverter only" and "Charger only" modes, or "External Control" in the Cerbo GX. These are bad in my opinion because:
Edit: Fix various typos and move sections around which didn't belong where I originally had them
Lanmate commentedon Jul 20, 2026
An update - I've been using these since just before the last post and they've been working brilliantly since. All modes have been thoroughly tested in the last week.
WesSec commentedon Aug 3, 2026
To add my 2 cents, i've gone various (difficult) routes before and decided to keep it simple for now. predbat exposes the requested state via
predbat.statuswithin node red i take that value, and set gridpoint accordingly:I have not implemented freeze modes yet, will update if done
jeangroen commentedon Sep 14, 2026
A working target-SoC setup on Victron — traps, freeze export, and a watchdog
@Lanmate's mode mapping above is the better control model where you can use it: an AC power setpoint plus ESS limits gives you real charge and discharge modes, which the target-SoC route cannot. This comment covers the other route, the one the Victron section of the docs currently describes, where Predbat mainly writes a target SoC. It has been running here since 13 September and has planned and executed freeze export since 15 September.
System: MultiPlus-II 48/5000/70-50 with Cerbo GX (Venus OS v3.79), Seplos 16 kWh, Enphase AC-coupled PV (east/west, 9.66 kWp), single phase, Home Assistant with the Predbat add-on (v9.0.3). Victron GX integration, so the same
gx_device_*entity names as @Lanmate.The thing to understand first: on a Victron the target SoC register is the minimum SoC. Every value Predbat writes as "charge up to here" is read by the Cerbo at the same time as "never go below here". Most of what follows comes from that.
1. Set the ESS mode to "Optimized (without BatteryLife)" — or nothing you write is binding
This one cost me an evening and it gives no error anywhere.
In Optimized with BatteryLife (
select.gx_device_ess_mode=optimized_battery_life) the minimum SoC you write is only a lower bound. The Cerbo keeps its own, dynamically moving value next to it, the Active SoC limit (sensor.<name>_active_soc_limitin the GX integration), and that is what actually applies.number.gx_device_ess_min_soc_limitreads back exactly what you wrote, so everything looks fine.Measured on 14 September:
That evening the battery stopped discharging with 11.6 kWh in it and the house ran on the grid at peak price. After switching to
optimized_no_battery_life, the Active SoC limit went from 75 to 10 within one second and the battery resumed discharging.Keep the Active SoC limit next to your written min SoC on a dashboard. As long as the two move together, Predbat is really in control. If they drift apart, something (a firmware update, a restored setting, a second controller) has let the Cerbo go its own way again.
Also check that Dynamic ESS (
select.gx_device_dess_mode) isoff, otherwise two optimisers fight over the same knobs.2. Use SK as the base type, and override its freeze capabilities
@jfreegard1 and @AlexCPU both hit the wall of a custom type. A fully custom
inverter_typehas to be defined completely; an incomplete block gives:The shortcut:
SK(Sunsynk) is a built-in type whose capability profile matches what the docs describe for Victron:has_charge_enable_timehas_discharge_enable_timehas_target_sochas_time_windowoutput_charge_control"current"— charge rate is written in ampsTo be clear, this does not claim there is a Sunsynk here. It borrows the closest matching capability set until there is a real Victron type (the word "Victron" does not appear in
INVERTER_DEF).But SK has both freeze capabilities set to False, and
execute.pythen switches freeze charge and freeze export off again every compute cycle, whatever you set in HA. The only trace is in the log:The
inverter:block in apps.yaml overwrites every key of the profile (inverter.py:INVERTER_DEF[self.inverter_type][key] = inverter_def[key]), so this is enough:After saving, the two "does not support ... freeze" lines disappear and
set_export_freeze_only(True)shows up in the planner options. I checked the v9.1.0 diff: the override mechanism and both capability keys are unchanged. After every Predbat update, check the log for those two lines.3. Mode: "Control charge & discharge", with a lock on forced battery export
Control SOC only sounds exactly right for an inverter that can only write a SoC. It is the wrong choice: Predbat sets
set_charge_windowto False,isChargingnever becomes True,execute.pyends up atadjust_battery_target(0), and nothing ever charges.Control charge works. I now run Control charge & discharge, because that is what lets Predbat plan freeze export (solar to the grid instead of into the battery when export pays more than storing). It also opens up forced battery export, which I do not want (my supplier pays a solar bonus that does not apply to battery energy). Freeze and forced export sit behind different thresholds in
plan.py, so they can be separated:input_number.predbat_metric_min_improvement_exportinput_number.predbat_metric_min_improvement_export_freezeswitch.predbat_export_more_solarNote that this is an economic threshold, not a lock. If forced export ever pays more than 50p per slot, Predbat will plan it. On a Victron with a slightly negative grid setpoint nothing physically exports from the battery anyway, but the plan will raise the min SoC.
set_export_freeze_onlydoes nothing useful hereset_export_freeze_onlyis honoured inplan.pytoo (for export windows the planner then only tries idle or freeze). It only appeared to do nothing because the SK profile had freeze disabled (see section 2).4. Freeze export via the charge current, not the charge power
SK controls by current: Predbat writes (power ÷ battery voltage) to
timed_charge_current, and during a freeze slotexecute.pycallsadjust_charge_rate(0). That 0 is the only signal needed:An automation writes 0 to
number.gx_device_ess_max_charge_currentwhen the helper is 0, and −1 (unlimited) for any other value. I deliberately do not pass the ampere value through: Predbat assumes 3500 W → 67 A while the MultiPlus can do 70 A, so passing it would throttle normal charging for no reason.Why current and not
ess_max_charge_power_limit(a note for @Lanmate's freeze-export mapping): on my system, with AC-coupled PV, the charge power limit at 0 did not stop the battery charging from solar surplus. It kept taking 285 W. The charge current limit at 0 brought it down to 26 W within a minute. Your firmware or topology may behave differently, but it is worth checking with a meter.Measured end to end on 15 September:
5.
Trap: the min-SoC register has a step of 5— withdrawnIn the first version I reported that
number.gx_device_ess_min_soc_limit(it advertisesstep: 5) silently discards any value that is not a multiple of 5 (12 vanished, 15 came through). That was measured in BatteryLife mode. Since switching to Optimized without BatteryLife the Cerbo accepts every whole percent, even though the entity still reportsstep: 5. For example, on 20 September it took 22, 23, 24, 26, 28, 29, 30 … 41 in sequence. So my suggestion to honour the entity's step attribute would actually be counterproductive here. If you see this behaviour, check your ESS mode first (section 1).6. Trap:
reset_inverter()writes 100% as its "safe" valueIn
apps/predbat/execute.py,reset_inverter()calls:On a GivEnergy that is safe: 100 means "you may charge up to 100" inside a time window. On a Victron it means "never go below 100". The battery charges itself full from the grid and is then forbidden to deliver anything. The same call appears in the calibration branch and in
Inverter.self_test().It runs on every Predbat start and on every change of
select.predbat_modeorswitch.predbat_set_read_only. Normally Predbat overwrites it within the same cycle, so the 100 only stands for seconds. But it is the wrong direction for any inverter where the target SoC acts as a minimum, and anything that stops Predbat in between leaves it standing.Suggestion: make the reset value configurable per inverter type, or for
has_target_soc-only inverters reset to the current SoC or the configured reserve instead of 100.7. The translation layer
charge_limitpoints at a helper, not at the Cerbo, and an automation translates it. The one-minute delay swallows the transient 100 from section 6. A real charge target holds for half an hour or more, so starting a minute later costs nothing, while a value that stands for seconds never arrives.Simplified version (mine also has a 5-minute heartbeat and the readiness check from section 8):
Clamped between 10 and 100. The lower bound repeats what Predbat already clamps to via
battery_min_soc, so no mistake in apps.yaml can pull the battery below the floor. Mine also sends a notification when the ESS mode drifts away fromoptimized_no_battery_life, because of section 1.8. A watchdog — which I think every Victron route needs (revised)
This part is not specific to the target-SoC approach. Whatever you write to a Victron stays written. A min SoC left at 80 means the battery can no longer discharge; a charge current left at 0 means it can no longer charge from solar; a grid setpoint left at 24000 is the same failure with a bigger bill. Predbat stopping is not the same as Predbat undoing.
The heartbeat in my first version was wrong. I used the age of
last_reportedofsensor.predbat_pv_forecast_h0with a 30-minute threshold. That sensor is written only once every 30 minutes, so there was no margin, and it gave a false alarm at 02:45 one night. Lesson: measure how often your heartbeat entity is actually written, and make the threshold a multiple of that.predbat.statusis updated every compute cycle (5 minutes). Together withpredbat.last_startedit gives one template helper that everything else uses:predbat.*entities do not exist. Predbat creates them over the API and they do not survive a Home Assistant restart.The translation automations use it like this:
The stability check is deliberately separate from the helper. Predbat sometimes writes a status in the middle of a cycle, so the helper can say ready a little too early. The stability check is what really keeps transient
reset_inverter()values away from the Cerbo. After a Predbat restart in the middle of a freeze slot, the freeze was restored 86 seconds later.9. Predbat does not always recover after a Home Assistant restart
Update 29 September: fixed upstream in v9.1.0 (#5135). Predbat now stops itself when the HA interface is missing, so the add-on restarts it. My hang was on v9.0.x; the watchdog below is now only a safety net.
When HA restarts, Predbat sometimes stops with
Too many API errors, stopping, and then the add-on watchdog restarts it before HA is back:The HA connection is only set up at start and never retried, and the watchdog sees a running process, so it stays like that. Whether it happens depends on timing (which API drops first). I have seen both the good and the bad case.
My workaround is an automation: if the add-on is running (
binary_sensor.predbat_running, enable it in the Supervisor integration) and the helper above has not been ready for 10 minutes, send a notification, callhassio.app_restart, then wait 30 minutes (mode: single). A healthy Predbat is ready within a minute after an add-on restart and within one cycle after an HA restart, so 10 minutes is a safe threshold.Possibly worth a separate issue: retry the HA interface initialisation instead of giving up.
10. Two sensors not to use as indicators
sensor.gx_device_dc_battery_stateflips between charging and idle every few seconds around zero (ESS control dead band of 0–32 W). I measured eight changes in nine minutes. It is useless as a "battery is charging" indicator.load_poweryou calculate yourself (grid + PV + battery AC), notac_loads.Full apps.yaml
apps.yaml (entity serials anonymised; comments explain the why)
Offer (done)
Done: the docs PR is #5332, merged on 9 October 2026. The Victron section of
docs/inverter-setup.mdandtemplates/victron.yamlare now inmain.docs/inverter-setup.mdstill links totemplates/victron.yaml, but as of today that file does not exist in the repository (onlysunsynk.yamland the others). The link 404s.@AlexCPU mentioned writing a template for the HACS MQTT integration. Are you still on that? If not, I am happy to open the PR: @Lanmate's setpoint mapping as the main documented route, the target-SoC route above as the simpler fallback, the SK base type with the freeze override, the BatteryLife warning, and the watchdog. I would raise the code points (
reset_inverter()writing 100 for target-SoC-only inverters, and freeze export at 100% SoC never callingdischarge_freeze_service) as a separate issue, so a docs PR does not get held up behind them. (Done: #5302 for the freeze export, #5303 forreset_inverter().)jeangroen commentedon Sep 21, 2026
I've updated my comment above after a week of running it. The main changes: the step-5 trap was a BatteryLife side effect and is withdrawn, BatteryLife mode itself is a much bigger trap, freeze export now works (freeze capability override on SK plus the charge current), and the watchdog heartbeat has been replaced. The offer to write the Victron docs/template PR still stands. @gcoan, would that be welcome?
WesSec commentedon Sep 21, 2026
Thanks for your extensive testing @jeangroen! Although I think your approach is solid in the way it's designed, I'd personally prefer a method that doesn't touch the Min SoC setting, similar to what @Lanmate described. There is no good or bad, just different usecases. If the docs could have both methods documented and worked out, that would be great.
My Node-RED flow (mentioned above) has been updated with freeze nodes:
Only 3 values in the Victron system are now controlled:
number...ess_max_charge_current)number...ess_max_inverter_power_limit)number...ac_power_setpoint)Here is how each Predbat mode maps to those parameters:
24000 Wthermal_charge_current_a0 W50 Wthermal_charge_current_a0 W-5700 W0 Avictron_discharge_limit50 W0 Avictron_discharge_limit50 Wthermal_charge_current_avictron_discharge_limit(Note:
thermal_charge_current_ais dynamically calculated based on battery temperature/limits (hot and cold), andvictron_discharge_limitreflects my inverter's maximum output limit). These are global variables but can also be set directlyjeangroen commentedon Sep 22, 2026
Thanks @WesSec, and agreed: no good or bad, just different situations.
My setup has only been in production for a short while. I'm still in the phase of monitoring it and adjusting where needed. It's built around my own situation: my contract pays a solar bonus that doesn't apply to energy exported from the battery, so battery export gains me nothing and I don't do it.
I find it interesting to see how others approach this, and I want to learn from that and test further on my own system. The goal is a design that is as simple and clear as possible, usable for more than one battery strategy, and that relies as much as possible on Predbat's own planning.
Precisely because these are different use cases, I think it's important that the docs spell out those differences, so that people searching end up faster on the route that fits their situation.
One thing that already stands out: for freeze exporting we independently arrived at the same thing, max charge current to 0 and everything else open. That seems like the core that belongs in any Victron route.
A few questions so I understand your route properly:
I'm really curious about your answers, as they're important input for what we'd eventually put in the docs. I'll take a few more weeks to investigate before proposing anything there. @gcoan, so my offer for the PR still stands, just a bit later than I wrote.
WesSec commentedon Sep 22, 2026
It's a personal preference to be able to view a flow of an automation. Although the same behavior can ben created in pure code. I like node red (without function nodes). If an automation breaks, the steps are easy to follow without need for extensive documentation. This also allows for other automation (temp throttling, discussed later), or limiting the Victron charger current when the EV is charging (i charge very cheap so i want EV charging to have a higher priority than my ESS)
I do not stop at a target SoC, Predbat recalculates often enough (every 10 minutes) to adjust for this in my situation. When prediction is a bit off, this can result in target SoC being reached earlier than expected, possibly for a little higher price. I prefer this over not reaching the target at all because theres no charging headroom due to unplanned demand.
Yes, i use JKBMS with DVCC. My battery is in the (ventilated) shed and temps fluctuate a bit (max reported ambient was 36c this summer). My cells specify charge rates at different temps, and JKBMS only supports a hard stop at a certain temp:
Using node red, i can modify fan speed, or limit charging/discharing power when temps are out of a comfortable or specced range. In practice i limit charging speed a bit when ambient is above 36, lower thresholds ave not been met yet, i expect them to hit this fall/winter.
When limiting, it is important to do this on multiple levels:
manual_api:("option":"inverter_limit_charge(0)=" & $string(predbat_charge_limit)and{"option":"inverter_limit_discharge(0)=" & $string(predbat_discharge_limit)}entity to let it know it's current limits, this triggers a recalculation based on those limits, making the plan accurate for the current restrictions. There is debouncing implemented in case the battery hovers around a tigger temp.The gradual limiting can also be done via JKBMS directly (i have the entities in Home Assistant), but i prefer not to touch those and have that as a hard fall back in case anything fails.
To summarize: in order to combine these various systems in automations, node red is the tool for me to design and implement it. But that's very personal and although i like to explain and give context about it. It is not very relevant to the Victron support module in predbat.
My complete control flow looks like this (temp limit calculation and fan speed for shed is in another flow):
Hope this helps you, I am happy to explain any choices further if needed. And thanks again for your contributions!
jeangroen commentedon Sep 29, 2026
Thanks @WesSec, that answers all three, and it helps me see where our routes really differ.
What I take from it for the docs:
inverter_limit_charge) make sense for a BMS that only has a hard stop. My Seplos passes its temperature-dependent charge current limit over CAN/DVCC, so I only give Predbat the temperature curve inapps.yamland do not throttle myself. Worth a line in the docs: whether you need your own limiting depends on what your BMS sends.Two corrections to my long comment above, after checking the code again:
set_export_freeze_onlyis used inplan.py(it limits the planner to idle/freeze for export windows). What I saw came from the SK profile: withsupport_discharge_freezefalse, freeze is disabled entirely, so the setting has nothing to act on. With the override from section 2 it works as documented.I've corrected both in the comment above.
Lanmate commentedon Oct 5, 2026
I'll add my answers here too:
jeangroen commentedon Oct 6, 2026
Thanks @Lanmate, that's really helpful, and thanks for confirming the route B summary in #5332.
Your answers make the difference between the routes quite clear:
jeangroen commentedon Oct 10, 2026
The Victron docs are now in
main(#5332, merged by @springfall2008 on 9 October). The Victron section ofdocs/inverter-setup.mddescribes three routes: A (target SoC), B (grid setpoint and ESS limits, by @Lanmate) and C (Node-RED followingpredbat.status, by @WesSec), plus the shared prerequisites and known limitations. Thetemplates/victron.yamllink no longer 404s.Thanks @Lanmate and @WesSec for sharing your set-ups and checking the summaries, and @springfall2008 for merging.
Once #5302 or #5303 is fixed, I'll update the known limitations in the docs.
@jfreegard1 @gcoan: from my side the documentation part of this issue is done.