springfall2008/batpred

Home battery prediction and charging automation for Home Assistant, supporting many inverter types

Predbat

Introduction

Home battery prediction and automatic charging for Home Assistant supporting multiple inverters including GivEnergy, Solis, Huawei, SolarEdge and Sofar.

Also known by some as Batpred or Batman!

If you want to buy me a beer then please use Paypal - [email protected]

Predbat documentation

You can find the latest Predbat documentation at https://springfall2008.github.io/batpred/ and how-to videos on my YouTube channel.

The documentation covers how Predbat works, how to get it installed and configured, video tutorials and FAQs to help you get going. It also explains how you can contribute to the project.

Support

For support please raise a Github ticket or use the Facebook Group: Predbat

Some inverters have their own groups also e.g:

• GivTCP
• Solis

Copyright (c) Trefor Southwell 2024 - All rights reserved
This software maybe used at no cost for personal use only.
No warranty is given, either expressed or implied.

batpred's Issues

set_window_notify sends notifications to all phones [feature request]

When set_window_notify (also set_discharge_notify, set_soc_notify, set_reserve_notify) are set to True, Home Assistant will send a notification to any phones with the companion app installed. This is fine and useful for me, but my SO doesn't need to know the ins and outs of battery charging. It would be great to have section in apps.yaml to configure which devices receive the notification, instead of all-or-nothing

0% Error

When batteries are over voltage and go from 100% to 0% SoC due to a bug in GE's reporting. BatPred misscalculates SoC targets as it thinks there is less battery capacity.

Saw this today on a 2 * 5.2 setup, where first one battery "faulted" and only 4.2kws was used for calcs, then when my second one over voltaged it went up to 5.1 for some reason.

I Know GE were meant to fix this at some point in the future. But not sure what update its in.

Setting discharge window is resetting Force Discharge to False

I have noticed that if it is currently within the discharge window, and the recalc wants to update the start or end time, sending that instruction to GivTCP appears to disable Force Discharge. This means the invertor stops exporting until the next recalc cycle at which point the Force Discharge setting is re-enabled.
This is similar to something I recall happening when I was hand rolling automations for charging/discharging so it could be the result of a GivTCP bug but if batpred checked, and updated if necessary, the Force Discharge setting after the discharge window has been set the impact would be minimised.

Alternatively, would it be worth separating the optimisation and actions (setting the correct values) into separate loops? This would mean you could rerun the calculations at a lower frequency, but have a higher frequency loop to check the values match the output of the last optimisation. The log currently seems to occaionally have workarounds for different bugs logged out which this could also take out of the optimisation loop.

README improvement: Adding info to help others to contribute

Hi, I think it'd be good to update the README with some info to help others to contribute, if you're up for them doing that.

Things like:

• Getting a development environment set up, including with the right Python version, required libraries (and library versions) etc.
• Any preferences you have for people contributing, creating pull requests etc.
• Any standards or approaches you want people to follow
• Anything else they'd need to know to be able to work on the code

There may be other things, but they're what came to mind.

Scheduling re-evaluation at the start of next window

This is a suggestion rather than specifically an issue.

I have noticed that for due to the periodic scheduling of batpred, you can miss out on part of your discharge window because both the window and the force discharge need to be set. The window can be set in advance but the force discharge can only be set by the first scheduled run within the discharging window, so in the worst case you will miss out on discharging for period equal to your recalc period length.

What would be nice is if the next scheduled recalc is after the start of the discharge window, that a recalc is specifically scheduled to run at the start of the discharge window, or potentially a specific task to enable force discharge.

This would mean that the usual recalc loop could be performed at a much lower frequency (every 30 mins) without the loss of export time.

New feature - add option to stop discharge when a car is charging

Some users would like to hold discharge of the battery when their car charges, add this as an option

Odd discharge pattern with IO

Hi @springfall2008

I followed your guide and video on setting up IO having switched from Flux, and have therefore set my settings as per https://github.com/springfall2008/batpred#cheap-night-rate-with-a-good-export-rate-eg-intelligent-with-octopus-outgoing

I kinda expected that predbat would schedule export at the end of the window thus minimising the risk of running out, but it seems to be scheduling a few random tiny discharge_best drops throughout the window with the final large one ending half an hour before the low rate kicks in:

Does that seem right?

Thanks

Adam

Discharge with Octopus Intelligent and Export tariff

Hi Trefor,

As per FB, last night there was 69% battery remains at 21:43, with the Intelligent off-peak rate starting at 23:30.

Any idea why it wasn't discharging? Logs from today enclosed. I will update when it happens again.

appdaemon.log

Improvement suggestion for inter-day averaging

Different users have varying needs for averaging of consumption data - from previous day only to 3/5/7/14-day average, but also the same day last week appears popular for those with a weekly usage cycle. Also, giving yesterday's consumption a higher weighting than earlier days is a useful technique.

Consider mirroring the more flexible scheme of weighted averages that I recently introduced in palm.py. It can accommodate (almost) any regime a user could dream up. Here are some examples:

Load history is a weighted average of actual load from previous days.

# Uncomment required settings or make your own using positive integers only. Examples:
# Most recent day only
# load_hist_weight = [1]
# 3-day average
load_hist_weight = [1, 1, 1]
# 7-day average
# load_hist_weight = [1, 1, 1, 1, 1, 1, 1]
# Same day last week - useful if, say, Monday is always wash-day
# load_hist_weight = [0, 0, 0, 0, 0, 0, 1]
# Weighted average (a more extreme example)
# load_hist_weight = [4, 2, 2, 1, 1, 1, 1]

Add descriptions of HA entities in the entities themselves

Maybe add a short description of each entity in a field so the user can click on one and read it.

Add option to limit max charge/discharge rate settings

Currently predbat will ovewrite charge and discharge rate settings, but the user can't set the max/min themselves.

Time zone issues?

Hi i noticed that something odd on the log:
@ TS 00:15:52. it said now 09-19 23:14:00. Tim zone is Europe/London both on appdaemon.yml and apps.yaml.
My first charge slot was at 23:30-00:00. tht was triggered correctly, but at 23:45, th aemon changed the start tim to 22:30-2300.

2023-09-20 00:15:52.565870 INFO pred_bat: Charge window will be: 2023-09-21 05:00:00+01:00 - 2023-09-21 05:30:00+01:00 - current soc 78.target 100
2023-09-20 00:15:52.567479 INFO pred_bat: Configuring charge window now (now 09-19 23:14:00 target set_window_minutes 30 charge start time 09-20 05:00:00
2023-09-20 00:15:52.569196 INFO pred_bat: Inverter 0 charge window is 05:00:00 - 05:30:00, being changed to 05:00:00 - 05:30:00
**2023-09-20 00:15:52.570634 INFO pred_bat: Not setting charging SOC as we are not within the window (now 09-19 23:14:00 target set_soc_minutes 30 charge start time 09-20 05:00:00)**
2023-09-20 00:15:52.572087 INFO pred_bat: Adjust reserve to default (as set_reserve_enable is true)
2023-09-20 00:15:52.573503 INFO pred_bat: Inverter 0 Current reserve is 4.0 already at target
2023-09-20 00:15:52.574932 INFO pred_bat: Completed run status Idle
2023-09-20 00:15:52.586617 INFO AppDaemon: Previous message repeated 1 times
2023-09-20 00:15:52.587008 WARNING AppDaemon: Excessive time spent in callback 'update_time_loop() in pred_bat', Thread 'thread.thread-1' - now complete after 82.585794 seconds (limit=60.0)

also plots have gone weird after midnight.

edit:plots came back okay at 0100 and this was in the log:

2023-09-20 01:04:55.021018 INFO pred_bat: Inverter 0 Updated start and end charge window to 00:30:00 - 01:00:00 (old 00:46:00 - 01:00:00)

setup question - inverter max discharge rate

I'm Octopus Flux so your script correctly detected high export rate between 4-7PM. I have a gen 1 GIV-HY5.0 inverter that can only export 2500kwh and yet the script insists on starting export at 17:30 and exporting 4.6kwh in 1.5hours. My inverter needs 2 hours to export that amount so I suspect that something somewhere is set incorrectly.
I looked in the config but there is no place to define max charge/discharge rate.
BTW in the logs I can see this:
Found 1 inverters total reserve 0.38 soc_max 9.52 soc 8.95 charge rate 2.6 kw discharge rate 2.6 kw ac limit 5.0 kw loss charge 4 % loss discharge 4 % inverter loss 6 %
so it clearly knows the limits and yet the data produced is wrong

New feature - add holiday mode

When people go away their usage profile changes.
A holiday mode toggle could change days_previous to '1' while away rather than using say 7/14 days previous. It's easier than modifying the apps.yml

Fluctuating Target SoC

Hi Trefor.

Not sure this is an issue with the calculations or just my own specific setup (using latest v6.7) but last night the calculated target SoC was fluctuating every 5 minutes.

My Zappi was charging the car too so the battery was discharging into the EV when the target was below the actual SoC (this is something I would prefer it not to do even if it means the actual SoC ends up higher than the target SoC at the end of the final Intelligent Octopus cheap charging window at 5:30am).

But because the target SoC would move between either side of the actual SoC, the battery was charging then discharging into the EV. Solcast forecast wasn't changing - everything should be static.

This is an extract of the log showing it moving around every 5 minutes:

2023-07-18 00:00:05.061102 INFO pred_bat: predict base end_record 07-18 23:30:00 final soc 2.05 kwh metric 160.74 p min_soc 0.38 @ 07-18 01:15:00 kwh load 33.38 pv 12.48
2023-07-18 00:00:05.064066 INFO pred_bat:          [  00:00,   01:00,   02:00,   03:00,   04:00,   05:00,   06:00,   07:00,   08:00,   09:00,   10:00,   11:00,   12:00,   13:00,   14:00,   15:00,   16:00,   17:00,   18:00,   19:00,   20:00,   21:00,   22:00,   23:00]
2023-07-18 00:00:05.066968 INFO pred_bat:     SOC: [   4.48,    1.38,    0.38,    0.38,    0.38,    0.38,    0.38,    0.38,    0.42,    0.46,    0.67,     1.2,    1.78,    2.69,    3.64,    4.31,    4.74,    4.92,    5.03,    4.94,    4.65,    4.03,    3.16,    2.37]
2023-07-18 00:00:05.069773 INFO pred_bat:   STATE: [  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-]
2023-07-18 00:00:05.073700 INFO pred_bat:    LOAD: [    0.0,    4.26,    8.59,   13.48,   17.93,   22.27,   22.82,   23.26,   23.81,   24.51,    25.2,    25.8,   26.57,    27.2,   27.77,   28.44,   29.04,   29.67,   30.12,   30.53,    30.9,    31.5,   32.32,   33.08]
2023-07-18 00:00:05.076779 INFO pred_bat:      PV: [    0.0,     0.0,     0.0,     0.0,     0.0,     0.0,    0.07,    0.37,    0.91,    1.62,    2.52,    3.68,    5.08,    6.66,    8.23,     9.6,   10.66,   11.49,   12.06,   12.38,   12.47,   12.48,   12.48,   12.48]
2023-07-18 00:00:05.079809 INFO pred_bat:  IMPORT: [    0.0,    1.32,     4.7,    9.59,   14.04,   18.37,   18.85,    19.0,   19.06,    19.1,    19.1,    19.1,    19.1,    19.1,    19.1,    19.1,    19.1,    19.1,    19.1,    19.1,    19.1,    19.1,    19.1,    19.1]
2023-07-18 00:00:05.089595 INFO pred_bat:  EXPORT: [    0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0]
2023-07-18 00:00:05.092586 INFO pred_bat:     CAR: [    0.0,    3.89,     8.8,    13.7,   18.61,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52,   23.52]
2023-07-18 00:00:05.106100 INFO pred_bat:  METRIC: [    0.0,    9.87,   35.21,   71.89,  105.29,  137.81,   150.9,  156.65,  159.29,  160.74,  160.74,  160.74,  160.74,  160.74,  160.74,  160.74,  160.74,  160.74,  160.74,  160.74,  160.74,  160.74,  160.74,  160.74]
2023-07-18 00:00:05.774754 INFO pred_bat: Battery has 1.25 hours left - now at 4.48
2023-07-18 00:00:08.035205 INFO pred_bat: Inverter 0 Current charge Limit is 40.0 % and new target is 34 %

2023-07-18 00:05:03.842971 INFO pred_bat: predict base end_record 07-18 23:30:00 final soc 2.08 kwh metric 159.14 p min_soc 0.38 @ 07-18 01:20:00 kwh load 33.12 pv 12.52
2023-07-18 00:05:03.845925 INFO pred_bat:          [  00:05,   01:05,   02:05,   03:05,   04:05,   05:05,   06:05,   07:05,   08:05,   09:05,   10:05,   11:05,   12:05,   13:05,   14:05,   15:05,   16:05,   17:05,   18:05,   19:05,   20:05,   21:05,   22:05,   23:05]
2023-07-18 00:05:03.848998 INFO pred_bat:     SOC: [   4.38,    1.28,    0.38,    0.38,    0.38,    0.38,    0.38,    0.39,    0.38,    0.49,    0.75,    1.23,    1.94,    2.86,    3.75,    4.38,    4.82,     5.0,    5.09,    4.93,    4.65,     4.0,    3.12,    2.34]
2023-07-18 00:05:03.851784 INFO pred_bat:   STATE: [  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-]
2023-07-18 00:05:03.854619 INFO pred_bat:    LOAD: [    0.0,    4.38,     8.7,   13.58,   18.04,   22.05,   22.58,   23.03,   23.68,    24.3,   24.97,   25.66,   26.34,   26.95,   27.56,   28.24,   28.84,   29.46,    29.9,   30.32,   30.66,   31.29,   32.12,   32.87]
2023-07-18 00:05:03.857382 INFO pred_bat:      PV: [    0.0,     0.0,     0.0,     0.0,     0.0,    0.01,    0.09,    0.41,    0.97,    1.71,    2.65,    3.85,    5.27,    6.86,    8.41,    9.74,    10.8,   11.63,   12.16,   12.44,   12.51,   12.52,   12.52,   12.52]
2023-07-18 00:05:03.860205 INFO pred_bat:  IMPORT: [    0.0,    1.43,     4.9,    9.78,   14.24,   18.24,   18.69,   18.83,   18.92,   18.92,   18.92,   18.92,   18.92,   18.92,   18.92,   18.92,   18.92,   18.92,   18.92,   18.92,   18.92,   18.92,   18.92,   18.92]
2023-07-18 00:05:03.863068 INFO pred_bat:  EXPORT: [    0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0]
2023-07-18 00:05:03.866077 INFO pred_bat:     CAR: [    0.0,    4.06,    8.96,   13.87,   18.78,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28,   23.28]
2023-07-18 00:05:03.868986 INFO pred_bat:  METRIC: [    0.0,   10.72,   36.73,   73.38,   106.8,  136.82,  149.95,   155.4,  159.14,  159.14,  159.14,  159.14,  159.14,  159.14,  159.14,  159.14,  159.14,  159.14,  159.14,  159.14,  159.14,  159.14,  159.14,  159.14]
2023-07-18 00:05:04.111692 INFO pred_bat: Battery has 1.25 hours left - now at 4.38
2023-07-18 00:05:23.988556 INFO pred_bat: Inverter 0 Current Reserve is 34.0 % and new target is 42 %

2023-07-18 00:10:03.969237 INFO pred_bat: predict base end_record 07-18 23:30:00 final soc 2.08 kwh metric 160.49 p min_soc 0.38 @ 07-18 01:20:00 kwh load 32.92 pv 12.52
2023-07-18 00:10:03.972195 INFO pred_bat:          [  00:10,   01:10,   02:10,   03:10,   04:10,   05:10,   06:10,   07:10,   08:10,   09:10,   10:10,   11:10,   12:10,   13:10,   14:10,   15:10,   16:10,   17:10,   18:10,   19:10,   20:10,   21:10,   22:10,   23:10]
2023-07-18 00:10:03.974940 INFO pred_bat:     SOC: [   4.09,    0.93,    0.38,    0.38,    0.38,    0.38,    0.38,    0.39,     0.4,    0.51,    0.78,    1.29,    2.05,     2.9,    3.82,    4.47,    4.84,    5.01,    5.09,     4.9,    4.62,    3.95,    3.06,    2.28]
2023-07-18 00:10:03.977675 INFO pred_bat:   STATE: [  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-]
2023-07-18 00:10:03.980556 INFO pred_bat:    LOAD: [    0.0,    4.55,    8.87,   13.75,   18.22,   21.89,   22.42,   22.88,   23.53,   24.16,   24.84,   25.51,   26.16,   26.84,   27.41,   28.04,   28.69,    29.3,   29.73,   30.17,    30.5,   31.14,   31.99,   32.73]
2023-07-18 00:10:03.983367 INFO pred_bat:      PV: [    0.0,     0.0,     0.0,     0.0,     0.0,    0.01,    0.11,    0.45,    1.03,    1.78,    2.75,    3.96,     5.4,    6.99,    8.53,    9.84,   10.88,   11.68,   12.19,   12.45,   12.51,   12.52,   12.52,   12.52]
2023-07-18 00:10:03.986270 INFO pred_bat:  IMPORT: [    0.0,    1.55,    5.35,   10.23,   14.69,   18.36,   18.78,   18.91,    19.0,    19.0,    19.0,    19.0,    19.0,    19.0,    19.0,    19.0,    19.0,    19.0,    19.0,    19.0,    19.0,    19.0,    19.0,    19.0]
2023-07-18 00:10:03.989287 INFO pred_bat:  EXPORT: [    0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0]
2023-07-18 00:10:03.992100 INFO pred_bat:     CAR: [    0.0,    4.23,    9.13,   14.04,   18.95,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04,   23.04]
2023-07-18 00:10:03.994904 INFO pred_bat:  METRIC: [   0.75,   12.39,   40.85,   77.45,  110.93,  138.44,  151.51,  156.75,  160.49,  160.49,  160.49,  160.49,  160.49,  160.49,  160.49,  160.49,  160.49,  160.49,  160.49,  160.49,  160.49,  160.49,  160.49,  160.49]
2023-07-18 00:10:04.234854 INFO pred_bat: Battery has 1.1666666666666667 hours left - now at 4.09
2023-07-18 00:10:59.225191 INFO pred_bat: Inverter 0 Current Reserve is 42.0 % and new target is 45 %


2023-07-18 00:15:03.968007 INFO pred_bat: predict base end_record 07-18 23:30:00 final soc 5.43 kwh metric 167.34 p min_soc 3.73 @ 07-18 08:00:00 kwh load 32.63 pv 12.52
2023-07-18 00:15:03.970946 INFO pred_bat:          [  00:15,   01:15,   02:15,   03:15,   04:15,   05:15,   06:15,   07:15,   08:15,   09:15,   10:15,   11:15,   12:15,   13:15,   14:15,   15:15,   16:15,   17:15,   18:15,   19:15,   20:15,   21:15,   22:15,   23:15]
2023-07-18 00:15:03.973829 INFO pred_bat:     SOC: [   4.19,    4.28,    4.28,    4.28,    4.28,    4.28,    3.96,    3.81,    3.76,    3.87,    4.15,    4.69,    5.45,    6.38,    7.24,    7.83,    8.22,    8.37,    8.44,    8.22,    7.94,    7.22,    6.34,    5.58]
2023-07-18 00:15:03.976778 INFO pred_bat:   STATE: [  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-]
2023-07-18 00:15:03.979655 INFO pred_bat:    LOAD: [    0.0,    4.63,    8.95,   13.82,   18.29,   21.64,   22.14,   22.65,   23.28,   23.92,   24.61,   25.27,   25.93,   26.55,   27.16,   27.83,   28.45,   29.05,   29.47,   29.91,   30.23,   30.92,   31.76,   32.48]
2023-07-18 00:15:03.982436 INFO pred_bat:      PV: [    0.0,     0.0,     0.0,     0.0,     0.0,    0.01,    0.13,    0.49,    1.08,    1.86,    2.84,    4.07,    5.53,    7.12,    8.64,    9.93,   10.96,   11.73,   12.22,   12.46,   12.51,   12.52,   12.52,   12.52]
2023-07-18 00:15:03.985245 INFO pred_bat:  IMPORT: [    0.0,    4.73,    9.07,   13.97,   18.47,   21.83,   21.91,   21.91,   21.91,   21.91,   21.91,   21.91,   21.91,   21.91,   21.91,   21.91,   21.91,   21.91,   21.91,   21.91,   21.91,   21.91,   21.91,   21.91]
2023-07-18 00:15:03.988120 INFO pred_bat:  EXPORT: [    0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0,     0.0]
2023-07-18 00:15:03.991012 INFO pred_bat:     CAR: [    0.0,     4.4,     9.3,   14.21,   19.12,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8,    22.8]
2023-07-18 00:15:03.993890 INFO pred_bat:  METRIC: [    3.0,   38.46,   71.04,  107.79,  141.51,  166.72,  167.34,  167.34,  167.34,  167.34,  167.34,  167.34,  167.34,  167.34,  167.34,  167.34,  167.34,  167.34,  167.34,  167.34,  167.34,  167.34,  167.34,  167.34]
2023-07-18 00:15:04.244884 INFO pred_bat: Battery has 48.0 hours left - now at 4.19
2023-07-18 00:15:38.917053 INFO pred_bat: Inverter 0 Current Reserve is 45.0 % and new target is 42 %

Here are my full logs starting at around 11pm to about 12:15am:
https://pastebin.com/dyBC0DFD

Here is my apps.yaml:
https://pastebin.com/X7ZcSmch

Cheers!

Latest update, entities missing

Trefor, just installed the latest update and get a number of entities not working

update: looks like my Solcast has maxed out. Thanks Trefor, I’ll fix that

this follows updating the the latest version of core yesterday and solcast today

Missing `indirect=False` when reading `rate_import_octopus_url` config URL

batpred/predbat.py

Line 996 in b4983ba

self.log("Downloading import rates directly from url {}".format(self.get_arg('rates_import_octopus_url')))

incorrect values in predbat.rates on Agile tariff

Before 16:00, predbat.rates shows an incorrect value at 23:00 and 23:30. For me it shows at 38p/kWh.
The Agile rates are published up until 22:30, and I think batpred uses yesterday's rates to extrapolate forwards? It seems to be fine from 00:00 onwards, using the previous day's values.
38 p/kWh is much higher than the average rate and it's pushing up the "average" attribute of predbat.rates

Sorry if I've explained this badly - let me know if you need anything more!

Lost helper card

More than likely something I've done but I seem to have lost the helper card from my dashboard, is there an easy way to readd the whole card?

Testing wrong key when reading `metric_octopus_export`

Line 512 should be testing for the existence of metric_octopus_export, not metric_octopus_import:

if 'metric_octopus_export' in self.args:

instead of

if 'metric_octopus_import' in self.args:

Chart Data

I think the data behind a few of my charts might not be correct. I know i'm an above average user for energy but surely these figures aren't correct?
Background - 16kWp in solar panels, 2 x AC Coupled Inverters and 2 x 9.5kWh batteries.



Log file -
a0d7b954_appdaemon_2023-09-21T16-00-18.004Z.log

Any help would be very much appreciated :)

[Feature Request] Manage Export Limitation

My system has an export limitation in place, I have been playing around with a simple script to try and optimize charging so that when we generate > Export we can pipe the spare into the battery. This has meant that instead of capping out at 5kw it has been able to cap closer to the total PV value so the system.

I would be nice if batpred supported this sort of thing, it would improve generation for anyone where PV > Invertor output.

Not an issue - Advice

Great work by the way.
I don't have an electric vehicle, I also only have 1.3kw Solar panels, and to add insult to injury, I don't get paid for export. I am on the agile tariff. So what would be the best settings for for this? I have an 8.2kwh batter with a DoD of 100%

Scheduled discharge?

I noticed that scheduled charge was working fine - however scheduled discharge was being ignored by the system.

On investigating the givTCP entities, enable charge schedule was "true"
Enable discharge was "false" - and if set to "true" manually, would quickly revert to false

Could that be why there is a problem?

I see in config we have:

scheduled_charge_enable: 
   - switch.givtcp_{geserial}_enable_charge_schedule_2

But there is no corresponding entry for scheduled discharge enable?

(note, the _2 suffix was added due to an issue with givTCP recently where all MQTT entities were renamed)

Option to minimise import

Is there an option somewhere where you can minimise grid imports?

Octopus Energy update (V8)

Since the Octopus energy was updated https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy it seems that batpred can no longer read the rates from it.

sensor.octopus_energy_electricity_22l4330885_2199998082940_current_rate is what my rate sensor is called, just in case your auto discovery is looking for something different

Feature suggestion: battery headroom

Great project - thanks for all the hard work. I have a suggestion for a feature. I'd like to be able to leave space in the battery when it charges from the grid.

I have a 3.6 kW hybrid inverter with a 9.5 kWh battery and 4.4 kW of PV. I'm on the Octopus Flux tariff. In the middle of the day, if my battery is full and the PV is generating (for example) 4.4 kW, then 3.6 kW goes to the grid, but the remaining 800 W is lost. If there was space in the battery, some would go to the grid and some to the battery, and nothing would be lost. I can't see a way of doing that with the current config options.

The simplest implementation I can think of would be a "best_soc_max" that sets the maximum that'll charge from the grid, leaving some space for the surplus later in the day. Along with that, setting the battery charge power to (for my example case) 800 W would mean at max PV generation 3.6 kW goes to the grid and the excess to the battery.

More sophisticated would be to calculate the likely excess, based on the max output of the inverter, the capacity of the PV and the solar forecast, and use that to set the max SOC during the grid charge.

car_charging_limit overwrites octopus intelligent vehicle charging details

batpred/predbat.py

Line 1792 in 0713c71

self.car_charging_limit = (float(self.get_arg('car_charging_limit', 100)) * self.car_charging_battery_size) / 100.0

The car_charge_limit is read from app.yaml, but overwrites the charge limit read from the octopus intelligent details. Probably want to read the "static" value first, then overwrite with the octopus value if available.

Error calculating charge_limit

Errors being generated once target SoC has been set (e.g. first charge window 23:30, initial target SoC set at 23:04, errors start appearing from 23:09 onwards). Predbat stops the current cycle after generating this error...

2023-05-31 23:09:28.550241 WARNING pred_bat: ------------------------------------------------------------
2023-05-31 23:09:28.550859 WARNING pred_bat: Unexpected error in worker for App pred_bat:
2023-05-31 23:09:28.551057 WARNING pred_bat: Worker Ags: {'id': '59e7d07f2e0f480d9ec0c6952185feb7', 'name': 'pred_bat', 'objectid': 'dbe1e7dd995a4ba58ff99662476fac52', 'type': 'scheduler', 'function': <bound method PredBat.run_time_loop of <predbat.PredBat object at 0x7f5b96148950>>, 'pin_app': True, 'pin_thread': 1, 'kwargs': {'interval': 300, '__thread_id': 'thread-1'}}
2023-05-31 23:09:28.551512 WARNING pred_bat: ------------------------------------------------------------
2023-05-31 23:09:28.552965 WARNING pred_bat: Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/appdaemon/threading.py", line 1022, in worker
funcref(self.AD.sched.sanitize_timer_kwargs(app, args["kwargs"]))
File "/config/appdaemon/apps/predbat.py", line 2401, in run_time_loop
self.update_pred()
File "/config/appdaemon/apps/predbat.py", line 2098, in update_pred
self.charge_limit = [self.current_charge_limit * self.soc_max / 100.0 for i in range(0, len(self.charge_window))]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/appdaemon/apps/predbat.py", line 2098, in
self.charge_limit = [self.current_charge_limit * self.soc_max / 100.0 for i in range(0, len(self.charge_window))]
~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
TypeError: can't multiply sequence by non-int of type 'float'

2023-05-31 23:09:28.553132 WARNING pred_bat: ------------------------------------------------------------

Line 2080 originally has:
self.current_charge_limit = inverter.current_charge_limit

I've temporarily fixed it by converting it to a float:
self.current_charge_limit = float(inverter.current_charge_limit)

Also possibly linked to this (maybe an error somewhere else or due to my "float" change) a warning on the main appdaemon.log:

2023-06-02 02:44:02.541499 INFO pred_bat: WARN: Return bad value number.givtcp_ce1234g567_target_soc from soc_percent
2023-06-02 02:44:02.543557 INFO pred_bat: Inverter 0 Current SOC is 100.0 % and new target is 29 %
2023-06-02 02:44:02.582685 INFO pred_bat: Inverter 0 Current reserve is 29.0 already at target

The above can't seem to read the inverter's current target SoC so it constantly sets it to the expected 29% target every 5 minutes even though it is already set to 29%.

Unable to get 'next' discharge window to fully discharge

Hi

I love the tool you've created. I'm trying to tune it to do what I want whilst I'm waiting for our export MPAN to be issued.

I've modified the config to

• use the Flux import/export tariffs (until we actually switch)
• calculate_best_discharge: True (but turned off actually charging/discharging using the new switches)
• reduced the SOC min/keep to zero as I dont care if we run out of battery, only that we make the best use of import/export for Flux:
  best_soc_margin: 0 best_soc_min: 0 best_soc_keep: 0 best_soc_step: 0.25 best_soc_pass_margin: 0

As you will see, the best and best10 predictions keep a reserve of around 2kwh prior to the overnight charging window where I would have expected it to maximise discharge, and estimate hitting 0kwh just before the charging window.

Any tips to tweak this would be great.

Thanks

Octopus Intelligent ‘bump charge’

Hi

I’m not sure if this is just too fine grained to be handled, and its not a major issue… but I noticed that when I initiated an Octopus Intelligent bump charge (which is at the ‘day’ import rate) that Predbat started to charge my giv battery (not just the car). I figure this is because it sees the planned_dispatches on the dispatching sensor but perhaps doesn’t differentiate between the source (bump-charge vs smart-charge) and presumes the dispatch window is at the cheap rate?

No big deal but thought I’d let you know.

Many thanks for your work @springfall2008 - its a great tool.

Adam

Missing Data

Originally opened on Facebook: I no longer have Load, PV or Import data appearing in the pred_bat log and also not in the Data or Power charts. This data is available from GivTCP. As requested logs are attached

home-assistant_2023-09-20T19-42-32.646Z.log
appdaemon.log
a0d7b954_appdaemon_2023-09-20T19-33-41.581Z.log

Add power up support

Octopus have introduced Power-ups in my area, where I can opt in to get 2 hours of free electricity. The Agile rate shown on my meter will not change but Octopus will credit my account in about 2 weeks time to make it free. My question for Trefor is whether there is a way to factor this in to Predbat so that it keeps some capacity in my battery before this 2 hour window to allow me to charge from the grid for free. Many thanks.

Add battery charging curve support

With the latest GE firmware the battery charging rate tails off close to 100%, add support to model this:

Strange discharge

Hi Trefor,

Attached is the log file your where after

appdaemon1.log

Car Charging doesn't use sensor

Looking at the prebat.py 4.0 source, I can't see any code to handle the responses listed in apps.yaml? Am I missing some aspect to how the car charging prediction now works?

Setting the car_charging_planned to a sensor results in:
INFO pred_bat: WARN: Return bad int value EV Disconnected from car_charging_planned
2023-06-02 12:14:21.136105 INFO pred_bat: Previous message repeated 848 times

apps.yaml
car_charging_planned_response:
- 'yes'
- 'on'
- 'true'
- 'connected'
- 'ev connected'
- 'charging'
- 'paused'
- 'waiting for car demand'
- 'scheduled'
- 'enabled'
- 'latched'
- 'locked'
- 'plugged in'

predbat.py:
planned = self.get_arg('car_charging_planned', False)
if isinstance(planned, str):
if planned.lower() in self.get_arg('car_charging_planned_response', ['yes', 'on', 'enable', 'true']):
planned = True
else:
planned = False

REST error

I'm getting the following error:

2023-07-25 10:10:04.340105 WARNING pred_bat: ------------------------------------------------------------
2023-07-25 10:10:04.340366 WARNING pred_bat: Unexpected error in worker for App pred_bat:
2023-07-25 10:10:04.340596 WARNING pred_bat: Worker Ags: {'id': '69099532cee14d6ca41329e600f77a94', 'name': 'pred_bat', 'objectid': '28934eeb431f40c8870d421805df2dce', 'type': 'scheduler', 'function': <bound method PredBat.run_time_loop of <predbat.PredBat object at 0x7f42499d1d90>>, 'pin_app': True, 'pin_thread': 1, 'kwargs': {'interval': 300, 'random_start': 0, 'random_end': 0, '__thread_id': 'thread-1'}}
2023-07-25 10:10:04.340769 WARNING pred_bat: ------------------------------------------------------------
2023-07-25 10:10:04.343343 WARNING pred_bat: Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/appdaemon/threading.py", line 1022, in worker
    funcref(self.AD.sched.sanitize_timer_kwargs(app, args["kwargs"]))
  File "/config/appdaemon/apps/batpred/predbat.py", line 4044, in run_time_loop
    raise e
  File "/config/appdaemon/apps/batpred/predbat.py", line 4040, in run_time_loop
    self.update_pred(scheduled=True)
  File "/config/appdaemon/apps/batpred/predbat.py", line 3549, in update_pred
    metric, self.charge_limit_percent, import_kwh_battery, import_kwh_house, export_kwh, soc_min, soc, soc_min_minute = self.run_prediction(self.charge_limit, self.charge_window, self.discharge_window, self.discharge_limits, self.load_minutes, pv_forecast_minute, save='base', end_record=end_record)
                                                                                                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/appdaemon/apps/batpred/predbat.py", line 1854, in run_prediction
    save, self.time_abs_str(end_record + self.minutes_now), self.dp2(final_soc), self.dp2(final_metric), self.dp2(soc_min), self.time_abs_str(soc_min_minute), self.dp2(final_load_kwh), self.dp2(final_pv_kwh)))
                                                                     ^^^^^^^^^
UnboundLocalError: cannot access local variable 'final_soc' where it is not associated with a value

2023-07-25 10:10:04.343602 WARNING pred_bat: ------------------------------------------------------------

Config file is using the standard REST connection:

  givtcp_rest: 
   - 'http://homeassistant.local:6345'

However, when I comment out the REST comment so it uses the HA entity control, predbat starts working fine. Switching back to REST control and predbat continues to work fine.

This has happened a couple of times now.

It seems like if the communication via REST becomes broken then it doesn't try to recover that connection other than restarting predbat.

Expose notification config so it can be defined.

Currently all notifications go to notify.notify. Would it be possible to make this a configurable option as notify sends to all "people" in HA. Had a look at the code and it looks like some of the work for this has already been done, it's just not exposed in a way we can configure.

Support for Solcast latest release

It seems the v3.0 branch has some breaking changes, where detailedForecast is replaced by forecast - need to support this

https://github.com/oziee/ha-solcast-solar

KeyError: 'geserial'`

It looks like the most recent release as of June 6th may have a small problem?

2023-06-06 22:10:00.030098 WARNING pred_bat: Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/appdaemon/threading.py", line 1022, in worker funcref(self.AD.sched.sanitize_timer_kwargs(app, args["kwargs"])) File "/config/appdaemon/apps/batpred/predbat.py", line 2552, in run_time_loop self.update_pred() File "/config/appdaemon/apps/batpred/predbat.py", line 2065, in update_pred load_minutes = self.minute_data_load(now_utc) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/appdaemon/apps/batpred/predbat.py", line 715, in minute_data_load entity_ids = self.get_arg('load_today', indirect=False) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/appdaemon/apps/batpred/predbat.py", line 599, in get_arg value = self.resolve_arg(arg, value, default=default, indirect=indirect, combine=combine, attribute=attribute, index=index) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/appdaemon/apps/batpred/predbat.py", line 577, in resolve_arg item = self.resolve_arg(arg, item, default=default, indirect=indirect) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/appdaemon/apps/batpred/predbat.py", line 584, in resolve_arg value = value.format(**self.args) ^^^^^^^^^^^^^^^^^^^^^^^^^ KeyError: 'geserial'

Feature Request: Home Cost Prediction to include service charge

Just as the title says. It's in the octopus integration under

sensor.octopus_energy_electricity_numbershere_morenumbershere_current_standing_charge

Add option to show predicted remaining battery charge at the end of the day (prior to end of day forced charge/discharge) as a figure

I'd like the value of the battery prior to end of day forced charge/discharge so that I can plot this as a gauge on the dashboard (I therefore know how much extra energy I can use in the day as a value to drive automations etc)

Improving code quality

Running code through the pylint linting tool identifies some things to be fixed... "Your code has been rated at -6.17/10"

Add iBoost on negative rates

Ab Iboost (Eddi boost) when rate below zero and stop battery discharging to house would work

Add unique id's to predbat entities

Currently the predbat control entities do not have unique id's so its not possible to manage them in the home assistant UI. For example to hide entities such as car charger that are not relevant to every user.

Enhance predbat status with time information

The predbat status would be more useful if it additionally showed time information in it, eg "Idle, last run at hh:mm" or "Charging, started at hh:mm to xx:yy"
This would give a simple status confirmation that predbat is still running ok and when major activities started

solcast entity nomenclature

This is a fantastic tool.
One thing I noticed, was that though I had the solcast integration installed, the entities created didn't have "solcast" in the entity names, so did not match the default config file. Easy to fix - I simply removed the bolt sections below.

I mention it only because the comments in that file suggest they won't need changing, so if it is a change in nomenclature by the solcast integration it might be good to know. Cheers either way!!

#Set these to match solcast sensor names (unlikely to need changing)

pv_forecast_today: sensor.**solcast_**forecast_today
pv_forecast_tomorrow: sensor.**solcast_**forecast_tomorrow
pv_forecast_d3: sensor.**solcast_**forecast_d3
pv_forecast_d4: sensor.**solcast_**forecast_d4

New feature request - Stop battery discharge whilst EV charging

I have a new feature request (unless it is already there and I've missed it!)

Currently when the EV is charging on grid power (in my case during an Intelligent Octopus charging slot) and the target SoC is below the battery's current SoC, the battery discharges into the EV.

To reduce unnecessary battery cycles, I'd prefer if there was an option to hold the existing battery SoC (i.e. disable discharging) whilst in an active charging slot (or for non-IO users if it detects the EV is charging from grid).

I know this might mean that by the end of the night's cheap rate the battery SoC stays higher than the target SoC meaning a full battery earlier than planned resulting in exporting solar (although I have a solar diverter to avoid this) but I would rather export solar during the day than charge my EV direct from the battery overnight.

Is this easy to do or is it a silly idea because of something I've missed?

Multiple instances of batpred

Hi Trefor,

To run multiple instances of batpred do I just need to duplicate apps.yaml and in the second one change the name of the two following tags below?

pred_bat2:
module: predbat
class: PredBat

prefix: predbat2

Add option to chart % rather than just kWh

Some users would like charts in battery % rather than kWh