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

punkymuzzle · 2024-11-07T23:31:21Z

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

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.
PV-Opt would then set the inverter to not discharge the battery during these times
if the time slots selected coincided with the PV-Opt charging schedule, the battery would also charge as per the schedule (but not discharge)
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:

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.
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.
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 · 2024-11-08T21:40:23Z

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 · 2024-11-08T22:10:23Z

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 · 2024-11-08T23:12:03Z

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 · 2024-11-08T23:41:11Z

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:

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.
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 · 2024-11-09T19:57:21Z

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 · 2024-11-09T20:58:27Z

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:

put the dashboard into edit mode
click the 3 dots
select "raw configuration editor"
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 · 2024-11-09T22:49:24Z

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.

New Test Card for Issue #284

stevebuk1 · 2024-11-13T21:51:48Z

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 · 2024-11-13T21:56:28Z

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 · 2024-11-13T23:17:17Z

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 <#284 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNR355W6PHW7PY24WW42G32APDKDAVCNFSM6AAAAABRMJ6GR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZUHEYDGMBUHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

punkymuzzle · 2024-11-14T23:45:43Z

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 · 2024-11-15T00:35:30Z

Tried the "Prevent discharge" option without success:

Battery still providing power to the house.

stevebuk1 · 2024-11-15T07:47:32Z

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

Can you post the pv_opt.log from when you toggled "Prevent Discharge" please.
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.

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

punkymuzzle · 2024-11-15T09:24:17Z

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 · 2024-11-15T09:26:21Z

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 · 2024-11-15T09:27:27Z

SCratch that, this was set via PV-Opt:

stevebuk1 · 2024-11-15T09:43:42Z

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 · 2024-11-15T10:28:51Z

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:

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?
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?
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 · 2024-11-15T10:34:13Z

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 · 2024-11-15T11:34:27Z

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:

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.

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.

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 · 2024-11-15T12:11:12Z

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 · 2024-11-15T12:17:49Z

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:

Set backup mode
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 · 2024-11-15T12:19:32Z

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.

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 · 2024-11-15T12:22:17Z

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 · 2024-11-15T12:23:29Z

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 · 2024-11-15T12:27:30Z

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 · 2024-11-15T12:30:00Z

Awesome, thank you

stevebuk1 · 2024-11-19T13:19:23Z

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 · 2024-11-19T13:28:00Z

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%.

punkymuzzle · 2024-11-19T13:48:09Z

Changed the value to 120 so there is now a pause between it optimising, which seems to have calmed it down.
However, still problems

The 1W charge disappeared from the schedule again (assuming this is as per your earlier messages).
As the SoC dropped to 10% my inverter hibernated, meaning that HA cannot update it any further. This issue was overcome by @fboundy adding some code to make PV-Opt write the charging schedule to my inverter when it got to 13%.
So I had to use my (SolaX) app to communicate with the inverter and manually reset chargiing times to effectively bring it to life.
I've had to put PV-Opt in read only mode now as my battery is flat so I need to charge it before my expensive peak time (16:00 - 19:00) so I have a full battery. However, when I put PV-Opt in Read only mode, it resets back to "Active" mode. So now there is some power back in the battery and the inverter is not in hibernate, PV-Opt keeps overwriting my manual charging settings I have had to setup as above. I seem to have this issue a lot but can't pin down what the problem is.
So now I've had to actually stop AppDaemon so PV-Opt does not run at all.

Do we need a rethink on how this works? or do you think we are still on the right track?
Also, I noticed there is an update to PV-Opt (to 3.18.2). Assuming that if I update to this version it will overwrite the beta files. Is it worth me updating first and then re-adding the files from your beta?

Thanks

stevebuk1 · 2024-11-19T15:06:49Z

Do we need a rethink on how this works? or do you think we are still on the right track?

From the log you posted today everything actually appears to be working, its just long delays between each optimiser run and lags of whats done where that makes it look like it isn't. We just need to solve the 300/360 seconds delay, which is an issue from the original Solax integration development that hadn't affected things too much up to now but certainly does now. For reference my delay is 15 seconds, so a full optimiser run from idle through to idle takes a minute or so. We need to achieve the same, otheriwse, any method of preventing discharge is going to result in more inverter writes and certainly needing 10 minutes for each one will going to cause issues for anything more than the most basic charge window.

Also, I noticed there is an update to PV-Opt (to 3.18.2). Assuming that if I update to this version it will overwrite the beta files. Is it worth me updating first and then re-adding the files from your beta?

No need - the files you have already include the changes made to 3.18.2. I merge production changes into the development code as soon as they are released.

Changed the value to 120 so there is now a pause between it optimising, which seems to have calmed it down.
However, still problems

I really do need a Pv_opt.log from you with every post that describes a behaviour. I really can't do anything without them......

punkymuzzle · 2024-11-19T17:35:15Z

OK thanks for this.
Understood the point with the logs, will ensure I upload one for each post.

I realised I was having some problems with my inverter / battery charging rate. I ended up speaking with the installer who has helped in hopefully resolving this.
So i ended up updating to the latest version of PV-Opt in order to rule out that my inverter issue wasn't related.

Now it's (hopefully) been resolved I will reinstall the beta and start charging / testing again (with the refresh time down to 60 seconds) and we'll see how it goes.

Please bear with me whilst I do this.
Many thanks for your support and patience with this, it's really appreciated.

stevebuk1 · 2024-11-19T20:44:48Z

For now its probably best that you revert to the production release of Pv_opt and make sure you have stable operation with an inverter delay of 60seconds and see if that resolves the issue you raised . If you think its working a pv_opt.log and main.log would be very useful to see if this solves the issues within #299. I'll also put a similar response in #299. We'll leave this open and come back to it once #299 is resolved.

punkymuzzle · 2024-11-19T22:58:53Z

Fantastic, thank you very much.
To confirm, now I have reverted back to 3.18.2 and set the optimiser time to 120 seconds (as 60 seconds was causing issues with the dashboard showing various states of optimisation).
I will drop this to 60 seconds as requested and leave overnight to see if this is still OK. If it is I will then re-download the bera files and start to test the "prevent discharge" option again.

Many thanks

stevebuk1 · 2024-11-19T23:12:37Z

The recommendation for 60secs was entirely arbitrary. If 120s is reliable we can stick with that. That means everything completes in 5 minutes which is less than the optimiser scheduled time of 10 minutes. Can I just confirm that the value of 60 (or 120) is regarding the value of id_cycle_seconds in config yaml? You referred to it as optimiser time and I can't see this needing to be set any lower than 10 minutes.

…

On Tue, 19 Nov 2024, 22:59 punkymuzzle, ***@***.***> wrote: Fantastic, thank you very much. To confirm, now I have reverted back to 3.18.2 and set the optimiser time to 120 seconds (as 60 seconds was causing issues with the dashboard showing various states of optimisation). I will drop this to 60 seconds as requested and leave overnight to see if this is still OK. If it is I will then re-download the bera files and start to test the "prevent discharge" option again. Many thanks — Reply to this email directly, view it on GitHub <#284 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASVRJMFVX5HJASPUV46YQHL2BO7EFAVCNFSM6AAAAABRMJ6GR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBWHEZDAOBRGQ> . You are receiving this because you were assigned.Message ID: ***@***.***>

punkymuzzle · 2024-11-19T23:17:14Z

This is the setting I am referring to (in the config.yaml)

update_cycle_seconds: 60

This is set towards the end of the .yaml file under the section:

===============================================================================================================
Brand / Integration Specific Config: SOLAX_X1:
===============================================================================================================
These are the default entities used with the Solax X1integration. You can change them here and over-ride the defaults

Set it to 60 seconds and no adverse behaviour yet.

Is this the wrong setting?

I don't have the id_cycle_seconds in my .yaml file

stevebuk1 · 2024-11-19T23:21:18Z

Yep that's the one!

…

On Tue, 19 Nov 2024, 23:17 punkymuzzle, ***@***.***> wrote: This is the setting I am referring to (in the config.yaml) update_cycle_seconds: 60 This is set towards the end of the .yaml file under the section: =============================================================================================================== Brand / Integration Specific Config: SOLAX_X1: =============================================================================================================== These are the default entities used with the Solax X1integration. You can change them here and over-ride the defaults Set it to 60 seconds and no adverse behaviour yet. Is this the wrong setting? — Reply to this email directly, view it on GitHub <#284 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASVRJMHBBXJDO3LELUD4P532BPBJBAVCNFSM6AAAAABRMJ6GR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBWHE2DQMJSHA> . You are receiving this because you were assigned.Message ID: ***@***.***>

punkymuzzle · 2024-11-20T10:01:42Z

OK so I just went for it last night and tried it out end to end:

Installed the latest beta files from the earlier post - Worked OK
My charging schedule calculated OK with no issues. It had several charging slots allocated overnight. I wanted to charge my car overnight for approx 4 hours, which overlapped the charging slots. - Worked OK
Used the Automations and helpers I created (mentioned in earlier post ) to set the "prevent discharge" to switch on just before my car started charging, and to switch off just after my car stopped charging. Worked OK

I watched the 1W charging slot be inserted into the schedule just before the car charger started - Worked OK
I watched as the original charging schedule kicked in at the right time (and the battery charged successfully) - Worked OK
I watched as the next 1W charging slot was inserted into the schedule - Worked OK

In the morning I came down to a car that was fully charged as well as a battery that was charged as per the PV-Opt schedule, which is fantastic.
Looking at the charging graph for my battery it showed that there was no discharge, as planned.
So I reckon that it`s all working correctly.

Attached logs if you need them:
main.log
pv_opt.log
error.log

my only two comments are:

When the charging slot completed and the next 1W slot was configured, there is a slight delay in applying the config to the inverter. This is obviously due to the update cycle, and is expected. So the way to minimise this delay is to make the update cycle as small as possible, which results in HA constantly recalculating. So there is a balance to be decided upon.
Regarding the automations and helpers I created, I will look to add some more, so we have more charging slots. I also want to look at how the times that are entered can be reset once used, to avoid them recurring at the same time if left as they are.
Once I get this all up and running I will upload the yaml for the automations, helpers and dashboard so they can be included in the PV-Opt dashboard if you want.

Once again, huge thanks for working on this. Hopefully this can be added into the production version of PV-Opt, but please let me know if you need anything from me.

Thanks

stevebuk1 · 2024-11-21T08:32:19Z

Pleased it all now seems to be working.

Regarding your observations:

When the charging slot completed and the next 1W slot was configured, there is a slight delay in applying the config to the inverter. This is obviously due to the update cycle, and is expected. So the way to minimise this delay is to make the update cycle as small as possible, which results in HA constantly recalculating. So there is a balance to be decided upon.

Yes that's it.
In general, the optimiser runs every 10 minutes.
If it doesn't need to do anything with the inverter, it takes a minute or two complete.
If if does need to do anything with the inverter, there is an additional 2 minutes (2 lots of "update cycle_seconds")

However, when you toggle Prevent_discharge, the optimiser will be triggered to run immediately, so its about 4 minutes for the toggle to take effect. This is a minimum though, this will be longer if done midway through a scheduled optimise, as it has to wait for that one to finish first. Not so convienient for your use case of preventing discharge if someone wants a shower.

The delays are unfortunately unavoidable as Pv_opt is reading the status of Prevent_discharge live. The ideal (long term) is that the particular 1/2 hour slots are all setup in advance, then there would be no delays because Pv_opt does the inverter loading 10 minutes before the slot starts. This functionality is mostly incorporated already as PV_opt can read the Intelligent Octopus Go car charging schedule and load all the prevent slots for the night, but thats a very bespoke format that the Octopus Energy Integration generates and it would be quite hard to generate that from a dashboard that has a number of start and end time pairs. I think the way forward on this is to simply have 48 slots in a some sort of drop down list (24 hours of 1/2 hour slots) and one simply sets each slot individually for whether discharge is presented? Or do you think say 3 pairs of start/end times would be sufficient?

Regarding the automations and helpers I created, I will look to add some more, so we have more charging slots. I also want to look at how the times that are entered can be reset once used, to avoid them recurring at the same time if left as they are.
Once I get this all up and running I will upload the yaml for the automations, helpers and dashboard so they can be included in the PV-Opt dashboard if you want.

Yes please, I'll add them into the repo and documentation.

Hopefully this can be added into the production version of PV-Opt, but please let me know if you need anything from me.

Theres a few things to iron out in the dev version (unrelated to this) but yes, the intention is to incorporate all of this into the production version.

punkymuzzle · 2024-11-25T11:19:37Z

Hi
I've been using this over the past few days and this has generally been working well. I have set the "prevent discharge" on several occasions so I can charge my car and it works well.

However I have noticed a couple of anomalies which I'm not sure if we can fix. These are observations at the moment so I'll keep an eye on it and try and capture the logs when I see this happening.

Sometimes the 1W slot is added to the schedule fine and gets written to the inverter. However if the SoC drops to 10% and the inverter hibernates, when it wakes up (for the 1W slot) PV-Opt cannot update the schedule again as the SoC is still at 10% and still in hibernate mode.
Sometimes after the 1W slot has finished, if PV-Opt writes the next slot which happens to be a "self use" mode, then it doesn't amend the Amperage of the inverter, leaving at 0A. This means that the battery will discharge to provide power to the house, but won't ever charge. When I've noticed this I have intervened to up the Amperage to allow the battery to charge, but if this happens overnight then the batter will still remain at 10% SoC until it's manually changed.

Apart from the two above issues it seems to be working great.

I still have slight issues with the scheduling slots from my automations / helpers (as I need to think of a way to disable the automation once it's been applied at a certain time, to stop it repeating the next day) but that's a minor thing I need to fix.

Thanks

stevebuk1 · 2024-11-25T21:14:28Z

Sometimes the 1W slot is added to the schedule fine and gets written to the inverter. However if the SoC drops to 10% and the inverter hibernates, when it wakes up (for the 1W slot) PV-Opt cannot update the schedule again as the SoC is still at 10% and still in hibernate mode.

Thanks for pointing this out. Because the Car slots are seen as charge slots (at 1W), then the code Francis wrote to load the next charge slot once the battery SOC approached a "Sleep_SOC" will load a charge of 1W, which isnt much use in lifting the inverter out of its sleep state when the time comes. I'm not entirely sure I can fix this without designating the car slots as something other than a charge slot, which is a major piece of work.

2. Sometimes after the 1W slot has finished, if PV-Opt writes the next slot which happens to be a "self use" mode, then it doesn't amend the Amperage of the inverter, leaving at 0A. This means that the battery will discharge to provide power to the house, but won't ever charge. When I've noticed this I have intervened to up the Amperage to allow the battery to charge, but if this happens overnight then the batter will still remain at 10% SoC until it's manually changed.

I'd added code to write a current of 20A once any form of timed charge period exited, which should equally encompass true charge slots as well as car slots. This is probably an easy fix but I'll need a log to see where its going wrong.

punkymuzzle · 2024-11-25T22:53:54Z

Sometimes the 1W slot is added to the schedule fine and gets written to the inverter. However if the SoC drops to 10% and the inverter hibernates, when it wakes up (for the 1W slot) PV-Opt cannot update the schedule again as the SoC is still at 10% and still in hibernate mode.

Thanks for pointing this out. Because the Car slots are seen as charge slots (at 1W), then the code Francis wrote to load the next charge slot once the battery SOC approached a "Sleep_SOC" will load a charge of 1W, which isnt much use in lifting the inverter out of its sleep state when the time comes. I'm not entirely sure I can fix this without designating the car slots as something other than a charge slot, which is a major piece of work.

Not sure if this will work, but, I have two charging slots available on my inverter. PV-Opt always sets these two sets of sots to be identical, but could we use both slots (one with the 1W slot and the other with the next "real" slot)? Not sure if this would work, but maybe worth thinking about?

Sometimes after the 1W slot has finished, if PV-Opt writes the next slot which happens to be a "self use" mode, then it doesn't amend the Amperage of the inverter, leaving at 0A. This means that the battery will discharge to provide power to the house, but won't ever charge. When I've noticed this I have intervened to up the Amperage to allow the battery to charge, but if this happens overnight then the batter will still remain at 10% SoC until it's manually changed.

I'd added code to write a current of 20A once any form of timed charge period exited, which should equally encompass true charge slots as well as car slots. This is probably an easy fix but I'll need a log to see where its going wrong.

Sure, log attached:

pv_opt.log
error.log
main.log

You might see other errors in these files because PV-Opt has crashed on me in the last few hours and despite me restarting everything multiple times it's hanging on "Optimising Charging Plan" - but that will be for another issue that I will raise.

Thanks

stevebuk1 · 2024-11-26T20:29:12Z

Not sure if this will work, but, I have two charging slots available on my inverter. PV-Opt always sets these two sets of sots to be identical, but could we use both slots (one with the 1W slot and the other with the next "real" slot)? Not sure if this would work, but maybe worth thinking about?

Yes this makes good sense for your inverter but given the core of Pv_opt is written around one start/end time pair and supports multiple different inverter types then I think it might be complex. I'll puzzle some more but this will be long term.

3. Sometimes after the 1W slot has finished, if PV-Opt writes the next slot which happens to be a "self use" mode, then it doesn't amend the Amperage of the inverter, leaving at 0A. This means that the battery will discharge to provide power to the house, but won't ever charge. When I've noticed this I have intervened to up the Amperage to allow the battery to charge, but if this happens overnight then the batter will still remain at 10% SoC until it's manually changed.

I'd added code to write a current of 20A once any form of timed charge period exited, which should equally encompass true charge slots as well as car slots. This is probably an easy fix but I'll need a log to see where its going wrong.

Sure, log attached:

Due to last nights problems the log contains only two optimiser runs that completed, and neither of these had prevent_discharge set. I'd need a log where the 1W slot has just finished and Pv_opt writes the next slot for self use mode but doesn't set it to 20A.

punkymuzzle · 2024-11-26T22:42:44Z

Not sure if this will work, but, I have two charging slots available on my inverter. PV-Opt always sets these two sets of sots to be identical, but could we use both slots (one with the 1W slot and the other with the next "real" slot)? Not sure if this would work, but maybe worth thinking about?

Yes this makes good sense for your inverter but given the core of Pv_opt is written around one start/end time pair and supports multiple different inverter types then I think it might be complex. I'll puzzle some more but this will be long term.

Of course, not a problem. Last thing I want to do is create lots of extra work for this.

Sometimes after the 1W slot has finished, if PV-Opt writes the next slot which happens to be a "self use" mode, then it doesn't amend the Amperage of the inverter, leaving at 0A. This means that the battery will discharge to provide power to the house, but won't ever charge. When I've noticed this I have intervened to up the Amperage to allow the battery to charge, but if this happens overnight then the batter will still remain at 10% SoC until it's manually changed.

I'd added code to write a current of 20A once any form of timed charge period exited, which should equally encompass true charge slots as well as car slots. This is probably an easy fix but I'll need a log to see where its going wrong.

Sure, log attached:

Due to last nights problems the log contains only two optimiser runs that completed, and neither of these had prevent_discharge set. I'd need a log where the 1W slot has just finished and Pv_opt writes the next slot for self use mode but doesn't set it to 20A.

No worries, the next time I use the "prevent discharge" option I'll upload the logs. I won't do it just yet as the p/kW is high and my car doesn't need charging yet (and that would give the best chance of it spanning multiple charging slots)
Thanks very much

punkymuzzle · 2024-12-02T12:50:54Z

Hi
Tried to use the "prevent discharge" setting both last night and today. Unfortunately it didn't work.
pv-opt did not immediately recalculate as it normally does, but when it did recalculate, the usual 1W charge slot wasn't entered into the schedule, meaning the battery was still discharging.
So I've had to put pv-opt into read only mode (took a couple of attempts today) and set the inverter manually to preserve the SoC.

Logs attached for information:
pv_opt.log
main.log
error.log

Thanks

stevebuk1 · 2024-12-02T20:29:46Z

I'm 99% sure the logs show you are running the production version of Pv_opt, which doesn't contain the prevent_discharge functionality. The usual cause of this is that a new production release was made available on HACS and you have HA set to perform updates automatically, but I don't think thats the case here as the last logs you attached were using the development code and I don't think theres been a new release in the last two weeks.

You'll need to overwrite your files with the following development code:

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

Version is now at 3.19.0-Beta-19. I've added a mod in this one to print out the version number on each optimiser run, so in future I'll know for certain what version of code is running.

Also, I think we need to increase your log file size and also increase the number of retained logs from 3 to 9, as the last log only recorded about an hours worth of running.

Instructions for this are here, Section 11 Step 3:
https://github.com/fboundy/pv_opt/tree/dev?tab=readme-ov-file#11-configure-appdaemon

(basically add the lines log_generations: 9 and log_size: 10000000 in the location shown, making sure the indentation is correct)

Along with the debug_categories controls in the development version, this should ensure we always have a weeks worth of log files for diagnostics.

punkymuzzle · 2024-12-02T22:15:12Z

Thanks for this.
Checked my installed version and it says 3.18.2.
Don't think I have it set to auto update as I always see when there is a new version to install' Unless I've inadvertently set this.
Assuming 3.19.0-Beta-19 can just be installed as is, and the files you have linked to are already included? If I have this wrong please let me know.

I'll look to increase the logfile size as requested.

Once I've done this I'll retest (will probably be late tomorrow / Weds) and let you know how it goes.

Thanks again.

punkymuzzle · 2024-12-02T23:07:37Z

Update
Installed and ran a very quick test to see if the 1W slot would be added, and it has. So thanks very much for this.
I'll do a more thorough test over the next few days and report back.

One thing I have been thinking of is the issue we have around the inverter going into hibernate with 0.0A set (meaning it won't ever charge until I intervene)
What about if we change the charging rate from 1W to, say 75W? Then if the inverter hibernates with this charging slot, at least after 30 minutes of charging at 75W it would have hopefully come out of hibernate (as the SoC would now be above 10%), thereby allowing pv-opt to write the next charge slot.

Would that work? I chose 75W as a nominal figure but I guess we can play with that amount if needed.

stevebuk1 · 2024-12-03T08:41:36Z

What about if we change the charging rate from 1W to, say 75W? Then if the inverter hibernates with this charging slot, at least after 30 minutes of charging at 75W it would have hopefully come out of hibernate (as the SoC would now be above 10%), thereby allowing pv-opt to write the next charge slot.

Would that work? I chose 75W as a nominal figure but I guess we can play with that amount if needed.

If you are happy with a 75W charge rate for whenever prevent_discharge is set then this is a good idea and I think will work well, as it makes sense to do this alongside a SleepSOC and it can be kept specific to Solax inverters. The dashboard will still display 1W as the plugins for each of the inverters is largely 1 way. The inverter plugin writes a current to the inverter based on required power and battery voltage but we can keep it simple and write a fixed current, probably 1A (I think Solax is a 100V system so thats about 100W).

punkymuzzle · 2024-12-03T08:46:48Z

Yep 100W is probably a good setting. Assuming that charging at 100W for 30 mins (as this is the minimum charging slot) would be sufficient to raise the SoC enough to bring the Inverter out of hibernation?

…

On Tue, 3 Dec 2024, 08:41 stevebuk1, ***@***.***> wrote: What about if we change the charging rate from 1W to, say 75W? Then if the inverter hibernates with this charging slot, at least after 30 minutes of charging at 75W it would have hopefully come out of hibernate (as the SoC would now be above 10%), thereby allowing pv-opt to write the next charge slot. Would that work? I chose 75W as a nominal figure but I guess we can play with that amount if needed. If you are happy with a 75W charge rate for whenever prevent_discharge is set then this is a good idea and I think will work well, as it makes sense to do this alongside a SleepSOC and it can be kept specific to Solax inverters. The dashboard will still display 1W as the plugins for each of the inverters is largely 1 way. The inverter plugin writes a current to the inverter based on required power and battery voltage but we can keep it simple and write a fixed current, probably 1A (I think Solax is a 100V system so thats about 100W). — Reply to this email directly, view it on GitHub <#284 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNR35Y2Y6SB2XMXMKIHFRT2DVVFNAVCNFSM6AAAAABRMJ6GR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJTHA3TQNJSHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

punkymuzzle · 2024-12-04T09:13:42Z

OK, tried it in anger last night but ended up with an empty battery when I woke up this morning.

I set my car to charge my car between 01:30 and 04:30. In this time there were several scheduled battery charging slots so I tried to use the "prevent discharge" setting.
Looking at the schedule last night the battery SoC would have been at 10% (and the inverter hibernated) when the first 1W slot was due to commence. So I decided to manually charge the battery with sufficient power so that it didn't hibernate.
When the time came for the first 1W slot, it got added to the schedule (all good to this point). The last I saw of the schedule before I went to bed was a 1W slot scheduled from 00:30 - 01:30, with the battery at 13% (the next "real battery charging slot was at 01:30).
So, all good.

Woke up at 06:30 to a charged car but a battery which was at 8% SoC (despite a minimum SoC of 10%).
When I checked the inverter settings the charge rate had been set to 0.0A before it went idle, so the inverter would not subsequently wake up for additional charging overnight.
Bummer......

So I've had to put pv-opt in read only mode and manually set the battery to charge during the day so it's fully charged by 16:00, when my peak charges apply (the offpeak times are really expensive today so they are double the cheaper overnight slots, so today's bill is going to sting).
Incidentally, I tried to put pv-opt in read only mode three times but it just reset itself and switched back on during the next cycle, so I suspect there is a setting in the .yaml somewhere which sets read only to off. - so, I need to fix that.
I've had to stop AppDaemon in order to stop pv-opt, so I can manually set the battery to charge today. However, looking at the logs there also appears to be errors, as follows:

Task exception was never retrieved
future: <Task finished name='Task-724276' coro=<HassPlugin.run_hass_service_check() done, defined at /usr/lib/python3.11/site-packages/appdaemon/plugins/hass/hassplugin.py:763> exception=ClientResponseError(RequestInfo(url=URL('http://supervisor/core/api/services'), method='GET', headers=<CIMultiDictProxy('Host': 'supervisor', 'x-ha-access': 'bc88660f0882028c57000d1e8b888a8fdc2d92d9a48358666f02036bc937928ec3d41e1c2fe2f6853ac99dd24e90b34b4ad8f50ddf7d3388', 'Accept': '/', 'Accept-Encoding': 'gzip, deflate', 'User-Agent': 'Python/3.11 aiohttp/3.8.6')>, real_url=URL('http://supervisor/core/api/services')), (), status=502, message='Bad Gateway', headers=<CIMultiDictProxy('Content-Type': 'text/plain; charset=utf-8', 'Content-Length': '16', 'Date': 'Tue, 03 Dec 2024 11:56:57 GMT', 'Server': 'Python/3.12 aiohttp/3.10.11')>)>
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/appdaemon/plugins/hass/hassplugin.py", line 772, in run_hass_service_check
hass_services = await self.get_hass_services()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/appdaemon/plugins/hass/hassplugin.py", line 732, in get_hass_services
r.raise_for_status()
File "/usr/lib/python3.11/site-packages/aiohttp/client_reqrep.py", line 1011, in raise_for_status
raise ClientResponseError(
aiohttp.client_exceptions.ClientResponseError: 502, message='Bad Gateway', url=URL('http://supervisor/core/api/services')
Task exception was never retrieved
future: <Task finished name='Task-717136' coro=<HassPlugin.run_hass_service_check() done, defined at /usr/lib/python3.11/site-packages/appdaemon/plugins/hass/hassplugin.py:763> exception=ClientResponseError(RequestInfo(url=URL('http://supervisor/core/api/services'), method='GET', headers=<CIMultiDictProxy('Host': 'supervisor', 'x-ha-access': 'bc88660f0882028c57000d1e8b888a8fdc2d92d9a48358666f02036bc937928ec3d41e1c2fe2f6853ac99dd24e90b34b4ad8f50ddf7d3388', 'Accept': '/', 'Accept-Encoding': 'gzip, deflate', 'User-Agent': 'Python/3.11 aiohttp/3.8.6')>, real_url=URL('http://supervisor/core/api/services')), (), status=502, message='Bad Gateway', headers=<CIMultiDictProxy('Content-Type': 'text/plain; charset=utf-8', 'Content-Length': '16', 'Date': 'Tue, 03 Dec 2024 11:57:12 GMT', 'Server': 'Python/3.12 aiohttp/3.10.11')>)>
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/appdaemon/plugins/hass/hassplugin.py", line 772, in run_hass_service_check
hass_services = await self.get_hass_services()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/appdaemon/plugins/hass/hassplugin.py", line 732, in get_hass_services
r.raise_for_status()
File "/usr/lib/python3.11/site-packages/aiohttp/client_reqrep.py", line 1011, in raise_for_status
raise ClientResponseError(
aiohttp.client_exceptions.ClientResponseError: 502, message='Bad Gateway', url=URL('http://supervisor/core/api/services')
Task exception was never retrieved
future: <Task finished name='Task-709959' coro=<HassPlugin.run_hass_service_check() done, defined at /usr/lib/python3.11/site-packages/appdaemon/plugins/hass/hassplugin.py:763> exception=ClientResponseError(RequestInfo(url=URL('http://supervisor/core/api/services'), method='GET', headers=<CIMultiDictProxy('Host': 'supervisor', 'x-ha-access': 'bc88660f0882028c57000d1e8b888a8fdc2d92d9a48358666f02036bc937928ec3d41e1c2fe2f6853ac99dd24e90b34b4ad8f50ddf7d3388', 'Accept': '/', 'Accept-Encoding': 'gzip, deflate', 'User-Agent': 'Python/3.11 aiohttp/3.8.6')>, real_url=URL('http://supervisor/core/api/services')), (), status=502, message='Bad Gateway', headers=<CIMultiDictProxy('Content-Type': 'text/plain; charset=utf-8', 'Content-Length': '16', 'Date': 'Tue, 03 Dec 2024 11:57:29 GMT', 'Server': 'Python/3.12 aiohttp/3.10.11')>)>
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/appdaemon/plugins/hass/hassplugin.py", line 772, in run_hass_service_check
hass_services = await self.get_hass_services()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/appdaemon/plugins/hass/hassplugin.py", line 732, in get_hass_services
r.raise_for_status()
File "/usr/lib/python3.11/site-packages/aiohttp/client_reqrep.py", line 1011, in raise_for_status
raise ClientResponseError(
aiohttp.client_exceptions.ClientResponseError: 502, message='Bad Gateway',

url=URL('http://supervisor/core/api/services')

Also, logs attached fyi - hope this helps.
pv_opt.log
main.log
error.log

Many thanks

stevebuk1 · 2024-12-04T20:17:32Z

Hi, thanks for the logs, the new file size is working well. The one you've attached stretches back to 05:15 but need to get back to 04:30 and also 0:30. You should have nine files in the same area that pv_opt.log is stored in, these are named as follows:

pv_opt.log.1
pv_opt.log.2
pv_opt.log.3
and so forth up to
pv_opt.log.9

You may not have all 9 files as its not been running that long, but can you attach all the ones you do have.
The readonly problem is because at least from 5am Pv_opt is constantly resetting itself, I'm not sure whether that is because your inverter is down or due to some other issue, but that needs solving first.

*** edit I meant to say please grab them quick otherwise last nights run will be overwritten with new logs ***

punkymuzzle · 2024-12-05T00:14:55Z

edit:

*** edit I meant to say please grab them quick otherwise last nights run will be overwritten with new logs ***

I reenabled pv-opt this afternoon (before my peak time) and, "prevent discharge" aside it's been working fine since. Selected read only mode and it went into read only mode with no issues. So not sure what was happening earlier when it kept resetting.

OK thanks, here's all 9 logfiles (had to zip them as this site won't let me upload the filenames).

pv_opt.logfiles.zip

Looking at the timestamps on the files, hopefully we've still captured everything:

Thanks very much

stevebuk1 · 2024-12-05T21:46:03Z

I've inspected the logs. Theres a few issues here:

It appears that the inverter does indeed take many minutes to respond to writes, and the 300seconds that we changed in Issue Errors in AppDaemon Log - PV-Opt ceases to run #299 is looking like it was right (I perhaps should have known better to question the original value set by fboundy!) I also think this is the cause of the constant resets as the first log in Errors in AppDaemon Log - PV-Opt ceases to run #299 wasnt showing these. So, we need to reinstantiate the 300second delay, but also back off the optimiser frequency from 10 minutes to 15 minutes to compensate. The optimser frequency can be set in config.yaml but there isnt an entry for it currently - we need to add it here rather than just change it in HA as if the resets aren't due to this its going to reset itself to 10 minutes every time. Please send me your config.yaml and I'll update and send it back. (I'll also sort the readonly setting so if we do get resets it will reboot in readonly mode)
The code I added to revert the current setting to 20A doesnt trigger if the SOC is beneath the Sleep SOC because it continues to try and load the next active charge slot rather than turn off Force time Use. The problem is falling beneath the sleep SOC with a current of zero.
The issue of falling beneath sleep SOC remains, as we previously discussed. I've coded a fix for this (just set a current of 1A, will probably prevent Sleep SOC happening at all) but think we need to resolve 1) first.

punkymuzzle · 2024-12-06T00:47:08Z

Brilliant, thanks for this.

Please see config.yaml attached (my details redacted)
Does this get fixed if we sort the 1W charging slot and change to 100W charging slot? Won't that keep the inverter from hibernating?
Thanks very much.

Out of interest there is an update for pv-opt (that I've ignored at this time). Assuming I just stick with beta 19 a per the earlier post? happy to install whichever version helps.

Please let me know if you need anything further. However I'll be away for a couple of days so won't be able to test any changes for a while, so no rush.
Thanks
config.yaml.txt

stevebuk1 · 2024-12-06T21:40:48Z

Brilliant, thanks for this.

Please see config.yaml attached (my details redacted)

Attached is an updated one. All changed lines include "SVB".
I've:

Set read only to true by default
Set optimiser frequency to every 15 minutes
Set update_cycle_seconds back to 300

config.yaml.txt

First aim is to see if the above prevents constant restarts.

After copying in config.yaml you'll have to set the readonly switch in HA to false.
If it goes back to true of its own accord the fixes above haven't worked - please post me a log.

Does this get fixed if we sort the 1W charging slot and change to 100W charging slot? Won't that keep the inverter from hibernating?

Yes this is the plan. If the inverter is holding, just prevent it from sleeping.

Thanks very much.

Out of interest there is an update for pv-opt (that I've ignored at this time). Assuming I just stick with beta 19 a per the earlier post? happy to install whichever version helps.

Yep stick with what you have. The production release doesn't yet have all this functionality in it. (I don't have write access to the production releases so am dependent on Francis for that part)

Please let me know if you need anything further. However I'll be away for a couple of days so won't be able to test any changes for a while, so no rush. Thanks

No rush!

stevebuk1 self-assigned this Nov 9, 2024

stevebuk1 added the enhancement New feature or request label Nov 9, 2024

stevebuk1 added a commit that referenced this issue Nov 10, 2024

New Test Card for

4294801

New Test Card for Issue #284

stevebuk1 added the long term Good idea but not a priority label Nov 27, 2024

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

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

Comments

punkymuzzle commented Nov 7, 2024

stevebuk1 commented Nov 8, 2024 • edited Loading

stevebuk1 commented Nov 8, 2024 • edited Loading

punkymuzzle commented Nov 8, 2024 • edited Loading

punkymuzzle commented Nov 8, 2024

stevebuk1 commented Nov 9, 2024 • edited Loading

stevebuk1 commented Nov 9, 2024 • edited Loading

punkymuzzle commented Nov 9, 2024

stevebuk1 commented Nov 13, 2024 • edited Loading

stevebuk1 commented Nov 13, 2024 • edited Loading

punkymuzzle commented Nov 13, 2024 via email

punkymuzzle commented Nov 14, 2024

punkymuzzle commented Nov 15, 2024

stevebuk1 commented Nov 15, 2024 • edited Loading

punkymuzzle commented Nov 15, 2024

punkymuzzle commented Nov 15, 2024

punkymuzzle commented Nov 15, 2024

stevebuk1 commented Nov 15, 2024 • edited Loading

punkymuzzle commented Nov 15, 2024

punkymuzzle commented Nov 15, 2024

stevebuk1 commented Nov 15, 2024

punkymuzzle commented Nov 15, 2024

stevebuk1 commented Nov 15, 2024 • edited Loading

punkymuzzle commented Nov 15, 2024

stevebuk1 commented Nov 15, 2024

punkymuzzle commented Nov 15, 2024

stevebuk1 commented Nov 15, 2024

punkymuzzle commented Nov 15, 2024

stevebuk1 commented Nov 19, 2024

stevebuk1 commented Nov 19, 2024

punkymuzzle commented Nov 19, 2024 • edited Loading

stevebuk1 commented Nov 19, 2024

punkymuzzle commented Nov 19, 2024

stevebuk1 commented Nov 19, 2024

punkymuzzle commented Nov 19, 2024

stevebuk1 commented Nov 19, 2024 via email

punkymuzzle commented Nov 19, 2024 • edited Loading

stevebuk1 commented Nov 19, 2024 via email

punkymuzzle commented Nov 20, 2024

stevebuk1 commented Nov 21, 2024 • edited Loading

punkymuzzle commented Nov 25, 2024

stevebuk1 commented Nov 25, 2024 • edited Loading

punkymuzzle commented Nov 25, 2024

stevebuk1 commented Nov 26, 2024

punkymuzzle commented Nov 26, 2024

punkymuzzle commented Dec 2, 2024

stevebuk1 commented Dec 2, 2024 • edited Loading

punkymuzzle commented Dec 2, 2024

punkymuzzle commented Dec 2, 2024

stevebuk1 commented Dec 3, 2024

punkymuzzle commented Dec 3, 2024 via email

punkymuzzle commented Dec 4, 2024

stevebuk1 commented Dec 4, 2024 • edited Loading

punkymuzzle commented Dec 5, 2024 • edited Loading

stevebuk1 commented Dec 5, 2024 • edited Loading

punkymuzzle commented Dec 6, 2024

stevebuk1 commented Dec 6, 2024

stevebuk1 commented Nov 8, 2024 •

edited

Loading

stevebuk1 commented Nov 8, 2024 •

edited

Loading

punkymuzzle commented Nov 8, 2024 •

edited

Loading

stevebuk1 commented Nov 9, 2024 •

edited

Loading

stevebuk1 commented Nov 9, 2024 •

edited

Loading

stevebuk1 commented Nov 13, 2024 •

edited

Loading

stevebuk1 commented Nov 13, 2024 •

edited

Loading

stevebuk1 commented Nov 15, 2024 •

edited

Loading

stevebuk1 commented Nov 15, 2024 •

edited

Loading

stevebuk1 commented Nov 15, 2024 •

edited

Loading

punkymuzzle commented Nov 19, 2024 •

edited

Loading

punkymuzzle commented Nov 19, 2024 •

edited

Loading

stevebuk1 commented Nov 21, 2024 •

edited

Loading

stevebuk1 commented Nov 25, 2024 •

edited

Loading

stevebuk1 commented Dec 2, 2024 •

edited

Loading

stevebuk1 commented Dec 4, 2024 •

edited

Loading

punkymuzzle commented Dec 5, 2024 •

edited

Loading

stevebuk1 commented Dec 5, 2024 •

edited

Loading