fboundy
Large charge plan variations for small changes in input conditions
Describe the bug
At 22:30 the plan was
22:30:13 INFO: Optimal forced charge/discharge slots:
22:30:13 INFO: 14-Dec 02:30 GMT - 14-Dec 03:30 GMT Power: 1200W SOC: 40% -> 52%
22:30:13 INFO: 14-Dec 03:30 GMT - 14-Dec 06:00 GMT Power: 4000W SOC: 52% -> 95%
Which seemed a good plan, although it was supposed to be sunny next day, starting the day in the 90s SOC will get me through to 8pm with batteries alone.
by just after midnight it had changed to
00:20:39 INFO:
00:20:39 INFO: Optimal forced charge/discharge slots:
00:20:39 INFO: 14-Dec 02:30 GMT - 14-Dec 03:30 GMT Power: 100W SOC: 44% -> 45% <=
00:20:39 INFO: 14-Dec 03:30 GMT - 14-Dec 06:00 GMT Power: 4000W SOC: 45% -> 66%
Which doesn't add up, 1 and a half hours at 4000W should give me at least 50% more charge.
At 2:20..
02:20:38 INFO: 14-Dec 02:30 GMT - 14-Dec 03:30 GMT Power: 100W SOC: 45% -> 46% <=
02:20:38 INFO: 14-Dec 03:30 GMT - 14-Dec 06:00 GMT Power: 4000W SOC: 46% -> 68%
02:20:38 INFO: 15-Dec 04:00 GMT - 15-Dec 05:30 GMT Power: 4000W SOC: 20% -> 77%
02:20:38 INFO: 15-Dec 07:30 GMT - 15-Dec 08:30 GMT Power: 4000W SOC: 73% -> 100%
02:20:38 INFO:
At 3:30 was
03:30:38 INFO: Optimal forced charge/discharge slots:
03:30:38 INFO: 14-Dec 03:30 GMT - 14-Dec 06:00 GMT Power: 4000W SOC: 46% -> 69%
03:30:38 INFO: 15-Dec 04:00 GMT - 15-Dec 05:30 GMT Power: 4000W SOC: 20% -> 77%
03:30:38 INFO: 15-Dec 07:30 GMT - 15-Dec 08:30 GMT Power: 4000W SOC: 73% -> 100%
We had very little usage yesterday which may have confused the issue. If it charging at 4000W from 46% for 1 and a half hours does it stop at the predicted outcome, which in this case appears incorrect. So this morning I have 59% battery and it is dull outside, so could be in trouble later.
To Reproduce Could be difficult as need same weather forecast and pricing?
Expected behavior Stick to approximately same plan.
Screenshots pv_opt.log
Desktop (please complete the following information):
- OS: Widows 11
- Browser Edge
Smartphone (please complete the following information): N/A
Additional context Add any other context about the problem here.
Was OK at
00:00:24 INFO: Optimal forced charge/discharge slots:
00:00:24 INFO: 14-Dec 02:30 GMT - 14-Dec 03:30 GMT Power: 1200W SOC: 44% -> 56%
00:00:24 INFO: 14-Dec 03:30 GMT - 14-Dec 06:00 GMT Power: 4000W SOC: 56% -> 97%
But at
00:10:39 INFO: 14-Dec 02:30 GMT - 14-Dec 03:30 GMT Power: 100W SOC: 44% -> 45% <=
00:10:39 INFO: 14-Dec 03:30 GMT - 14-Dec 06:00 GMT Power: 4000W SOC: 45% -> 66%
00:10:39 INFO: 15-Dec 04:00 GMT - 15-Dec 05:30 GMT Power: 4000W SOC: 20% -> 77%
00:10:39 INFO: 15-Dec 07:30 GMT - 15-Dec 08:30 GMT Power: 4000W SOC: 73% -> 100%
00:10:39 INFO:
00:10:39 INFO: Plan time: 14-Dec 00:00 - 15-Dec 23:30 Initial SOC: 49.0 Base Cost: 430.9 Opt Cost: 295.5
Which version is this please?
Do you have the detailed logs for these periods? On 14 Dec 2024 at 12:28 +0000, Pyinthesky99 @.***>, wrote:
Was OK at 00:00:24 INFO: Optimal forced charge/discharge slots: 00:00:24 INFO: 14-Dec 02:30 GMT - 14-Dec 03:30 GMT Power: 1200W SOC: 44% -> 56% 00:00:24 INFO: 14-Dec 03:30 GMT - 14-Dec 06:00 GMT Power: 4000W SOC: 56% -> 97% But at 00:10:39 INFO: 14-Dec 02:30 GMT - 14-Dec 03:30 GMT Power: 100W SOC: 44% -> 45% <= 00:10:39 INFO: 14-Dec 03:30 GMT - 14-Dec 06:00 GMT Power: 4000W SOC: 45% -> 66% 00:10:39 INFO: 15-Dec 04:00 GMT - 15-Dec 05:30 GMT Power: 4000W SOC: 20% -> 77% 00:10:39 INFO: 15-Dec 07:30 GMT - 15-Dec 08:30 GMT Power: 4000W SOC: 73% -> 100% 00:10:39 INFO: 00:10:39 INFO: Plan time: 14-Dec 00:00 - 15-Dec 23:30 Initial SOC: 49.0 Base Cost: 430.9 Opt Cost: 295.5 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Hi Francis, Thanks for the response. pv_opt.log and the error.log are in my opening post, would you like HA or something else? home-assistant_2024-12-14T15-38-57.233Z.log I am running 3.19.0-Beta-18
That’s fine. On my phone so didn’t see them. I noticed that my optimiser was off with the very high prices. The fix I put out a couple of days ago may help with that. Basically it was still trying to use slots that were already maxed out and it ran out. Need to check wether you already had the patch when this happened On 14 Dec 2024 at 15:43 +0000, Pyinthesky99 @.***>, wrote:
Hi Francis, Thanks for the response. pv_opt.log and the error.log are in my opening post, would you like HA or something else? home-assistant_2024-12-14T15-38-57.233Z.log I am running 3.19.0-Beta-18 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
No worries, Francis
This is the current plan, which looks lightly odd especially the charge 04:30 to 21:00 at 4000w which takes us from 61% to 33%!!
So knocked off 'Include Export' and now have..
Looking at the recent cases: it seems to be a reporting issue as it's not charging 4:30 - 21:30, it's actually 4:30 to 5:30 same as the case with no export. I'll have a look at the code that does the rounding and see if there's anything obvious.
Hmmm - @stevebuk1 has added a whole load of car-related stuff to that routine so best if he has a look
@stevebuk1 - I have merged my changes to solis.py into dev on my repo. It's working fine for me but I notice that you were using hold_soc_old which I have dropped. If you need this for the EV stuff then by all means reinstate it but let's call it hold_soc_backup or similar.
FYI - dev on my repo seems to be running pretty well on my system using the Solax integration. I also want to test it using Core modbus and SolisCloud but I'm hopeful it is nearly ready to release
00:20:39 INFO: 00:20:39 INFO: Optimal forced charge/discharge slots: 00:20:39 INFO: 14-Dec 02:30 GMT - 14-Dec 03:30 GMT Power: 100W SOC: 44% -> 45% <= 00:20:39 INFO: 14-Dec 03:30 GMT - 14-Dec 06:00 GMT Power: 4000W SOC: 45% -> 66%
Which doesn't add up, 1 and a half hours at 4000W should give me at least 50% more charge.
So this one is a reporting issue. At the 00:20 optimiser run this is the charge plan from 2:30 split into half hours:
import export Solcast Solcast_p10 Solcast_p90 weighted consumption chg chg_end battery grid forced soc soc_end carslot period
2024-12-14 02:30:00+00:00 16.9785 15.0 0.0 0.0 0.0 0.000 161.976109 4211.3 4268.2 -125.054945 287.0 125 43.867708 44.460417 0 1
2024-12-14 03:00:00+00:00 16.9785 15.0 0.0 0.0 0.0 0.000 157.926706 4268.2 4325.1 -125.054945 283.0 125 44.460417 45.053125 0 1
2024-12-14 03:30:00+00:00 16.8420 15.0 0.0 0.0 0.0 0.000 153.877303 4325.1 6145.1 -4000.000000 4154.0 4000 45.053125 64.011458 0 2
2024-12-14 04:00:00+00:00 16.9785 15.0 0.0 0.0 0.0 0.000 149.827900 6145.1 6202.0 -125.054945 275.0 125 64.011458 64.604167 0 2
2024-12-14 04:30:00+00:00 16.9785 15.0 0.0 0.0 0.0 0.000 145.778498 6202.0 6258.9 -125.054945 271.0 125 64.604167 65.196875 0 2
2024-12-14 05:00:00+00:00 16.9785 15.0 0.0 0.0 0.0 0.000 141.729095 6258.9 6315.8 -125.054945 267.0 125 65.196875 65.789583 0 2
2024-12-14 05:30:00+00:00 16.9785 15.0 0.0 0.0 0.0 0.000 137.679692 6315.8 6372.7 -125.054945 263.0 125 65.789583 66.382292 0 2
Note the fact that six of the Agile slots have exactly the same price, to four decimal places. This means Pv_opt splits any high cost swaps equally between these six slots. What you actually have from 02:30 to 6:00 is
- a 125W charge from 02:30 to 03:30 (eventually rounded to 100W)
- a 4kW charge from 03:30 to 04:00
- a 125W charge from 04:00 to 06:00 (also eventually rounded to 100W)
When the above is reported as charge windows, the first 125W period is shown separately but the 4kW slot and the 2nd 125W period are shown as one window. This is because each window is displayed based on whether "period" (final column above) increments. What I've always noticed is that this period is incremented when the charge rate (power) is increased but NEVER when it is decreased, for reasons I don't understand. @fboundy I noticed this when i first coded the IOG stuff, I assume there must be a reason so I've always left it unchanged, but it would make a lot more sense if the 3 bulleted periods above were treated as 3 charge windows rather than two? Issues #263 and #271 are queries on the same feature. Was it originally there to join together charge rates that effectively were "charge to 100% and stay there" to avoid unncessary writes to the inverter? Or is it just a bug?
Thanks Steve - I’ll have a look tomorrow On 14 Dec 2024 at 20:36 +0000, fboundy/pv_opt @.***>, wrote:
rates
At 22:30 the plan was 22:30:13 INFO: Optimal forced charge/discharge slots: 22:30:13 INFO: 14-Dec 02:30 GMT - 14-Dec 03:30 GMT Power: 1200W SOC: 40% -> 52% 22:30:13 INFO: 14-Dec 03:30 GMT - 14-Dec 06:00 GMT Power: 4000W SOC: 52% -> 95% Which seemed a good plan, although it was supposed to be sunny next day, starting the day in the 90s SOC will get me through to 8pm with batteries alone. by just after midnight it had changed to 00:20:39 INFO: 00:20:39 INFO: Optimal forced charge/discharge slots: 00:20:39 INFO: 14-Dec 02:30 GMT - 14-Dec 03:30 GMT Power: 100W SOC: 44% -> 45% <= 00:20:39 INFO: 14-Dec 03:30 GMT - 14-Dec 06:00 GMT Power: 4000W SOC: 45% -> 66%
Setting aside the charge rates issue that I posted about above, there is indeed quite a big difference between the 22:30 plan (which is maintained in the the 00:00 plan), which charges you to 100% at 06:00am and the 00:10 plan which then only charges you to 66%.
The difference is that the 15th December Solar Forecast has now dropped in, which wasn't taken into account at 00:00 (nor 22:30)
Apologies @fboundy , been away :-) SolarmanV2, but you probably know that already.
@stevebuk1 - I have merged my changes to
solis.pyintodevon my repo. It's working fine for me but I notice that you were usinghold_soc_oldwhich I have dropped. If you need this for the EV stuff then by all means reinstate it but let's call ithold_soc_backupor similar.
@fboundy I kept it because in my brief time updating predbat I had a tete-a-tete with a user with a Solis inverter who commented that if hold slots were done with charge current = 0 rather than backup mode, any excess solar would go to grid rather than filling the battery. I felt he had a point, so maintained it in Dev. Not sure whats actually better for cost purposes.
As all dedicated EV holding uses current = 0 and 99% of IOG cheap rates are at night I'm fine with using current = 0 for all holding - it really only gets any possible benefit in Agile. Do you want me to convert Dev to that strategy?
*** edit - sorry you've already done it. Hadnt synced Github desktop when I wrote this.
** edit 2: Theres still a call here in Pv_opt.py:
self.inverter.hold_soc_old(enable=True, soc=self.hold[0]["soc"])
FYI -
devon my repo seems to be running pretty well on my system using the Solax integration. I also want to test it using Core modbus and SolisCloud but I'm hopeful it is nearly ready to release
Agreed, it now feels stable and I'm not actively working on any code changes. I'm on Solax so tests for core modbus and Soliscloud would be a good idea. Solarman_v2 (new repo with very different way of doing things) is Beta tested.
I think the only task left for me is the readme.md to add a section on EV charging, to explain how to use the EV charge plan generation when on Agile.
With the changes I’ve made it will be that way anyway. Would be good if you can test the dev from my repo On 14 Dec 2024 at 22:11 +0000, stevebuk1 @.***>, wrote:
@stevebuk1 - I have merged my changes to solis.py into dev on my repo. It's working fine for me but I notice that you were using hold_soc_old which I have dropped. If you need this for the EV stuff then by all means reinstate it but let's call it hold_soc_backup or similar. @fboundy I kept it because in my brief time updating predbat I had a tete-a-tete with a user with a Solis inverter who commented that if hold slots were done with charge current = 0 rather than backup mode, any excess solar would go to grid rather than filling the battery. I felt he had a point, so maintained it in Dev. Not sure whats actually better for cost purposes. As all dedicated EV holding uses current = 0 and 99% of IOG cheap rates are at night I'm fine with using current = 0 for all holding - it really only gets any benefit in Agile. Do you want me to convert Dev to that strategy? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Ah, ok. In which case could you try the dev branch from the main repo rather than Steve’s fork? I’ve re-factored all the Solis control to a cleaner setup. I can test all the other modes but not solarman as my (3!) data sticks are all too new to support it. On 14 Dec 2024 at 22:04 +0000, Pyinthesky99 @.***>, wrote:
Apologies @fboundy , been away :-) SolarmanV2, but you probably know that already. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Ah, ok. In which case could you try the dev branch from the main repo rather than Steve’s fork? I’ve re-factored all the Solis control to a cleaner setup. I can test all the other modes but not solarman as my (3!) data sticks are all too new to support it.
No problem. I'm doing all development in the main repo now, but still then merging to my fork just to give me an easily accessible release archive.
Theres still a call here in Pv_opt.py:
self.inverter.hold_soc_old(enable=True, soc=self.hold[0]["soc"])
I'll correct and test tomorrow,
Setting aside the charge rates issue that I posted about above, there is indeed quite a big difference between the 22:30 plan (which is maintained in the the 00:00 plan), which charges you to 100% at 06:00am and the 00:10 plan which then only charges you to 66%.
The difference is that the 15th December Solar Forecast has now dropped in, which wasn't taken into account at 00:00 (nor 22:30)
Hi Steve That's slightly curious, the forecast for the 15th was a lot worse than Saturday 14th, I think it was over 4 for Saturday and just over 1 for today. Perhaps last nights cheaper rates had something to do with it. Regards Alan
I mean that until 00:10, it hasn't loaded any solar data for the 15th, so the battery charging plan was based on solar for the 14th only.
On Sun, 15 Dec 2024, 11:10 Pyinthesky99, @.***> wrote:
Setting aside the charge rates issue that I posted about above, there is indeed quite a big difference between the 22:30 plan (which is maintained in the the 00:00 plan), which charges you to 100% at 06:00am and the 00:10 plan which then only charges you to 66%.
The difference is that the 15th December Solar Forecast has now dropped in, which wasn't taken into account at 00:00 (nor 22:30)
Hi Steve That's slightly curious, the forecast for the 15th was a lot worse than Saturday 14th, I think it was over 4 for Saturday and just over 1 for today. Perhaps last nights cheaper rates had something to do with it. Regards Alan
— Reply to this email directly, view it on GitHub https://github.com/fboundy/pv_opt/issues/321#issuecomment-2543829423, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASVRJMCJ2JGT75IG4WMX4XT2FVPRLAVCNFSM6AAAAABTTOBHPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBTHAZDSNBSGM . You are receiving this because you were mentioned.Message ID: @.***>
I mean that until 00:10, it hasn't loaded any solar data for the 15th, so the battery charging plan was based on solar for the 14th only.
My thinking was if Sunday's Solar was going to worse than Saturday's, why reduce the charge? It worked out OK in the end as the sun finally peeped out just before lunchtime on Saturday and gassed up the batteries.
Ah, ok. In which case could you try the dev branch from the main repo rather than Steve’s fork? I’ve re-factored all the Solis control to a cleaner setup. I can test all the other modes but not solarman as my (3!) data sticks are all too new to support it.
No problem. I'm doing all development in the main repo now, but still then merging to my fork just to give me an easily accessible release archive.
You'll see that I've changed the structure of solis.py to get rid of all the ifs and use class inheritance instead.
Ah, ok. In which case could you try the dev branch from the main repo rather than Steve’s fork? I’ve re-factored all the Solis control to a cleaner setup. I can test all the other modes but not solarman as my (3!) data sticks are all too new to support it.
Interesting @fboundy what you say about Dataloggers, mine is a cheap looking silver effort with no visible LEDs, except you can see a green glow in the area of the antenna connector in complete darkness. As far as I know it is a DLS-W which according to https://usservice.solisinverters.com/support/solutions/articles/73000593957-solis-data-loggers-explained does not support settings changes and only one inverter. I have found this, possibly a more likely candidate,, https://www.amazon.co.uk/dp/B0BTT1WCBV?tag=ceukreviews9056831-21&linkCode=ogi&th=1&psc=1 which says supports multiple inverters. It looks much the same as mine except for the RJ45 looking connector at the antenna end, but it looks to me as if they have mixed pics for both WiFi and ethernet versions. My solar install was by a group purchase scheme so it is possible the supplier bought a bunch of the cheapest available. Regards Alan
The Amazon add is confusing. The photos are of DLS-L and DLS-W’s or clones of them. These are both pretty old and no longer supported by Solis as far as I know.
This summarises the various Datalogger models: https://github.com/fboundy/ha_solis_overview On 15 Dec 2024 at 21:12 +0000, Pyinthesky99 @.***>, wrote:
Ah, ok. In which case could you try the dev branch from the main repo rather than Steve’s fork? I’ve re-factored all the Solis control to a cleaner setup. I can test all the other modes but not solarman as my (3!) data sticks are all too new to support it. Interesting @fboundy what you say about Dataloggers, mine is a cheap looking silver effort with no visible LEDs, except you can see a green glow in the area of the antenna connector in complete darkness. As far as I know it is a DLS-W which according to https://usservice.solisinverters.com/support/solutions/articles/73000593957-solis-data-loggers-explained does not support settings changes and only one inverter. I have found this, possibly a more likely candidate,, https://www.amazon.co.uk/dp/B0BTT1WCBV?tag=ceukreviews9056831-21&linkCode=ogi&th=1&psc=1 which says supports multiple inverters. It looks much the same as mine except for the RJ45 looking connector at the antenna end, but it looks to me as if they have mixed pics for both WiFi and ethernet versions. My solar install was by a group purchase scheme so it is possible the supplier bought a bunch of the cheapest available. Regards Alan — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
I guess you can add Solarman_ha (PV_OPT SolarmanV2) to your list! I am still not convinced mine is an official DLS-W due to the lack of LEDs.
You'll see that I've changed the structure of
solis.pyto get rid of all theifs and use class inheritance instead.
Much neater! I see you've got rid of the errant hold_soc_old call as well. I've installed on my system without any issues (I did a push of some comment tidyups but no code changes), will run it over the next few days.
My thinking was if Sunday's Solar was going to worse than Saturday's, why reduce the charge? It worked out OK in the end as the sun finally peeped out just before lunchtime on Saturday and gassed up the batteries.
There is certainly something strange going on.
The 00:00 plan reports this:
00:00:23 INFO: Optimisation Summary
00:00:23 INFO: --------------------
00:00:23 INFO:
00:00:23 INFO: Base cost: 444.7p
00:00:24 INFO: Optimised cost (Optimised Charging): 292.1p
00:00:24 INFO: Optimised cost (Optimised PV Export): 292.1p <=== Current Setup
00:00:24 INFO: Optimised cost (Forced Discharge): 292.1p
The 00:10 plan reports this:
00:10:39 INFO: Optimisation Summary
00:10:39 INFO: --------------------
00:10:39 INFO:
00:10:39 INFO: Base cost: 430.9p
00:10:39 INFO: Optimised cost (Optimised Charging): 344.2p
00:10:39 INFO: Optimised cost (Optimised PV Export): 295.5p <=== Current Setup
00:10:39 INFO: Optimised cost (Forced Discharge): 295.5p
Whilst there is only 3pish difference between the two "Current Setup" plans (and I can believe this - the extra charging you had at 00:00 mostly covers off slots which will be at the same price once round trip losses are taken into account), I don't understand the large disparity between the two "(Optimised Pricing)" costs.
The 00:00 plan makes sense. The Optimised Pv Export plan is the same price as the Optimised Charging plan, which you'd expect as the Optimised Pv Export plan doenst actually involve any exporting.
The 00:10 plan doesn't make sense. The Optimised Pv Export plan is cheaper than as the Optimised Charging plan, but it shouldn't be as the Optimised Pv Export plan again doesn't actually involve any exporting.
Unfortunately whilst I have lots of detail on whatever is the "<===== Current Setup", I have none on the others as all that is logged is the cost value above. I'll see what I can elicit.
I've made some changes to the optimiser logic recently. Is this still a problem with 4.0.5?
Hi Francis I am still running on 3.19.0-Beta-18 but am more than happy to move to 4.0.5 if advised. The problem may be difficult to reproduce as happened under a certain circumstance, @stevebuk1 was doing some digging, as per his last post.
Hi Alan, you can now move to v4.0.5 - all the development work done in the Beta releases is now part of the main production release.
You can use HACS to do the upgrade, noting you may need to do two upgrades to get to V4.0.5 (I did).
I'm still looking at the logs you previously provided. I now understand why the Optimised Pv Export plan is cheaper than the Optimised Charging plan. I think its simply that the 00:10 plan used a very slightly different starting SOC, and whilst the charging plan result was quite different, the cost was not.