Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Possible Incorrect Resulting SOC #321

Open
Pyinthesky99 opened this issue Dec 14, 2024 · 27 comments
Open

Possible Incorrect Resulting SOC #321

Pyinthesky99 opened this issue Dec 14, 2024 · 27 comments

Comments

@Pyinthesky99
Copy link

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

error.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.
@Pyinthesky99
Copy link
Author

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

@fboundy
Copy link
Owner

fboundy commented Dec 14, 2024 via email

@Pyinthesky99
Copy link
Author

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

@fboundy
Copy link
Owner

fboundy commented Dec 14, 2024 via email

@Pyinthesky99
Copy link
Author

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%!!
image

So knocked off 'Include Export' and now have..
image

pv_opt.log

@fboundy
Copy link
Owner

fboundy commented Dec 14, 2024

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.

@fboundy
Copy link
Owner

fboundy commented Dec 14, 2024

Can you remind me what integration you use to control your inverter?

@fboundy
Copy link
Owner

fboundy commented Dec 14, 2024 •
edited
Loading

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

@stevebuk1
Copy link
Collaborator

stevebuk1 commented Dec 14, 2024 •
edited
Loading

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?

@fboundy
Copy link
Owner

fboundy commented Dec 14, 2024 via email

@stevebuk1
Copy link
Collaborator

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)

@Pyinthesky99
Copy link
Author

Apologies @fboundy , been away :-)
SolarmanV2, but you probably know that already.

@stevebuk1
Copy link
Collaborator

stevebuk1 commented Dec 14, 2024 •
edited
Loading

@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 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"])

@stevebuk1
Copy link
Collaborator

stevebuk1 commented Dec 14, 2024 •
edited
Loading

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

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.

@fboundy
Copy link
Owner

fboundy commented Dec 14, 2024 via email

@fboundy
Copy link
Owner

fboundy commented Dec 14, 2024 via email

@stevebuk1
Copy link
Collaborator

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.

@stevebuk1
Copy link
Collaborator

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,

@Pyinthesky99
Copy link
Author

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

@stevebuk1
Copy link
Collaborator

stevebuk1 commented Dec 15, 2024 via email

@Pyinthesky99
Copy link
Author

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.

@fboundy
Copy link
Owner

fboundy commented Dec 15, 2024

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.

@Pyinthesky99
Copy link
Author

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

@fboundy
Copy link
Owner

fboundy commented Dec 15, 2024 via email

@Pyinthesky99
Copy link
Author

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.

IMG_0925 1

@stevebuk1
Copy link
Collaborator

You'll see that I've changed the structure of solis.py to get rid of all the ifs 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.

@stevebuk1
Copy link
Collaborator

stevebuk1 commented Dec 15, 2024 •
edited
Loading

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@fboundy @stevebuk1 @Pyinthesky99