EV charging support/integration

[mergwyn]

Is your feature request related to a problem? Please describe. I'm all electric at home with ASHP, Solar, storage and and an EV charger. PV Opt does a good job of managing my solar and storage but I also need to be able schedule EV charging

Describe the solution you'd like I'd really like pvopt to ensure that charging the EV is synchronised such that ir does not discharge the storage battery. At its simplest level the EV is just another battery which needs be charged to a target SOC in the cheapest slots so hopefully there is an overlap in the algorithm. This could either be done fully within PV Opt or via hooks that allow users to build their own automation using the results (eg publishing x cheapest slots)

Describe alternatives you've considered At the moment, I am using zappi 'agile knowledge' to set a schedule that only charges when the tariff is below a certain level, but obviously this may or may not cause the storage battery to discharge. (I also have to change schedule manually depending on the latest tariff)

I've tried using Predbat, but this is soo complicated and I've not been able to understand the charging plans it puts together and am struggling with the amount of 'hold' and 'reserve' charging that does on.

Additional context I understand that this might not be where you want or need to take PV Opt and appreciate all that you have done so far. I wish I could program in python to help out but that it beyond me! If I can help in any other way please let me know.

[fboundy]

That is helpful thanks. It's definitely trickier with Agile that IOG. I will add some more logging of what is coming out the Zappi entities I think.

[mergwyn]

Logs from last nights charge -14kWh added between approx 0130 and 0330. pv_opt.log error.log

I can carry on sending logs if you think it useful - just let me know.

[fboundy]

Could you switch to 3.14.0-beta-2? It should fix some of the errors you are getting add add a bit more logging of the Zappi entities

[fboundy]

Do you programme your Zappi Boost times and kWh through HA?

[mergwyn]

Not yet! I've set up a schedule in the car to charge between 0130 and 0530 (on the basis these are usually reasonably cheap agile rates at that time). When this is working with pv_opt, I'll look to building an automation.

I'll install 3.14.0-beta-2 and send you logs tomorrow.

[fboundy]

But potentially this could be incorporated? Since PV_Opt really needs to know what you are planning to do. If you know how much charge you want to supply then this is effectively just more consumption for PV_Opt that you will optimally buy at the lowest price.

[fboundy]

If I added an "ev_charge_kwh" number field I could, for now, simply log when it would have called the Zappi Boost service.

[mergwyn]

As I said when I created this issue: "At its simplest level the EV is just another battery which needs be charged to a target SOC in the cheapest slots" so it would be prefect if this could be incorporated. The minimum I need is for pv_opt to block battery discharge when the EV is charging so that I can automate.

I could create a template which would populate the ev_charge_kwh though the would change every day and the template update would need to be disabled whilst charging to make sure pv_opt does not keep recalculating. Though more fields, would it be simpler to mirror the current config have have fields for:

• EV battery capacity
• EV charger power

This would allow allow calculation of "ev_charge_kwh" and give you the rate of charge.

I'm not sure we would need 'EV target SOC' as this can be set in the car.

[fboundy]

OK so here's a simple approach:

• Battery capacity: 28 kWh
• Charger 7 kW

So you will need maximum 4 hours to charge depending on the car's initial SOC. So PV-Opt looks at the Agile rates and finds the cheapest 4 hour slot. It then says battery discharge rate must be minimum zero during these slots.

Of course it is very likely that you will want to use the same slots for charging the house battery.

[fboundy]

If you were on IOG it take the IOG slots instead of the cheapest Agile ones.

[mergwyn]

Sounds perfect!

[fboundy]

OK - will have something in the next couple of days

[stevebuk1]

Hi - back from hols now, installed 3.14.0-beta-2, it got stuck in Loading tariffs and produced the following in error.log:

22:21:47 WARNING pv_opt: ------------------------------------------------------------ 22:21:47 WARNING pv_opt: Unexpected error in worker for App pv_opt: 22:21:47 WARNING pv_opt: Worker Ags: {} 22:21:47 WARNING pv_opt: ------------------------------------------------------------ 22:21:47 WARNING pv_opt: Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/appdaemon/app_management.py", line 162, in initialize_app await utils.run_in_executor(self, init) File "/usr/lib/python3.11/site-packages/appdaemon/utils.py", line 304, in run_in_executor response = future.result() ^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/concurrent/futures/thread.py", line 58, in run result = self.fn(*self.args, self.kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/appdaemon/adbase.py", line 35, in f_app_lock return f(*args, *kw) ^^^^^^^^^^^^^^ File "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 408, in initialize self.optimise() File "/usr/lib/python3.11/site-packages/appdaemon/adbase.py", line 35, in f_app_lock return f(args, kw) ^^^^^^^^^^^^^^ File "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 1407, in optimise if self._check_tariffs(): ^^^^^^^^^^^^^^^^^^^^^ File "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 809, in _check_tariffs self._check_tariffs_vs_bottlecap() File "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 2498, in _check_tariffs_vs_bottlecap self.rlog(self.contract.tariffs[direction].to_df()) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/homeassistant/appdaemon/apps/pv_opt/pvpy.py", line 160, in to_df use_day_ahead = kwargs.get("day_ahead", ((start > time_now) or (end > time_now))) ^^^^^^^^^^^^^^^^ TypeError: '>' not supported between instances of 'NoneType' and 'Timestamp'

I changed line 2498 to self.rlog(self.contract.tariffs[direction]) which fixed the error, I'm also charging overnight so will log and send the results.

[stevebuk1]

3.14.0-beta-2 there seems to be some anomalous discharging being setup, both in that my export rate is 0 and the discharge rates are well in excess of my inveter capabilities.

Charging plan is here: Log file:pv_opt.log (error.log is blank so not attached)

[fboundy]

That looks very odd. Could you please set debug: true in your config.yaml? That will give me a bit more to go on.

[stevebuk1]

Hi - back from hols now, installed 3.14.0-beta-2

I changed line 2498 to `self.rlog(self.contract.tariffs[direction])` which fixed the error, I'm also charging overnight so will log and send the results.

Log file now attached. pv_opt.log

(Error.log is blank so not attached)

[fboundy]

I think I've found the cause of this. Please try 3.14.0-beta-5 (about to be pre-released).

[stevebuk1]

I think I've found the cause of this. Please try 3.14.0-beta-5 (about to be pre-released).

Just loaded, but getting this error:

20:51:21 WARNING pv_opt: Unexpected error running initialize() for pv_opt 20:51:21 WARNING pv_opt: ------------------------------------------------------------ 20:51:21 WARNING pv_opt: Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/appdaemon/app_management.py", line 162, in initialize_app await utils.run_in_executor(self, init) File "/usr/lib/python3.11/site-packages/appdaemon/utils.py", line 304, in run_in_executor response = future.result() ^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/concurrent/futures/thread.py", line 58, in run result = self.fn(*self.args, *self.kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/appdaemon/adbase.py", line 35, in f_app_lock return f(args, **kw) ^^^^^^^^^^^^^^ File "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 469, in initialize self._compare_tariffs() File "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 2430, in _compare_tariffs consumption = self.load_consumption(start, end) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 2407, in load_consumption consumption["time"] = consumption.index.time ^^^^^^^^^^^ UnboundLocalError: cannot access local variable 'consumption' where it is not associated with a value

Note I'm initializing Pv_opt using fixed consumption, to avoid the EV corrupting the calculations.

By comparison with beta-2, the problem looks to be that the code that was at the start of "load_consumption" has been moved to be within the if statement which only runs when the consumption history option is chosen. Some of that must have been required for the "else" statement that presumably covers the fixed consumption estimate option.

[stevebuk1]

By comparison with beta-2, the problem looks to be that the code that was at the start of "load_consumption" has been moved to be within the if statement which only runs when the consumption history option is chosen. Some of that must have been required for the "else" statement that presumably covers the fixed consumption estimate option.

I've reconfigured config.yaml to use consumption history, which avoids the issue. I'll log for 24 hours and post.

[fboundy]

Correct - fixed in 3.14.0-beta-6

[stevebuk1]

3.14.0-beta-6 installed, log file attached below.

pv_opt.log

I'm not sure if any of the changes made include any fixes for the issue in #181, but I have no charging plan for the evening due to Pv_opt thinking there isnt a peak rate. I'll cross post the log and screenshots to #181 to avoid cluttering the EV enhancement thread here, but let me know if you'd prefer otherwise.

[fboundy]

I haven’t been able to explicitly address this because I don’t think I’d seen a log from you which caught it. Hopefully this will help. Was there anything in error.log? On 5 Apr 2024 at 20:32 +0100, stevebuk1 @.***>, wrote:

3.14.0-beta-6 installed, log file attached below. pv_opt.log I'm not sure if any of the changes made include any fixes for the issue in #181, but I have no charging plan for the evening due to Pv_opt thinking there isnt a peak rate. I'll cross post the log and screenshots to #181 to avoid cluttering the EV enhancement thread here, but let me know if you'd prefer otherwise. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[mergwyn]

Here are the (correct) logs from last night using 3.14.0-beta-6. It was a small charge of about 5kWh starting at 0130. pv_opt.log error.log

[stevebuk1]

I haven’t been able to explicitly address this because I don’t think I’d seen a log from you which caught it. Hopefully this will help. Was there anything in error.log?

There was a single warning that seemed to be generated during loading consumption data when triggered by the compare tarriffs function, it didnt seem related. It reliably occurs once per night but at different times. I attached the error.log in #181.

I've looked all through the logs too and like you I can't see it logging anything that looks to be in error. The only place it shows up is in the "import" attribute of "sensor.pvopt_opt_cost", which is where the graph gets its data from. I'm going to have a bash at adding more logging around this point and see what it does. After a restart it always works, but it no longer works by the next night, so its fairly easy to reproduce. I think it must be something that only is done once on programme initialisation and not done again (or incorrectly done again). What time does the refresh of IOG from the internet actually occur, or it it done regularly?

[mergwyn]

When I select the zappi charger I get the following error:

10:41:10 WARNING pv_opt: ------------------------------------------------------------
10:41:10 WARNING pv_opt: Unexpected error in worker for App pv_opt:
10:41:10 WARNING pv_opt: Worker Ags: {'id': '7f8c9a57928846fbb9ce8fcbf4104fef', 'name': 'pv_opt', 'objectid': 'b7ff3c016eae41d4bc305d21187c3736', 'type': 'state', 'function': <bound method PVOpt.optimise_state_change of <pv_opt.PVOpt object at 0x7f5a5dbe66b0>>, 'attribute': 'state', 'entity': 'select.pvopt_ev_charger', 'new_state': 'Zappi', 'old_state': 'None', 'pin_app': True, 'pin_thread': 0, 'kwargs': {'__thread_id': 'thread-0'}}
10:41:10 WARNING pv_opt: ------------------------------------------------------------
10:41:10 WARNING pv_opt: Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/pandas/core/indexes/range.py", line 1018, in __getitem__
    return self._range[new_key]
IndexError: range object index out of range

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/appdaemon/threading.py", line 1045, in worker
    funcref(
  File "/usr/local/lib/python3.10/site-packages/appdaemon/adbase.py", line 35, in f_app_lock
    return f(*args, **kw)
  File "/home-assistant/appdaemon/apps/pv_opt/pv_opt.py", line 1441, in optimise_state_change
    self.optimise()
  File "/usr/local/lib/python3.10/site-packages/appdaemon/adbase.py", line 35, in f_app_lock
    return f(*args, **kw)
  File "/home-assistant/appdaemon/apps/pv_opt/pv_opt.py", line 1547, in optimise
    consumption = self.load_consumption(
  File "/home-assistant/appdaemon/apps/pv_opt/pv_opt.py", line 2348, in load_consumption
    f">>> EV consumption from    {ev_power.index[0].strftime(DATE_TIME_FORMAT_SHORT)} to {ev_power.index[-1].strftime(DATE_TIME_FORMAT_LONG)}"
  File "/usr/local/lib/python3.10/site-packages/pandas/core/indexes/range.py", line 1020, in __getitem__
    raise IndexError(
IndexError: index 0 is out of bounds for axis 0 with size 0

Here is pv_opt.log: pv_opt.log

[mergwyn]

I've just installed the new control card, and it's made me think about your proposal:

OK so here's a simple approach:

Battery capacity: 28 kWh Charger 7 kW So you will need maximum 4 hours to charge depending on the car's initial SOC. So PV-Opt looks at the Agile rates and finds the cheapest 4 hour slot. It then says battery discharge rate must be minimum zero during these slots

Do you also need access to an entity with the current EV SOC? Or are you just going to allocate the max? In my case, my battery is 63 kWh, so you might be allowing for 9ish hours of charge. The zappi integration does not expose this information so it would have to come from the car (the ID.3 integration does expose this data)

[fboundy]

When I select the zappi charger I get the following error:

10:41:10 WARNING pv_opt: ------------------------------------------------------------

Here is pv_opt.log: [pv_opt.log](https://github.com/fboundy/pv_opt/files/14896675/pv_opt.log)

This should be fixed in the next release.

[fboundy]

I've just installed the new control card, and it's made me think about your proposal:

OK so here's a simple approach: Battery capacity: 28 kWh Charger 7 kW So you will need maximum 4 hours to charge depending on the car's initial SOC. So PV-Opt looks at the Agile rates and finds the cheapest 4 hour slot. It then says battery discharge rate must be minimum zero during these slots

Do you also need access to an entity with the current EV SOC? Or are you just going to allocate the max? In my case, my battery is 63 kWh, so you might be allowing for 9ish hours of charge. The zappi integration does not expose this information so it would have to come from the car (the ID.3 integration does expose this data)

This would probably be useful

[fboundy]

I haven’t been able to explicitly address this because I don’t think I’d seen a log from you which caught it. Hopefully this will help. Was there anything in error.log?

There was a single warning that seemed to be generated during loading consumption data when triggered by the compare tarriffs function, it didnt seem related. It reliably occurs once per night but at different times. I attached the error.log in #181.

I've looked all through the logs too and like you I can't see it logging anything that looks to be in error. The only place it shows up is in the "import" attribute of "sensor.pvopt_opt_cost", which is where the graph gets its data from. I'm going to have a bash at adding more logging around this point and see what it does. After a restart it always works, but it no longer works by the next night, so its fairly easy to reproduce. I think it must be something that only is done once on programme initialisation and not done again (or incorrectly done again). What time does the refresh of IOG from the internet actually occur, or it it done regularly?

This might well be the issue. It should force a download at midnight UTC every night but maybe this isn't the best time for IOG? With Agile I force an update at 16:00 local time which is when the new rates get released.

I'll have a look at your PR

[stevebuk1]

This might well be the issue. It should force a download at midnight UTC every night but maybe this isn't the best time for IOG? With Agile I force an update at 16:00 local time which is when the new rates get released.

Yes I found that bit of the code after my last post. I've got logs from Saturday night where Sundays plan didn't generate, but after a restart Sunday nights logs show the plan for Monday night has generated ok.

Unfortunately the self.log function truncates "df" (datafile?) when longer than 60 rows. At the point of IOG download its 96 rows (2 days worth of 1/2 hour slots). As each half hour clicks over a row is removed so eventually I can see the full array. The log to sensor.pvopt_opt_cost seems to be the full one but thats very difficult to read as its all one line. I'll do some more inspections/logging and see if I can illicit anything.

I'll have a look at your PR

Please ignore, I took a fork of Beta6 and then a new branch with the aim of doing my own versions on allowing logging and hopefully a fix with the fix to be the subject of a future PR, but got totally confused on how to do tags what I wanted to be PRs to my own main ended up as PRs to your main, so gave up and deleted the fork. I'm brand new to github and yet to run git.

[fboundy]

Unfortunately the self.log function truncates "df" (datafile?) when longer than 60 rows. At the point of IOG download its 96 rows (2 days worth of 1/2 hour slots). As each half hour clicks over a row is removed so eventually I can see the full array. The log to sensor.pvopt_opt_cost seems to be the full one but thats very difficult to read as its all one line. I'll do some more inspections/logging and see if I can illicit anything.

df = DataFrame - the pandas data format. For logging this I tend to append the to_string() method so that you get all the data but it gets pretty long sometimes.

I'll have a look at your PR

Please ignore, I took a fork of Beta6 and then a new branch with the aim of doing my own versions on allowing logging and hopefully a fix with the fix to be the subject of a future PR, but got totally confused on how to do tags what I wanted to be PRs to my own main ended up as PRs to your main, so gave up and deleted the fork. I'm brand new to github and yet to run git.

OK - I've added some basic loging in 3.14.0 where the Contract last loaded datetime is kept and reported prior to each optimisation and also more explicitly forced it to update at midnight UTC.

[stevebuk1]

OK - I've added some basic loging in 3.14.0 where the Contract last loaded datetime is kept and reported prior to each optimisation and also more explicitly forced it to update at midnight UTC.

Right - I think I've got it. When the IOG tariff is loaded at midnight UTC (1am BST) it loads 27 hours of data, so through to the next day at 04:30. After that, the df (which is reset to cover 48 hours at midnight BST) is still filled with the cheap rate for data beyond the 27 hours. Once we roll all the way from the 1am load to the time it really counts, which is just before 23:20, we don't have an expensive rate on file, so no charging.

Both Saturdays and Sundays logs had no problem with loading the tariff. In fact its done at 3 or 4 times, from 1.10am to 1.50am. The difference between Saturdays and Sundays logs was that on Sundays log "load_contract" was triggered around 16:30 for some unknown reason, so the data was valid when I looked at it a few hours ago, hence the charging plan.

Can you try adding a 2nd IOG reload at midday UTC - lets see whether the 27 hours is constant from tariff load point, or whether the 4.30am limit is consistent. If the latter, then a single IOG load at 4pm UTC will be the answer.

[fboundy]

Will add to the next patch release

[stevebuk1]

Saturdays logs attached, as it was an EV charging night.

pv_opt ends 07-04-24 20-20.log pv_opt1 ends 07-04-24 15-10.log

It was taken using a modified version of Beta6 that has the extra logging to track down the IOG stale issue. Unfortunately I overwrote the code for Sundays logs otherwise would have attached it.

[stevebuk1]

OK - I've added some basic loging in 3.14.0 where the Contract last loaded datetime is kept and reported prior to each optimisation and also more explicitly forced it to update at midnight UTC.

3.14.0 installed, its an EV charging night so will log and attach tomorrow. Slots allocated are: 11pm to 11.30pm 11.30pm to 2am 2am to 3am

Whilst a slot outside of 23.30 to 05.30 is rare, house battery discharge will need to be prevented. I don't think there is any need to add this to the house battery charging plan - as this would need a tariff redownload or picking up the extra slot from the intelligent dispatching entity I imagine it would be complicated.

[stevebuk1]

3.14.0 installed, its an EV charging night so will log and attach tomorrow. Slots allocated are: 11pm to 11.30pm 11.30pm to 2am 2am to 3am

Logs attached. pv_opt.log

Note: I gave PV_opt control of the inverter for this evening (Readonly = off).
When the EV started charging I found the charge plan started adding discharge slots of ever increasing power as follows (full detail in the log)

22:20:05 INFO: 09-Apr 23:30 BST - 10-Apr 05:30 BST Power: 100W SOC: 68% -> 71%

22:30:05 INFO: 09-Apr 23:30 BST - 10-Apr 00:00 BST Power: 100W SOC: 70% -> 70% <= 22:30:05 INFO: 10-Apr 00:00 BST - 10-Apr 05:30 BST Power: 100W SOC: 70% -> 73%

23:10:05 INFO: 09-Apr 23:30 BST - 10-Apr 00:00 BST Power: -200W SOC: 71% -> 70% <= 23:10:05 INFO: 10-Apr 00:00 BST - 10-Apr 00:30 BST Power: 100W SOC: 70% -> 70% <= 23:10:05 INFO: 10-Apr 00:30 BST - 10-Apr 05:30 BST Power: 100W SOC: 70% -> 74%

23:30:06 INFO: 09-Apr 23:30 BST - 10-Apr 00:00 BST Power: -1000W SOC: 64% -> 60% 23:30:06 INFO: 10-Apr 00:00 BST - 10-Apr 00:30 BST Power: 0W SOC: 60% -> 59% <= 23:30:06 INFO: 10-Apr 00:30 BST - 10-Apr 05:30 BST Power: 100W SOC: 59% -> 64%

Shortly after this I enabled readonly mode. I'm mentioning this as it may be related to the general EV subject. I'll get a log for a non-EV night.

[stevebuk1]

I'm mentioning this as it may be related to the general EV subject. I'll get a log for a non-EV night.

I think issue reported in #203 is the same issue. I had the Use Export switch off, but Forced Discharge on. When I turned Force Discharge off, it didnt correct itself - as below (full log in previous post).

23:35:18 INFO: Base cost: 104.5p 23:35:18 INFO: Optimised cost (Optimised Charging): 80.6p <=== Current Setup 23:35:18 INFO: Optimised cost (Optimised PV Export): 80.6p 23:35:18 INFO: Optimised cost (Forced Discharge): 80.6p 23:35:18 INFO: 23:35:18 INFO: Checking for Hold SOC slots 23:35:18 INFO: 23:35:18 INFO: Optimal forced charge/discharge slots: 23:35:18 INFO: 09-Apr 23:30 BST - 10-Apr 00:00 BST Power: -1300W SOC: 64% -> 58%
23:35:18 INFO: 10-Apr 00:00 BST - 10-Apr 00:30 BST Power: -200W SOC: 58% -> 57% <= 23:35:18 INFO: 10-Apr 00:30 BST - 10-Apr 01:00 BST Power: 100W SOC: 57% -> 57% <= 23:35:18 INFO: 10-Apr 01:00 BST - 10-Apr 05:30 BST Power: 100W SOC: 57% -> 61%

[mergwyn]

Here are my logs for last night (3.14.0). The charge started at 00:30 and ended around 03:15 adding just over 18kWh. From what I can tell that coincided with a charging event for the main batteries. pv_opt.log pv_opt.1.log pv_opt.2.log error.log

[fboundy]

@stevebuk1 FYI - this I think this was because negative power was being erroneously calculated during the High Cost Swaps routine. The coding of this was a bit opaque so I’ve made it a bit clearer in 3.14.1 with an additional check that nothing is negative. You can see the edits if you look at the Commits on the beta version.

I’ll get that beta released to production once I’m where I’m going today. On 11 Apr 2024 at 13:32 +0100, mergwyn @.***>, wrote:

Here are my logs for last night (3.14.0). The charge started at 00:30 and ended around 03:15 adding just over 18kWh. From what I can tell that coincided with a charging event for the main batteries. pv_opt.log pv_opt.1.log pv_opt.2.log error.log — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[stevebuk1]

@fboundy I had a look at both mine and @mergwyn's logs and noted the Zappi entity was being read but no DataFrame was being stored. I found a typo in the df assignment and corrected it, looks like the conversion from kWh to kW is now working.

I've also added a fix to load the IOG tariffs at the same time Agile is done, but put it in its own elif statement just in case it needs to be modified further. I'll run for 24 hours, if it looks right I'll post and also do a PR. The changes are in my fork anyway if you want to take a look.

[stevebuk1]

To help move this forward I've now added code to subtract the Zappi consumption from the total consumption to leave the house consumption, this means I can re-enable historic consumption data without the EV consumption corrupting the charging plan for the house battery. The two consumption arrays are different sizes so I've had to combine them and then split them off again with what I doubt is efficient code, but it appears to work. I've put the code behind a switch called "switch.pvopt_ev_part_of_house_load" and set it to true.

@mergwyn, would you mind running this at your end so I can check it works ok with a 2nd system? Code attached, just replace pv_opt.py with the attached one (change ".txt" to ".py")

pv_opt.txt

[mergwyn]

@stevebuk1 I’ve just installed this and I’ll report back after tonight’s charge. So far so good, and it seems to remove the EV charge consumption.

FYI I swapped from agile to IOG yesterday and probably won’t swap back until November/December.

[stevebuk1]

Great thanks for letting me know.

If you've swapped to IOG the code also includes a fix to sort the IOG two rates going stale that I reported above, again me know if you see any issues with that. I've opened a pull request for the stale issue but it's not been processed yet.

On Fri, 26 Apr 2024, 09:08 mergwyn, @.***> wrote:

@stevebuk1 https://github.com/stevebuk1 I’ve just installed this and I’ll report back after tonight’s charge. So far so good, and it seems to remove the EV charge consumption.

FYI I swapped from agile to IOG yesterday and probably won’t swap back until November/December.

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

[fboundy]

@stevebuk1 - very happy for you to crack on with this as I can't really test anything without an EV

[fboundy]

@stevebuk1: couple of things:

• I found that your PR was causing my setup a problem because I don't have an EV so I've added a global flag of self.ev which is set by the state of the ev_charger config variable. This is now in 3.14.6 so would be good if you can test this.

• FYI: My branches are normally set up with patch for any bug fixes (currently 3.14.7) and dev for the next release version (3.15.0).

[stevebuk1]

@stevebuk1: couple of things:

• I found that your PR was causing my setup a problem because I don't have an EV so I've added a global flag of self.ev which is set by the state of the ev_charger config variable. This is now in 3.14.6 so would be good if you can test this.

Apologies, I have the opposite problem to you in that I can't do tests on a system that doesn't have an EV so never quite sure if I haven't broken anything else. I'll download 3.14.6 and test.

[stevebuk1]

• FYI: My branches are normally set up with patch for any bug fixes (currently 3.14.7) and dev for the next release version (3.15.0).

So for new EV development I do this?

1) Take a fork your "main" 2) branch my fork to "dev" 3) Make code changes 4) Do a PR?

[stevebuk1]

@stevebuk1 - very happy for you to crack on with this as I can't really test anything without an EV

Ok will do a PR for the pv_opt.py linked above that removes the zappi charge from the total consumption to leave the house load, once I've reinserted that into 3.14.6 so the self.ev gate works. (I knew the linked file wasnt ready for reintegration into main so didnt do a PR for that yet).

I think you said you'd added some functionality for applying Hold SOC to the inverter (around March 25th)? Is there any code added for triggering this hold based on planned_dispatches or _intelligent_dispatchingyet?

[fboundy]

Probably best to fork 'dev' for any major updates and, no I haven't done anything based on the dispatching yet.

[stevebuk1]

Ok will do a PR for the pv_opt.py linked above that removes the zappi charge from the total consumption to leave the house load, once I've reinserted that into 3.14.6 so the self.ev gate works. (I knew the linked file wasnt ready for reintegration into main so didnt do a PR for that yet).

Scrub that. I thought a PR would only take the changes made to my fork up to the point I raised the PR. It seems whats been pulled by the PR is all of the changes made to it after the PR as well. Is there a way to stop that happening?