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.

[SzosszeNET]

Like this idea. While you get a response as an alternative not sure if you looked into it, but zappi seems to have its own integration. https://github.com/CJNE/ha-myenergi

Could imagine to have both, and create an automation (under settings in HA) if not already one in the myenergi repo, that would watch the myenergi integration and if it's scheduled to charge, at the beginning of the charge window: Stop AppDaemon (or maybe less drastic to set pv_opt to read only) Set a static charge window to the inverter (to hold charge Just to be sure 00 the discharge window and current

And potentially a second one that would start AppDaemon when the myenergi charge is finished/is outside the charge window?

[fboundy]

Keen to support this as an idea but I don't want to get as complicated as PredBat!

One starting point would be the entity that already exists called switch.pvopt_charge_active - this is On when pv_opt is charging so is a good starting point. If I knew how much charge your needed for Zappi in a given window and at what rate I could probably call the zappi integration too.

It sounds like installing the Zappi integration would be a start. I would then need to know what sensors and services it exposes.

[mergwyn]

Hi, yes I do have both set up in HA. TBH the zappi integration doesn’t do much for me at the moment as I set it charge from excess solar during the day (not much of that about at the moment) and then to “Boost” overnight when the agile tariff is below a certain value.

SzosszeNET's suggestion could work, but it is likely that the EV charge and storage top up would like to happen at the same time as both want the cheapest rates. Your suggestion would need to charge them consecutively if I have understood correctly.

The EV battery is much bigger (63 kWH) but can charge from around 30-80% in around 4 hours, so not entirely dissimilar from the need to charge my storage battery which take about 2.5 hours to go from 10% to 100%.The zappi integration does have a few services which could help: Service to start boost (provide boost amount in kWh as parameter) Service to start smart boost (provide boost amount in kWh and desired finished time as paramters) Service to stop boost

The EV SOC would have to be user input or come from another iteration (ID.3 in my case), and I suspect the EV capacity would have to be a similar (no ID.3 battery capacity sensor)

There is also the ’target rate sensors’ in BottlecapDave’s Octopus integration but I’m struggling to get my head around those!

So it looks like the building blocks might be there

On 13 Feb 2024, at 17:39, SzosszeNET @.***> wrote:

Like this idea. While you get a response as an alternative not sure if you looked into it, but zappi seems to have its own integration. https://github.com/CJNE/ha-myenergi Could imagine to have both, and create an automation (under settings in HA) if not already one in the myenergi repo, that would watch the myenergi integration and if it's scheduled to charge, at the beginning of the charge window: Stop AppDaemon Set a static charge window to the inverter (to hold charge Just to be sure 00 the discharge window and current And potentially a second one that would start AppDaemon when the myenergi charge is finished/is outside the charge window? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[stevebuk1]

Seconded for an EV integration. I'm on IOG so all I'd be looking for is a "hold SOC" whilst the EV is charging. I'd prefer a charge current = 0 to do the hold function rather than setting Backup/Reserve, as in Backup/Reserve my inverter doesnt respect Bit 6 in the Energy Storage register to prevent grid charging, causing oscillations between full rate charging and full rate discharging during EV charging. This rules me out of Pv-opt for now.

I'm currently running Predbat and am contributing to Solis code changes for IOG, but I can see that the fundamental way it works is never going to work properly for Agile due to GivEnergy functions Solis inverters just don't have (like Freeze Charging) - and I figure one day I'll be moving to Agile.

I have an ID4 and Zappi so similar to [mergwyn] and will happily assist with Alpha/Beta testing.

[fboundy]

I think that setting charge current to zero for the Solis is a better method of holding SOC anyway so I'm about to start testing that.

How would you flag up the EV charging slots with IOG?

[mergwyn]

BottlecapDave's integration has a sensor: binary_sensor.octopus_energy_{{ACCOUNT_ID}}_intelligent_dispatching which is used to determine if you're currently in a planned dispatch period (i.e. "smart-charge" determined by Octopus Energy) or are within the standard off peak period. This sensor will not come on during a bump charge which I think is an OK limitation.

There are some limitations: https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/blob/b06499c86548847b5c75c17a487a87178f59b64a/_docs/entities/intelligent.md?plain=1#L9

This doesn't cover how to make EV charging work with Agile rather than IOG which is a harder problem I suspect. I'm probably going to switch to IOG shortly until the Autumn, so again this is a limitation I can live with for a while at least!

Thanks again for your great work on pv_opt.

[fboundy]

OK - so looking at the attributes for this would it be reasonable to assume that pv_opt should simply "hold SOC" for all entries in planned_dispatches?

@stevebuk1 - I'm a bit confused by your comment regarding Bit 6 for Energy Storage as this is the Feed In Priority bit. Do you mean this or Bit 5 which is Grid Charging? How does this interact with setting Backup Mode (Bit 4) and Backup SOC? One of the current limitations with the Solax integration is that the control switch isn't set bit-wise or by number but using a select. That said I've successfully added modes to the integration before.

[mergwyn]

For me, the ideal situation would be for pv_opt to do its thing regarding whether the solar batteries need to be charged. If this is at the same time as the EV needs to be charged (indicated by intelligent_dispatching for IOG) is it possible just to set the discharge current to zero (or some equivalent) such that both the EV and solar batteries can be charged at the same time?

[stevebuk1]

I'm a bit confused by your comment regarding Bit 6 for Energy Storage as this is the Feed In Priority bit. Do you mean this or Bit 5 which is Grid Charging?

Apologies, I was responding to an Issue in the Solis Inverters Facebook group where people were labelling the 8 bits as Bit1 to Bit 8, and I forgot to reset my language to the traditional LSB = 0, MSB = 7 nomenclature. It is indeed Bit 5.

Regarding the Solax integration, it currently has two options for Backup/Reserve:

"Backup/Reserve" "Backup/Reserve - No Grid Charging".

and I imagine the 2nd one clears Bit 5.

What I was trying to say in my previous post is that there is no change in behavior between these modes (both charge from grid when battery SOC is below backup SOC), so I'd prefer using charge/discharge slots and current (amps) setting to do it instead.

[stevebuk1]

OK - so looking at the attributes for this would it be reasonable to assume that pv_opt should simply "hold SOC" for all entries in planned_dispatches?

Yes, this is the way Predbat works, or rather it does now in my local copy since the addition of setting charge slots and current = zero for Solis inverters. Note: I'd toyed with using discharge start/end times and discharge current = 0, but Predbat doesnt clear out old charge start/end times anyway, so I just used the charge start/end times. I guess either would work as long as there are no conflicts between charge and discharge times.

[fboundy]

Ok understood - from a Backup perspective I think that behaviour is correct in that you want to maintain a certain SOC in case the grid goes out but it’s not the same as holding SOC.

I wrote some of the initial Solis code for PredBat but I gave up on it because I found it too heavily predicated on GivEnergy behaviour. I also couldn’t get my head around the optimiser which often didn’t seem very optimal for Agile.

I’ve tried to make pv_opt a bit more “open” but all inverters seem to be quite different. On 25 Mar 2024 at 20:21 +0000, stevebuk1 @.***>, wrote:

I'm a bit confused by your comment regarding Bit 6 for Energy Storage as this is the Feed In Priority bit. Do you mean this or Bit 5 which is Grid Charging? Apologies, I was responding to an Issue in the Solis Inverters Facebook group where people were labelling the 8 bits as Bit1 to Bit 8, and I forgot to reset my language to the traditional LSB = 0, MSB = 7 nomenclature. It is indeed Bit 5. Regarding the Solax integration, it currently has two options for Backup/Reserve: "Backup/Reserve" "Backup/Reserve - No Grid Charging". and I imagine the 2nd one clears Bit 5. What I was trying to say in my previous post is that there is no change in behavior between these modes (both charge from grid when battery SOC is below backup SOC), so I'd prefer using charge/discharge slots and current (amps) setting to do it instead. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[fboundy]

OK - will have a go at getting this going. On 25 Mar 2024 at 20:34 +0000, stevebuk1 @.***>, wrote:

OK - so looking at the attributes for this would it be reasonable to assume that pv_opt should simply "hold SOC" for all entries in planned_dispatches? Yes, this is the way Predbat works, or rather it does now in my local copy since the addition of setting charge slots and current = zero for Solis inverters. Note: I'd toyed with using discharge start/end times and discharge current = 0, but Predbat doesnt clear out old charge start/end times anyway, so I just used the charge start/end times. I guess either would work as long as there are no conflicts between charge and discharge times. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[stevebuk1]

I wrote some of the initial Solis code for PredBat but I gave up on it because I found it too heavily predicated on GivEnergy behaviour. I also couldn’t get my head around the optimiser which often didn’t seem very optimal for Agile.

I remember you saying in the Solis Facebook group you authored some of the code in Predbat. I've carried on making some changes and additions for getting it working in IOG (e.g. I've disabled it using Backup/Reserve mode to fix low rate charging) but the target SOC changes wildly through the 6 hours cheap rate period for what looks like no input changes (solcast, power forecast etc), resulting in a mess of high rate and low rate charging with constant writes to the inverter all night. For this reason I've just started trying to figure out the optimizer too but not encouraged by your experience. With EV hold functionality PV_opt will do the job, although getting in an electrician to add a Henley block for the Zappi is the other way ;-)

[stevebuk1]

Regarding consumption data, I'm not sure if the current algorithm just uses what the Solis supplied to the house as energy, or takes account of the house load coming from grid during charging slots and hold slots. If one load shifts to co-inside with charging slots to avoid battery losses (as I do) then its likely direct use of grid energy will be a significant portion of consumption, so I assume grid energy forms part of the consumption data calculations?

If the assumption is correct, then car charging is going to add to (and corrupt) any existing method of grid use being factored into consumption data. This means the energy consumed from the grid use for car charging will need discounting from any consumption data, so it doesn't influence the charging plans for the house battery. Ultimately, we are compensating for the fact that the Solis CT clamp sees both the EV and the house as consumption.

I see 3 different ways of doing this: 1) Assume any grid draw above 6kW will mean the EV is charging, so subtract 7kw (the actual EV charge rate) from the consumption figures 2) Utilise a Zappi entity that tracks consumption "sensor.myenergizappi{Serial number}_charge_added_session", and subtract this from the consumption figures. Note this resets to zero when the car is plugged in. 3) Utilise the "completed dispatches" attribute within the "_intelligent_dispatching" entity mentioned above and subtract it from the consumption figures.

Apologies if this was already obvious.

[fboundy]

Consumption is house load (plus backup if you have a backup circuit as I do). I take solar and house load as gives and then optimise the battery charging and hence grid in/out to minimise cost so I think it will be immune to EV charging as it is effectively “blind” to this. Of course actual grid usage will be much higher than calculated but the excess is all going to the EV. Make sense?

There is an issue around how the Solax integration reports total load which I need to document (it basically includes inverter losses) but that is relatively minor in the scheme of things. On 26 Mar 2024 at 22:38 +0000, stevebuk1 @.***>, wrote:

Regarding consumption data, I'm not sure if the current algorithm just uses what the Solis supplied to the house as energy, or takes account of the house load coming from grid during charging slots and hold slots. If one load shifts to co-inside with charging slots to avoid battery losses (as I do) then its likely direct use of grid energy will be a significant portion of consumption, so I assume grid energy forms part of the consumption data calculations? If the assumption is correct, then car charging is going to add to (and corrupt) any existing method of grid use being factored into consumption data. This means the energy consumed from the grid use for car charging will need discounting from any consumption data, so it doesn't influence the charging plans for the house battery. Ultimately, we are compensating for the fact that the Solis CT clamp sees both the EV and the house as consumption. I see 3 different ways of doing this:

1. Assume any grid draw above 6kW will mean the EV is charging, so subtract 7kw (the actual EV charge rate) from the consumption figures
2. Utilise a Zappi entity that tracks consumption "sensor.myenergizappi{Serial number}_charge_added_session", and subtract this from the consumption figures. Note this resets to zero when the car is plugged in.
3. Utilise the "completed dispatches" attribute within the "_intelligent_dispatching" entity mentioned above and subtract it from the consumption figures.

Apologies if this was already obvious. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[stevebuk1]

Make sense?

Not really. Looking at the log file, consumption is loaded from "sensor.solis_house_load_today". The plot of that sensor is below, and it includes the 26kWh ish of car charging that I did last night. It can't be blind to it, otherwise the we wouldn't have the problem of the house battery discharging into the EV in the first place?

[fboundy]

OK - got it.

I think all 3 of your suggestions would work. I'd probably prioritise them in terms of what is available on a per case basis:

1. Zappi (or other EV charger entity)
2. IO dispatches (would only work for IO I presume)
3. Charge threshold power which is the crudest and might pick up cooking Sunday Roast in error

[fboundy]

I'm hoping to have something out to test later today as a pre-release I don't think it will work fully but hopefully it will log enough stuff to gather the necessary info.

[fboundy]

v3.13.0-ev-beta-1 should now be available as a pre-release via HACS. It adds:

• Hold SOC using charge at zero amps
• Checks for IO entities and logging of same
• Checks for Zappi entities and logging of same
• Additional logging of tariff busts with Bottlecap Dave to diagnose #181

If you can load it up and check it doesn;t bust anything. If it doesn't then could you run it for at least 24 hours and then send me the pv_opt.log and error.log (if any errors occur)?

If this works OK then next step is to isolate the IO charging intervals from the optimisation.

Thanks

[stevebuk1]

Great - I've now installed it and its up and running. Its scheduled a house battery charge for this evening (the weather in Scotland is currently awful solar-wise) and I'll plug in the car.

I assume there aren't any changes needed to apps.yaml?

[stevebuk1]

I think all 3 of your suggestions would work. I'd probably prioritise them in terms of what is available on a per case basis:

1. Zappi (or other EV charger entity)
2. IO dispatches (would only work for IO I presume)
3. Charge threshold power which is the crudest and might pick up cooking Sunday Roast in error

Agree that Option1 is the best, and should easily be configurable for other chargers. 2) agree thats only useful for IO, so no use for Agile or the other tariffs 3) is crude and it would probably work for me as during the day as I try and keep all consumption below 3kW (max battery discharge rate in my 3.6kW inverter) so I don't draw from grid. Overnight is similar (I offset all appliances), but I doubt it would work for those having G99 inverters and bigger battery banks.

[fboundy]

Great - I've now installed it and its up and running. Its scheduled a house battery charge for this evening (the weather in Scotland is currently awful solar-wise) and I'll plug in the car.

I assume there aren't any changes needed to apps.yaml?

Shouldn't be any changes needed. It should just check for the io and zappi entities and then spit out their contents to the log file.

[stevebuk1]

Apologies, I spoke too soon. I flicked the toggle on Consumption to go fixed, and have since realised that it did a restart of PV_opt ok but the first run had hung. I've now restarted AppDeamon and Pv_Opt is stuck in "Loading Tarrifs".

Error log code is:

15:58:03 WARNING pv_opt: ------------------------------------------------------------ 15:58:03 WARNING pv_opt: Unexpected error running initialize() for pv_opt 15:58:03 WARNING pv_opt: ------------------------------------------------------------ 15:58:03 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 "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 407, in initialize self._check_for_zappi() File "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 472, in _check_for_zappi for entity_id in self.self.io: ^^^^^^^^^ AttributeError: 'PVOpt' object has no attribute 'self'

15:58:03 WARNING pv_opt: ------------------------------------------------------------

I thought it might be a duplicate "self" at line 472, but removing it didnt make any difference:

16:03:22 WARNING pv_opt: ------------------------------------------------------------ 16:05:16 WARNING pv_opt: ------------------------------------------------------------ 16:05:16 WARNING pv_opt: Unexpected error in worker for App pv_opt: 16:05:16 WARNING pv_opt: Worker Ags: {} 16:05:16 WARNING pv_opt: ------------------------------------------------------------ 16:05:16 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 "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 407, in initialize self._check_for_zappi() File "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 472, in _check_for_zappi for entity_id in self.io: TypeError: 'bool' object is not iterable

[fboundy]

If you are happy to edit it yourself it's just a simple typo. Line 472 should be:

        for entity_id in self.self.io_entities:

Didn't flag in my system because it was an empty list for me and the prior if caught it

[stevebuk1]

Yes no problem on code changes, I'll change that and restart. Is there a quicker way of doing a restart of pv_opt without doing a restart of Appdaemon?

On Wed, 27 Mar 2024, 16:16 fboundy, @.***> wrote:

If you are happy to edit it yourself it's just a simple typo. Line 472 should be:

    for entity_id in self.self.io_entities:

Didn't flag in my system because it was an empty list for me and the prior if caught it

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

[fboundy]

Any changes to the .py files or config.yaml should cause AD to restart it

[mergwyn]

I've also installed this version and made the edit to py_opt.py, but I get a different error:

16:45:14 WARNING pv_opt: ------------------------------------------------------------
16:46:15 WARNING pv_opt: ------------------------------------------------------------
16:46:15 WARNING pv_opt: Unexpected error running initialize() for pv_opt
16:46:15 WARNING pv_opt: ------------------------------------------------------------
16:46:15 WARNING pv_opt: Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/appdaemon/app_management.py", line 162, in initialize_app
    await utils.run_in_executor(self, init)
  File "/usr/local/lib/python3.10/site-packages/appdaemon/utils.py", line 304, in run_in_executor
    response = future.result()
  File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/home-assistant/appdaemon/apps/pv_opt/pv_opt.py", line 407, in initialize
    self._check_for_zappi()
  File "/home-assistant/appdaemon/apps/pv_opt/pv_opt.py", line 472, in _check_for_zappi
    for entity_id in self.self.io_entities:
AttributeError: 'PVOpt' object has no attribute 'self'

I'm also seeing something I've not noticed before:

16:45:14 WARNING pv_opt: ------------------------------------------------------------
16:45:14 WARNING pv_opt: Unexpected error running initialize() for pv_opt
16:45:14 WARNING pv_opt: ------------------------------------------------------------
16:45:14 WARNING pv_opt: Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/appdaemon/app_management.py", line 162, in initialize_app
    await utils.run_in_executor(self, init)
  File "/usr/local/lib/python3.10/site-packages/appdaemon/utils.py", line 304, in run_in_executor
    response = future.result()
  File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/home-assistant/appdaemon/apps/pv_opt/pv_opt.py", line 372, in initialize
    while (not self.inverter.is_online()) and (retry_count < ONLINE_RETRIES):
AttributeError: 'InverterController' object has no attribute 'is_online'

[fboundy]

OK hopefully 3.14.0-ev-beta-2 fixes all these issues. Too many beta versions flying around...

[mergwyn]

We're moving forward, now I got:

17:46:23 WARNING pv_opt: ------------------------------------------------------------
17:46:23 WARNING pv_opt: Unexpected error running initialize() for pv_opt
17:46:23 WARNING pv_opt: ------------------------------------------------------------
17:46:23 WARNING pv_opt: Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/appdaemon/app_management.py", line 162, in initialize_app
    await utils.run_in_executor(self, init)
  File "/usr/local/lib/python3.10/site-packages/appdaemon/utils.py", line 304, in run_in_executor
    response = future.result()
  File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/home-assistant/appdaemon/apps/pv_opt/pv_opt.py", line 364, in initialize
    self._load_args()
  File "/home-assistant/appdaemon/apps/pv_opt/pv_opt.py", line 974, in _load_args
    raise ValueError(e)
ValueError:     id_daily_solar                     : Neither the entities listed in the YAML sensor.solis_power_generation_today nor the system default of None exist in HA.

This went away when I uncommented id_daily_solar: sensor.{device_name}_power_generation_today

I'm still seeing the error:

17:53:40 WARNING pv_opt: ------------------------------------------------------------
17:53:40 WARNING pv_opt: Unexpected error running initialize() for pv_opt
17:53:40 WARNING pv_opt: ------------------------------------------------------------
17:53:40 WARNING pv_opt: Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/appdaemon/app_management.py", line 162, in initialize_app
    await utils.run_in_executor(self, init)
  File "/usr/local/lib/python3.10/site-packages/appdaemon/utils.py", line 304, in run_in_executor
    response = future.result()
  File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/home-assistant/appdaemon/apps/pv_opt/pv_opt.py", line 369, in initialize
    self._check_for_zappi()
  File "/home-assistant/appdaemon/apps/pv_opt/pv_opt.py", line 434, in _check_for_zappi
    for entity_id in self.self.io_entities:
AttributeError: 'PVOpt' object has no attribute 'self'

[fboundy]

You can either edit yourself to change line 434 of `pv_opt.py' to:

            for entity_id in self.io_entities:

Or upgrade to 3.14.0-ev-beta-3

[stevebuk1]

Oh yes, I forgot about that. That's a good quick way.

On Wed, 27 Mar 2024, 16:27 fboundy, @.***> wrote:

Any changes to the .py files or config.yaml should cause AD to restart it

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

[mergwyn]

Thanks for the update - still getting an error:

19:56:30 WARNING pv_opt: ------------------------------------------------------------
19:56:30 WARNING pv_opt: Unexpected error running initialize() for pv_opt
19:56:30 WARNING pv_opt: ------------------------------------------------------------
19:56:30 WARNING pv_opt: Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/appdaemon/app_management.py", line 162, in initialize_app
    await utils.run_in_executor(self, init)
  File "/usr/local/lib/python3.10/site-packages/appdaemon/utils.py", line 304, in run_in_executor
    response = future.result()
  File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/home-assistant/appdaemon/apps/pv_opt/pv_opt.py", line 369, in initialize
    self._check_for_zappi()
  File "/home-assistant/appdaemon/apps/pv_opt/pv_opt.py", line 434, in _check_for_zappi
    for entity_id in self.io_entities:
AttributeError: 'PVOpt' object has no attribute 'io_entities'

19:56:30 WARNING pv_opt: ------------------------------------------------------------

[stevebuk1]

Changing Line 434 to "for entity_id in self.zappi_entities:" has fixed it, and logged the Zappi full entity name for charge_added_session, which I presume was its purpose.

Note: this entity contains serial number information. Is there a way to upload log files to Github such they are not public?

[stevebuk1]

This is just for reference, but as yesterday was a charging day and today wasn't, I thought I would attach this to compare the two.

I hadnt realised that Solis_House_Load_Today already takes account of what the house uses from the grid when the house battery is charging.

So regarding my previous post: "Regarding consumption data, I'm not sure if the current algorithm just uses what the Solis supplied to the house as energy, or takes account of the house load coming from grid during charging slots and hold slots. If one load shifts to co-inside with charging slots to avoid battery losses (as I do) then its likely direct use of grid energy will be a significant portion of consumption, so I assume grid energy forms part of the consumption data calculations?"

.........then no, grid energy used directly doesnt need to form part of the consumption data calculations that Pv_opt does, because its already taken account of within the results published by Solis_House_Load_Today. However the same is not true for EV charging.

[fboundy]

There isn’t but I’ll update the code tomorrow so it redacts them from the log. On 27 Mar 2024 at 20:36 +0000, stevebuk1 @.***>, wrote:

Changing Line 434 to "for entity_id in self.zappi_entities:" has fixed it, and logged the Zappi full entity name for charge_added_session, which I presume was its purpose. Note: this entity contains serial number information. Is there a way to upload log files to Github such they are not public? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[mergwyn]

Thanks - that worked for me, now up and running on beta, will send logs over the weekend GaryOn 27 Mar 2024, at 20:36, stevebuk1 @.***> wrote: Changing Line 434 to "for entity_id in self.zappi_entities:" has fixed it, and logged the Zappi full entity name for charge_added_session, which I presume was its purpose. Note: this entity contains serial number information. Is there a way to upload log files to Github such they are not public?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[fboundy]

This is just for reference, but as yesterday was a charging day and today wasn't, I thought I would attach this to compare the two.

I hadnt realised that Solis_House_Load_Today already takes account of what the house uses from the grid when the house battery is charging.

So regarding my previous post: "Regarding consumption data, I'm not sure if the current algorithm just uses what the Solis supplied to the house as energy, or takes account of the house load coming from grid during charging slots and hold slots. If one load shifts to co-inside with charging slots to avoid battery losses (as I do) then its likely direct use of grid energy will be a significant portion of consumption, so I assume grid energy forms part of the consumption data calculations?"

.........then no, grid energy used directly doesnt need to form part of the consumption data calculations that Pv_opt does, because its already taken account of within the results published by Solis_House_Load_Today. However the same is not true for EV charging.

This is very helpful as, not being on IO or having and EV, I'm not fully up to speed on the implications. Could you also plot out the zappi sensor and battery soc for the two days?

[fboundy]

3.14.0-ev-beta-4 should fix the typos and also redact the zappi serial numbers

[stevebuk1]

This is very helpful as, not being on IO or having and EV, I'm not fully up to speed on the implications. Could you also plot out the zappi sensor and battery soc for the two days?

No problem. The first day is now a non-charging day, the 2nd day incluldes EV charging. IO scheduled two slots, one from 00.00 to 00.30 and another from 01.30 through to 05.30.

You can see the operation of the Zappi sensor - it clears to zero when the car is plugged in and Octopus creates the charging plan (and sets it via the _intelligent_dispatching entity). It then increments through the charging, with the final value persisting until the next plug-in. The Zappi integration with IOG uses a "charge to add %" rather than a "charge to %" as the Zappi doesn't know what the cars SOC is. Mine is set to 50% and I don't tend to need to adjust it. I thought I would mention this as this is why all nights of EV charging always end in 29kWh being dispatched.

[stevebuk1]

3.14.0-ev-beta-4 should fix the typos and also redact the zappi serial numbers

The redaction is working but PV_opt status is now stuck in "Loading Tariffs".

Error.log reports the following:

22:58:32 WARNING pv_opt: ------------------------------------------------------------ 22:59:33 WARNING pv_opt: ------------------------------------------------------------ 22:59:33 WARNING pv_opt: Unexpected error in worker for App pv_opt: 22:59:33 WARNING pv_opt: Worker Ags: {} 22:59:33 WARNING pv_opt: ------------------------------------------------------------ 22:59:33 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 "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 393, 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 1365, in optimise if self._check_tariffs(): ^^^^^^^^^^^^^^^^^^^^^ File "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 792, in _check_tariffs self._check_tariffs_vs_bottlecap() File "/homeassistant/appdaemon/apps/pv_opt/pv_opt.py", line 2340, in _check_tariffs_vs_bottlecap self.log(self.contract[direction])

TypeError: 'Contract' object is not subscriptable

22:59:33 WARNING pv_opt: ------------------------------------------------------------

PV_opt.log shows this:

23:03:43     INFO: 
23:03:43     INFO: Running initial Optimisation:
23:03:43     INFO: 
23:03:43     INFO: 
23:03:43     INFO: Found Octopus Savings Events entity: event.octopus_energy_**********_octoplus_saving_session_events
23:03:43     INFO: 
23:03:43     INFO: No upcoming Octopus Saving Events detected or joined:
23:03:43     INFO: 
23:03:43     INFO: Starting Opimisation with discharge enabled
23:03:43     INFO: -------------------------------------------
23:03:43     INFO: 
23:03:43     INFO: Checking tariffs:
23:03:43     INFO: -----------------
23:03:43     INFO: 
23:03:43     INFO: Checking tariff prices vs Octopus Energy Integration:
23:03:43     INFO: -----------------------------------------------------
23:03:43     INFO: 
23:03:43     INFO: >>> E-1R-INTELLI-BB-VAR-23-03-01-N
23:03:43     INFO: >>> Start: 28/03 00:00 End: 28/03 23:30
23:03:43  WARNING: pv_opt: Entity sensor.pvopt_tariff_import_OK not found in namespace default
23:03:43     INFO:   Import: Average Prices - PV_OPT: 24.35 p/kWh  OE Integration: 23.88 p/kWh  Mean difference:  0.47 p/kWh <<< ERROR
23:03:52     INFO: 
23:03:52     INFO: ******************* PV Opt v3.14.0-ev-beta-4 *******************
23:03:52     INFO: 
23:03:52     INFO: Pre-release version. Enabling debug logging
23:03:52     INFO: Local timezone set to GB
23:03:52     INFO: Time Zone Offset: 0.0 minutes
23:03:52     INFO: Inverter type: SOLIS_SOLAX_MODBUS: inverter module: solis.py
23:03:52     INFO: Inverter appears to be online
23:03:52     INFO: 
23:03:52     INFO: Available entities for device solis:
23:03:52     INFO: ------------------------------------
23:03:52     INFO: 

I think the event at 23:03:52 is a restart, this repeats indefinitely. 

Line 2340, should self.log(self.contract[direction]) be self.log(self.contract.tariffs[direction])?

[stevebuk1]

I've just noticed the error messages above started at 16:45, which was using Beta3 + the manual fix for zappi_entities established last night, that was working. 16:45 is also the last time PV-opt updated any plans. I think therefore this might be the stale tariff problem I was having in #181.

Full error log is below. Apologies it also has predbat errors interlaced.

error.log

[stevebuk1]

Modifying the .py files to restart did not clear the error, but stopping and restarting AppDaemon has cleared the error.

Tomorrow I'll be leaving for holidays and returning 3rd April. I will try and upload log files before I go.

[fboundy]

Line 2340, should self.log(self.contract[direction]) be self.log(self.contract.tariffs[direction])?

Yes. Actually make it self.rlog(self.contract.tariffs[direction]) which will apply the redaction.

This should add some detail regarding #181.

[stevebuk1]

Thanks - on hols now till Wednesday so will correct and log on my return.

On Fri, 29 Mar 2024, 10:42 fboundy, @.***> wrote:

Line 2340, should self.log(self.contract[direction]) be self.log(self.contract.tariffs[direction])?

Yes. Actually make it self.rlog(self.contract.tariffs[direction]) which will apply the redaction.

This should add some detail regarding #181 https://github.com/fboundy/pv_opt/issues/181.

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

[mergwyn]

Hi Francis - I've had to revert to 3.13.1 (@ 17:04 today) as for some reason tariffs stopped loading. Here are the logs I've collected so far. pv_opt.log error.log

(just to remind you I'm still on agile and charge via a schedule in the car with zappi in fairly dumb mode) I was not able to re-download the beta in HACS as there are now too many other betas, and I don't have time to do a manual install today. Hopefully, I'll be able to do this tomorrow.

[fboundy]

This is a one-off related to the clocks changing and Agile. It would be the same in both but only happened before the new agile rates were released at 16.00. On 30 Mar 2024 at 17:49 +0000, mergwyn @.***>, wrote:

Hi Francis - I've had to revert to 3.13.1 (@ 17:04 today) as for some reason tariffs stopped loading. Here are the logs I've collected so far. pv_opt.log error.log (just to remind you I'm still on agile and charge via a schedule in the car with zappi in fairly dumb mode) I was not able to re-download the beta in HACS as there are now too many other betas, and I don't have time to do a manual install today. Hopefully, I'll be able to do this tomorrow. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[mergwyn]

I'm struggling to provide any logs to support this issue as I still can't load tariffs properly. I've had some issues at this end and have had to restore from backup, so it could be a misconfiguration here. error.log pv_opt.log

[fboundy]

Please try 3.14.0-ev-beta-5

[mergwyn]

Thanks, back up and running. Tonight is a charging night so I’ll try and send logs tomorrowOn 31 Mar 2024, at 20:01, fboundy @.***> wrote: Please try 3.14.0-ev-beta-5

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[mergwyn]

Here are the logs for last night. pv_opt.log error.log

The car charged from 18% to 63% adding 27kWh in the period from 0130 to 0530. Hopefully this helps!