Open mpartington opened 1 week ago
So looking at the logfile the system is set at AC Coupled, so charging from grid and charging from solar will have exactly the same losses.
This means really charging >15.0 is wrong and <=15.0 is the same or cheaper?
In your screenshot you show a 15.88p charge which seems to arrive at 11:15 (it wasn't there at 11:00). I'm wondering if the problem relates to when the potential period has already started.
Can you try to capture this again with debug enabled?
Notice the simulation things there is no extra import which is odd
024-06-21 11:15:33.590664: [ 11:15, 11:30, 12:00, 12:30, 13:00, 13:30, 14:00, 14:30, 15:00, 15:30, 16:00, 16:30, 17:00, 17:30, 18:00, 18:30, 19:00, 19:30, 20:00, 20:30, 21:00, 21:30, 22:00, 22:30, 23:00, 23:30, 00:00, 00:30, 01:00, 01:30, 02:00, 02:30, 03:00, 03:30, 04:00, 04:30, 05:00, 05:30, 06:00, 06:30, 07:00, 07:30, 08:00, 08:30, 09:00, 09:30, 10:00, 10:30, 11:00, 11:30, 12:00, 12:30, 13:00, 13:30, 14:00, 14:30, 15:00, 15:30, 16:00, 16:30, 17:00, 17:30, 18:00, 18:30, 19:00, 19:30, 20:00, 20:30, 21:00, 21:30, 22:00, 22:30, 23:00, 23:30, 00:00, 00:30, 01:00, 01:30, 02:00, 02:30, 03:00, 03:30, 04:00, 04:30, 05:00, 05:30, 06:00, 06:30, 07:00, 07:30, 08:00, 08:30, 09:00, 09:30, 10:00, 10:30]
2024-06-21 11:15:33.591442: SOC: [ 6.77, 6.85, 7.64, 8.26, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.32, 8.2, 8.03, 7.84, 7.62, 7.42, 7.25, 7.09, 6.97, 6.83, 6.69, 6.52, 6.35, 6.34, 6.33, 7.77, 8.29, 8.28, 8.35, 8.35, 8.35, 8.35, 8.21, 8.14, 8.16, 8.24, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.27, 8.04, 7.81, 7.59, 7.38, 7.2, 7.03, 6.87, 6.69, 6.49, 7.88, 8.3, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35, 8.35]
2024-06-21 11:15:33.592053: BAT: [ g>bf+, g~be+, g<bf+, g>be+, g>be+, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-, g<be-, g<be-, g<bf+, g<bf+, g<be-, g<bf+, g<bf+, g<bf+, g<bf+, g~be-, g~be+, g~be+, g~be+, g~be+, g>be+, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g>be~, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-, g<bf+, g<bf+, g<bf+, g<bf+, g<bf+, g<bf+, g<bf+, g<bf+, g<bf+, g<bf+, g<bf+, g<bf+, g>bf+, g>bf+, g>bf+, g>be~, g>be~, g>be~, g>be~]
2024-06-21 11:15:33.592833: LOAD: [ 3.2, 3.29, 3.46, 3.64, 3.83, 4.03, 4.23, 4.42, 4.61, 4.81, 5.02, 5.24, 5.48, 5.72, 5.96, 6.18, 6.37, 6.55, 6.71, 6.88, 7.06, 7.24, 7.45, 7.62, 7.78, 7.92, 8.04, 8.16, 8.29, 8.45, 8.61, 8.78, 8.95, 9.09, 9.22, 9.36, 9.5, 9.68, 9.88, 10.1, 10.33, 10.56, 10.77, 10.96, 11.12, 11.28, 11.44, 11.6, 11.78, 11.97, 12.17, 12.38, 12.6, 12.82, 13.05, 13.27, 13.5, 13.73, 13.97, 14.22, 14.48, 14.76, 15.01, 15.26, 15.49, 15.7, 15.89, 16.09, 16.29, 16.51, 16.73, 16.93, 17.12, 17.29, 17.43, 17.59, 17.75, 17.93, 18.13, 18.33, 18.52, 18.7, 18.86, 19.0, 19.18, 19.38, 19.6, 19.84, 20.09, 20.34, 20.56, 20.77, 20.95, 21.12, 21.29, 21.44]
2024-06-21 11:15:33.593598: PV: [ 2.7, 3.18, 4.2, 5.33, 6.56, 7.86, 9.15, 10.42, 11.69, 12.89, 13.98, 14.93, 15.74, 16.41, 16.95, 17.38, 17.74, 18.0, 18.16, 18.21, 18.24, 18.25, 18.25, 18.25, 18.25, 18.25, 18.25, 18.25, 18.25, 18.25, 18.25, 18.25, 18.25, 18.25, 18.25, 18.25, 18.25, 18.26, 18.29, 18.35, 18.46, 18.63, 18.87, 19.15, 19.47, 19.85, 20.32, 20.85, 21.41, 22.04, 22.71, 23.46, 24.32, 25.29, 26.34, 27.41, 28.43, 29.42, 30.38, 31.32, 32.25, 33.14, 33.98, 34.74, 35.41, 35.96, 36.4, 36.67, 36.8, 36.82, 36.82, 36.82, 36.82, 36.82, 36.82, 36.82, 36.82, 36.82, 36.82, 36.82, 36.82, 36.82, 36.82, 36.82, 36.82, 36.84, 36.88, 36.94, 37.02, 37.14, 37.31, 37.52, 37.79, 38.15, 38.62, 39.16]
2024-06-21 11:15:33.594354: IMPORT: [ 0.7, 0.7, 0.7, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.79, 0.95, 1.11, 2.79, 3.47, 3.61, 3.82, 3.98, 4.15, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 4.32, 5.99, 6.64, 6.88, 7.06, 7.22, 7.37, 7.54, 7.73, 7.91, 8.09, 8.26, 8.39, 8.46, 8.48, 8.48, 8.48, 8.48, 8.48]
2024-06-21 11:15:33.595117: EXPORT: [ 0.0, 0.29, 0.29, 0.66, 1.57, 2.64, 3.69, 4.73, 5.77, 6.74, 7.58, 8.28, 8.84, 9.24, 9.52, 9.72, 9.88, 9.95, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.96, 9.99, 10.21, 10.5, 10.85, 11.22, 11.64, 12.09, 12.6, 13.22, 13.93, 14.73, 15.55, 16.31, 17.03, 17.72, 18.39, 19.03, 19.63, 20.18, 20.66, 21.09, 21.42, 21.65, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.71, 21.72, 21.74, 21.81, 22.0, 22.28, 22.66]
2024-06-21 11:15:33.595890: CARBON: [ 47.84, 36.88, 40.3, 21.01, -20.39, -65.02, -109.18, -152.91, -196.46, -238.23, -275.32, -310.74, -338.77, -361.66, -377.56, -388.5, -396.83, -400.93, -400.93, -400.93, -400.93, -400.93, -400.93, -400.93, -400.93, -400.93, -400.93, -400.93, -400.93, -400.93, -399.76, -384.48, -346.38, -204.32, -158.23, -142.34, -125.66, -111.34, -96.41, -82.85, -82.85, -82.85, -82.85, -82.85, -87.6, -104.88, -126.54, -149.65, -174.16, -198.89, -225.91, -254.84, -288.11, -319.83, -354.39, -387.76, -419.12, -451.5, -483.16, -517.96, -551.71, -585.05, -615.21, -637.95, -657.61, -673.38, -683.84, -686.11, -686.11, -686.11, -686.11, -686.11, -686.11, -686.11, -686.11, -686.11, -686.11, -674.99, -611.06, -587.65, -578.84, -569.47, -560.97, -551.82, -541.23, -526.82, -512.14, -494.94, -479.42, -465.78, -460.21, -461.25, -471.69, -493.84, -526.67, -572.28]
2024-06-21 11:15:33.596644: CAR0: [ 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77, 45.77]
2024-06-21 11:15:33.597374: METRIC: [ 63.52, 59.15, 59.15, 54.94, 41.24, 25.23, 9.44, -6.17, -21.77, -36.21, -48.86, -59.07, -67.09, -72.96, -77.07, -79.96, -82.2, -83.29, -83.37, -83.37, -83.37, -83.37, -83.37, -83.37, -83.37, -83.37, -83.37, -31.06, -31.06, -31.06, -31.06, -28.76, -26.55, -5.18, 3.61, 5.59, 8.66, 11.22, 13.99, 16.53, 16.53, 16.53, 16.53, 16.53, 16.11, 12.72, 8.35, 3.11, -2.45, -8.62, -15.38, -23.14, -32.4, -43.1, -54.96, -67.31, -78.7, -89.56, -99.94, -109.58, -118.89, -127.51, -135.51, -142.56, -148.7, -153.48, -156.95, -157.89, -157.89, -157.89, -157.89, -157.89, -157.89, -157.89, -157.89, -105.58, -105.58, -105.58, -77.3, -68.06, -64.79, -62.5, -60.47, -58.2, -55.77, -52.82, -49.83, -46.94, -44.12, -41.85, -40.81, -40.67, -41.82, -44.59, -48.8, -54.44]
I think I might know the issue, the battery level is report at 81% and the charge is to 82% so thats 0.81 x 8.35 = 6.7345 0.82 x 8.35 = 6.8470
Total charge 0.1125 kWh in a 5 minute period PV is 0.48 in a 15 minute period which is 0.16 kwh
Thus when computed for the next 5 minutes the PV exceeds the charge amount and no import occurs.
Of course in reality the charge rate is 3kW while the PV is 1.92kW and import occurs.
What's not clear is why the calculation shows any benefit from the charge when in reality it should have been neutral and hence not selected, only the debug logs will tell us that.
Thanks for looking, will try and capture debug next time. It doesn't happen often, but odd a few of us saw it today. The chap who was charging at 24p is.a bit more of a mystery.
Yes, AC3 for me, so nice and easy to compare
Will.have to try and catch it as it's happening, as debug will soon fill up the log files
Potential fix on main to test
Potential fix on main to test
Thanks. I've installed it, will keep an eye on it today, but prices much higher this morning. Might be difficult to confirm a fix )as I'm unsure of the trigger conditions) and have to go on the basis the change doesn't break anything
Potential fix on main to test
Tried it and it crashes ☹️
Saw the similar pattern of charging at a rate higher than the export rate:
This was on v8.0.0
Turned on debug, and predbat showed another issue I have intermittently seen, that of Discharging to then re-Charge the battery. This doesn't make sense, the discharge and recharge will incur the conversion losses and given my export rate is flat 15p, isn't worthwhile.
Anyway, debug on so you can at least see it:
Upgraded to main (8.1.1) and predbat crashes:
2024-06-23 09:05:08.423135 INFO pred_bat: Calculate Best options: mode(Control charge & discharge) calculate_discharge_oncharge(False) set_discharge_freeze_only(False) set_discharge_during_charge(False) combine_charge_slots(False) combine_discharge_slots(False) combine_rate_threshold(0.0) best_soc_min(0.0 kWh) best_soc_max(0.0 kWh) best_soc_keep(0.5 kWh) inverter_loss(4 %) battery_loss(5 %) battery_loss_discharge (5 %) inverter_hybrid(True) metric_min_improvement(0.0 p) metric_min_improvement_discharge(1.0 p) metric_battery_cycle(0.0 p/kWh) metric_battery_value_scaling(1.0 x)
2024-06-23 09:05:08.424653 INFO pred_bat: Error: Exception raised unsupported operand type(s) for +=: 'float' and 'NoneType'
2024-06-23 09:05:08.426406 INFO pred_bat: Error: Traceback (most recent call last):
File "/homeassistant/appdaemon/apps/batpred/predbat.py", line 11051, in run_time_loop
self.update_pred(scheduled=True)
File "/homeassistant/appdaemon/apps/batpred/predbat.py", line 9889, in update_pred
recompute = self.calculate_plan(recompute=recompute)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/homeassistant/appdaemon/apps/batpred/predbat.py", line 8155, in calculate_plan
self.optimise_all_windows(metric, metric_keep)
File "/homeassistant/appdaemon/apps/batpred/predbat.py", line 6796, in optimise_all_windows
window_sorted, window_index, price_set, price_links = self.sort_window_by_price_combined(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/homeassistant/appdaemon/apps/batpred/predbat.py", line 6383, in sort_window_by_price_combined
average += self.metric_self_sufficiency
TypeError: unsupported operand type(s) for +=: 'float' and 'NoneType'
2024-06-23 09:05:08.453370 INFO pred_bat: Info: record_status Error: Exception raised unsupported operand type(s) for +=: 'float' and 'NoneType'
Reverting back to v8.0.0
Logfiles covering this period: appdaemon.log.3.txt appdaemon.log.2.txt appdaemon.log.1.txt
Did not see the charging issue yesterday, but keeps trying to charge this morning.
Odd, shows the benefit of multiple users testing. I ran it all night and no errors whatsoever.
I've also seen the issue of a forced discharge followed by charge. Or alternatively a solar charge, followed by a discharge (whereas freeze discharge would be better to save losses). AC coupled
Update: I tried again to upgrade to main (now calls itself 8.1.2). Same error, crashes with float conversion in optimise_all_windows at 20:26. Subsequent run at 20:30 also crashed same place.
Restarted AppDaemon and that cured the crashing problem, predbat running fine now.
I will see if we get any more examples of grid charging at higher rate or discharge then recharge with this version on main
Logfile: appdaemon.log.1.txt
Adding logs just in case this suggests an issue. I suspect all is OK and it's just hedging bets as the in day prices are so high
I was running 8.1.2 off main and wasn't expecting any grid charge last night, but as you can see from the plots it did. Now it was only around 15.5p, so hardly any difference to using solar, I wonder if it's being influenced by the PV_10 model (if so that is fine)
However I also see the same thing happening on the repeated rates tomorrow evening, but its charging at above 16p. So I'm starting to question is this a bug, or just insurance against PV_10. This plan has already changed 3 times, so doesn't seem very stable.
Also realise it will almost certainly change before then, but I've captured some debug around 06.07
And the test to disable PV10, makes little difference
However I also see the same thing happening on the repeated rates tomorrow evening, but its charging at above 16p. So I'm starting to question is this a bug, or just insurance against PV_10. This plan has already changed 3 times, so doesn't seem very stable.
Last night I had similar, the plan showed import rates just above the 15p export rate and Predbat planned to do freeze charging for most of the night so would grid import to cover house load.
At some point it changed to just run off the batteries and I saw the SoC continue to drop overnight and no grid import occurred
Tonight's forecast plan with repeated rates is showing no grid import either:
My assumption for the grid import was that with the rates just over 15p export rate, by the time battery & inverter losses are included when discharging and recharging the battery, it would be just as beneficial to hold the charge level. I've seen this before. But doesn't explain why the plan is unstable and changes from Freeze Charging to Eco - would have thought the plan is the plan and it stays constant. Don't think it's affected by PV10 as this is overnight it occurs. Next day I have way more solar generation than is needed to refill the battery regardless of PV10
After updating to v8.1.1 did not force charge from grid this morning, but also looks to have reduced the force charging at 2am.
Similar behaviour this morning on main (8.1.2), discharging then recharging the battery, incurring losses in both directions, and charge rate higher than export:
Log with debug turned on:
@springfall2008 I think I may have worked out why Predbat keeps planning what seem like unnecessary discharges and recharges of the battery.
Tomorrow being a case in point, blended PV generation is > 4kW for the morning and lunchtime slots, so why is Predbat planning discharge and solar recharge and lowering the battery SoC to then grid charge it at 12p when my export is fixed at 15p? Inverter capacity is 2.6kW per half hour slot so there's no way to take advantage of the low charge rate anyway.
Similar behaviour occurred yesterday with cheap agile rates, Predbat wanted to discharge the battery to grid recharge at low rate but predicted solar was such that it would recharge off solar.
I believe these unwarranted behaviours are due to the PV10 cloud model and the Load10 modulation model. If you look at the headline PV estimation and Load estimation there is no financial benefit at all of discharging then recharging.
But if you look at the worst case PV10% and Load 10% figures, much reduced solar and increased load mean it is worthwhile discharging and recharging if those worst cases come true - which is unlikely
So question is how to get Predbat to take the more 'middle of the road' forecast rather than assume the worst and discharge unnecessarily. Its only beneficial if the worst does come true, and if it doesn't, it's a poor plan as extra battery losses incurred due to the discharge and charge
Update: further testing has confirmed its the cloud PV model that is causing this behaviour. Turning switch.predbat_metric_cloud_enable off and the plan has no such discharging and recharging:
Turning switch.metric_load_divergence_enable off made no impact to the plan
Describe the bug As requested, a couple of us have experienced grid charging when the import rate is higher than the value of export. In this case it would have been more efficient to have just charged from solar. In my case I forced the slot to Idle, (11am) but it resumed grid charging the next slot (11.30).
I can confirm on both cases Grid was actually being used to charge the battery
Expected behavior Choose most cost efficient charge source
Predbat version
8.1.0
Environment details
Screenshots![Screenshot_2024-06-21-13-29-47-741_com facebook katana](https://github.com/springfall2008/batpred/assets/106986397/7ddd262e-cff4-4dd2-8535-97be4b19ed6f)
Log file predbat1.log