EV charging support/integration #121
Comments
|
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. 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: And potentially a second one that would start AppDaemon when the myenergi charge is finished/is outside the charge window? |
|
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 It sounds like installing the Zappi integration would be a start. I would then need to know what sensors and services it exposes. |
|
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: ***@***.***>
|
|
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. |
|
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? |
|
BottlecapDave's integration has a sensor: 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. |
|
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 @stevebuk1 - I'm a bit confused by your comment regarding |
|
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 |
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" 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. |
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. |
|
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: ***@***.***>
|
|
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: ***@***.***>
|
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 ;-) |
|
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. I see 3 different ways of doing this:
Apologies if this was already obvious. |
|
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.myenergi_zappi_{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: ***@***.***>
|
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?
|
|
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:
|
|
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. |
|
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 If this works OK then next step is to isolate the IO charging intervals from the optimisation. Thanks |
|
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? |
Agree that Option1 is the best, and should easily be configurable for other chargers. |
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. |
|
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: ------------------------------------------------------------ I thought it might be a duplicate "self" at line 472, but removing it didnt make any difference: 16:03:22 WARNING pv_opt: ------------------------------------------------------------ |
|
If you are happy to edit it yourself it's just a simple typo. Line 472 should be: Didn't flag in my system because it was an empty list for me and the prior |
|
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
<#121 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASVRJMFYMSEATYJ4SFIYWPLY2LPGHAVCNFSM6AAAAABDG4TRJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRTGE3TGNZYGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Any changes to the .py files or config.yaml should cause AD to restart it |
|
I've also installed this version and made the edit to py_opt.py, but I get a different error: I'm also seeing something I've not noticed before: |
|
OK hopefully 3.14.0-ev-beta-2 fixes all these issues. Too many beta versions flying around... |
Apologies but I think I completely misunderstood the point you made above. I thought you were looking for Pv_opt to suppress a discharge if the car was charging because it was in an scheduled IOG slot. what you really meant was that if a discharge is taking place, the Zappi should not divert this to the car if the car is plugged in, it should instead go to grid as that pays better? If so, the most usual way to fix that is to set an "export margin" in the Zappi to a level above what the inverter is capable of. This ensures all export goes to grid and not to car. This is a front screen Zappi setting, rather than anything thats available via the myEnerrgi API or myEnergi App. Theres a MyEnergi article about it here: |
|
@stevebuk1 - a im testing beta-4 testing with no car/io: I think you need to set a default for to Seems to now be running OK so I'll test for a couple of days. |
Thanks - I thought I'd caught all the variables that wouldn't be initialised on a non-EV setup but missed this one. I've added it into my local code.
Great, let me know of any issues. I'm still working on the odd negative power consumption value after substracting EV consumption from Total consumption. I think its due to the interpolation going on in _get_hass_power_from_daily_kwh when it requantises to half hour slots. The Zappi power data is kWh to one decimal place, so when the car stops charging the entries can be hours apart as the consumption is either zero or a very low value. I think _get_hass_power_from_daily_kwh interpolates beyond the last entry it downloads from HA but if it does this with the Zappi it will be wrong - the interpolation feature needs to be off for the Zappi and any times beyond the last entry from HA need to be equal to that last entry. Will either add a switch to the function call or just write a new function for EV chargers in general. I'll also do an updated dashboard based on the clean version in the repo (this is mostly done) and write the release notes. Your testing aside, I think it will be another week before I have a production ready version. |
|
I've made some of your logging on |
I synced forks last night to include the 3.15.4 changes - no impacts as far as I can see. I've since also added two commits to suppress any negative values in consumption which was the last bug I was working on. As I've recorded in stevebuk1#1, there's either something in the interpolation that doesn't work well with the typical consumption of an EV charger (mostly 7kW or nothing) or its an artefact of doing a power subtraction as opposed to an energy subtraction. With the negative suppression the error is a single 1/2 hour of background house load which for me is around the 150Wh mark so I think its an error that can ignored. If I find time I think permanent fix would be to quantitize to 1/2 hour slots using energy, substract EV from Total and then convert to power, but its low priority and to be honest, probably beyond my abilities to unpick that single line of .interpolate/.resample/.asfreq etc! No problem on the logging, I was just leaving it place for your test runs to aid debug (self.opt being the useful one) and was going to remove it after your testing. Agree all of it should now be behind self.debug. I've uploaded an update to the dashboard that includes extra views for IOG and Zappi stuff - these should all self hide if EV_charger is set to none. Suggested release notes are as follows:
I think the README.md "Consumption Parameters" needs entries for: "EV Part of House Load", and the need for the MyEnergi HA integration should be added - is that best to with a PR? |
|
I've downloaded 3.16.0-Beta-6 this morning but seems to be getting stuck |
|
Hi @mergwyn, I had a quick look. The log shows various HA entities going unavailable, then shows that attempted loads of consumption data from "sensor.solax_house_load" fail with "ERROR: No data returned from HASS entity sensor.solax_house_load" Looking at your previous logs when it was all working, reading of power from sensor.solax_house_load was working ok. I don't think any of this area (loading the total consumption from the Solax integration) has changed recently, either in the EV changes I've made or elsewhere. Also, the restarts should show the following banner but they are all showing In looking at this I've discovered Pv_opt will attempt to use power sensors first and then try energy sensors ("house_load_today"), and my setup has only ever used energy sensors for some reason, but I don't think there is an untested element here as yours was working previously with the power sensors. I think ensure you've got the files from the dev branch at https://github.com/stevebuk1/pv_opt/tree/dev/apps/pv_opt and then try an HA restart. |
|
Hi @stevebuk1 thanks for your work on this. I'm running v3.16.0-Beta-6 since yesterday with no issues and a successful IOG charge overnight and one outside of the usual 23.30-05.30 window. In your pvopt_dashboard.yaml there are several script entities for changing the charge current. Are these necessary for the integration to function or to you use them for something else? |
|
Thanks for your response. The versions I was using was from before my holiday (maybe June 21) and I don't think the version was set correctly in the code at that time. I've re-download the code at 1337 today, and it looks like I am getting the right tag this time. After restarting HA, I started seeing When I tried to load the information direct from octopus I got the following error Here are the logs: |
Hi @dolce08, thats great, pleased its working well for you. Re the script entries - are you refering to these?
If so, then no, these arent necessary for Pv_opt to function and aren't part of Pv_opt. These are effectively manual overrides to Pv_opt; when run they set Pv_opt to read only, set a fixed charge current and charge between 23:30 and 05:30. As I used these frequently during development of the EV stuff if it got to late at night and things weren't working, I'd placed these on the Pv_opt dashboard for convenience. I've now removed these from the production candidate dashboard, which is here: https://github.com/stevebuk1/pv_opt/blob/dev/pvopt_control_card.yaml Conversely, if you do want the scripts for your own use let me know and I'll upload them! |
@mergwyn, this error is due to Pv opt has 3 ways of loading the contract - it tries first via the Octopus Energy Integration, then via the website using your account ID and API, and then finally via manual tariffs in config.yaml. If it can't complete these then Pv_opt will stop with a fatal error. The log file includes multiple entries for both the contract last loaded and the contract fatal error, but as they are all identically timestamped with 13:44:56 I can't see whats actually occuring first. Try this code for pv_opt.py (remove the .txt extension) which has a fix for the initialized variable and post a log please. If it doesn't work I'll add some debugging in to trace the problem. |
|
Thanks for the quick response - here are the logs: |
|
@mergwyn I think I've found the cause of the problem - try Beta-7 at https://github.com/stevebuk1/pv_opt/tree/dev/apps/pv_opt |
|
@stevebuk1 that looks like it has done to trick - many thanks. Installed and appdeamon restarted at 12:52: |
@mergwyn Good news. It took me a while to figure out you've got debug text switched on, which is where the bug was. I don't tend to use it as I find it generates far too much to find anything, instead just adding debug to the code directly. I'd switch it off by setting Debug to False in config.yaml ( @fboundy, any objection if I add in a debug_level setting alongside the debug switch with value 1 to 5 for controlling the amount of logging? Level 5 would be the verbose setting with everything as is, with the other four levels with less and less. I'll probably run my system at Level 1 permanently to include the power flows and charging plans to catch the odd instability in charge current variation I see from time to time, and have Level 2 for the EV work, which I do intend to continue for the Agile tariff (but probably not start in the next few months). |
|
@stevebuk1 On the face of it things are working, but I seem to have stopped force discharging since installing the latest version. Looking at the logs I see It seems weird that the cost delta is 0. Here are the logs - I'll turn debug back on, let me know if you want me to upload those logs: |
Yes please to logs with debug logging on. Also if you can upload config.yaml at the same time. |
|
Here are the logs since I turned on debug yesterday: |
|
@mergwyn, thanks for the logs, they didn't contain any further detail around the area that calculates the cost delta. I forced an export tariff into my setup and enabled force discharging and I think I have repeated the same behaviour you've got, in that there is no forced discharge due to a cost delta of 0. I'm also getting no Low cost charging plan. You did get one of these in your logs you posted when you first raised this but not in the logs with debug switched on. I then reverted to the latest full production release (3.15.4 from https://github.com/fboundy/pv_opt), did the same tweak to force an export tariff and have found exactly the same behaviour. I also tried 3.14.0 and then 3.13.2, exactly the same. It might be worth repeating the same reversion testing to see if it makes a difference, otherwise its a case of opening a new issue. I'm afraid I can't explain why there isn't any charging and discharging going on. Uncommenting some extra logging lines in the code illicts this, which I can't explain: (@fboundy there is a fix for the * being an hour out within the existing PR, its a UTC v GMT thing) |
|
Hi @mergwyn,I'm about to start the EV support under the Agile tariff. I've released Beta-8 which allows me to turn off Octopus Auto and set manual tariffs so I can progress the development. I do however have a question though, mainly for my own benefit - I remember you saying that you tend to use IOG in spring/summer and then swap back to Agile for late Autumn/Winter. On IOG, I can pretty much average 7p per kWh as I have sufficient battery capacity to power the house for all consumption. Looking at months of Agile, I cannot see how its possible to approach that 7p, even the regular cheapest Agile slots seem to exceed that. Granted I have seen negative pricing and plunge events, but I assume you think it is is possible to achieve 7p or less using the Agile tariff over winter. Am I correct in my assumptions? Whilst I don't have export, the price for export on IOG and Agile is the same (15p)? |
|
@stevebuk1 Unfortunately I don't have the battery capacity to bridge a whole day. We have an ASHP which in the depths of winter can consume over 800 kWh in a month on its own (vs less than 50 kWh in the lowest summer month)! My 10kWh batteries are usually enough to bridge the 3 hour agile peak periods in the morning and afternoon. It doesn't like you have had chance to add the fix for discharge issue in Beta-8 as per your email:
Is that still something you are thinking of taking a look at? |
Thanks for your answer - makes perfect sense. I'm planning an ASHP, but aware that for the cold months I'm averaging around 110kWh a day on gas, so even with better insulation (WIP) and a decent SCOP I'll have the same problem (I have 12kWh of batteries). |
Ok, the reason you'll no longer find that post in the thread when viewed on the Github website is because I deleted it. Basically I'd written nonsense: although the figures reported by my debug log were very slightly different, it didnt actually affect the if/then/else statement that used them. I'd gone on a bit further after that and I'm still not sure I understand what "Low cost charging" actually does. I think it adds a single slot of full rate charging and then sees if it saves you money, but this cost saving is calculated prior to running the forced discharge part of the algorithm. Therefore, the only way it can work is making the assumption that any spare charge added is over and above needs and can be exported. It should always be over and above needs, as the "High cost swaps" that runs prior to that deals with all your actual needs, i.e ensures the battery finishes the day at just above max DOD. So, then doing a full rate charge in the cheapest slot should mean that excess can be exported, thus netting a cost saving. When I ran it I found the same as you. It may be because the cheapest slot for IOG is all 12 overnight slots (as they are all the same price), but as it appears to do one at a time I don't think its that. Its a case of setting up some detailed logging of the power flows to get a better understanding of whats actually happenning, to ensure the algorithm that was developed for the Agile tariff works equally as well for a dual rate tariff. I feel it should, but the devil is somewhere in the detail..... |
|
@mergwyn to carry on from the previous post I found this write-up on what the algorithm does from Francis in the Solax development thread. "Low Cost Charging" is point 4, and should result in a cost saving because of "Max Export". As stated in #121 (comment), the issue we are both finding in Beta-7 and that I'm finding in all historic versions that I've tried is that Net Cost Delta is zero. Did you try out 3.14.0 and then 3.13.2? |
|
@stevebuk1 I could not get either 3.14.0 or 3.13.2 to work for me - both got stuck at "Checking tariff prices vs Octopus Energy Integration" so I gave up on both. I did try 13.15.4 which did work but did not produce any discharge slots (I can supply logs if it helps) At the moment my export rate is 15p and overnight import is 7p so I would have expected discharge slots. |
|
Regarding Discharge slots, I think I've found the source of the problem , it was introduced in 3.15.4 (3.15.3 is ok) which I keep the Dev branch up to date with. I've raised this as a separate issue (#254) so it can get fixed on the production release. I'll do another Beta release with this code fix and additional logging, and post again when its done. Regarding low cost charging, I think I now understand how this works. As mentioned in #188 (comment) , the algorithm runs in 3 parts:
On a time of use tariff , 1) will basically aim to leave your battery at max DOD at 11.30pm. The key part I've noticed is that 2) runs on each slot at a time, by simulating a maximum rate charge for 1/2 hour and see if that saves you any money. The only way this can reduce cost prior to 3) being run is that the battery reaches 100% so there is then an export that will go to grid. If the available solar in that day doesn't get your battery anywhere near 100% then adding a full charge slot isnt going to get the battery to 100%, so no export and no cost saving. All that happens for each simulation is that you end the day with a battery that it is now above max DOD. If each slot simulation in 2) doesn't save you any money then no charge is actually added, so when 3) runs the battery is sitting at max DOD at 11.30pm, so there isnt anything additional to discharge in any slot (any discharge means you'll be importing at peak rate later on). If the algorithm instead tried one slot of low rate charging and then ran through all of the slots of discharging to see if that saved you any money, then it would find a battery that had spare charge in it at 11pm and discharge it. Both of these slots would then be locked in, so the next low rate charging slot added would give more energy in the battery that could be discharged in another discharge slot, and so on and so forth. I guess doing that might be theoretically possible, but wasn't chosen when Pv Opt was originally written and at first glance, would be an architectural rewrite from scratch. Francis may well be able to chime in and explain more? I'm aware that he always thought that Predbat was not all that optimum for Agile, and I know Trefor (the author of Predbat) is on IOG, so its certainly possible we may well be looking at the fact that the optimal algorithm for these tariffs differs, i.e an Agile based algorithm only considers everything a slot at a time but a time of use tariff would be better considering the 6 hour cheap rate period as a full block. |
3.16.0-Beta-9 released at: Copy all of pv_opt.py, pvpy.py and solis.py. In your config.yaml, add the following lines: And when you see charging/discharging that doesn't look right (late evening is best), change and post the log from a single optimser run. |
|
@stevebuk1 Thanks so much for tracking this down and supplying a fix. I've installed Beta-9 this morning and discharge slots have returned! However, as you suggest above, the timing of the slots doesn't look right: I have discharge slots at 16:30 when it makes more sense to discharge immediately before the cheap rate at 23:30. Also, given there is good solar today and the battery looks like it will be at 100% from around 10:30 this morning, there are opportunities to discharge and then recharge from solar at at 15p per kWh nominal gain. Here are the logs for an optimiser run starting at 10:213:23 with debug on: |
I don't pretend to fully understand the subtleties of what you are saying, but I think my expectation is roughly what you describe. At a high level the goal is the same irrespective of Agile or IOG, ie to use cheap rate slots to charge the battery such that battery + solar can bridge higher rate slots. As I think you explain above the devil is in the detail! Taking the simple case of IOG, I would hope that the algorithm can can determine whether to force discharge before the cheap rate slot, as well as not charge during the cheap rate slot if there is enough battery capacity to meet the forecast demand until solar generation can take over and start filling the battery. Whilst I don't claim to understand Predbat (and find it hugely complicated), it does produce differer very different results for the next day or so: 
|
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.
The text was updated successfully, but these errors were encountered: