Specific 'charge_freeze_service' for LuxPower inverters.

[brickatius]

Would it be possible to have a specific 'lux_charge_freeze_service' to accommodate the Charge First / Charge Priority function on LuxPower inverters?

You will see from Issue #2197 that we can't quite manipulate the LuxPower entities to emulate what should happen with the Predbat 'charge_freeze_service'

With the LuxPower 'Charge First' ALL of the PV output (if there is any) goes to charging the battery. The battery will not discharge (effectively freezing/holding the charge) because ALL of the house load is met from the grid. Could the plan be adapted to use this facility if it was cost effective?

Charge First has a switch to enable the function

switch.lux_charge_priority

It also has scheduled start and finish times but we don't need to worry about these as they can be set to 00:00 and 23:59 in the Lux App/Web Portal to give effectively an ON/OFF function.

Interesting LuxPower also has a 'Charge Last' function which is an exact fit for the Predbat 'discharge_freeze_service'.

[raldred]

Batpred can't manipulate anything different that we can with our own automation that we could trigger with:

  charge_freeze_service:
    service: automation.trigger
    entity_id: "automation.lux_batpred_start_freeze_charge"

I don't see what a specific lux_charge_freeze_service would bring?

Maybe just enabling charge priority is enough, aslong as long as charge_limit (number.lux_ac_battery_charge_level) is set to the current SOC by batpred?

So it will stop force charging, but excess solar will still feed into the battery because charge priority is enabled.

So...

  charge_freeze_service:
    service: switch.turn_on
    entity_id: "switch.lux_charge_priority"

Then just add a turn off for that into the charge_stop_service automation

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
  - action: switch.turn_off
    metadata: {}
    data: {}
    target:
      entity_id: switch.lux_charge_priority
mode: single

[brickatius]

The logic behind my asking for this, is that whatever we have done so far comes at a cost that is different from what 'charge_freeze_service' is expecting. Maybe I'm being over-particular and a couple of pence difference here and there doesn't really matter. After all the plan will recalculate during and after any FrzChrg slot anyway. I was just curious to see what @springfall2008 thinks. If it turns out that it is feasible without having to go to any great lengths and LuxPower's ability to put as much solar energy into the battery as quickly as possible (at the cost of grid import) is of benefit, then surely a fully accurate integration of LuxPower inverters into Predbat would be a good thing?

[springfall2008]

I'm not sure I really understand the request, the current service setting is generic you can add any action you like to it, why would a luxpower specific one be any different?

[brickatius]

Thank you Trefor. I appreciate what you say about the service setting being generic. All I was trying to do was mimic what is described in 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 way I read this is that the battery never discharges. We are in normal 'Demand' mode unless the house load exceeds the Solar power, at which point what solar there is supplies the house load with any excess load being met from the grid. The closest we can get to this is that when house load exceeds Solar ALL of the house load is met from the grid, not a combination of grid and solar, resulting an increased cost.

Eg.* A) House Load = 1,000w Solar = 2,500w Predbat and LuxPower are identical. Solar to house = 1,000w; Grid import = 0w; Solar to battery = 1,500w B) House Load = 2,500w Solar = 1,500w Predbat - Solar to house = 1,500w; Grid import = 1,000w; Solar to battery = 0w LuxPower - Solar to house = 0w; Grid import = 2,500w Solar to battery = 1,500w

Increased cost = 1,500w grid import for as long as the scenario lasts, however the battery is still charging. We end up with a situation that the plan is not expecting.

I'm guessing we either A) Give up on 'charge_freeze_serivice' altogether B) Live with the compromise above C) Get a Lux specific 'charge_freeze_service' where the plan calculates a scenario where ALL of the house load comes from the grid and ALL of any solar goes to charging the battery.

• Losses not included