Feature to put the inverter in backup mode for a number of hours to protect battery SoC whilst EV charging.

[punkymuzzle]

Is your feature request related to a problem? Please describe. I want to be able to set the inverter to set to Backup mode for a number of hours (either a single or multiple slots) when I put my EV on charge, so the battery does bot drain to charge the car. When charging my Electric car overnight, some of this load will be provided by my batteries. I don't want this to happen as then I need to charge the batteries again before any price increase in the half hourly tariff rates. So a way to let the inverter know what times the car is charging (so it can not provide battery power to charge the car) would be ideal.

Describe the solution you'd like

1. What Would be great is a dashboard option to set PV-Opt into "EV Charge" mode and assign time slots & durations for this to happen.
2. PV-Opt would then set the inverter to not discharge the battery during these times
3. if the time slots selected coincided with the PV-Opt charging schedule, the battery would also charge as per the schedule (but not discharge)
4. Once the last EV charging slot had completed, PV-Opt would revert back to its calculated schedule.

I know that other automations (cough - Predbat - cough) have the ability to integrate car charging into the schedule, but that is dependent on a car charger that can be controlled. This is more of a process to protect the battery from discharging whilst EV charging is occurring when controlled via a separate app - i.e my ProjectEV app for my charger.

Describe alternatives you've considered If the hourly rates slots overnight are relatively cheap then I place PV-Opt in read only and manually set the inverter to Backup mode to prevent the battery from discharging to charge the EV. Then reset everything in the morning. However the process is not particularly easy:

1. Sometimes PV-Opt takes numerous cycles for the read only selection to "stick" so the inverter keeps resetting back to its schedule.
2. Sometimes PV-Opt resets the read only toggle back to "off", effectively ignoring my request for read only and so ends up powering the EV charge.
3. In the event of the above I sometimes have to stop AppDaemon to force PV-Opt to stop running. This is sometimes a problem as if I forget to reset things in the morning, PV-Opt does not resume running and I am usually left with an empty battery and consuming expensive electricity.
4. I can't do any of the above if the overnight price fluctuates and I want to charge my EV at certain time blocks, unless I stay up overnight to keep configuring PV-Opt.

Additional context More than willing to test this via beta versions if needed. My Inverter is a Solax X1AC.

Thanks very much in advance

[stevebuk1]

Hi, not sure whether you saw it already but over the last six months the basics of an EV integration has been added on to Pv_opt, see issue #121 for full details.

For users on IOG, it picks up the charge slots for the car and holds the inverter if not already charging, and also subtracts the car charging consumption from the total consumption to leave the house consumption only. A few of us have been using this for a good few months now without issue. Note for this the inverter is put into charge mode at zero current - backup mode isnt ideal as depending on Solis inverter model this can oscillate between full rate charging and/or self use discharge.

For Agile users, code is in place to generate a car schedule based on a "car ready by" time and a "charge to add", and will select the cheapest slots between car plugin and car ready by time to meet the charge target. This sets an entity that can then be used to start and stop the car charger automatically. (This is very much as Predbat does it) I've done some limited testing with this by forcing an Agile tariff and getting it to control my car charger - all appears fine but it does need some more testing. Can your ProjectEV charger be controlled by HA at all?

If so, then all of the above has been written for Zappi chargers but if you are ok with keeping "Use Consumption History" as Off for the time being (I imagine it is already) then I "think" it will work for any charger as the Agile car charging part doesn't communicate directly with the charger - maybe a few tweaks needed.

The ability for Pv_opt to read an external car charging schedule is for the future. Its queued up behind the ability to set manual tariff times (for Eon NextDrive and Tomato Energy users) and the ability to integrate with two Zappis.

[stevebuk1]

• Sometimes PV-Opt takes numerous cycles for the read only selection to "stick" so the inverter keeps resetting back to its schedule.
• Sometimes PV-Opt resets the read only toggle back to "off", effectively ignoring my request for read only and so ends up powering the EV charge.

Neither of these should happen (and don't on my system, where I've regularly set read only for overnight if I'm working on new code which allows me to disable Pv_opt and just do the inverter setting manually).

Separately to the EV query/request, if you can post Pv_opt.log and error.log from an overnight run where it does I'll take a look. In the interim it may be worth setting Read only = True in your config.yaml, so if Pv_opt resets for any reason that will be its default state:

  # ========================================
  # Basic parameters
  # ========================================
  read_only: true # If true the inverter will not be controlled

[punkymuzzle]

• Sometimes PV-Opt takes numerous cycles for the read only selection to "stick" so the inverter keeps resetting back to its schedule.
• Sometimes PV-Opt resets the read only toggle back to "off", effectively ignoring my request for read only and so ends up powering the EV charge.

Neither of these should happen (and don't on my system, where I've regularly set read only for overnight if I'm working on new code which allows me to disable Pv_opt and just do the inverter setting manually).

Separately to the EV query/request, if you can post Pv_opt.log and error.log from an overnight run where it does I'll take a look. In the interim it may be worth setting Read only = True in your config.yaml, so if Pv_opt resets for any reason that will be its default state:

  # ========================================
  # Basic parameters
  # ========================================
  read_only: true # If true the inverter will not be controlled

Will do, thank you very much

[punkymuzzle]

Hi, not sure whether you saw it already but over the last six months the basics of an EV integration has been added on to Pv_opt, see issue #121 for full details.

For users on IOG, it picks up the charge slots for the car and holds the inverter if not already charging, and also subtracts the car charging consumption from the total consumption to leave the house consumption only. A few of us have been using this for a good few months now without issue. Note for this the inverter is put into charge mode at zero current - backup mode isnt ideal as depending on Solis inverter model this can oscillate between full rate charging and/or self use discharge.

For Agile users, code is in place to generate a car schedule based on a "car ready by" time and a "charge to add", and will select the cheapest slots between car plugin and car ready by time to meet the charge target. This sets an entity that can then be used to start and stop the car charger automatically. (This is very much as Predbat does it) I've done some limited testing with this by forcing an Agile tariff and getting it to control my car charger - all appears fine but it does need some more testing. Can your ProjectEV charger be controlled by HA at all?

If so, then all of the above has been written for Zappi chargers but if you are ok with keeping "Use Consumption History" as Off for the time being (I imagine it is already) then I "think" it will work for any charger as the Agile car charging part doesn't communicate directly with the charger - maybe a few tweaks needed.

The ability for Pv_opt to read an external car charging schedule is for the future. Its queued up behind the ability to set manual tariff times (for Eon NextDrive and Tomato Energy users) and the ability to integrate with two Zappis.

Thanks very much for this information, much appreciated. Yes I did take a look at the thread you mentioned but I don't think it will work in my case (plus I have other use cases for pausing charging / discharging, will describe this later).

Unfortunately my Project EV is not controllable via HA. I did try to find an integration but there is nothing official to access it. Someone has tried to put something together by hacking into it with varying degrees of success, but there is nothing official that will work. So at the moment I'm stuck with using the app to charge my car (which works surprisingly well to be honest). The next issue is that I don't want to put my car n charge regularly. I do quite low mileage so tend not to charge the car every day, few days etc. My charging is more sporadic than that. So this is why I requested this functionality to be added, so I can effectively set the inverter / battery to pause when I put the car on charge, thereby charging from the mains and not the battery, which I then have to re-charge, etc.

Other use cases for this functionality are:

1. When my kids use the shower, again I would like the ability to isolate the inverter / battery so it doesn't discharge, thereby saving its charge to supply power during the expensive times (as it's programmed to do). Switching on a 10kW Shower will draw 2kW from my battery for however long the shower is in use (and as I have two kids, that can be a while). Again, draining the battery which is not desirable.
2. When Electricity is cheap / negative I would like the ability to isolate the battery for the duration, so the house load draws directly from the grid. Unless I intervene, PV-Opt will supply house load even when the price is low / negative. Yes I know I can set PV-Opt to read only and then set the Inverter to backup mode (which is what I do now) but that means effectively switching PV-Opt off whilst I do this and then remembering to reset it all back again when I want it to resume.

When @fboundy was kindly adding functionality for my Solax X1AC inverter, he setup an additional dashboard for me to send commands directly to the inverter to see if charging commands etc worked:

In my mind, something similar to set the inverter not to use the battery to supply load at these times would be the ideal thing.

Hope all that makes sense, and if you need any further information I'm happy to provide it. This isn't essential (it is an enhancement after all, not a necessity). But if something like this can be added I'm sure others would use it as well (there are probably more use cases than the three I've provided).

Thanks

[stevebuk1]

Without a way to control the charger then agreed, the EV functionality I've added won't help you.

Thanks for explaining your use case - that makes good sense and I can see how it would be a useful addition in its own right. I'll have a think and see what I can quickly add. Gut reaction at the moment is to provide a switch called "prevent battery discharge". When set, PV_opt would still charge the battery at the slots it needs to but would prevent discharge when not charging. You could then just toggle it manually, and/or use an external automation with start and end times for automated use.

[stevebuk1]

When @fboundy was kindly adding functionality for my Solax X1AC inverter, he setup an additional dashboard for me to send commands directly to the inverter to see if charging commands etc worked:

Are you using this unmodified from what was originally provided? If not, can you: 1) put the dashboard into edit mode 2) click the 3 dots 3) select "raw configuration editor" 4) copy and paste the contents into a .txt file and attach to this issue.

I'll then put the additional switch into this dashboard so you can test it out.

[punkymuzzle]

That's fantastic, thanks very much for this. This would be really helpful. yaml code for the "test" dashboard (that @fboundy kindly created for me) as follows:

type: entities
entities:
  - entity: select.pvopt_test_function
    name: Function
  - entity: select.pvopt_test_enable
    name: Enable / Disable
  - entity: text.pvopt_test_start
    name: Start Time (Local Time Zone)
  - entity: text.pvopt_test_end
    name: End Time (Local Time Zone)
  - entity: number.pvopt_test_power
    name: Power
  - entity: number.pvopt_test_target_soc
    name: Target SOC
  - entity: button.pvopt_test_button
    name: Send to Inverter
title: PV Opt Test Card

Thanks once again.

[stevebuk1]

Ok theres a Beta release (3.18.0 Beta-15) to try on my fork at https://github.com/stevebuk1/pv_opt/tree/main/apps/pv_opt.

Best probably not use HACS to install this, just overwrite the files you need, which is: https://github.com/stevebuk1/pv_opt/blob/main/apps/pv_opt/pv_opt.py https://github.com/stevebuk1/pv_opt/blob/main/apps/pv_opt/pvpy.py

Essentially I've added a new entity switch.pvopt_prevent_discharge which does exactly that for as long as it is set.

I've created a test dashboard update, which is here, https://github.com/stevebuk1/pv_opt/blob/main/dashboards/pvopt_test_card%20V2.yaml and looks like this: as you can see there is a new entity at the bottom called "Prevent Discharge".

When set, it will set the battery charge current to zero and maintain that until cleared.

You'll be able to see that in the charge plan via a charge power of 1W and a "<=Car" string, as the new entity is effectively being coupled into the car charging logic that prevents house battery discharge during car charging. Its shown as a slot at a time but will roll forward as slots come and go. Toggling "Prevent Discharge" will trigger an optimser run so latency will be a minute or two at most.

I've tested it with my system and all seems fine, but theres been a lot of updates into Beta-15 for other reasons and control of Solax inverters probably hasn't been tested. Post with logs here for any issues.

[stevebuk1]

Forgot to add that setting this switch will not affect any house battery charge plan. So you can go to bed at 10pm with it set and the house battery will charge overnight to the charge plan as normal.

[punkymuzzle]

That's fantastic, thank you very much for this. I'm away from home at the moment so won't be able to install and test this until Friday, but will install and test as soon as I can. Thanks once again, really appreciate it.

On Wed, 13 Nov 2024, 21:56 stevebuk1, @.***> wrote:

Forgot to add that setting this switch this will not affect any house battery charge plan. So you can go to bed at 10pm with it set and the battery will charge to the charge plan as normal.

— Reply to this email directly, view it on GitHub https://github.com/fboundy/pv_opt/issues/284#issuecomment-2474903049, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNR355W6PHW7PY24WW42G32APDKDAVCNFSM6AAAAABRMJ6GR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZUHEYDGMBUHE . You are receiving this because you authored the thread.Message ID: @.***>

[punkymuzzle]

OK, copied the files over and rebooted. Can see the following error in the AppDaemon log.

/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2385: SettingWithCopyWarning: A value is trying to be set on a copy of a slice from a DataFrame. Try using .loc[row_indexer,col_indexer] = value instead See the caveats in the documentation: https://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#returning-a-view-versus-a-copy y["start"] = y.index.tz_convert(self.tz) /homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2386: SettingWithCopyWarning: A value is trying to be set on a copy of a slice from a DataFrame. Try using .loc[row_indexer,col_indexer] = value instead See the caveats in the documentation: https://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#returning-a-view-versus-a-copy y["end"] = y.index.tz_convert(self.tz) + pd.Timedelta(30, "minutes")

Logs: pv_opt.log error.log

I can't test the dashboard yet as my battery SoC is 10% so it won't discharge any lower (so I won't be able to test if it's working). I'll test tomorrow when my battery has some charge in it.

Thanks

[punkymuzzle]

Tried the "Prevent discharge" option without success: Battery still providing power to the house.

[stevebuk1]

Hmmm. Thanks for the appdaemon log, I'll get that fixed but I don't think its preventing operation.

1) Can you post the pv_opt.log from when you toggled "Prevent Discharge" please.

2) Also, in your config.yaml, can you change this:

 log: pv_opt_log
  prefix: pvopt
  debug: false

  # User configuration ---  EDIT AWAY! ---
  # ========================================
  # System parameters
  # ========================================

to read this:

  log: pv_opt_log
  prefix: pvopt
  debug: true
  debug_categories: O

  # User configuration ---  EDIT AWAY! ---
  # ========================================
  # System parameters
  # ========================================

ie change debug from false to true and add " debug_categories: O" (the letter O, not the number 0) just underneath.

3) So I can understand the normal operation of Solax inverter control, can you send me an old log with things running correctly please.

[punkymuzzle]

Set the discharging to this: Switched on my immersion heater to draw 3Kw, but it's still coming from the battery and not the grid:

Here are my three logs: main.log pv_opt.log error.log

Also, copies of the oldest logs I have on HA: pv_opt.log.3.txt error.log.1.txt main.log.3.txt

Hope this helps. Many thanks

[punkymuzzle]

Update. Whilst I was replying, it started working:

so that's good progress. I'm going to retest this to coincide with when the battery should also charge to see if the settings get overwritten

[punkymuzzle]

SCratch that, this was set via PV-Opt:

[stevebuk1]

SCratch that, this was set via PV-Opt:

Good news. I expected the tag "<=Car" to appear, but I've noticed its gated on being on IOG and/or having a car charger. As part of this flag set EndSOC is set to the same as StartSOC to keep things neat. You therefore may notice end SOC is not the same as start SOC because the discharge prevention is an override after the SOC calculations are done.

Let us know when you've checked out that charging is unaffected.

[punkymuzzle]

Please tell me if I'm misunderstanding. So I think what's happening is that when I set the "Prevent Discharge" option in the test dashboard and send to the inverter it's inserting a 30 minute slot in the PV_opt schedule, but setting the W to 1W? Then, when I set the option back to deselect "prevent Discharge" then it's removing the charging slot from the schedule? Is that correct? If it is then I think it's working.

If the above is correct then I have a couple of follow on questions:

1. When I set it, the 1W charging slot was for 30 minutes (and then my next "real" charging slot was scheduled). I'm assuming that if my next "real" charging slot was a few hours away, the 1W charging slot would extend until my "real" charging slot was active?
2. If so, then what happens after the charging slot has completed? Will PV-Opt put another 1W slot in place until I cancel it from the test dashboard?
3. If that is the case then can is it just a case of toggling the "Prevent Discharge" on and off or can this be scheduled? I.e. if I had a charging schedule in place, I want to prevent discharge from, say, 0200 - 0400 to charge my car, then resume my actual PV_opt charging schedule. Will the current setup cater for this? or are we just testing that the "Prevent Discharge" option works?

Thanks very much

[punkymuzzle]

Also, not sure it's 100% working. The normal schedule has restarted, but when I look at my inverter settings the charge maximum current is still set to 0A, meaning the inverter won't charge is the sun actually comes out. Here's the settings for the inverter (which by default sets to self use mode"

But here's the charging settings:

The 0A should be set to 20 so it can charge / discharge as it sees fit until PV-Opt tells it otherwise

[stevebuk1]

Please tell me if I'm misunderstanding. So I think what's happening is that when I set the "Prevent Discharge" option in the test dashboard and send to the inverter it's inserting a 30 minute slot in the PV_opt schedule, but setting the W to 1W? Then, when I set the option back to deselect "prevent Discharge" then it's removing the charging slot from the schedule? Is that correct? If it is then I think it's working.

Yes thats correct.

If the above is correct then I have a couple of follow on questions:

1. When I set it, the 1W charging slot was for 30 minutes (and then my next "real" charging slot was scheduled). I'm assuming that if my next "real" charging slot was a few hours away, the 1W charging slot would extend until my "real" charging slot was active?

Yes thats correct also. It will only set a current of zero if Pv_opt isnt requesting a charge.

2. If so, then what happens after the charging slot has completed? Will PV-Opt put another 1W slot in place until I cancel it from the test dashboard?

Also correct.

3. If that is the case then can is it just a case of toggling the "Prevent Discharge" on and off or can this be scheduled? I.e. if I had a charging schedule in place, I want to prevent discharge from, say, 0200 - 0400 to charge my car, then resume my actual PV_opt charging schedule.

You can use an HA automation with a couple of datetime helpers to set Prevent_Discharge at 2am and clear it at 4am. If Pv_opt wants to force charge the battery in this time then it can and will.

Will the current setup cater for this? or are we just testing that the "Prevent Discharge" option works?

Thanks very much

[punkymuzzle]

OK Tried setting the "Prevent Discharge" time for a longer time to span PV-Opt charging schedul slots:

However it still looks like it defaults to a 30 minute slot:

And then when once PV_opt sets the inverter for Self use mode / Forced Time mode, it's leaving the charging rate at 0A, meaning the battery will not charge:

[stevebuk1]

The normal schedule has restarted, but when I look at my inverter settings the charge maximum current is still set to 0A, meaning the inverter won't charge is the sun actually comes out.

Yes, this is the way that the function has been designed. For Solis inverters, there are two ways of preventing discharge:

1) Set backup mode 2) Set the inverter to charge, but at a current of 0.

For Solis inverters, 1) is that backup mode will charge the battery at full rate until it reaches backup_soc, then slowly discharge until it falls beneath it, then charge at full rate again. Using 2) is basically a "don't use battery" command which avoids the above issues.

The disadvantage of 2) is that as you've spotted, if its daytime and there is good solar generation, the battery cannot charge and so the excess goes to grid. For EV charging (which is what the function was designed for) this doesnt really come into play as the 7kW draw usually exceeds solar and overnight charging on IOG means theres no solar anyway. For Agile users though, its less than ideal because cheap daytime slots are a thing.

But here's the charging settings:

The 0A should be set to 20 so it can charge / discharge as it sees fit until PV-Opt tells it otherwise

Whilst Prevent_Discharge in set, the inverter should be in "Force Time Use" so it uses the time registers, sets Charge mode and use the value on the charge current slider, which Pv_opt will set to zero. Basically, charging at a very low rate prevents any discharge.

Whilst Prevent_Discharge is cleared, the inverter should Revert back to Self use. In Solis inverters, the charge and discharge current slides have no effect in Self use. Are you saying that if that charge current remains at zero its a problem in self use?

[punkymuzzle]

1. When I set it, the 1W charging slot was for 30 minutes (and then my next "real" charging slot was scheduled). I'm assuming that if my next "real" charging slot was a few hours away, the 1W charging slot would extend until my "real" charging slot was active?

Yes thats correct also. It will only set a current of zero if Pv_opt isnt requesting a charge.

2. If so, then what happens after the charging slot has completed? Will PV-Opt put another 1W slot in place until I cancel it from the test dashboard?

Also correct.

Thanks for this. However it looks like it didn't insert the next 1W slot in (as per my latest post)?

[stevebuk1]

Thanks for this. However it looks like it didn't insert the next 1W slot in (as per my latest post)?

Ah ok. It should do, I'll try that on my system this evening (I don't think I tested it out across a slot transition so there may be a problem there).

[punkymuzzle]

OK great thank you.

Ref the earlier reply:

Whilst Prevent_Discharge in set, the inverter should be in "Force Time Use" so it uses the time registers, sets Charge mode and use the value on the charge current slider, which Pv_opt will set to zero. Basically, charging at a very low rate prevents any discharge.

Whilst Prevent_Discharge is cleared, the inverter should Revert back to Self use. In Solis inverters, the charge and discharge current slides have no effect in Self use. Are you saying that if that charge current remains at zero its a problem in self use?

Yes, when this is set to zero, my inverter will not charge (as that's the setting which controls how much power is being used to charge the battery)

Can this be set to a default of whatever the maximum power of the inverter (in my case it will set to 20A)?

[stevebuk1]

Yes, when this is set to zero, my inverter will not charge (as that's the setting which controls how much power is being used to charge the battery)

Can this be set to a default of whatever the maximum power of the inverter (in my case it will set to 20A)?

Yes that should be an easy fix. I can't imagine Pv_opt doesnt already have code for doing that after a charging slot ends, but perhaps the override logic we've added is operating slightly differently.

[punkymuzzle]

Awesome, thank you

[punkymuzzle]

3. If that is the case then can is it just a case of toggling the "Prevent Discharge" on and off or can this be scheduled? I.e. if I had a charging schedule in place, I want to prevent discharge from, say, 0200 - 0400 to charge my car, then resume my actual PV_opt charging schedule.

You can use an HA automation with a couple of datetime helpers to set Prevent_Discharge at 2am and clear it at 4am. If Pv_opt wants to force charge the battery in this time then it can and will.

One more thing :)

If the plan is to use an HA automation in order to allow us to select a slot that "Prevent Discharge" is active for, can't we use the time selection option in the dashboard instead?

The previous dashboard created by @fboundy allowed these times to be used to set charging times. So can't we use them to select "Prevent Discharge" instead?

[stevebuk1]

The previous dashboard created by @fboundy allowed these times to be used to set charging times. So can't we use them to select "Prevent Discharge" instead?

From what I made of the Solax inverter support threads, this test dashboard was created to test out writes to the inverter. So you'd set up these values, press "send to inverter" and Pv_opt would read these and send to the inverter. The key here is that the actual times were just sent to the inverter along with Power and Target SOC, Pv_opt didn't do much more with them than just program both time register sets to be the same thing. Adding a "Prevent Discharge" switch to this dashboard was done because it was a convienient place to put it, not because there is any connection between the Discharge prevent functionality and those other sliders. Reusing these to form some sort of new input to Pv_opt for Pv_opt to then create a series of hold points in advance is far more involved. This is what I meant by "The ability for Pv_opt to read an external car charging schedule is for the future." in my early posts. It might be a bit earlier than I originally envisaged because I note fboundy has already done the manual tariff overrides, but current focus is getting the existing EV functionality stable and ready for production release, then adding multiple Zappi support.

[punkymuzzle]

OK thanks, understood. I`ll look to see if i can use automatons for this.

Just so I fully understand, the prevent discharge button is in isolation, not attached to anything else? Reason I ask is that selected prevent discharge a while ago (and the 30 min slot created) and it worked, but then hasn't worked afterwards, despite it being left on.

[stevebuk1]

Just so I fully understand, the prevent discharge button is in isolation, not attached to anything else?

Yes thats right.

Reason I ask is that selected prevent discharge a while ago (and the 30 min slot created) and it worked, but then hasn't worked afterwards, despite it being left on.

If left set it should just roll into the next slot on the charge plan when the time comes. If its not doing this its a bug - I'll look at this this evening, alongside the setting of the <=Car tag and the endSOC value.

[punkymuzzle]

Thank you very much, really appreciate your help

[punkymuzzle]

For what it's worth I've created some automations, helpers and a dashboard to start / stop the "prevent discharge" at certain times (once the code is fully working):

Helpers:

created two date/time helpers:

_input_datetime.prevent_battery_discharge_time_start input_datetime.prevent_battery_discharge_timestart

Automations:

Turn on Prevent Battery Discharge:

alias: Prevent Battery Discharge - Turn On
description: Prevent Battery Discharge - Turn On
triggers:
  - value_template: >
      {{ now().strftime('%H:%M') ==
      states('input_datetime.prevent_battery_discharge_time_start')[0:5] }}
    trigger: template
conditions: []
actions:
  - target:
      entity_id: switch.pvopt_prevent_discharge
    action: switch.turn_on
    data: {}
mode: single

Turn off Prevent Battery Discharge:

alias: Prevent Battery Discharge - Turn Off
description: Prevent Battery Discharge - Turn Off
triggers:
  - value_template: >
      {{ now().strftime('%H:%M') ==
      states('input_datetime.prevent_battery_discharge_time_stop')[0:5] }}
    trigger: template
conditions: []
actions:
  - target:
      entity_id: switch.pvopt_prevent_discharge
    action: switch.turn_off
    data: {}
mode: single

Dashboard Card:

type: entities
title: Prevent Battery Discharge Settings
entities:
  - entity: input_datetime.prevent_battery_discharge_time_start
  - entity: input_datetime.prevent_battery_discharge_time_stop
  - entity: switch.pvopt_prevent_discharge
    name: Prevent Discharge
state_color: true

This is the result:

Please feel free to ignore / reuse / include in any instructions once this gets released, etc.

[stevebuk1]

Hi, ok I have a Beta version (3.19.0-Beta-16) to try that

• continues to prevent battery discharge on contiguous slots (basically it needed extending from 1/2 hour to an hour)
• sorts out the <=Car tagging and SOC values
• resets the inverter current back to 20A once finished. (this is hard coded for now)

https://github.com/fboundy/pv_opt/blob/dev/apps/pv_opt/pv_opt.py https://github.com/fboundy/pv_opt/blob/dev/apps/pv_opt/pvpy.py https://github.com/fboundy/pv_opt/blob/dev/apps/pv_opt/solis.py https://github.com/fboundy/pv_opt/blob/dev/apps/pv_opt/solax.py

I've tested this out on my system without issue so hopefully this will work better.

[punkymuzzle]

I've installed so will look at how this performs. Thank you

[punkymuzzle]

It's been running a short while now and the AppDaemon log has no errors, which is great. it also seems to be calculating charging slots etc.

I won't have time to test further for a couple of days due to work, but I'll report back as soon as I have finished testing. Thank you

[punkymuzzle]

I`ve selected the "prevent discharge" botton.

It looks like it is set for one hour at the moment so I`ll keep an eye on it to see what happens after the hour is up.

Looking good so far

[punkymuzzle]

Spoke too soon. its now disappeared from tge schedule

[stevebuk1]

Ok, please grab the log at that point and attach.

On Tue, 19 Nov 2024, 10:50 punkymuzzle, @.***> wrote:

Spoke too soon. its now disappeared from tge schedule

image.png (view on web) https://github.com/user-attachments/assets/b188bb87-f870-4da7-8c63-ca45c83bf3cf

— Reply to this email directly, view it on GitHub https://github.com/fboundy/pv_opt/issues/284#issuecomment-2485349744, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASVRJMC2W6YBCEWDCEF2V4L2BMJVVAVCNFSM6AAAAABRMJ6GR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBVGM2DSNZUGQ . You are receiving this because you were assigned.Message ID: @.***>

[punkymuzzle]

Here you go (not sure which log you need, so here's all three of them): pv_opt.log main.log error.log

[punkymuzzle]

The slot has just reappeared in the schedule (10:58 when I saw it):

I've set the PV-Opt calculation time to 5 mins so I can keep a closer eye on it

[punkymuzzle]

Looks like it has recalculated the slot (11:12 when I noticed)

[punkymuzzle]

It's just updated and rescheduled the slot again (11:35):

So it looks like it's working OK.

I'll uncheck the "prevent discharge" button and wait for it to update the charging schedule, then I'll look to see if the automations / helpers I mentioned in an earlier post work

[stevebuk1]

The appearing/disappearing I suspect this is coupled with the optimiser taking 13 minutes when you only have 10 (issue #299) , which according to main.log is equally affecting this release (which is expected).

I think the cause of this is that once the inverter is written to, it waits 300 seconds (5 minutes) for the inverter to update itself before Pv_opt checks the update has gone through, and it needs to do this twice when trying to write to the inverter. Add on the rest of the computation time gets us roughly to 13 minutes.

I looked through the Solax development issue and found this post:

You can see "update_cycle_seconds" is set to 300. This however is an override for the default value in solax.py, which is set to 15.

I can't tell from the Solax threads (both over 200 posts long) whether the inverter really needs 300 seconds (I doubt it) or can be reduced to 15. I suggest reducing it to 60 in config.yaml and see what happens. The other alternative is to back off the optimiser frequency from 10 minutes to 30 minutes, to give it time.

[punkymuzzle]

So we may have three bugs: 1. Unchecked the "prevent discharge" button at 11:35 but it hasn't removed the 1W slot until the time went past 12:00, then it removed it. So I think the charging calculation isn't removing this until 30 mins have passed.

2. Although the "prevent discharge" has been deselected, it's reappeared in the charging schedule:

3. One other thing I have noticed is that the charging schedule does not take into account the SoC when it's being prevented from discharging (ie the current SoC is 21% but PV-Opt is still calculating at 10%) :

[punkymuzzle]

The appearing/disappearing I suspect this is coupled with the optimiser taking 13 minutes when you only have 10 (issue #299) , which according to main.log is equally affecting this release (which is expected).

I think the cause of this is that once the inverter is written to, it waits 300 seconds (5 minutes) for the inverter to update itself before Pv_opt checks the update has gone through, and it needs to do this twice when trying to write to the inverter. Add on the rest of the computation time gets us roughly to 13 minutes.

I looked through the Solax development issue and found this post:

You can see "update_cycle_seconds" is set to 300. This however is an override for the default value in solax.py, which is set to 15.

I can't tell from the Solax threads (both over 200 posts long) whether the inverter really needs 300 seconds (I doubt it) or can be reduced to 15. I suggest reducing it to 60 in config.yaml and see what happens. The other alternative is to back off the optimiser frequency from 10 minutes to 30 minutes, to give it time.

I'll take a look at changing the schedule (mine seems to count down from 360 seconds, pretty sure I haven't changed anything with this). Will look later

Thanks

[punkymuzzle]

Changed the setting in config.yaml from 300 to 60 and rebooted. Now the status keeps flipping (timewise) between different readings as to how long is left (example below). it also flickers between "Waiting for Inverter Read" and "Writing to HA", "Idle", etc.

So it's not happy

[stevebuk1]

I'll take a look at changing the schedule (mine seems to count down from 360 seconds, pretty sure I haven't changed anything with this). Will look later

I'll take a look at changing the schedule (mine seems to count down from 360 seconds, pretty sure I haven't changed anything with this). Will look later

Pv_opt takes the value of updated_cycle_seconds (set to 300) and multiplies it by 1.2, which gets you the 360.

I appreciate nothings changed with this, but we have to wait 5 minutes for an inverter command to work then new functionality to write to the inverter is going to cause a massive backlog of optimiser iterations. Its probably been fine up to now because the inverter is only written to a few times, and the other optimiser runs then have a chance to catchup. Toggling Prevent_discharge is going to take 15 minutes to actually operate, and thats assuming the optimiser queue is empty. If its queued up already, its potentially hours before any external changes are going to take effect. We have to solve this issue first.

[stevebuk1]

Changed the setting in config.yaml from 300 to 60 and rebooted. Now the status keeps flipping (timewise) between different readings as to how long is left (example below). it also flickers between "Waiting for Inverter Read" and "Writing to HA", "Idle", etc.

Given the screenshots show figures above 60 the change hasnt worked or Pv_opt is still processing events that occured prior to the change. It should go: Writing to HA Waiting for Inverter Read (countdown from 60) Waiting for Inverter Read (countdown from 60) Idle

I'll relook at the code to see if its picking up 300 (360) from anywhere else, but I deduced this from the log on issue #299. Please post main.log and pv_opt.log with every post - theres nothing I can really do or investigate without them. All the information from screenshots is in the logs anyway.

[stevebuk1]

So we may have three bugs: 1. Unchecked the "prevent discharge" button at 11:35 but it hasn't removed the 1W slot until the time went past 12:00, then it removed it. So I think the charging calculation isn't removing this until 30 mins have passed.

2. Although the "prevent discharge" has been deselected, it's reappeared in the charging schedule:

I think both of these are just the delay from Prevent discharge being toggled to the optimiser getting round to it due to the queuing problem in #299. The triggers are done in strict order - the optimiser is being triggered every 10 mins but anything with inverter writes takes 13, the optimiser run scheduled to process the prevent_discharge toggle then go in at the end of that queue.

One other thing I have noticed is that the charging schedule does not take into account the SoC when it's being prevented from discharging (ie the current SoC is 21% but PV-Opt is still calculating at 10%) :

10% is what Pv_opt predicts the battery will be at 13:30. That prediction does not take account that there is a hold slot in place. (The value at the end of the hold slot is artificially changed to just be the same at the start). What will happen though is that on each run Pv_opt will work out that you havent used as much energy as you were predicting to use during 12:00 to 13:00, and update the forecast, so as the end of the 12-13 slot approaches you'll see that 10% edging back towards 20%.