Unexpected error in worker for App pv_opt - charge slots not optimal

[solarjones]

PV Opt v3.8.12

Think there's still a bug lurking somewhere as the optimised charge plan wasn't optimal (maybe it was but represented differently compared to the one below?):

I reloaded OE integration, tried to nudge PV_OPT by toggling between readonly and normal modes but the plan remained the same. Next I restarted AppDaemon which aligned to cheapest slots.

I can see some errors, but that was from last night. Perhaps it caused the above issue?

pv_opt.log
main.log
error.log

Thanks.

[fboundy]

Do you have the pv_opt.log from 22:30 when the error occurred?

AppDaemon failed to return recent SOC data which is what caused the error in error.log and I suspect this may have stopped it loading correct tariffs after that.

[solarjones]

1pv_opt.log

[solarjones]

v3.8.14 downloaded at about 15:30, restarted AP.

Doesn't look like it picked up the OE slots correctly. No errors.

Restarted AD.

Looks ok.

However, (and this isn't specific to this version as I noticed this morning) I don't think the PV forecast has been taken into consideration, 26 kWh tomorrow! :) My projected consumption is lowish.

Also toggled between consumption history and fixed. It changed the charge plan by always resulted with 100% SOC around 6am.

pv_opt.log
main.log
error.log

Thanks

[fboundy]

In 3.9.0 I've added a feature to compare the pv_opt tariffs with those from the Octopus Energy automation (so long as you have octopus_auto set to true). At the moment all it does is flag if they are different and also populate a sensor called sensor.pvopt_tariff_import_OK with True or `False'. This should at least help identify when there is a problem and, hopefully, eventually track down the source.

[solarjones]

In 3.9.0 I've added a feature to compare the pv_opt tariffs with those from the Octopus Energy automation (so long as you have octopus_auto set to true). At the moment all it does is flag if they are different and also populate a sensor called sensor.pvopt_tariff_import_OK with True or `False'. This should at least help identify when there is a problem and, hopefully, eventually track down the source.

Ok, I'll try 3.9.0. Is this correct?

What do you think about the PV forecast & SOC with the charge plan?

Thanks

[fboundy]

In 3.9.0 I've added a feature to compare the pv_opt tariffs with those from the Octopus Energy automation (so long as you have octopus_auto set to true). At the moment all it does is flag if they are different and also populate a sensor called sensor.pvopt_tariff_import_OK with True or `False'. This should at least help identify when there is a problem and, hopefully, eventually track down the source.

Ok, I'll try 3.9.0. Is this correct?

What do you think about the PV forecast & SOC with the charge plan?

Thanks

You should be able to comment it all out as octopus_auto: true is the default

[fboundy]

What do you think about the PV forecast & SOC with the charge plan?
Thanks

I think that's correct. Mine is similar. There are some marginal benefits from charging at <15p and exporting at 15p. My cost saving for tomorrow is only 20p though. If you increase the two thresholds (per slot and per pass) it will probably reduce the amount of forced charging.

[fboundy]

You can see it is reading the Solcast OK because the "Initial SOC" curve reaches 100%.

You can also check that it is reading the forecast correctly by switching to the Solcast_p10 forecast in which case it should charge more and not get to such a high SOC:

[solarjones]

I'd been using the Solcast default (p50?), so have now switched to P10.

Thanks.

[fboundy]

v3.8.14 downloaded at about 15:30, restarted AP.

Doesn't look like it picked up the OE slots correctly. No errors.

One thing I don't understand in your comparison is that Octopus don't release the next day's tariffs until ~16.00 so when I look at the log file for 15.30 PV_Opt doesn't have them - it is using a guesstimate based on the published wholesale day-ahead prices which is only hourly so it won't be 100% correct. Once the Octopus prices are available (after 16.30) it all looks OK.

[fboundy]

I'd been using the Solcast default (p50?), so have now switched to P10.
Thanks.

This will be more conservative in that it's likely you will charge your battery more than you needed to but you are very unlikely to charge too little.

[fboundy]

3.9.1 tidies up a few things related to these marginal charging slots and makes it less likely to charge unnecessarily,

[solarjones]

3.9.2
I've got some more errors and just checked the charging plan, which doesn't look like its updated or got he OE slots correct.

Restarting AppD, and the charging plan looks correct now.

Logs:
pv_opt.log
main.log
error.log
1pv_opt.log

Just noticed you have version 3.9.3, I'll update to this. Does this have any changes in this area?

Thanks.

[fboundy]

Yes 3.9.3 should fix this

…

On 25 Feb 2024 at 17:48 +0000, solarjones ***@***.***>, wrote: 3.9.2 I've got some more errors and just checked the charging plan, which doesn't look like its updated or got he OE slots correct. image.png (view on web) Restarting AppD, and the charging plan looks correct now. image.png (view on web) Logs: pv_opt.log main.log error.log 1pv_opt.log Just noticed you have version 3.9.3, I'll update to this. Does this have any changes in this area? Thanks. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[solarjones]

v3.9.3
Unexpected error in worker for App pv_opt:

pv_opt.log
main.log
error.log

[fboundy]

Added a check on this in 3.9.4

[fboundy]

Think I may have finally found the root cause! Please check out 3.9.5

[solarjones]

Happy to report a lovely stable version for me, zero errors and good time slots! Truly very grateful for you being so responsive and what a brilliant optimiser!