springfall2008
LuxPower - charge_freeze_service & discharge_freeze_service raising exceptions.
I'm trying to get the above services set up but an exception is raised each time these services are called. What am I doing wrong? apps.yaml has_service_api: True support_charge_freeze: True support_discharge_freeze: True
charge_freeze_service: - service: my_charge_freeze_service device_id: 53b47dc71e7cd328925306f3497 power: number.lux_charge_current_limit target_soc: sensor.lux_battery - service: switch.turn_on entity_id: "switch.lux_charge_priority" discharge_freeze_service: - service: my_discharge_freeze_service device_id: 53b47dc71e7cd328925306f3497 power: number.lux_discharge_current_limit target_soc: sensor.lux_battery - service: switch.turn_on entity_id: "switch.lux_charge_last"
Exceptions raised: charge_freeze_service
2025-04-03 15:05:23.940605: Inverter 0 Calling service charge_freeze_service domain charge service_name my_charge_freeze_service with data {'device_id': '53b47dc71e7cd328925306f3497', 'power': 'number.lux_charge_current_limit', 'target_soc': 'sensor.lux_battery'} 2025-04-03 15:05:23.940677: Error: Exception raised not enough values to unpack (expected 2, got 1) 2025-04-03 15:05:23.950155: Error: Traceback (most recent call last): File "/config/predbat.py", line 1307, in update_time_loop self.update_pred(scheduled=False) File "/config/predbat.py", line 632, in update_pred status, status_extra = self.execute_plan() File "/config/execute.py", line 442, in execute_plan inverter.adjust_charge_immediate(inverter.soc_percent, freeze=True) File "/config/inverter.py", line 2138, in adjust_charge_immediate if not self.call_service_template("charge_freeze_service", service_data, domain="charge", extra_data=extra_data): File "/config/inverter.py", line 2112, in call_service_template self.base.call_service_wrapper(service_name, **service_data) File "/config/predbat.py", line 252, in call_service_wrapper return self.ha_interface.call_service(service, **kwargs) File "/config/ha.py", line 502, in call_service domain, service = service.split("/") ValueError: not enough values to unpack (expected 2, got 1)
discharge_freeze_service
2025-04-03 15:24:05.986117: Inverter 0 Calling service discharge_freeze_service domain discharge service_name my_discharge_freeze_service with data {'device_id': '53b47dc71e7cd328925306f3497', 'power': 'number.lux_discharge_current_limit', 'target_soc': 'sensor.lux_battery'} 2025-04-03 15:24:05.986258: Error: Exception raised not enough values to unpack (expected 2, got 1) 2025-04-03 15:24:05.986716: Error: Traceback (most recent call last): File "/config/predbat.py", line 1307, in update_time_loop self.update_pred(scheduled=False) File "/config/predbat.py", line 632, in update_pred status, status_extra = self.execute_plan() File "/config/execute.py", line 429, in execute_plan inverter.adjust_export_immediate(inverter.soc_percent, freeze=True) File "/config/inverter.py", line 2163, in adjust_export_immediate if not self.call_service_template("discharge_freeze_service", service_data, domain="discharge", extra_data=extra_data): File "/config/inverter.py", line 2112, in call_service_template self.base.call_service_wrapper(service_name, **service_data) File "/config/predbat.py", line 252, in call_service_wrapper return self.ha_interface.call_service(service, **kwargs) File "/config/ha.py", line 502, in call_service domain, service = service.split("/") ValueError: not enough values to unpack (expected 2, got 1)
2025-04-03 15:24:06.028682: Info: record_status Error: Exception raised not enough values to unpack (expected 2, got 1) 2025-04-03 15:24:06.028826: Error: not enough values to unpack (expected 2, got 1)
Any help would be greatly appreciated.
I'm personally not a fan of device id's which are HA-install specific and I never use them. I always just use entity id's.
Don't know if that helps fix your problem or not?
I agree. I only used device_id because it is what's mentioned in the documentation on the following page:-. https://springfall2008.github.io/batpred/inverter-setup/#service-api I'm no expert and I can't fathom out from the exception what the missing value could be.
@raldred It would be good to get this working properly especially discharge_freeze_service (Charge Last) since this is more likely to happen following update v18.16.7 @springfall2008
I am hoping that this problem turns out to be nothing more than a schoolboy error on my part.
charge_freeze_service:
- service: my_charge_freeze_service device_id: 53b47dc71e7cd328925306f3497 power: number.lux_charge_current_limit target_soc: sensor.lux_battery
- service: switch.turn_on entity_id: "switch.lux_charge_priority" discharge_freeze_service:
- service: my_discharge_freeze_service device_id: 53b47dc71e7cd328925306f3497 power: number.lux_discharge_current_limit target_soc: sensor.lux_battery
- service: switch.turn_on entity_id: "switch.lux_charge_last"
have you got a service defined in Home Assistant called my_charge_freeze_service? The example in the documentation is just that, its an example, is expecting you to customise to the precise sequence of activities you need to invoke to do a charge freeze - this can either be manipulating HA controls OR calling an API, or both
If you look at the terminolgy Predbat uses for Freeze Charge mode https://springfall2008.github.io/batpred/what-does-predbat-do/#predbat-modes (and freeze discharge), you will probably need to manipulate the luxpower inverter controls to achieve the same result.
So freeze charging on my givenergy inverter sets the inverter into charge mode (set start and end time and turn AC charge enable on) BUT also sets the target_soc (charge-to) to the current SoC value
Yeh so having a think about it, based on the terminology of the states @gcoan linked, I think we could do something like...
Freeze charging
- Switch on
switch.lux_charge_last - Switch off
switch.lux_feed_in_grid - Set
number.lux_discharge_current_limitto0
PV or the grid will meet demand, If PV generation exceeds demand, it will charge the battery
Freeze exporting
- Switch on
switch.lux_charge_lastthis should be enough, excess PV will be exported, if there is a short fall the battery will discharge to meet demand as normal
We'll need an automation to watch for changes to predbat.status to switch off switch.lux_charge_last and switch on switch.lux_feed_in_grid when it's no longer in freeze state.
May also want to turn on switch.lux_feed_in_grid if the battery reaches 100% so that in "Freeze charging" excess PV will be exported rather than clipped.
We'll need an automation to watch for changes to predbat.status to switch off switch.lux_charge_last and switch on switch.lux_feed_in_grid when it's no longer in freeze state.
there isn't a stop_discharge_freeze service in predbat unfortunately - maybe there should be - but at the moment it calls the same stop_discharge service
Could the luxpower stop_discharge turn lux_charge_last off and switch on lux_feed_in_grid for every stop discharge activity - would that cause a problem (for ordinary export to grid discharges) ?
If we setup an automation.... We can use conditions to trigger different things depending on the current state? eg.
alias: Lux toggle discharge freeze
description: ""
triggers: []
conditions: []
actions:
- if:
- condition: state
entity_id: switch.lux_charge_last
state: "on"
then:
- action: switch.turn_off
metadata: {}
data: {}
target:
entity_id: switch.lux_charge_last
else:
- if:
- condition: state
entity_id: switch.lux_charge_last
state: "off"
then:
- action: switch.turn_on
metadata: {}
data: {}
target:
entity_id: switch.lux_charge_last
mode: single
Then we can trigger from batpred with...
discharge_freeze_service:
service: automation.trigger
entity_id: automation.lux_toggle_discharge_freeze
I think discharge freeze service is only called at the start of a discharge freeze, its the ordinary stop discharge service that is caused at the end of BOTH a discharge freeze and a discharge period
So the flexibility needs to be in discharge_stop
I see what you're saying, stopping freeze calls the regular discharge_stop_service
So I think we could do that with a similar automation, with the conditions being dependant on whether charge last is enabled?
If it is, we know to reset everything as we've stopped discharge freeze, if charge last isn't set, we know it's a regular so just turn off switch.lux_force_discharge_enable
Ahh I remember why I gave on this, you can't set the charge/discharge current to zero. I wanted to use current control to prevent charging/discharging, but the minimum I can set on my inverter is 8A.
How about this...
When triggered
- If charge last is on, it will switch it off
- If charge last is off, it will disable the regular force discharge
alias: Lux batpred stop discharge
description: "Either stop freeze discharge or regular discharge"
triggers: []
conditions: []
actions:
- if:
- condition: state
entity_id: switch.lux_charge_last
state: "on"
then:
- action: switch.turn_off
metadata: {}
data: {}
target:
entity_id: switch.lux_charge_last
else:
- if:
- condition: state
entity_id: switch.lux_charge_last
state: "off"
then:
- action: switch.turn_off
metadata: {}
data: {}
target:
entity_id: switch.lux_force_discharge_enable
mode: single
Call with
discharge_stop_service:
service: automation.trigger
entity_id: automation.lux_batpred_stop_discharge
I'll give it a whirl and report back.
I don't know if this will be any help as a start but I made a couple of switch groups one switch.lux_charge_group which consists of Lux Charge Priority and Lux AC Charge Enable and switch.lux_discharge_group which consists of Lux Force Discharge Enable and Lux Charge Last.
Calling
charge_stop_service:
service: switch.turn_off
entity_id: "switch.lux_charge_group"
Would ensure that both were turned off. Likewise
discharge_stop_service:
service: switch.turn_off
entity_id: "switch.lux_discharge_group"
That way I can't see a scenario where one member of the group would be on and the other would be off. All the entities can be turned on individually. Doesn't particularly help with defining the services properly though.
Ok, my freeze export is working as expected it seems,
It was freezing, then stopped
It's been functioning normally with my import/export overnight
Interesting switch groups might work freeze export but I don't think charge priority is going to give us what we want because we don't want the battery charging during freeze?
Actually maybe it will work because you can have a switch group for charge stop and one for discharge Stop with the relevant switches within
I don't think charge priority is the right option for charge freeze because it won't hold the current SOC. It will charge the battery before load.
I think charge freeze needs to be a combination of enabling charge last and disabling feed in.
The problem with disabling feed-in comes. If there is an excess of PV and the battery is full, the extra generation will be clipped so you'll lose out on the export, but we could get around that with another automation I always making sure that grid feedin is enabled if the battery is full
Sorry to disagree but I think it is Charge Priority, This is from the documentation:
Freeze charging - The battery is charging but the current battery level (SoC) is frozen (held). Think of it as a charge to the current battery level. The grid or solar covers any house load. If there is a shortfall of Solar power to meet house load, the excess house load is met from grid import, but if there is excess Solar power above the house load, the excess solar will be used to charge the battery,
Basically I think it means that nothing will be drawn from the battery. For example, with an EV (which I don't have) freeze_charge would stop the house battery from charging the car.
It took me a while to get my head around the terminology. LuxPower looks at things from the solar panels point of view, whilst Predbat takes a battery perspective.
"Charge priority" on Lux inverters is intended to prioritise charging the bettery first, before any solar is used to supply load, it will only supply the load if PV exceeds your max charge rate.
Therefore I believe this goes against the ideal of what batpred is trying to do with "Charge Freeze", since it it's intending to hold the current SOC, and use PV / Grid for demand, you wont get that if you use "Charge priority".
Yeh it will stop the battery being discharged, but it will charge the battery from the PV, therefore, not holding, which isn't what we want with "Charge Freeze"
If you have a car, like I do, batpred will automatically sync battery charge, export with your car charging schedule to prevent your EV discharging the battery.
Charge priority enabled will distribute PV as follows
PV -> Battery -> load
it will only fulfil load if the battery generation exceeds the max charge rate in your case 4kW or the battery is full
Charge freeze on batpred expects
PV -> Load -> Battery
when the load has been satisfied by PV only then will it charge the battery
I think I have it working, using a couple more automations to turn on last charge and set discharge limit to 0A to prevent the battery being discharged to satisfy load, load above PV generation is being pulled from the grid.
So with charge freeze, battery is being held.
Start freeze
charge_freeze_service:
service: automation.trigger
entity_id: "automation.lux_batpred_start_freeze_charge"
alias: Lux batpred start freeze charge
description: "Start batpred charge freeze mode, turn on charge last, and set discharge current 0 to prevent discharging battery to satisfy load"
triggers: []
conditions: []
actions:
- action: switch.turn_on
metadata: {}
data: {}
target:
entity_id: switch.lux_charge_last
- action: number.set_value
metadata: {}
data:
value: "0"
target:
entity_id: number.lux_discharge_current_limit
mode: single
Stop charge/freeze charge
charge_stop_service:
service: automation.trigger
entity_id: "automation.lux_batpred_stop_charge"
alias: Lux batpred stop charge
description: Either stop freeze charge or regular charge
triggers: []
conditions: []
actions:
- action: switch.turn_off
metadata: {}
data: {}
target:
entity_id: switch.lux_charge_last
- action: switch.turn_off
metadata: {}
data: {}
target:
entity_id: switch.lux_ac_charge_enable
mode: single
Just a thought……Should we be looking at the logic of why and when freeze_charge happens? Is it that it’s only called when the battery SOC is less than 100% and it’s important to the plan that the battery is not discharged? Is it the intention that the battery gets up to 100% sooner than would otherwise have happened, even at the expense of having to import from the grid? And/or if it is at 100% it’s crucial that it doesn’t discharge? If that is the case I’m thinking that LuxPower might have a built-in advantage with Charge First/Priority. Given that the plan recalculates every 5 - 10 mins it may be that freeze_charge is needed for less time. I’ve never used Charge First/Priority and am away from home for a couple of days but I’d really like to see what actually happens when it is enabled. Have I got this completely wrong @springfall2008 ?
What if we used Charge Priority but had a custom service with a template sensor that reduced the battery_rate_max (with the proviso that it is >= 0) to the difference between the PV output live and the house load live when the freeze_charge_service was called? That way the house load is met, any excess charges the battery and hopefully if there’s a shortfall the battery won’t discharge and the difference is met by the grid. Apologies, I’m on my phone so giving a code example is painfully slow.
How and why predbat uses the different modes is a bit of a black art! One example of freeze charge that predbat is doing for me on Octopus Cosy is in the cheaper rate periods, Predbat will set a freeze charge to hold the current soc and ensure that the home runs off grid as this is cheaper (after losses) than letting the battery discharge and then be recharged next day from solar. This can happen regardless of SoC, its more a function of import and export rates now and in the future.
I would be doubtful of changing battery charge rates based upon live PV values - PV changes all the time based on temperature, clouds, etc and so you won't get an accurate result.
Note that whilst predbat runs every 5 minutes it only recalculates the plan every 10 minutes. Every other run it is just executing the previously calculated plan (which is at 5 minutes granularity)
DISCHARGE_FREEZE_SERVICE
From the documentation Freeze exporting - The battery is in demand mode, but with charging disabled. The battery or solar covers the house load. As charging is disabled, if there is excess solar generated, the current SoC level will be held and the excess solar will be exported. If there is a shortfall of generated solar power to meet the house load, the battery will discharge to meet the extra load.
This is easy as it is the same as Charge Last
discharge_freeze_service:
- service: switch.turn_on
entity_id: "switch.lux_charge_last"
(As far as I know the 58w going to the battery is what is required to keep the BMS ticking over)
And a little later with a high load with FrzExp
As mentioned before I made a switch group "switch.lux_discharge_group" with the following members -
discharge_stop_service:
service: switch.turn_off
entity_id: "switch.lux_discharge_group"
Doing this means that you don't need any automations to start or stop the services. As they will never both be on at the same time, stopping one will stop both so that they will be 'off' next time the are called.
Sounds good, yeh freeze export is as easy as enabling charge last, and ensuring is disabled by stop discharge.
I've done it by triggering an automation because it like the traces you get with automation triggers but the result is the same.
Freeze charge is more complicated.
CHARGE_FREEZE_SERVICE
From the documentation -
Freeze charging - The battery is charging but the current battery level (SoC) is frozen (held). Think of it as a charge to the current battery level. The grid or solar covers any house load. If there is a shortfall of Solar power to meet house load, the excess house load is met from grid import, but if there is excess Solar power above the house load, the excess solar will be used to charge the battery, (the bold italics are mine)
Despite some admittedly confusing terminology I read this as being basically the same as 'Demand mode' but with with any shortfall being met from the grid, not the battery. Note: if The battery is charging is correct then battery level (SoC) being frozen (held) isn't quite right, as the battery level can actually rise but it won't go below its present level.
@raldred I tested your solution this morning and evening. It does work however, with respect, it is not quite doing what is described above. Battery is charging at the same rate as the solar output (less losses) and all of the house load is coming from the grid. Solar is not contributing to the house load. Unless I'm mistaken isn't this the same behaviour as Charge First?
In an attempt to mimic 'charge_freeze_service' ,as described, I removed the 'Charge Last' action from the @raldred automation as follows:-
alias: Lux batpred start freeze charge
description: >-
Start batpred charge freeze mode, turn on charge last, and set discharge
current 0 to prevent discharging battery to satisfy load
triggers: []
conditions: []
actions:
- action: number.set_value
metadata: {}
data:
value: "0"
target:
entity_id: number.lux_discharge_current_limit
mode: single
This resulted in the inverter behaving as if it was in 'Charge First / Charge Priority' mode - all solar going to the battery and house load coming from the grid, again not matching the definition of charge_freeze_service.
Unless anyone knows otherwise I can't see a way to manipulate 'Demand' mode to replicate what 'charge_freeze_service is supposed to do. Does anyone else agree?
If we can't get anything to work, is it worth submitting a feature request specific to LuxPower inverters such that 'Charge First / Charge Priority' can be used by the Predbat plan if ever it proved to be cost-effective? @springfall2008 @gcoan
There's nothing predbat can do more, we need to find the combination.
I think we need to do the following on charge freeze service call.
- Enable charge last, to enforce that solar covers demand first
- Disable grid feed in, prevents export of excess solar
- Set discharge current to 0A, prevents battery being discharged
This will ensure that...
If there is a short fall of solar for demand, any extra required will be supplied by the grid. If there is an excess of solar, demand will be met by the solar, the extra will charge the battery, as feed in is disabled
switch.lux_charge_last, enable
switch.lux_feed_in_grid, disable
number.lux_discharge_current_limit, set 0
Stop charge service just needs to
Disable switch.lux_charge_last,
Enable switch.lux_feed_in_grid,
number.lux_discharge_current_limit will be managed automatically by predbat
I think I've cracked it (almost)! Given that the crucial thing about 'charge_freeze_service' is that the battery doesn't discharge to met any house load and any shortfall is drawn from the grid, how about this?
Create a number helper to check whether the solar output is sufficient to meet the house load - Solar output minus Home consumption.
{{ states("sensor.lux_solar_output_live") | float - states("sensor.lux_home_consumption_live") | float }}
number.lux_predbat_solar_home
Create an automation as follows to constantly monitor the state of the helper. If the value is above 0 do nothing - we are in normal 'Demand' mode. If the value falls below 0, switch on 'Charge First' to prevent the battery from discharging and ensure house load is met from the grid. Any solar power will charge the battery.
alias: Lux Predbat Freeze Charge
description: >-
Predbat charge_freeze_service switching. Turn on Charge Priority if Home
Comsumption is greater than Solar Output.
triggers:
- trigger: state
entity_id:
- number.lux_predbat_solar_home
for:
hours: 0
minutes: 0
seconds: 30
conditions: []
actions:
- choose:
- conditions:
- condition: numeric_state
entity_id: number.lux_predbat_solar_home
below: 0.1
sequence:
- action: switch.turn_on
metadata: {}
data: {}
target:
entity_id: switch.lux_charge_priority
- conditions:
- condition: numeric_state
entity_id: number.lux_predbat_solar_home
above: -0.1
sequence:
- action: switch.turn_off
metadata: {}
data: {}
target:
entity_id: switch.lux_charge_priority
mode: single
I've added a time delay to cope with any 'inverter lag' to confirm that the load is genuinely higher than the solar output, especially in borderline cases.
Change from 'false' to 'true' in the inverter section of the default apps.yaml
inverter_type: LuxPower
inverter:
..................................................
support_charge_freeze: True
support_discharge_freeze: True
Turn on the automation thus:
charge_freeze_service:
service: automation.turn_on
entity_id: "automation.lux_predbat_freeze_charge"
Turn the automation off as follows: Note 'charge_stop_service' also turns off ac charge as well charge priority (needed in case it was turned on by the automation)
charge_stop_service:
- service: switch.turn_off
entity_id: "switch.lux_ac_charge_enable"
- service: switch.turn_off
entity_id: "switch.lux_charge_priority"
- service: automation.turn_off
entity_id: "automation.lux_predbat_freeze_charge"
Now for the (almost) bit - Charge First / Charge Priority will stop the battery from discharging and will pull the whole of the house load from the grid whilst using all of the solar output to charge the battery, whereas the Predbat charge_freeze_service will only draw any shortfall from the grid. This isn't a problem when there is no solar output or the battery SoC is 100% but there is a small extra cost implication otherwise. In the official description If there is a shortfall of Solar power to meet house load, the excess house load is met from grid import, but if there is excess Solar power above the house load, the excess solar will be used to charge the battery,
The extra cost equates to the difference between the solar output that is put into the battery and what would have been used for house load according to the Predbat definition.
Unless someone can come up with a better idea, I think that this is about as close as we're going to get but of course it doesn't exactly match what 'charge_freeze_service' does.
Is it worth submitting a Feature Request, that would be specific to LuxPower inverters, a sort of lux_freeze_charge_service that would only be called if the conditions of 'Charge First' were of benefit to the plan?
@brickatius I'm going through issues assigned to me and came across this one. Not sure where we are with it, is there a working solution (with caveats) that can be incorporated in the documentation?
Notwithstanding your request for a specific charge freeze service which hasn't been progressed
In summary I'm running with this: discharge_freeze_service
support_discharge_freeze: True
discharge_freeze_service:
- service: switch.turn_on
entity_id: "switch.lux_charge_last"
discharge_stop_service:
- service: switch.turn_off
entity_id: "switch.lux_charge_last"
I've just switched from Flux to Agile import /Agile fixed. There's a lot of 'FrzExp' so this works well.
charge_freeze_service I was using this however for some reason the helper has been disabled and I can't reenable it. On top of that Predbat was ignoring the instruction to turn switch.lux_charge_priority on or off. The effect was that Charge Priority was turned on all the time whenever ChrgFrz was called even though the switch was off.
support_discharge_freeze: True
charge_freeze_service:
- service: automation.turn_on
entity_id: "automation.lux_predbat_freeze_charge"
charge_stop_service:
- service: automation.turn_off
entity_id: "automation.lux_predbat_freeze_charge"
The automation is this
alias: Lux Predbat Freeze Charge
description: >-
Predbat charge_freeze_service switching. Turn on Charge Priority if Home
Comsumption is greater than Solar Output.
triggers:
- trigger: state
entity_id:
- number.lux_predbat_solar_home
conditions: []
actions:
- choose:
- conditions:
- condition: numeric_state
entity_id: number.lux_predbat_solar_home
below: 0
sequence:
- action: switch.turn_on
metadata: {}
data: {}
target:
entity_id: switch.lux_charge_priority
- conditions:
- condition: numeric_state
entity_id: number.lux_predbat_solar_home
above: 0
sequence:
- action: switch.turn_off
metadata: {}
data: {}
target:
entity_id: switch.lux_charge_priority
mode: single
It relies on the lux_predbat_solar_home helper thus
{{ states("sensor.lux_solar_output_live") | float - states("sensor.lux_home_consumption_live") | float }}
I'm going to simply turn Charge Priority on whenever the charge_freeze_service is called with the caveat that the start and stop times are set to 00:00 and 23:59 in the LuxPower portal/app.
charge_freeze_service:
- service: switch.turn_on
entity_id: "switch.lux_charge_priority"
charge_stop_service
- service: switch.turn_off
entity_id: "switch.lux_charge_priority"
IN SUMMARY The discharge_freeze_service is absolutely fine. The straight charge_freeze_service on/off is good enough for me, as at least is does stop the battery from discharging - whether it's good enough to go in the apps.yaml I'm not sure. When there's no solar or the battery is full it's doing what the docs say but isn't the same when that's not the case. If you've got any ideas as to why the helper is disabled and Predbat is ignoring the automation I'd be happy to hear. If we can sort that out I'd say go with it. Your call.
Further investigation and resolution of charge freeze for Luxpower will be on #2916