I installed PredBat a couple of weeks ago and have been running it in Read-Only mode (just show the plan, don’t control the inverter). I quickly found out that it is a lot cleverer than I am !
In particular, I realised that my mindset regarding charging and discharging was still based on my Flux Summer tariff (charge in the early hours, export over the evening peak), even though I am now on Agile Import and 15p Fixed Export. This became apparent when the PredBat plan said it would export at midnight. Initially, I thought it had gone mad, but actually that is entirely reasonable as PredBat knows it can charge the battery later on using some of the negative cost Agile timeslots available tonight.

With some trepidation, I switched Read-Only off, disabled my normal morning charge HA automations, and let PredBat run …

@geoffreycoan , I have you to thank (or blame!) for this - if I thought HA was a rabbit-hole, PredBat takes it to the max !

Welcome to the club. Takes some time to adjust your head to the logic and realise it's looking to make the most optimal choice in every slot. Definitely a massive level above an overnight/cheap rate charge, then live off the batteries approach. It's not always perfect, but Trefor is highly active on the github issues.

My plan for today intentionally drains the battery, as the stored energy is worth more as export, 13.97p after conversion losses, than it is to run off grid 7.44p. Will charge up later on very cheap rates but as there are more cheap slots than needed to fully charge my batteries it will also perform some discharge between the charges.

Pushes the system much harder, but overall it's maximising the invest in the hardware and fully leveraging the tariffs we have.

That is what I like about it - it really is opportunistic about sliding in a quick bit of export, in a way that would be frankly impossible for a human operator to do. A very impressive body of work by Trefor. I have left Expert mode off for now whilst I study the comprehensive documentation some more.

Very curious about trying PredBat - need to first figure out how to get HA running on my synology. One question I had was whether it can handle doing multiple charges of the battery per day? My battery doesn’t last me through the day, and I am therefore currently using Cosy. I’d love to use PredBat to switch to Agile - but I wasn’t sure if it could operate by making multiple charging “runs”?

I am dipping a Xmas toe into PredBat at last too. All set up and ready to go. (And, yes, @geoffreycoan has a lot to answer for!)

But tomorrow they have just announced a 4 hour Power-up (first one that is so long). How do PredBat users deal with Power-ups?

Boffinboy

It absolutely can, and does, use multiple charging slots - in fact, it is quite dizzying at times how it switches from charge to discharge to hold-charge and back again, all to milk the most out of the changing import rates on Agile.

Easy to recommend Agile at the moment, with pretty frequent negative import rates, but of course that won’t always be the case.

If you are on Cosy at the moment, is that because you have a high daily load, from a heat pump for example ?

PianSom I am by no means the expert, but I believe you can override the import (and export) rates between certain times - will need to look into it !

PianSom Here it is in the PredBat documentation:

Manually Over-riding energy rates

You can also override the energy rates (regardless of if they are set manually or via Octopus) using the override feature. The override is used to set times where rates are different, e.g. an Octopus Power Up session (zero rate for an hour or two)

rates_import_override:

• start : "HH:MM:SS"
  end : "HH:MM:SS"
  rate : pence
  date : "YYYY-MM-DD"
  rates_export_override:
• start : "HH:MM:SS"
  end : "HH:MM:SS"
  rate : pence
  date : "YYYY-MM-DD"
  date is in the date format of "YYYY-MM-DD" e.g. "2023-09-09"

Lofthouse

Nice, thanks.

Though with a 4 hour Power-up I was wondering whether there was something more clever I could be doing. That's enough time to do some exporting to make some money, and still have time left over to leave myself with a full battery for free.

Hopefully, the Power-Ups will be extended to DNOs other than UK Power Networks - and it would be really helpful to have the Power-Up information exposed in the Octopus API so BottleCapDave could add a binary sensor to his Octopus HA integration, and Trefor could then automate the process in PredBat, as he does for Octoplus Saving Sessions, auto-joining and applying the Timed Export between the relevant start and end times.

PianSom Though with a 4 hour Power-up I was wondering whether there was something more clever I could be doing

That’s exactly the sort of thing that PredBat helps with - good to hear you are already setup and ready to go - the only gotcha for me was that I was expecting to see PredBat installed as an Integration, but in fact it “lives” in the AppDaemon Add-On.

The more people bite the bullet and install PredBat, the more we will be able to help each other.

I wish you the best of luck 🤞

Lofthouse I tried and failed miserably to get it working and gave up

Lofthouse that’s exactly it, I am a high user - charging the battery up in both Cosy periods as much as it can (3h not quite enough to get to full, if it’s emptied overnight).

Unfortunately I just started trying to get the required HA and add ons setup and I can’t even get GivTCP to see my inverter. Not sure why! Doesn’t find an inverter on the network and keeps timing out according the logs, I am certain the IP address is right. Any ideas?! This is one of the reasons I’m slightly wary about going with PredBat (if I can even get things working!) - troubleshooting ends up very complicated!

Boffinboy This sounds very much like the issue described here https://community.givenergy.cloud/d/3693-ha-green-givtcp

Make sure you have MQTT installed and configured - probably the best reference is one of the SpeakToTheGeek videos on YouTube
https://www.youtube.com/watch?v=ygD9KyciX54

Thank you. I do have the broker installed. Follow the speak to the geek written guide as well and don’t think I missed anything - may have some time again today to look.

Lofthouse I wish you the best of luck 🤞

So, following your lead, I went live last night for the first time. And woke up to find that the AIO had gone into a charge/discharge loop for 4 hours in the early hours. I’m on IOG, so it clearly decided at the last minute that a 15p export combined with a 7.5p import was a Good Thing!

As you say, surprising what it decides to do. Not necessarily wrong or irrational, just surprising.

Boffinboy
I'm at the 'MQTT doesn't authorise requests from GivTCP' stage - if I can figure out how to get Moquitto to allow all requests I'll let you know what to chnge in MQTT config file when I get it running. It's Mosquitto Broker version 6.1.3.

Slartibartfast You need to run mosquitto without auth, there is a switch to add to the docker deployment.

This is the mosquitto section of my docker compose.

'''
mosquitto:

container_name: "mosquitto"

command:
  - "/usr/sbin/mosquitto"
  - "-c"
  - "/mosquitto-no-auth.conf"

entrypoint:
  - "/docker-entrypoint.sh"

hostname: "mosquitto"

image: "eclipse-mosquitto:2.0"

network_mode: "bridge"

ports:
  - "1883:1883/tcp"

restart: "unless-stopped"

volumes:
  - "/volume1/docker/mosquitto:/mosquitto"
  - mosquitto-log:/mosquitto/log
  - mosquitto-data:/mosquitto/data

'''

Slartibartfast turns out my issue was a networking one. My APs had updated and the new firmware seems to introduce an issue

PianSom It's for a sure a change in mindset, historically I tried to run as long as I could on batteries. 5 hour charge a day, no automated export, try and make it to the next charge window. Predbat throws that out the window and simply says, let's make this as cheap as possible including discharging when the rates are stupidly low.

It works, however you need to trust it and avoid temptations to override.

I've been running it for 6 weeks, never would have expected to be exporting in December.

400+ kWh for £30 before the saving session income of £57. Could I have achieved the same without predbat, maybe but highly unlikely unless I wanted to manually control everything. It's definitely more efficient than my old scripts charging to 90% in cheapest slots.

Arg0t
It's certainly disconcerting!

ATM I have about 2kW of PV and an Octopus Power-up started 10 minutes ago. It has moved me from importing 6kW 5 minutes ago to exporting 5kW (my DNO limit) now. A wild ride, and certainly not one I would have done manually.

I expect to do about 25kWh of EXPORT today, thanks in part to the 4 hour Power-Up which PredBat is using to recharge the battery after dumping it this morning - I would never be that brave !

Has anyone got any pearls of wisdom on flux configuration, or is predbat optimised more for agile?

It planned to not charge 2-5am, ideally I'd like it predicting if it it needed a 3pm charge to cover me till 7pm on a rubbish solar day for example..

neomancer I'm on Flux as well, just got Predbat installed but not really planning to use it yet.
Is Predbat mode set to Monitor? If so change it to Control charge it will show the planned charging times.

Yeah I had it set to control... It was aiming for a 42% charge during the flux low slot. Which I wasn't super happy about :/

SJB If so change it to Control charge it will show the planned charging times.

If you do that, make sure you have Read Only mode set to True, otherwise PredBat will start sending commands to your inverter.

Settings->Devices & Services->Entities->switch.predbat_set_read_only

It's things like this that it's doing that make me a bit :/

I'll have another look through the config to make sure I've not enabled something silly.

I’m on go and a recent convert to predbat too. Making me think I should really look at agile again in the new year! Part of the reason I switched to go for the winter was to keep it simple but if Predbat can squeeze a few extra pounds it’s probably worth doing.

I had some dubious automation I’d set up myself to maximise my flux income in the summer but really impressed with what Trefor has done.

neomancer Has anyone got any pearls of wisdom on flux configuration, or is predbat optimised more for agile?

This seems the best reference, but I imagine you may have already looked there:

https://springfall2008.github.io/batpred/configuration-guide/#multiple-rates-for-import-and-export-eg-octopus-flux-cozy

neomancer for financial reasons it wants to make sure you hit 4pm with enough battery to discharge at full power for 3 hours or to empty your battery. Best way to do that is charge up overnight and then use the grid during the day… that’s what it’s showing right?

Lofthouse Thanks, - I'll have to remember that.

neomancer probably have combine charge slots enabled.

naltsta

Yeah, the way it usually works at the moment is I scrape through at 7pm and go onto grid sometime after 7 usually, but I guess using the grid incurs less loss in conversions, plus predbat is trying to put me into the 4PM with a full battery when I'm fine with anything above 60% usually.

Just very different to summertime usage. I guess.

Finding this really difficult to get finally set up! What I’m currently struggling with is getting the chart and html plans to be visualised in the dashboard. I’ve added the required visualisation add ons in HACS but when I try to paste and use the template code in a custom card, it’s not recognised. Any obvious things I need to do after adding them?

Boffinboy
No, just follow the instructions and they should work. That’s what I did yesterday, anyway. Make sure you have all the addons up and running before adding the cards.

Understanding the charts - that’s where the challenge is!

Boffinboy I presume you are talking about cut and pasting the individual charts from here:
https://github.com/springfall2008/batpred/blob/main/templates/example_chart.yml

I found it much easier to paste the sections of yaml into a Manual card (right at the end of the list of cards in Edit Dashboard->Add Card)

I also found a number of HA restarts were necessary, though not prompted for.

PianSom Understanding the charts - that’s where the challenge is!

Agreed - I am still trying to work out what the Calibration chart is telling me …

Thanks all. I had to restart Ha a couple of times and reinstall the chart add ons in HACs as they weren’t loading. I am still struggling to find the dashboard yaml. Instructions say “ in your AppDaemon configuration area under the filename predbat_dashboard.yaml” but I can’t see it anywhere! Also not getting the historic usage data pulling through yet, even though I’ve set it to use givenergy cloud for now

Boffinboy
I never found the example card (but I am a special case in that I have appdaemon in its own docker container anyway). But it’s not needed. Just do what Lofthouse suggested.

Boffinboy
The dashboard yaml is in /root/config - I think that’s a bug, as you would think it would be in the same place as apps.yaml …

That said, I found the dynamic-entities-card presentation better - you will need of course to install some more lovelace card integrations, and I found I needed to grab the dashboard code from here: https://github.com/DJBenson/ha-stuff/blob/main/homeassistant/dashboards/predbat-dynamic-list.yaml

Seem to have it working now! First test tonight… I have turned on the inverter notifications just to see what’s going on. Something odd seems to be happening - every 5 minutes I get three or four notifications in sequence, one about setting reserve to 4%, then target SOC to 100%, then to 5%, then target reserve to 6, then hold charging to 5%… Let’s see if it actually works overnight (not yet on agile, on cosy).

The other issue I am having now is the log file doesn’t seem to show up under the appdaemon log within HA menu. I have to open the actual file which is very unwieldy. A problem for another day!

Boffinboy If you set switch.predbat_set_status_notify to Off (it’s On by default), that will stop the notifications.

[Edit: Sorry, misread your mail - you have turned the inverter notifications on deliberately ☺️ - PredBat seems to tee a lot of things up in advance, and is always fiddling with charge windows and reserve percentages !]

If you are trying to view the AppDaemon log file on a mobile device, make sure your Internal URL is set correctly at Settings->Companion App then first option, where it says your name. Mine wasn’t, and it took me an age to work out why I could see the log on my desktop Mac, but not on my IPad !

I’ll be crossing fingers for you tonight 🤞

And I might have got the wrong end of the stick again …

There are 2 logs - the first is the AppDaemon log at Settings->Add Ons->AppDaemon->Log. It is worth looking in here if you have to restart HA - sometimes AppDaemon doesn’t start properly, and then PredBat won’t work. Just hitting Restart on the AppDaemon AddOn fixes things.

The second, and more interesting, is the PredBat log itself, accessed from the Open Web UI button on the AppDaemon AddOn. This should show something like below in your default browser. Select Logs and you can just leave that running, hitting refresh when you come back to it to wake it up.

Lofthouse thank you. This was it. I had assumed it would show in the Appdaemon log area in HA itself, but it didn’t. When I open the log it starts with the oldest messages first - so you know if there is a way for it to show the newest first? Thanks for all of your guidance!

I am tempted to switch from Cosy to Agile given the crazy low rates with the wind at the moment, but slightly fearful that PredBat won’t work or will break at some point and then I’ll have to just use a “best guess” approach with Agile… It seems to be working well, but I am always worried about breaking updates. Maybe I just never update it!

P.s. Happy Christmas! What can beat playing around with battery optimisation in Christmas Day 🤣

This is the weird behaviour I am seeing when battery hits near empty - the battery is actually at 7% - it’s almost like it’s yo-yoing?

Also seeing some very strange solar forecast data more than a day out…. Anyone else experiencing this? Seems to reach a point and then extend the same number out forwards - needless to say this causes some odd behaviour!

Boffinboy Yes, I see that too - I disregard any part of the plan more than 4 hours out, but have learned to trust PredBat to do the right thing at the right time !

Glad you are up and running 👍

Boffinboy When I open the log it starts with the oldest messages first - so you know if there is a way for it to show the newest first?

Odd, my newest messages are at the top, and scroll through at a pretty frantic pace.

This is why I am trusting PredBat - 18p for 174kWh, £7.50 of export over two very dull days, and all my gas (admittedly mild days) and standing charges covered, plus 8 hours of PowerUp to be refunded later - normal pre-PredBat energy figures (even with negative Agile rates) were £5 to £8 a day.

Summary below from the excellent Octo-Aid app:

Lofthouse Wow! Hope this Agile pattern of unseasonably warm windy weather holds…. My Agile switch will be backdated to midnight yesterday, but my charging pattern will be off.

Just re-checked my logs and they are indeed going newest first. Strange, I must have read wrong

Really glad I am not the only one who sees the odd solar pattern. It seemed fine at first, but then changed to the 0.53 value

Boffinboy

Trefor had released an update fixing the solar PV forecast.

Hello @Lofthouse @PianSom and all, sorry not been on this forum for a while so hadn't seen this thread, but great to see that others are dipping their toes and feet into the predbat pool, although not sure I like me being blamed for encouraging you !

Predbat is great, as @Arg0t says, you have to learn to trust what it does. By all means adjust the thresholds so it gives a usage pattern you are comfortable with, but it does do things that you sometimes don't think of. If I really set my mind to it I keep thinking I could probably optimise a tiny bit more, but we're talking pence so its just not worth it. And I may of course not be right anyway!

Trefor is very helpful and is always adding new features, the HTML plan, the charge/discharge mode, read-only, and just this week the new auto-update features.
I've also contributed a few bug fixes and minor enhancements along the way, the blue for negative pricing on the html plan is my doing!

Yes the apex charts are a pain to setup. I do plan to suggest an improvement to that. Manually cut and paste each chart into a blank chart is the way to go, don't try and paste the whole yaml into a dashboard - the indentation is all wrong.

December 23rd, total bill 17p, the 24th, -87p, Christmas day at 23:30, -9p.
Incredible!
And this is running the ASHP and I put the hot tub on and heated it up as well.
The powerup events and negative pricing have been great, who'd have believed making a profit in December! Makes the 60p/kW I was paying in peak slots in early December in the cold period a distant memory. Gotta take the rough with the smooth of course.

For someone that asked, yes predbat works excellent on Flux or Cosy. I started using it in early September on Flux and continued using it like that all the way through to October when I moved to agile. The plan is of course a lot simpler with Flux, but what it does do well is force export excess capacity in the peak period.

Arg0t Thanks. Will test!

First Pedbat fail today.

It’s a Power-up day (12-3) and last night it decided to charge up to about 50%. This morning a laundry load went on, which meant that the battery was drained by 11am, so went back to grid.

Not sure how I could have avoided that. Still, at least it’s now getting filled up for free.

PianSom Predbat uses historical load figures to predict what your battery level will be, and with the forthcoming power up event it would have decided to not charge the battery too much as you’d “have enough” to see you through to the cheap period.

Suggestions:

• make sure you are using enough days of history in apps.yaml to average out ups and downs such as extra washing, Christmas cooking or saving sessions. I have mine set to take an average of the last 2, 3, 4, 5, 6, 7 and 8 days. Used to have 1 as well but was suggested to remove this
• turn ‘Apply modal filter historical load’ on. This discards the lowest day of history from the average
• turn ‘calculate in day adjustment’ on and increase ‘load scaling’ to increase the weighting applied to todays’s load (mine is 1.15). This will adjust the predicted load based on what you have used already today
• increase ‘load scaling pv 10%’ to be more pessimistic about solar (mine is 1.1)
• increase best soc min (hard limit) and best soc keep (soft limit) to keep more in reserve in the battery for unexpected events. Beware of too high a minimum will result in charging in expensive slots to maintain that soc level
• train the family to do the washing when it’s cheap periods!

Cheers Geoffrey

First of all I'd like to comment what an excellent bit of work predbat is and to thank Trefor and all others who have contributed to it's development.

I had my first night of predbat controlling my battery last night. Currently just on an Eco 7 tariff so my charging needs are straightforward but I want to become familiar with predbat for when I switch to Agile in a month or so.

What I noticed last night is that my AIO charged at its max rate (5730W). As I have a 7 hour overnight window to charge I've been charging at a lower rate to both maintain a decent battery temperature throughout the night and also as there is speculation that charging at max rate increases the risk of loss of calibration/SOC accuracy issues. I had set the inverter limit in the apps.yaml to 3500W but this had no impact on the actual charge rate.

Is there a setting or scaling factor I can set to limit the charge rate to something other than the maximum?

Thanks in advance for any advice.

geoffreycoan
Many thanks for the suggestions, Geoffrey.

For your first point, it is not entirely clear to me why to exclude day 1 - please can you elaborate? Do you do this by setting days_previous to 8 and days_previous_weight to 0?

Your other points seem to be set as defaults already, which is good.

I have made suggestions about the timing of the laundry, and it has been made very clear to me that the only suggestion that would be welcomed in the future is one which involves me doing it. 🙂

Ivan What I noticed last night is that my AIO charged at its max rate (5730W). As I have a 7 hour overnight window to charge I've been charging at a lower rate to both maintain a decent battery temperature throughout the night and also as there is speculation that charging at max rate increases the risk of loss of calibration/SOC accuracy issues. I had set the inverter limit in the apps.yaml to 3500W but this had no impact on the actual charge rate.

Which setting did you change in apps.yaml, was it inverter_limit? According to the docs https://springfall2008.github.io/batpred/config-yml-settings/ you can set inverter_limit_charge to restrict the charge rate used.

PianSom I used to have days_previous set to 1 through to 7 to take an average of the previous week's activity, but in response to discussion over an issue I had, Trefor said that setting days_previous to 1 included today in the '1 day ago' calculation and that was skewing my load figures. TBH I didn't 100% understand this but changed my apps.yaml to:

 days_previous:
    - 2
    - 3
    - 4
    - 5
    - 6
    - 7
    - 8

  days_previous_weight:
    - 1

Yeah, the laundry, some things are best not interfered with. I've managed to get there by suggesting when the cheapest periods are and being proactive in setting the delay on the washing machine and dishwasher accordingly. This is the limit of my involvement !

I used Octoblock to calculate when the cheapest slots are and then some awfully complex Jinja coding to work out the start delays for the devices:

geoffreycoan Thanks Geoffrey - yes that was the setting I used. From the comments I suspect that must just limit the charge from PV?? Set it to 3600 but charged at the max rate.

Ivan Hi Ivan
If you set inverter_charge_limit it should do what you want, restrict the rate of charging, not charge at the inverter max (which is the default).
Inverter_Limit is used to model max inverter throughput, eg for solar pv charging. Ie so predbat knows what the maximum your inverter can charge at even if solcast says your panels are generating more.
The inverter_charge_limit isn’t in the default apps.yaml so you’ll have to add it in
Cheers Geoffrey

geoffreycoan
I wonder if Day 1 is today (since the implication of the holidays configuration suggests that it might be)? But then I don't see what may be wrong with including that ... Ah well, I am sure he and you are the sensible voices to follow, so I will do so blindly!

And I think I will leave calculated delays on starting the domestic machines well alone. The upside is limited, and the downside is horrible.

Ivan Do you have "Set Charge Low Power Mode" turned on?

geoffreycoan Thanks Geoffrey - I'll have a play with that tonight.

naltsta I did not - will also have a play with that tonight. Thank you.

Hi Geoffrey - for info I added this to the apps.yaml
inverter_charge_limit:

• 3000
  but it had no effect - still wanted to charge at the maximum.

I just allowed this to happen for a minute or so before switching on "Set Charge Low Power Mode" - this did reduce the charge rate to c. 1300W, which reduced further when the charge reached 90% SOC as I have the battery charge power curve enabled in the yaml.

naltsta See my comment above - the "Set Charge Low Power Mode" achieved my objective. Thanks.

Ivan Hi Ivan

Could you please raise an issue on the predbat GitHub https://github.com/springfall2008/batpred/issues so Trefor can investigate please?

From the documentation it looks like the inverter_charge_limit will do what you wanted it to, but sounds like it didn’t. The set charge low power mode I looks to be new and isn’t described in the documentation; must have been introduced to sort a similar bug but isn’t documented.
The docs should really guide which settings are to be used so worth getting it raised even if you’ve now got a solution.

Cheers Geoffrey

geoffreycoan Thanks Geoffrey - I've raised an issue.

For info low power mode is actually described under Inverter Controls

"switch.predbat_set_charge_low_power Enables low power charging mode where the max charge rate will be limited to the lowest possible to meet the charge target. Only really effective for charge windows >30 minutes. Off by default."

I've also commented on the above issue that I'm unsure of the maths as a full charge was achieved in just 4 hours of the available 7 hour window.

Cheers

Ivan Thanks I see your issue, and Trefor's reply that the apps.yaml entry is inverter_limit_charge

Looks like I mis-typed it ...

geoffreycoan Thanks - well it is easily fixed - I've give it a try tonight.

Thanks to you and Trefor for your help - I'm sure this won't be the last time I'll be asking for it!

Regards, Ivan

Tried Predate a while ago and wasn't sure so uninstalled it. Am on agile import and fixed export 15p/kWh so I am thinking of giving it another go. What's the best guide to installing it?

Wavy Davy https://springfall2008.github.io/batpred/

Probably worth watching all the videos through to 'Charts' and have a read of the instructions before starting the install. The only problem I had was that the default apps.yaml has to be configured for your own situation before predbat will run successfully.

Have started watching and installing, but not sure if appdaemon is installed correctly. I don't have a addon_configs file and cant find appdaemon anywhere. But hacs shows appdaemon as a option, so maybe it is installed ok.

Forget that it is in file editor now, so maybe needed HA restart.

It's downloaded but doesn't seem to be running. Have checked appdaemon logs and last entry says ready to run apps nut no sign of predbat. Have deleted the entries in the config.yaml but still not working.
Also still cant find the appdaemon.yaml file anywhere. Have appdaemon folder which has apps folder which has batpred folder and config.yaml and batpred.py files.

There is a line in config.yaml that needs to be removed once you have completed entering any required data in the config file.

Arg0t Thanks but have done that. What I think is the problem is that I cant find the appdaemon.yaml file.
It seems it has to be moved to get predbat to work, but I've disabled enforce basepath but still cant see it in the file editor.

ha I found it. now just need to find out what to do with it!!

This is added to mine

  time_zone: Europe/London
  thread_duration_warning_threshold: 90
  plugins:
    HASS:
      type: hass
      ha_url: http://127.0.0.1:8123
      token: <<create your own token in HA>>
      cert_verify: True

Think my brains frazzled. cant understand what "Add to the appdaemon: section apps_dir which should point to /homeassistant/appdaemon/apps"
Have added a directory apps_dir but what does point to mean?

Do you have this in the appdaemon.yaml?

  app_dir: /homeassistant/appdaemon/apps

ok so I added my ha url to the yaml file. but still cant see predbat running or added to the appdaemon.
yes this is my appdaemon.yaml
appdaemon:
latitude: 52.379189
longitude: 4.899431
elevation: 2
time_zone: Europe/Amsterdam
plugins:
HASS:
type: hass
http:
url: http://192.168.1.26:8123/
admin:
api:
hadashboard:

Just corrected Lat and Longitude settings as they were wrong.

I do not see the entry
app_dir: /homeassistant/appdaemon/apps

Do you see the Automation tab in HACS?
Did you add the custom repository in HACS?

Arg0t Yes I can see the automation tab and I do have predbat at the bottom of the screen. If I click it I get predbat page and no download button, so it did download.
Do i add the entry to the yaml file?

Have you watched this video? https://www.loom.com/share/d1f9e4432c2443eca1e236939b25bb99?sid=fe0627c7-85c1-4de4-a778-de50b58e4687

No will watch it now. Thanks

does this config look right?

the only files in the app folder were
apps.yaml
hello.py
both of which just had hello world in them.

Wavy Davy I just have the apps.yaml in the folder - think I deleted the hello.py. The apps.yaml is your configuration file for predat - you need to personalise the example apps.yaml file that is included with the download.

Ivan If you mean in the config folder then that's in there and personalised, also removed the 'template: True' line from the file.

in the appdaemon.yaml file does the app dir entry point to the app dir
(/homeassistant/appdaemon/apps/)
or where the apps.yaml file is (/homeassistant/appdaemon/apps/batpred/config)

Wavy Davy
yep -

Also change Amsterdam to London for correct time zone. (Edit - don't know why the font size/bold has changed!).

appdaemon:
latitude: 54.514821
longitude: -1.441296
elevation: 2
time_zone: Europe/London
thread_duration_warning_threshold: 120
plugins:
HASS:
type: hass
app_dir: /homeassistant/appdaemon/apps
http:
url: http://homeassistant.local:5050
admin:
api:
hadashboard:
logs:
main_log:
filename: /homeassistant/appdaemon/appdaemon.log
log_generations: 9
log_size: 10000000

I see from your config you have url: http://homeassistant.local:5050
I have the location url: http://192.168.1.26:8123/ which is my HA url

appdaemon:
latitude: 51.399151
longitude: -0.734351
elevation: 2
time_zone: Europe/Amsterdam
plugins:
HASS:
type: hass
app_dir: /homeassistant/appdaemon/apps
http:
url: http://192.168.1.26:8123/
admin:
api:
hadashboard:
logs:
main_log:
filename: /homeassistant/appdaemon/appdaemon.log
log_generations: 9
log_size: 10000000

Will change location.

Wavy Davy I'm part way through updating and enhancing the predbat documentation, the work in progress version is here: https://github.com/gcoan/batpred/blob/main/docs/install.md

Your predbat looks like it is installed in the right directory and the appdaemon.yaml configured to point to it. The lat and long don't matter what they are.

What do you get in appdaemon.log?

Hi Geoffrey, been having another play with it.
Here's a screen shot of logs

have found extended logs in appdaemon gui but its quite long, but looks like its trying to start predbat but not finding any entities.
I could post here if it helps.

Have just checked again and there are now some predbat entities appearing so maybe it was just a bit slow in creating them.

Wavy Davy Predbat writes voluminous logging information, and to make it easier to read it directs most of the appdaemon logging into a new logfile /homeassistant/appdaemon/appdaemon.log - you have to access this with a file editor (either the file editor add-on or visual studio)

Personally I use visual studio, but either will work

This bit isn't really covered in the docs so is something I will be expanding on as part of the doc refresh I'm doing

Have a look at that file and see what it says

Getting there !

geoffreycoan Thanks for the encouragement. Had a look at the logs and no obvious errors. Just going through the vids and creating a dashboard. Trying to find the charts in the git hub but not found them yet, but the entities are loaded and logging so good so far.

@Wavy Davy Here's the charts: https://github.com/gcoan/batpred/blob/main/templates/example_chart.yml

You have to copy each chart into a blank apex chart, can't copy the whole file into a dashboard

Do create a Predbat plan as well, that's most useful https://github.com/gcoan/batpred/blob/main/docs/output-data.md

Thanks for info, done all that, just got to digest it all now. will leave it in monitor for a week to get some data before trying out properly.

@Wavy Davy if you've got any questions, do ask as there's a few people using it.

Usually takes a bit of tuning to get the thresholds for charge, discharge and retained soc to be what you want them to be for your personal preferences.

I find the Predbat plan is the most useful to understand what Predbat is planning to do. That's the one I look at all the time. When I was on Flux I found the 'Home battery prediction' was the most useful of the Apex charts, but even with that there's a lot of info presented so I cut down what was shown and changed it to just the next 10 forward hours:

type: custom:apexcharts-card
header:
  show: true
  title: Home Battery Prediction (10 hours)
  show_states: true
  colorize_states: true
graph_span: 12h
span:
  start: minute
  offset: '-2h'
now:
  show: true
yaxis:
  - min: 0
series:
  - entity: predbat.soc_kw_h0
    stroke_width: 1
    curve: smooth
    name: actual
    extend_to: now
    show:
      in_header: raw
  - entity: predbat.soc_kw_best
    stroke_width: 3
    curve: smooth
    name: best
    data_generator: >
      let res = []; for (const [key, value] of
      Object.entries(entity.attributes.results)) { res.push([new
      Date(key).getTime(), value]); } return res.sort((a, b) => { return a[0] -
      b[0]  })
    show:
      in_header: raw
  - entity: predbat.soc_kw_best10
    stroke_width: 1
    curve: smooth
    name: best10
    data_generator: >
      let res = []; for (const [key, value] of
      Object.entries(entity.attributes.results)) { res.push([new
      Date(key).getTime(), value]); } return res.sort((a, b) => { return a[0] -
      b[0]  })
    show:
      in_header: raw
  - entity: predbat.best_charge_limit_kw
    stroke_width: 3
    curve: stepline
    name: charge_limit_best
    type: area
    opacity: 0.2
    data_generator: >
      let res = []; for (const [key, value] of
      Object.entries(entity.attributes.results)) { res.push([new
      Date(key).getTime(), value]); } return res.sort((a, b) => { return a[0] -
      b[0]  })
    show:
      in_header: raw
  - entity: predbat.best_discharge_limit_kw
    stroke_width: 1
    curve: stepline
    name: discharge_best
    data_generator: >
      let res = []; for (const [key, value] of
      Object.entries(entity.attributes.results)) { res.push([new
      Date(key).getTime(), value]); } return res.sort((a, b) => { return a[0] -
      b[0]  })
    show:
      in_header: raw
  - entity: predbat.grid_power_best
    name: power
    stroke_width: 1
    type: area
    opacity: 0.2
    data_generator: >
      let res = []; for (const [key, value] of
      Object.entries(entity.attributes.results)) { res.push([new
      Date(key).getTime(), value]); } return res.sort((a, b) => { return a[0] -
      b[0]  })
    show:
      in_header: raw
  - entity: predbat.rates
    stroke_width: 2
    curve: stepline
    name: import
    data_generator: >
      let res = []; for (const [key, value] of
      Object.entries(entity.attributes.results)) { res.push([new
      Date(key).getTime(), value]); } return res.sort((a, b) => { return a[0] -
      b[0]  })
    show:
      in_header: raw

Most of the other charts I never really use. Even now I still don't fully understand the Calibration chart !

Yes it's a bit confusing, I also seem to have lost a select_predbat_update entity. Sure it was on the predbat dashboard.yaml I set up before but did an auto update and maybe that's thrown it out of sync or some thing. But cant find the entity at all now.

Wavy Davy I also seem to have lost a select_predbat_update entity

Its select.predbat_update

geoffreycoan sorry my bad, that's what I have on the dashboard, but its not listed anymore for some reason.

That's funny, just searched the yaml file and its not in there, but it must have been there when I copied and pasted into the card otherwise it wouldn't be listed as a entity

Wavy Davy I have just updated to 7.14.29 and I do have the select.predbat_update entity present still, but in my case its now empty.
So something has gone wrong in the upgrade. I'll raise a bug report...

... just finished typing the bug report and the dropdown is now populated correctly. It may be that predbat needs a run or so after update to populate the dropdown again.

Is your entity reappeared now?

Its still confusing so I raised a bug report anyway https://github.com/springfall2008/batpred/issues/560

No it's still not there. I also raised a issue..
How did you do the update? I had mine set to auto.
We must have done them at the same time as yours wasn't there when I did mine..

Just rewatched the update video and Trefor's dashboard has an auto update toggle which I don't have. It must have been there before so it seems that's disappeared as well.

Wavy Davy there is a separate auto-update switch 'switch.predbat_auto_update'

Looks like Trefor is already working on a fix for this. I don't think he sleeps sometimes !

Did you mean to close the defect? https://github.com/springfall2008/batpred/issues/561

No I didn't realise I had. I just tried posting a screen shot

"switch.predbat_auto_update" don't have that entity either.

All working now. Have closed the issue. Thank you Geoffrey and Trefor.

Hello @geoffreycoan

I am having an issue with predbat that is slightly annoying. My system is over-discharging - so at the end of the day (before a charging slot starts at 23.30) it dumps excess power to generate income - great. The problem is that it dumps too much too early, so I have to go to the grid for 30 mins at 23.00. (I am away and in holiday mode at the moment, so things are pretty predictable.)

I thought the solution to my problem might be to increase "Best SOC keep" to something like 10 (I think the unit is %??). Do you agree?

PianSom you could use use best_soc_min or best_soc_keep.

The min specifies the minimum amount to keep in the battery and is a hard limit, so predbat won’t let the battery go below this. If need be it will charge the battery to ensure you have the minimum in.
Whereas keep is a soft limit that can be exceeded.

I’m surprised though that if you are in holiday mode predbat should be using yesterdays consumption to predict todays and shouldn’t be exhausting the battery so you need grid draw after discharge.

But yes set keep should keep more in reserve

Cheers Geoffrey

geoffreycoan I’m surprised though that if you are in holiday mode predbat should be using yesterdays consumption to predict todays and shouldn’t be exhausting the battery so you need grid draw after discharge.

Yes, me too. I had put it down to the vagaries of AIO BMS noise, but who knows. Seems to be consistent though.

Moving the “keep” to 10 produces some very odd plans (with projected min SOC above 35% by the end of the day). I will move to 10 anyway and see what actually happens.

PianSom keep and min soc are in kWh, not %, so if you are setting keep to 10kWh then you’re telling predbat to keep the AIO almost full.

Try setting it to say 1kWh if you just need a bit more retaining at the end of the day?

geoffreycoan
Ah, that explains it! My assumption (as I mentioned) was that the unit was %.

Moved to 1.

Thanks.

PianSom here’s the manual page BTW https://springfall2008.github.io/batpred/customisation/#battery-margins-and-metrics-options

I’ve been working my way through enhancing, updating and expanding the predbat documentation for Trefor to try to make it easier to follow. Have done the installation guide, energy rates and apps.yaml so far. Partly done the other pages but not end to end yet

geoffreycoan
Aha! It has been updated since I loaded it, and after a quick refresh it is now much clearer - thanks again.

(You may want to specify the units in that para, like you have in the following ones. Help an idiot. 🙂 )

PianSom (You may want to specify the units in that para, like you have in the following ones. Help an idiot. 🙂 )

That's one of the few parts of the Predbat docs I haven't done yet (saving the fun ones for last!).

I worked through tonight the 'what does predbat do' and 'installation guide' docs so did include this change as well. Its waiting for Trefor to approve the PR so the doc changes should go live soon.

geoffreycoan
Before I go and put a bug report together, if you have a mo I'd appreciate your thoughts on the following.

Tomorrow there is a Power-up 12-2.30pm. I have entered this in the appdeamon .yaml file (a few hours ago). The current plan includes this -

I am a bit confused about (1) why predbat is suggesting hitting the Power-up with an almost full battery and (2) why it is suggesting a discharge while free leccy is available.

Any thoughts?

PianSom I've got a power up event as well tomorrow, happy days as wifey wanted the tumble dryer on tonight otherwise!

This is nothing like my plan which is charging overnight, then using the electricity during the morning, then fully charging in the power up period:

There is a charge and discharge during the period like yours, but this I take to just be maximising the income as there's time in the 2.5 hour period to charge, partially discharge for export income, then re-charge to 100%.

What are your best_soc_keep and _min set to, is this preserving charge unnecessarily? The other thing I'd be wondering about is what's happening overnight (is there any charging going on earlier in the night) and whether you have enough load to discharge the battery?

At the moment I only have a single 5.2kW battery so I can get through it very quickly, but I did experience something like this once before with Predbat so I set it to read-only to stop it charging, then set it back to auto later on and it was fine.

What are your switch settings, in particular the different calculate_ switches?

Your solar forecast tomorrow is massive, are you sure it's grid charge?

geoffreycoan What are your best_soc_keep and _min set to, is this preserving charge unnecessarily?

_keep = 1 (was 0.8 until earlier today)
_min = 0

geoffreycoan what's happening overnight (is there any charging going on earlier in the night) and whether you have enough load to discharge the battery?

At the time of writing (10.45pm GMT) the battery is dumping charge to generate income. If it performs like previous nights it will stop discharging at 11pm, and then start charging at 11.30pm when the Intelligent Octopus Go cheap rate starts. Though - oddly - I expect it will fully charge, even though it knows there is a Power-up coming.

Load atm (holiday mode) is an almost completely constant 0.3kWh per half hour slot.

geoffreycoan What are your switch settings, in particular the different calculate_ switches?

As shown -

Arg0t Your solar forecast tomorrow is massive, are you sure it's grid charge?

Solwise projection shown below. (Ignore times - seems to be picking up my local time, rather than GMT.) Roughly 2x today 8th, and roughly the same as was achieved on 7th. So not massive.

I actually think I need to increase _keep further. As with previous nights, I have hit 11pm with the battery fully discharged following an income-generating dump and have now started importing - which is stupidly wasteful

PianSom all these settings look reasonable and match my own configuration.

Like @Arg0t I agree your solar forecast looks huge. 2.6kW in a half hour slot, sounds more like summer generation than winter.
My total generation for today was 3.7kW, and I’ve got 14kW across 3 arrays. Peak 1-hour output was only 1kW and that was at midday. You’ve got more than twice that in half an hour. Must be a massive panel you have!

But regardless of whether your Solcast is wrong or not, doesn’t explain why predbat isn’t looking far enough ahead to limit the overnight charging and then take advantage of the free electricity.

If the plan doesn’t improve tonight as it starts charging overnight (and predbat’s forward window reduces) I’d be inclined to put an automation in triggered at say 3am to put predbat into read only, cancel the charge and then turn read only off at say 8am.
And yes put a GitHub issue in

PianSom just thought of another easier way of stopping the import overnight, put a rate import override in apps.yaml to dissuade predbat from charging all night

Eg 3am to 8am import rate 300

geoffreycoan
Here are my production nos from 7th -

I have 8.8kW (20 x 440W panels, facing SSE), with a 6kW inverter. I keep an eye on the output from the inverter, and compare to the power received by the AIO and the power seen by my Harvi - I have not seen any anomalies. Total generation today was approx 1.7kWh, peaking at 0.8kW (considerably less today than the peak Solcast forecast of about 2.3kW; generally speaking it is closer than this).

I won't change anything more tonight - lets see what happens tomorrow.

PianSom OK, I looked at my figures for the 7th (today was worse) and its similar, a total of 9.6kW across my 3 arrays so I can believe yours now

Just today's figures are awful.

Still think it would be worth dissuading predbat from fully charging the battery overnight with an import rate override if it charges the battery up too much. It is possible that as the forward window rolls forward it works out that it doesn't need to charge as much, but the rate override would encourage it further and this is much simpler than an automation.

geoffreycoan
FYI Solcast data

geoffreycoan Still think it would be worth dissuading predbat from fully charging the battery overnight with an import rate override if it charges the battery up too much.

I guess I had hoped that predbat didn't need dissuading!

In the end, the absolute amounts of cash involved in any given day are small, so I'd rather focus on tweaking settings than introducing manual amendments to achieve a short term goal.

I'm just happy that you are as confused as me about what is going on - at least my understanding is not fundamentally flawed. Thanks.

PianSom no problem. HTH. As you say the sums involved are quite small, but worth still raising a GitHub issue if you can. 98% of the t8me predbat does exactly what I think it should do, but sometimes it still throws a curveball

PianSom can you share all your settings and the full plan? The PV forecast still seems very optimistic in Predbat, close to best from solcast.

Arg0t
Please see below. Apologies for the poor readability - couldn't think of a quick, better way.

I agree the solar looks optimistic. But, as Geoffrey points out that doesn't explain the lack of export pre-Power-up.

ps current pv production

This deserves a github issue. Would have expected it to discharge to a minimal level after 5:30, export the solar directly to grid and then recharge on the grid from 12. Can understand a discharge during the free energy section if the solar + import over the period is greater than your total battery capacity. Charge, Discharge, Charge earns you more than sitting on a full battery with free import.

I'd be tempted to dial down the metric battery cycle cost closer to 0, you've paid for it and it's under a lifefime warranty with unlimited cycles. I'd also switch off combine charge slots, set load scaling and load scaling pv10% to 1 and increase metric 10 weight to .2.

@PianSom your settings are very similar to mine. You've set a battery metric at 2p which would dissuade predbat slightly from cycling the battery (I have mine set to 0 as I take the view I've invested in the battery so want to use it, and manage the 'when to discharge' based on the % losses). So could try changing that to zero.

Also I see you have charge on discharge turned on. I do as well, but sometimes I have found you can get better plans by turning that off, or turning it on. Its just one of those things that is sometimes worth changing.

Assume you have an EV? num_cars is set to 0 (otherwise the car charging data would be in the predbat plan) but intelligent octopus charging is turned on in HA. Probably makes no difference but?

Looking at your discharge before overnight charge, it looks OK and should keep enough in reserve to prevent unnecessary import. Wonder if there is something wrong with the discharge rate being higher than predbat thinks it is if you keep running out?

I wonder also about your inday adjustment damping factor, this being set to 0.95 is counteracting the load scaling, and since you are in holiday mode, is this combining to under-represent the daily load? My damping factor is set to 1, and load scaling to 1.15

geoffreycoan
Good to know, thanks Geoffrey.

To address your thoughts:

• battery metric is (like most settings) as per defaults atm. Theoretically, I think that the 2p concept is ok - although the capital cost is sunk, my guess is that effective lifetime may be reduced by excessive charge/discharge cycles.
• I have no idea what charge on discharge does! I'd better rtfm
• Although I am on IOG I do not currently have an EV (shh!). One is arriving hopefully next month.
• I wonder too if there is something wrong with the discharge rate. In any case I will raise the _keep level to 1.5 later today.
• Again, I have not changed inday damping and scaling from defaults as yet. Seems unlikely that these could be causing the issues I am seeing.

FYI today's chart so far; I have just hit my DNO export limit -

geoffreycoan PianSom

I’m on Eco 7 and despite the simple battery charge regime, I am using predbat to control that battery in order to become familiar with its workings as I intend to switch to Agile in the next month or so.

Predbat, rightly chooses the 00:30 to 07:30 cheap rate window to charge the battery. I have the ‘Set Charge Low Power Mode’ enabled which is meant to set the charge to make full use of the available charge window. Generally, predbat fully charges the battery (to 99%) at around 05:30 – and then for the remainder of the cheap rate window it starts cycling between discharging the battery to cover the house lead and recharging. What it should be doing during this remaining cheap rate window is hold the battery as fully charged and cover the house load from the grid.

![

I note that PianSom had a similar charge/discharge cycle last on this morning’s charge – I assume this is not intended??
Before I raise this as a github issue is this a consequence of any setting I may have adjusted in error??

Arg0t
Many thanks - I will try your suggestions

Ivan
No, certainly not intentional!

I’m slightly loathe to raise an issue on GitHub, because all I can say is “things aren’t working like I’d hoped”, which is not much use to a developer! I’d rather be able to point at a specific case of error.

PianSom

battery metric is (like most settings) as per defaults atm. Theoretically, I think that the 2p concept is ok - although the capital cost is sunk, my guess is that effective lifetime may be reduced by excessive charge/discharge cycles.

The default for battery metric is 2p. If you've got an AIO then the warranty is for unlimited cycles (as is my 9.5) so hence my 'use it as I've got it' logic. TBH it probably makes little difference to the overall cost plan whether you have this set to 2p or,0p.

I have no idea what charge on discharge does! I'd better rtfm

Charge on discharge is to allow predbat to discharge in what would otherwise be a charging slot. If you turn it on then you (could) get more discharging, looks like this in the plan:

Its one of those settings that I've not found a good value for. Sometimes having it on makes the plan better, sometimes having it off makes it better. In my opinion anyway. Worth trying to change.

I wonder too if there is something wrong with the discharge rate. In any case I will raise the _keep level to 1.5 later today.
Again, I have not changed inday damping and scaling from defaults as yet. Seems unlikely that these could be causing the issues I am seeing.
I just checked the code and inday damping factor defaults to 0.95 (so you are on the default) and load scaling to 1.0 (you are on 1.15 as am I).

Load scaling of 1.15 will be taking a more pessimistic view of your historical load, so setting it to 1.15 means predbat will predict that today's consumption will be 15% more than yesterday's

inday adjustment is turned on so Predbat will be calculating the difference between your historical load and current today's load, and using that to adjust the prediction of what today's load will be.

The effects of these two is going to adjust your historical consumption, and given that you are on holiday and have said that your consumption is fairly flat, then I wonder whether these should either be ignored when in holiday mode, or whether there should be advice in the documentation for the user to review and change these when going away?

I've raised issue 602 to seek Trefor's thoughts on this https://github.com/springfall2008/batpred/issues/602

Just to close off this protracted discussion - I think it is fair to say that Predbat has not covered itself with glory today.

To summarise the starting position

• I am on Intelligent Octopus Go, with low (7.5p) import pricing 23:30-05:50, and high (31p) pricing at other times. My export pricing is a fixed 15p
• There was copious PV generation forecast for today. While the early forecast was not met, I managed 16.2kWh of sunny electrons
• I had an Octopus Power-up (ie 0p import pricing) 12:00-14:30. This was entered into the predbat yaml yesterday (ie in very good time)
• I am away (and predbat is in holiday mode), with consumption being pretty flat at around 600W (forgot to turn off the Quooker so there will be odd spikes!)

This is what my chart looks like for today -

Some observations

• I imported 21.2kWh, exported 7.7kWh and generated 16.2kWh
• Unlike some days, today predbat chose not to do significant export during the early morning cheap charge period. Instead after initial charging (other than two short export periods) it chose to cycle through running load and topping up. Don't know why
• Predbat did not get the battery to 100% during the morning. This was only achieved when the pv generation kicked in later.
• Even though the Power-up was known in advance and there was copious forecast and realised pv generation, no significant discharge to generate income took place. HUGE missed opportunity. The biggest issue of thee day.
• During the day I increased best_soc_keep to 1.15, to avoid the 11pm import that has been plaguing me the last few days. Fail!! Still had my late import.

Generally I am pleased with predbat. But today was not a good day.

Yesterday was not a good day for me also. Agile rates are not great at the moment but last night predbat was only going to charge my batts upto 71% and not charge them again until 10:30 tonight. They would have no chance of lasting that long, so reluctantly I set predbat to monitor/read only and switched back to bottlecap Dave's automation which was scheduled to be on from midnight to 1:00 and 1:30 until 6 am. I've switched back this morning
But it still looks strange for the rest of the day/evening.

Wavy Davy
Very odd.

I do wonder what the logic is. It is a horrible multi-variate equation to solve, and I guess sometimes it just gets it wrong. In your example I can't see any reason why it would stick to 60% in the evening; in mine there was no good reason to fully charge before a deluge of free power arrived. In both there seems to be a fairly obvious (to human eyes) better solution.

I guess I will take the rough with the smooth for a few weeks more and see how it goes.

EDIT - on reflection, I think I may be wrong about my human solution being obviously better. Maybe predbat was right to load up with 7.5p electricity and dump it at 15p. But then if it was going to do that then why didn't it dump it all? It's very hard ...

Just wondering if having Nordpool enabled is causing problems, so I think i Will disable it and see if that makes any difference.

I’m also sometimes having unusual behaviour - currently Predbat is holding charge when the cost is 24p. It charged at 14 or 15 overnight, so even with round trip losses it would be saving by using battery. It could be saving it for the evening peak, but looking at the prediction it would still have 50% even after the peak, so shouldn’t need to hold that much charge. I would have thought it should discharge for the 24p slots, then hold charge on the slightly lower priced ones.

Wavy Davy Your issue is with the freezecharge early in the morning? For me rest of plan looks ok, it charges adequately overnight and then has PV top off the batteries to 94%. In the evening it uses the grid to cover load early evening and then tops off the batteries from grid to 100%, using the grid avoids conversion losses and any battery cost metric you have maintained.
Is the calculation overly optimistic on the PV generation, pessimistic on the house load?

Boffinboy Something not right there, do you have a very high SOC keep or Best SOC Min value? do you have combine charge slots on?

These settings work generally well for me, they do result in a little more charge in the batteries than desired but overall they are suitably optimistic on my calculating the house load and PV and adjusting to any variations through the day. In my apps.yaml I have 2,3,4,5,6,7,8,14,21 maintained as historic dates considered in the plan so I get a very blended predicted load that isn't overly skewed because of cooking a massive Christmas dinner or everyone being off work for a week.

Arg0t Looking at the settings you have, there are some differences.
On mine I have the metric battery cycle cost is set to 2 where yours is 0
my metric future rate offset import is 0 where yours is 1
my in day adjustment is 0.95 yours 1.1
my Rate Low threshold 0 yours 0.9
My Plan forecast hours 24 yours 48
My HTML Plan Debug off yours on.
Not sure if any of these would help but will change them and see if I get a better forecast.

Also re the historic dates I assume the yaml setting is days_previous:
- 2,3,4,5,6,7,8,14,21

but if I try that I get this error.

Wavy Davy you need to enter each days_previous on a separate line

days_previous:
 - 2
 - 3
 - 4

days_previous_weight defaults to 1 so unless you want to weight the different historical days, just having a single entry '-1' is sufficient

I have updated the apps.yaml documentation for predbat with some examples to make this clearer. It'll get pushed through in my next doc update, but here's the fork: https://github.com/gcoan/batpred/blob/main/docs/apps-yaml.md

Arg0t Wavy Davy it’s a bit puzzling! I remembered I had set the forecast to 32h briefly, putting that back to 24 improved things. Still doesn’t seem to be discharging as much as I’d expect - was working consistently well previously. I don’t have combine discharge or charge on. I only have a soc keep of 0.3. My settings are slightly higher on inverter loss, and battery loss, and the default cycle cost - but even so, I would have expected it to discharge through some of the >24p slots

geoffreycoan in config.yaml Is there anything required before the entry
recorder:
purge_keep_days: 14
As I'm getting a error

Also seem to have a couple of template errors cropped up regarding binary_sensor.octopus_energy_target_my_charge_slots but don't think their related to this issue as they are showing as unavailable

Wavy Davy remove the 21, I have an external DB that gives me a longer history.

Arg0t thanks argot but the error is in the config.yaml and relates to the recorder entry.
Have tried changing the indent and also tried adding a "- " to the beginning so it matches the other entries but still get the error.

Wavy Davy

On mine I have the metric battery cycle cost is set to 2 where yours is 0 = Batteries are paid for, there is no actual cost or loss for using them. Conversion losses are real and have a financial impact.
my metric future rate offset import is 0 where yours is 1 = This causes predbat to predict that future rates will be more expensive than current rates, by at least 1p. Encourages taking advantage of current rate rather than guessing tomorrow might be cheaper.
my in day adjustment is 0.95 yours 1.1 = if my usage is higher than forecast then make the rest of the day higher.
my Rate Low threshold 0 yours 0.9 = this reduces the number of low rate slots and creates a real band between the high and low rates.
My Plan forecast hours 24 yours 48 = weirdly this does make a difference and I often flip this when predbat is predicting a weird night.
My HTML Plan Debug off yours on. = this adds conversion losses to the plan html, which I find informative.

Arg0t HTML Plan Debug off yours on. = this adds conversion losses to the plan html, which I find informative. I noticed the extra info but didn't understand what it was. I agree handy to know exact figures.

Boffinboy the loss parameters have a significant weight in the calculation, too high and using your battery will not be cost-effective in any low rate slot and discharge will only happen when there a rates significantly lower than 15p or excess PV.
The defaults are fairly reflective of actual losses and I'd recommend sticking with the 3% for battery losses and 4% for inverter loss.

Arg0t I'd recommend sticking with the 3% for battery losses and 4% for inverter loss.

Are these values reasonable for an AIO? I am rather hazy on the efficiency difference for different systems

Arg0t Could I ask you to share your config.yaml entry for the recorder part. Cant seem to get it right without error.

PianSom I'm not sure sorry, the process is the same with conversion from AC to DC to AC through the inverter so inverter losses should be similar, however I do not know if the different battery chemistry in the AIO has a material impact on battery losses.

Wavy Davy

Configuration.yaml for HA. NB I have a postgres DB setup to handle such a long history. Modifying purge_keep_days will store that in the HA DB but this can impact performance of HA. Default purge, if the value is not maintained, is 10.

# Database
recorder:
  purge_keep_days: 365
  db_url: !secret psql_string
  db_retry_wait: 15 # Wait 15 seconds before retrying
  exclude:
    domains:
      - automation
      - updater
    entity_globs:
      - sensor.weather_*
    entities:
      - sun.sun # Don't record sun data
      - sensor.last_boot # Comes from 'systemmonitor' sensor platform
      - sensor.date
      - predbat.plan_html
    event_types:
      - call_service # Don't record service calls

predbat apps.yaml

  # Days previous is the number of days back to find historical load data
  # Recommended is 7 to capture day of the week but 1 can also be used
  # if you have more history you could use 7 and 14 (in a list) but the standard data in HA only lasts 10 days
  days_previous:
    - 2
    - 3
    - 4
    - 5
    - 6
    - 7
    - 8
    - 14
    - 21
    - 28

  # Days previous weight can be used to control the weighting of the previous load points, the values are multiplied by their
  # weights and then divided through by the total weight. E.g. if you used 1 and 0.5 then the first value would have 2/3rd of the weight and the second 1/3rd
  # Include one value for each days_previous value, each weighting on a separate line.
  # If any days_previous's that are not given a weighting they will assume a default weighting of 1.
  days_previous_weight:
    - 0.8
    - 0.8
    - 0.8
    - 0.8
    - 0.8
    - 1.0
    - 0.8
    - 0.8
    - 0.8
    - 0.8

Thanks that seems to have got rid of that error, just now need to find out why binary_sensor.octopus_energy_target_my_charge_slots is showing as unavailable for the last few days.

Arg0t thanks for this. Even tuning them down I get odd behaviour. Turning on html debug was very helpful to see the values with loss. Even then I get some odd behaviour. In this screenshot I’d imagine it should be allowing the battery to be used in the slots circled, since even with losses the early charges would save money, but it keeps charging. I just tried turning the low rate threshold to 0.9 and that made a huge difference and broke up the plan.

When does the cost total reset.
was wondering if its a day or if not what amount of time.

@Wavy Davy total cost resets to zero at midnight but the predbat plan always shows total cost from midnight today, so cost at say 4pm tomorrow on the predbat plan will actually be 'actual cost up to now today' + 'projected cost from now to 4pm tomorrow'

I personally find this a bit confusing but its the way it works. But at midnight the cost column on the plan will reset to counting from zero.

Boffinboy here's my plan for tomorrow, it starts releasing the charge in those circled slots as you were expecting it to do

my low rate and high rate threshold are both set to zero

try turning combine charge slots off. that can make quite a difference sometimes

looking at your differences to @Arg0t 's settings:

metric_battery_cycle_cost of 2 will mean it "values" each cycle (charge & discharge) at 2p, so won;'t charge or discharge unless there's at least 2p cost benefit. I leave mine set to 0 as I have already paid for the battery so want to utilise it

metric future rate import is an offset to add to future agile prices for tomorrow before they are published. I have mine set to 0, the nordpool does a good enough job

in day adjustment adds a factor to adjusting your today's planned consumption by how much you have already consumed. 1.1 means if you are already consuming more today then assume (by +10%) that it'll continue. Useful if you have a heat pump and its a cold day already so likely to remain cost = more electricity

geoffreycoan thank you. I already have combine turned off…. I do have charge cycle at 2 and inverter loss, but looking at the raw numbers with loss it should still discharge. Have opened an issue to try and see if I am misunderstanding how it calculates. The fact that setting the low threshold to 0.9 changes it must mean something

Think I may have discovered a bug - or the documentation is unclear. I turned cycle cost down from 2 to 0, I get the argument of sunk cost of battery intended to be used. I had assumed this was the cost in pence for a full cycle, 9.5kW, but looking at the two screenshots below the full 2p appears to be applied to the rate for every slot. That can’t be right. Impact on cost per kWh should presumably be 1/9.5*2 = 0.21p

Boffinboy actually, thinking about this further - a cycle is 9.5 x 2. So per kWh it should be 1/19 x 2p difference in rate. I have an open issue where Trefor seems to confirm the full 2p is applied to kWh rate. Presumably either that calculation should change, or the documentation should make it clear that this is cycle cost per kWh, not for a full cycle.

Have an issue raised, I think it’s just a clarification in the language - the setting is actually the cost per kWh cycled, not the cost for a full cycle

All - Trefor is asking for some feedback on the new "save settings" feature on GitHub

Boffinboy Have an issue raised, I think it’s just a clarification in the language - the setting is actually the cost per kWh cycled, not the cost for a full cycle

I saw your issue. Likely will need to clarify it in the docs.

At the moment I'm very happy with predbat as its doing precisely what I want it to. Charging in the cheapest slots, discharging when the export rate is > import and is going through a pattern of charging overnight, letting the battery be used in the morning as the rates rise, then mid-day charging through to the evening peak when it gets released again.
Over the last 3 months I've been on agile my average per kWh import cost is about 18/19p, a third less than the standard variable rate, and that's with high consumption (40-70kWh a day)

Mines nearly there but I wish it would charge up to 100% before mid morning.
It doesn't get to 100% at all tomorrow.

geoffreycoan I’m currently seeing better average cost than I did on Cosy, and using a bit less (with Cosy I just charged to full twice, and there are definitely significant conversion losses). Very happy with it.

Wavy Davy Do you need 100% or is that just preference? If your predicted load is less than battery capacity, or loss calculations make grid use cheaper, it will not charge.

Just a preference , but my wife prefers to use the dishwasher in the evening, so concerned that the capacity won't be enough. It did last but was down to about 17%. Will persevere with it and keep monitoring it.

Wavy Davy I get the charge anxiety also!
If the evening dishwasher is a common activity, then it should be in your load history and part of the plan. For everything else, play with the Best SOC Keep to give yourself a couple of kWh of reserve for the abnormal loads, just remember the value includes the reserve.

the washing machine is a bit more of a problem, as it goes on at irregular intervals, so not as predictable.
Have increased the soc to 2.2 to see if it helps.
Today is a bit of a worry as there's no planned charge until midnight. Fingers crossed the predicted solar of 4 kWh will get us through. Roll on summer.

Lost my nerve today. It ran my batteries down to 4% and wasn't going to charge higher than 88% and then not charge again until 21:30.
Just seems very low charging soc.
Put it on read only and enabled bottlecap Daves automation to charge it up.

Wavy Davy my plan is similar, I let it do its thing. I'm at 66% and forecast to get to 8% with those numbers reliant on a little PV today.

I find you can make the system a little more aggressive, in charging, by increasing Metric Future Rate Offset Import. Making this 1 to 1.5p results in the calculation expecting todays import rates are lower than future rates, in my experience this results in charge to higher percentages as the system tries to make a cost benefit of the lower rates. NB can lead to higher costs and to some export if solar generation is better than forecast. In my plan above this is set to 0.

There's a passing comment over on Github that one user needs to amend Predbat (to turn off Combine Charging windows) for the DFS/Saving Sessions.

As a new user I'd be interested to hear people's experience of DFS sessions and Predbat last year - did it work well?

Arg0t As I said I set the status to read only, but for some reason after I went to bed it changed back to normal, so didn't charge as I hoped. I checked my Metric Future Rate Offset Import and it was set to 0. have set it to 1 but as yet its not made any noticeable difference in the chart, currently on 66% soc and not due to charge again until 21:30.
Will let it run and see how it does.

Arg0t You said you use an external database for predbat. is that easy to set up? For HA I use a dell thin client with 8gb ram and an internal 128gb ssd which is showing as 8.5% used, so should have plenty of room for use as storage. So would be able to extend the days previous table, or maybe don't need a external database to do that, just set it to 24 days.

Wavy Davy you can read about it here https://www.home-assistant.io/integrations/recorder/, I have postgres running in a container and the HA DB runs in postgres. It's fairly straightforward but overkill.

If I recall correctly you can extend the retained days, without an external DB, by changing/adding purge_keep_days in HA configuration.yaml. This can have a potential to slow your machine down significantly. Strongly advise taking a backup before playing with these settings or DBs.

recorder:
  purge_keep_days: 28

Wavy Davy

Yeah, I think my use case is to always charge to 100% at night on Flux, but I'd like it to only give a day rate bump charge if the battery is low prior to flux peak rate.. but I've been trying to work out how to configure that in the settings, charging to 65% because its going to be a sunny day isn't worth the risk, and I'd rather be exporting early.

I think this is very much weighted towards agile.

neomancer It's weighted towards lowest possible cost rather than a specific tariff, of course your personal environment impacts the best tariff and the optimisations that predbat can make with the tariff.
Personally I've run out of battery twice in 4+ months of use, both related to a BMS drop lowering the SOC rather than a poor predbat prediction. I however understand the safety net of utilising the lower rate slots to charge as much as you can, accepting the higher cost for the comfort of spare capacity. I'd encourage tweaking your best SOC keep slightly higher, creating an artificially higher floor in the plan, and letting it run for a few days to build trust.

Wavy Davy Did it make it through the day? My actual usage was much lower than the plan and PV was double the solcast forecast, net result my SOC is 40% higher than the plan at this point. Cost for the day 74p

It's at 16% against a hold charge value of 14% so yes its making it at the mo. Will charge to 30% at 21:30 and to 100% later in the morning.
Will persevere with it with fingers crossed.

PianSom As a new user I'd be interested to hear people's experience of DFS sessions and Predbat last year - did it work well?

In the early DFS sessions I found that Predbat wasn't discharging the battery sufficiently, it started the discharge then stopped it, then resumed it, etc. So after this experience I wrote my own automation script to turn predbat into read only, do my own force discharge, then turn predbat back on after the session ended.

Ran like this for a couple of sessions but did raise an issue that Trefor issued an update for. Long story short after further testing I have disabled my automation script and now entirely let Predbat manage the DFS session. My experience has been that its charged the battery prior to the peak then it holds enough SOC for a full rate discharge during the saving session.
We've even had some really weird scenarios just before Christmas of a Power up (0p import) session immediately followed by a DFS saving session. Predbat has managed the battery perfectly through all that, no issues.

Arg0t I find you can make the system a little more aggressive, in charging, by increasing Metric Future Rate Offset Import

Good tip, I'll add this to the documentation. I've been working my way through expanding the docs for Trefor, still got the main configuration doc to do but have done most of the others now.

Arg0t If I recall correctly you can extend the retained days, without an external DB, by changing/adding purge_keep_days in HA configuration.yaml. This can have a potential to slow your machine down significantly. Strongly advise taking a backup before playing with these settings or DBs.

There's instructions in the predbat installation docs for how to extend the history in HA if you need to for predbat. I don't know for sure if this was the cause but I had extended my history to 30 days and all was running fine until I came to apply a HA update when it basically wouldn't install. This happened with several 2023.9.* updates and I tracked it down to the upgrade process failing in a database purge. I eventually managed to get an upgrade to apply and then a day later I awoke to an empty HA system as the database had been declared as corrupt.
I integrity checked and put the database back and the next night same thing happened, probably when the recorder purge was running.

So end result is I lost about 3 months of HA history and had to start again.

I've since watched one of the HA release videos (from 2022.9 I think) where they basically said that when they introduced long term stats and reengineered the database their advice is now that people don't need to and shouldn't extend their purge history (even suggesting reducing purge to 2 or 3 days). They acknowledged that in the past people had used their own db because of history limits that were now not there. If people wanted to use their own db they of course could still do so but that they didn't recommend it and basically you were on your own if there was an issue.

I worked in IT for my career but I never wanted to be a DBA and now I definitely don't so I've extended my history from 10 to 14 days but am not going any further nor swapping to another DB.

Just my 2p worth.

neomancer Yeah, I think my use case is to always charge to 100% at night on Flux, but I'd like it to only give a day rate bump charge if the battery is low prior to flux peak rate.. but I've been trying to work out how to configure that in the settings, charging to 65% because its going to be a sunny day isn't worth the risk, and I'd rather be exporting early.

I think this is very much weighted towards agile.

I was on Flux with Predbat before I went to Agile for the winter. As @Arg0t says, Predbat will do a least cost optimisation. In my view charging the battery fully up overnight so you start exporting sooner is not cost effective. The overnight import rate is very similar to the day time export rate and by the time you include conversion losses you're actually losing something like 1p per kW.
Its better to only charge enough overnight to see you through the next day + PV topup.

You can always tweak the PV weightings to be more pessimistic which will increase the overnight charge %

I have come to the conclusion that
1 - predbat is much cleverer than me, and
2 - predbat is much better than me about getting stuff done.

Yesterday was a Power-up day - and the coldest day of the winter so far. My battery started the day (as it does most days) almost empty, charged and discharged while the electricity was cheap (to generate some cash while I slept). Then did a full discharge before a morning Power-up (and lots of sunshine) and charged (with a little discharge, cos it's rude not to) while the electricity was free. Then let the evening and afternoon load drain the battery down, with a quick discharge at the end to earn a bit more cash before starting it all again when the cheap rate started at 11.30pm.

Imported 33kWh (approx £2), generated 18kWh (good for Jan), consumed 29kWh (a heavy day), exported 15.5kWh (£2.42)

(I am sure some will be concerned with the battery/component wear and tear associated with two full charge/discharge cycles in 24 hours. But until someone tells me that the kit is not meant to be used this way it seems to me that it is what it is there for. Over a 12y warranty period if every day was like this (which obv it won't be) then I'd make about 1/3 of the cost of an AIO back and have all my electricity for free.)

I am increasingly impressed with predbat.

PianSom Excellent results, Predbat is as you say, cleverer than us!

I too am very impressed and am positive about Predbat, 99% of the time it does what I want it to without me having to touch it at all. Its worked flawlessly in the power up events and is doing a great job of eking out my battery to reduce peak grid import. Like you, a couple of charge/discharge cycle a day at the moment.

I do have to report though that it didn't work as expected in the recent DFS saving session. The session was in the peak period and we're usually cooking and the heat pump is on, so historic load was about 3kW vs 2.6 max inverter output. When the saving session started Predbat set itself to Eco mode which would normally be enough to support the house load, but of course the load was much lower than normal and I didn't get the force discharge I anticipated. Had to set predbat to read only and force the discharge myself.
Previous DFS sessions have been fine so I think this is as a result of the colder weather and more base load that Predbat got the plan wrong (for me). Have raised an issue on it

geoffreycoan
As I just mentioned on the other thread, we both will have a Power-up 7pm-11pm tomorrow. My IOG low cost rate will then start at 11.30pm.

This has all the makings of a great test for predbat.

geoffreycoan I refuse to accept that predbat is cleverer than me (although Trefor is!)

I am just not prepared to look at the data every 5 minutes 24 hours a day…

geoffreycoan When the saving session started Predbat set itself to Eco mode which would normally be enough to support the house load, but of course the load was much lower than normal and I didn't get the force discharge I anticipated

New “load reduction for saving session “ introduced in the latest predbat release, should resolve my issue of Eco mode not force discharge.

Also new ability to set slot override for charge, discharging and idle. Very useful

naltsta I refuse to accept that predbat is cleverer than me (although Trefor is!)

I am just not prepared to look at the data every 5 minutes 24 hours a day…

I've been playing around with the new Predbat 'manual mode' to over-ride the Predbat plan, setting charge and discharge slots.
Not tested exhaustively but when I have configured my own slots, the Predbat cost prediction afterwards is worse than if I'd left Predbat to do its own thing. So far Predbat is outsmarting me!

The manual override is useful if for example there is more house load than predicted and you want to stop a force discharge that won't get exported for profit.

Hello @geoffreycoan

I want to change my load prediction so that it is a lot like the same day last week, and a bit like the same day the week before. At the moment I have in my apps.yaml

  days_previous:
    - 7
    - 14

  days_previous_weight:
    - 2
    - 1

but I am getting a bit confused about days numbering.

Is today day 0? If so then why isn't day 1 used for the example weekly averaging (so days 1-7 rather than 2-8 as stated in the manual)?

Or is today day 1? In which case, why does the manual say to use days 7+14 for weekly average (rather than 8+15)?

I think you mentioned you had had a conversation with Trevor about this in the past ...

PianSom how do you go back further than 10 days? It’s that some home assistant history setting you have to change rather than something in GIvTCP?

naltsta
Yup. It’s actually set out in the predbat manual.

(Apologies for no link - on phone atm)

geoffreycoan How do you use the new functions like the Manual override.
I looked for a switch but cant find one.

Wavy Davy Its a select not a switch.

      - entity: select.predbat_manual_charge
      - entity: select.predbat_manual_discharge
      - entity: select.predbat_manual_idle

PianSom naltsta
Yup. It’s actually set out in the predbat manual.

I wrote that !

https://springfall2008.github.io/batpred/apps-yaml/

Wavy Davy How do you use the new functions like the Manual override.

Its at the bottom of this page of the documentation https://springfall2008.github.io/batpred/customisation/
As @Arg0t says, there's three new select switches. You'll need to add them to the dashboard

PianSom I want to change my load prediction so that it is a lot like the same day last week, and a bit like the same day the week before. At the moment I have in my apps.yaml
days_previous:
- 7
- 14

days_previous_weight:
- 2
- 1
but I am getting a bit confused about days numbering.

Is today day 0? If so then why isn't day 1 used for the example weekly averaging (so days 1-7 rather than 2-8 as stated in the manual)?

I've been looking at the Predbat code. From what I can understand, day 0 is today, day 1 is yesterday so to average the same day as today from a week ago and the week before that it would (logically) be:

days_previous:
- 7
- 14

I know the documentation is a bit unclear, trouble is that is a mixture of what Trefor originally wrote and then what I added based on advice he'd given me about avoiding today in the history.

I have logged an issue to get clarity https://github.com/springfall2008/batpred/issues/647

geoffreycoan there's three new select switches. You'll need to add them to the dashboard

@Wavy Davy - in case it helps, here's the code I use on my dashboard (to match the standard collapsible cards one):

  - type: custom:collapsable-cards
    title: 🔼 Manual overrides
    defaultOpen: false
    cards:
      - type: custom:auto-entities
        card:
          type: entities
        filter:
          include:
            - entity_id: select.predbat_manual_*
          exclude: []
        unique: true
        sort:
          method: friendly_name
          numeric: false

PianSom

See the Predbat issue I logged for the explanation, but basically the examples in the documentation are actually all correct. For your requirement, same day as today and a week ago, then days_previous should be set to -7 and -14 as you have them.

I'll go and lie down with a wet towel on my head whilst I work out how to explain how this works to any lay-people that may have wandered in the room ....

geoffreycoan makes perfect sense! Do you know how forecast_hours in apps.yaml and the forecast_plan_hours variable work and how they are different?

naltsta I think

apps.yaml forecast_hours is the number of hours that Predbat will forecast ahead things like Solar, Load, etc. Mine is set to the default, 48.

input_number.predbat_forecast_plan_hours is the number of hours that Predbat will create the plan for (from the forecast). Mine is set to 36.

But yes, this is another corner of predbat documentation that isn't clear (yet). The predbat_forecast_plan_hours is only briefly mentioned in the tariff rates configuration guide, not in the customisation guide.

geoffreycoan
Thanks!

As I read it, this is the issue: The (default) forecast period is 2 days. When creating a prediction for future usage, predbat needs to look back “days_previous” days from the END of the forecast period to see what the actual usage was at that time. So days_previous needs to be AT LEAST 2 days (or whatever the forecast period is) for this to work.

I may just post to Github, just to make sure that my understanding is correct.

If I am, then the civilian instruction is - days_previous can’t be less than forecast_hours (when expressed as days).

I’ve been running Predbat for the last few weeks in read only mode and I’m close to letting Predbat take control of my battery. I’m currently on Octopus Flux and still waiting for my export meter to be set-up (12 weeks and counting!) but plan to switch to Agile when I’m confident with the way my system is working.

However, I have some questions before I let Predbat take control:-

1. I have an AIO battery with a 4kw string inverter for the PV. The documentation for inverter_limit says “If you have a separate Solar inverter as well then add the solar inverter limit to the battery inverter limit to give one total amount”. The AIO has a limit of 6000w and the string inverter 4000w. I’ve put 10000 in the apps.yaml file for this, is this correct?

2. Are there any non standard settings I need for the AIO?

3. My AIO is still having SOC problems on BMS 8, occasionally crashing to 0% from around 20ish %. It’s been fine down to about 25% but after that it’s been a bit hit and miss, so at the moment I don’t trust where the bottom of the battery is.
   Predbat will try and minimise my cost and sometimes will suggest not charging up to 100% overnight as it expects the battery to cope with the load the next day, running it down to 5% the following day at 2am but that brings in the chance that the battery may have a SOC drop and leave me running off the grid, maybe even during the peak period. Are there any settings I can make in Predbat to try and minimise the potential SOC drop problems?

PianSom If I am, then the civilian instruction is - days_previous can’t be less than forecast_hours (when expressed as days).

The way I understand Trefor's explanation and my examples is that there isn't a restriction between days_previous and forecast_hours, but if you set days_previous to 1 and forecast_hours is (in days) > 1 then the previous days history has to repeat

i.e.

days_previous=1, i.e the day before

• when forecasting for the remainder of today, it will use the historical load from yesterday (previous day)
• when forecasting for tomorrow, it will use historical load from today (previous day)
• when forecasting for the day after tomorrow (e.g. forecast_hours>24) then it can't use historical load from the day before as that's tomorrow that hasn't happened yet so it takes historical load from today (i.e. - another day)

The Black Cat However, I have some questions before I let Predbat take control:-

Answering your questions:

1. Yes 10k is correct. Predbat uses that to predict the most you could get without importing, i.e. max from the array and max battery discharge. In practice unless its a very sunny day and you are running lots of things, its a limit you won't reach

2. I am not aware of any as the AIO differences are hidden by GivTCP. Maybe others with an AIO can chip in their experience and if common I am happy to add to the Predbat docs.

3. If you set best_soc_min (in kW) then this defines a minimum soc to always keep. Bear in mind that this will mean Predbat will charge (even if unfavourable rates) to keep this soc level.
   You might be better setting best_soc_keep which is a 'soft' minimum soc level to keep, it can go below it, but it tries to plan to keep above it.
   https://springfall2008.github.io/batpred/customisation/#battery-margins-and-metrics-options

If you don't have export setup yet then maybe set Predbat to 'control Charge' mode, or set a manual export rate of zero in apps.yaml

geoffreycoan
Thanks for the suggestions. I did try changing best_soc_keep from 0.5 to 1 yesterday but the charging plan changed to maintain 100% from 5am through to 4pm as the forecast was to drop down to 5% around 21:30 even though this was more expensive. See attached screen dump:-

The Black Cat what do you have input_number.predbat_metric_battery_cycle set to and your loss %'s? It seems its not planning on using the battery much, these are the usual things that prevent it.

A copy of the HTML plan (with debug on) is useful to see the planned activity with the battery and house load

geoffreycoan Metric battery cycle cost: 2, Loss charge: 0.03, Loss discharge: 0.03, Inverter loss: 0.04. This plan was from yesterday afternoon and currently as my usage is much less than planned, I will not run out of battery today and predbat is behaving as I would expect and recommending to charge up to 80% tonight with best_soc_keep set to 1. I've put debug on and will post if a similar situation occurs again. Thanks.

The Black Cat No problem

Just to add some context to those figures above, to discharge your battery to the home its a 7% loss.

PLUS the metric battery cycle cost of 2p means that each kW of battery energy is priced at 2p for the "amortised cost of using the battery".

So to use the battery over grid, there has to be at least 7% + 2p cost benefit. I'm guessing that the import rates were such that it was cheaper to keep the battery for the peak and post-peak period and grid import before then (once the battery was fully charged).

Your losses are quite reasonable. You might want to reduce battery cycle metric. Trefor has reduced the default now to 1p (from 2p). Bear in mind that the metric applies both when deciding to charge or discharge the battery.
Personally I figure that I've bought the battery already so I might as well use it and set my metric to 0p.

HTH

Geoffrey

geoffreycoan
No, you are quite correct that there is no restriction. But your explanation of what happens if you break my rule isn’t really for the faint-hearted!

What I’d really like (in the absence of a Google Nest Thermostat-like AI managed monitoring and prediction system) is the ability to set up a default load profile for weekdays and weekends. My usage on, say, a Sunday is very different from a Monday. Averaging over a week loses that, and averaging over days 7&14 is open to - like last Sunday - distortion by an very odd day with cooking, laundry and Power-ups. And I don’t really want to increase my history any more.

PianSom

I’ve gone for a hybrid approach with weighting…

@PianSom I'll have a go at explaining the way days_previous works next, but at the moment I'm working on an FAQ for the importance of the different loss rates, battery metric and best_soc values to 'getting the plan right' as this seems to trip a lot of people (me included) up at the beginning

Thinking about your problem, how about setting days_previous to 7 and 14 and tweaking input_number.load_scaling for anomalous historical load?

input_number.load_scaling is a percentage Scaling factor applied to historical load, increase this if you want to be more pessimistic on future consumption. Use 1.0 to use exactly previous load data. A value of 1.1 for example would add 10% to historical load.

geoffreycoan
Yes, I think there are probably several ways to “fiddle” it to manage anomalies. But - like @naltsta i suspect - I’d rather have something I can set and forget.

Still seems to me that two missing alternatives for load forecasting are a clever learning algorithm and a stupid fixed schedule. The latter should be easy to include, I’d imagine. (Just to be clear I am not in any way criticising predbat - I think it’s great!)

PianSom I had some initial thoughts about these ideas here https://github.com/springfall2008/batpred/issues/543

naltsta
Yup, looks like you and others are ahead of me.

naltsta geoffreycoan Do you know how forecast_hours in apps.yaml and the forecast_plan_hours variable work and how they are different?

I found the answers at last

apps.yaml / forecast_hours - the number of hours to that Predbat will forecast ahead, suggested to be 48

input_number.forecast_plan_hours is the number of hours after the next charge slot to include in the plan, default 24 hours is the suggested amount (to match energy rate cycles).

@PianSom @naltsta I have updated the Predbat documentation for apps.yaml to explain how days_previous works. In the end working through some examples seemed the only way to do it and make it crystal clear. Does make that part of the docs quite long but its worth getting it right.

https://github.com/gcoan/batpred/blob/main/docs/apps-yaml.md#basics

Have a look, see what you think before I push it into the Predbat core docs

geoffreycoan
I think it is very clear, and the examples help a lot. Well done!

A few thoughts (both about this work, and broader things):

• Even though you have done a magnificent job, it is still perhaps rather complicated and off-putting for what is, after all, an opening section of a manual that will be consulted by newbies. I wonder whether it may be worth putting the section from "When Predbat forecasts future home demand " onwards into a "See here for more detail" hyperlink?
• You have - quite reasonably - split the documentation into sections which describe naturally related items. I think that it would be very helpful for newcomers if the default installed apps.yaml followed the same ordering - one to suggest to Trefor?
• I watched Trefor's two introductory videos from 3 weeks ago earlier today. They really helped my understanding, but I was left with the feeling that the docs might benefit from a "here's a walk-through of how to configure" section. I know I'd read it!

Please don't take the above as criticism - I am trying to be helpful, honest!

PianSom thanks, all comments gratefully received.

Yes I was concerned that this section of describing just one configuration item is significantly longer and more elaborate than the others. I'll have a think about how to structure it. Would rather not have lots of different documentation files as they get out of step with each other and it becomes messy to navigate. In going through the docs and uplifting them I've found that there were duplicates across docs and some settings not documented, something I have been resolving as I go.

There is a walkthrough of setting up and configuring Predbat in the installation summary and main installation docs https://github.com/gcoan/batpred/blob/main/docs/installation-summary.md and https://github.com/gcoan/batpred/blob/main/docs/install.md - I had previously rewritten and expanded them considerably. Does that do what you want?

I did discuss with Trefor about updating apps.yaml as well, to merge the different apps.yaml's that exist for different inverters, to restructure it to follow the same sequence as the documentation, and to put headings etc in. He agreed it should be done as apps.yaml is a bit of a mess at the moment.
This is on my to-do list.

For what its worth, the list of things I still have in mind to do:

• complete the predbat customisation doc (its part done)
• rewrite and expand the sample Apex dashboards and creating-charts documentation, have a single 'starter' dashboard you can copy and paste in, explain what the different graphs show and how to tailor them
• output data, explain the Dynamic entities card better
• apps.yaml file update as above
• other inverters doc tidy up
• script to add power up zero rates 'automatically' to apps.yaml file

While looking for something else in the logs I noticed a number of predbat errors, one of which was

Logger: homeassistant.components.recorder.db_schema
Source: components/recorder/db_schema.py:582
Integration: Recorder (documentation, issues)
First occurred: 21 January 2024 at 17:06:53 (1795 occurrences)
Last logged: 19:41:19

State attributes for predbat.plan_html exceed maximum size of 16384 bytes. This can cause database performance issues; Attributes will not be stored

Anyone know what this mean and what should I do about it?

Wavy Davy it’s covered in the Predbat faq’s https://springfall2008.github.io/batpred/faq/
It’s only a warning that can be ignored, but the faq’s describe how to suppress it.
It’s caused by the length of the html plan and gives a warning it can’t be saved in the database. But as it’s an attribute it isn’t saved in the ha history anyway so it’s a spurious warning as well

PianSom thinking further about the extended days_previous, I could move the extended description to the end of the doc, with a summary at the beginning. That way it’d be in the same doc but not disrupt the flow and level of detail

Wavy Davy

Try adding an exclude to the recorder configuration.

  exclude:
    domains:
      - automation
      - updater
    entity_globs:
      - sensor.weather_*
    entities:
      - sun.sun # Don't record sun data
      - sensor.last_boot # Comes from 'systemmonitor' sensor platform
      - sensor.date
      - predbat.plan_html ##this
    event_types:
      - call_service # Don't record service calls

geoffreycoan
Putting the longer description at the end of the page is a good compromise, I agree.

I have looked at the two sections that you sent, and they are not really what I was looking for. Perhaps it will be the first bullet point you have (Predbat customisation)? Trefor's video covered tuning Predbat for best performance - eg by tweaking Load Scaling and the like. I watched the video twice, and think I need to watch it again in the absence of a doc! There is still a lot I don't understand.

On the subject of your second link - install.md - I think it needs some small corrections. As I think I have mentioned before, I am a HA Container user. (Last time I looked some 25% of HA users are either Container or Core users FYI.) That means that we cannot use Add-ons. At the risk of teaching you to suck eggs, let me expand.

HACS is not an Add-on, it's an Integration. I can and do use it all the time (eg for installing the Solcast or Octopus Integrations). However, for us Core/Container users, AppDaemon/Predbat (or even just AppDaemon) is not available in HACS. So we have to run AppDaemon standalone or - I as do - in its own container. And then add in Prebat as an app manually.

The docs as they stand are nearly there, but need some corrections perhaps especially in this section - https://github.com/gcoan/batpred/blob/main/docs/install.md#predbat-manual-install. The bold note is not correct for me.

AIO users of predbat (and Geoffrey for info) may be interested in https://github.com/springfall2008/batpred/discussions/646

PianSom I'm glad you raised the 13.5 or 15.96 issue as I've been wondering about this for a while.
In terms of charge curve, I've looked at my last 5 charges to 100%:-

There appears to be a change in behaviour for the last 2 charges I did, throttling down to about 68% from the 85% mark whereas the previous 3 did not throttle down until about the 95% mark. I'll see what happens over the next few charges.
Calculation used:- Charging rate in watts used to get to next % level divided by full charging rate in watts just before throttling.

The Black Cat
Thanks for that.

I'm inclined to believe your numbers more than mine. I seldom get a good, solid charge in these days. Predbat seems to love doing intermittent exports every night, interrupting the charge. Makes it hard to find a proper set of numbers.

Hi,
I have spent most of the last week trying to get to grips with Predbat, reading the documentation and watching, pausing, rewinding, all the videos.
I have managed to get Predbat installed together with all the charts and Predbat plan.
This is a great thread, showing how much everyone here has progressed and learnt from one another.

Some questions from the newbie on the Predbat block.

1. My initial Predbat (run in monitor mode with Export switched off), seems to just discharge my battery and run off the grid. Something not right. My 'best' etc are virtually at zero (0.7 kWh)
2. I have checked the Predbat entities in HA and they are all 'disabled'. Have I missed something in the set up?

I don't know whether I will ever trust the system to control my installation!
But so far, my journey has taught me so much, not only about Predbat, but the inner workings of HA.

Thanks

Rob

Rbor I think @geoffreycoan will have the answer for you, but (quoting his reply to someone earlier):

If you want to see what Predbat plans but don't execute it, set mode to 'Charge' or 'Charge and Discharge' and 'read only' to True then it will plan but not execute anything.

I think you'll then see something more sensible.

James L Absolutely correct, thanks

Monitor mode only monitors and predicts the current battery charge & discharge plans you have setup and predicts load and PV generation.
I’ve made this clearer in the latest documentation update that I’ll push through soon https://github.com/gcoan/batpred/blob/main/docs/install.md#ready-to-light-the-touch-paper

Don’t understand that your entities are disabled @Rbor can you post a screen shot? All the predbat output entities are read only but the predbat controls (input_number.predbat_* switch.* and input_select.* ) should be editable.

You’re almost there !

Cheers Geoffrey

James L Thanks. I have attached my new Predbat plan (Charge and discharge in read only) up to mid pm today, together with my Home battery prediction. This looks much closer to what I have seen on other screenshots in this thread. Last night, I nearly filled my battery as Agile rates are up today.
How do you think these look?

geoffreycoan Geoffrey, Thanks for this. I will read your Light and Touch doc (I think your docs are very informative - Thanks).
I have attached the disabled entities screen and also one of the dashboard cards. All sensors, etc show like this.

Rob

Rbor this looks sensible. Predbat looks to be doing the right thing. What’s your best Soc min, keep and losses set to? It may be worth tweaking those to reduce the amount predbat is charging if you want to but it looks like you are running well off the battery and cheap agile

It was set to charge not charge & discharge? Looks like you have an export rate of 15p.

@Rbor looking at the screen shot, all of those entities that are disabled are ‘expert mode’ entities. To try to hide away some of the complexity of predbat a lot of advanced settings have been moved to an expert mode so you don’t normally see them. These are fine. Get the hang of the basics first, you shouldn’t need expert mode unless there is a specific switch to change.

The error on the controls dashboard is because you haven’t installed the auto-entities HACS integration. I need to expand this bit of the documentation as its thin on details but you have only installed collapsible cards https://springfall2008.github.io/batpred/output-data/
To to HACS/front end and search for collap - you’ll need to add the custom repository first
(Needs to be written with more detailed instructions, its on my to-do list!)

Rbor This isn't a predbat error, you appear to be missing the auto-entities frontend addon in HA. Go to HACS, frontend, search for auto-entities, install and reload browser.

geoffreycoan Geoffrey,
Thanks for your feedback and explanation.

More for me to read and another HACS integration to find. Dealing with HA is a real merry-go-round. Sort one thing and there is always another lurking around the corner.

I have to do some work now and will leave Predbat for a few hours. There is so much to get your head around but I think I finally have some idea of what it does. Phew.

These are my settings (just the defaults that Predbat set up), looking at the card:
best Soc min: 0.66 (Can't set from the card)
keep: 0.5 (I can set this from the card)
losses: can't find it!

Will these be hidden away in apps.yaml?

Rob

Arg0t Thanks.
So much help from folk in this thread.
I will hunt this out.

Rob

Rbor losses: can't find it!

The losses are Home Assistant entities:

• input_number.predbat_battery_loss
• input_number.predbat_battery_discharge_loss
• input_number.predbat_inverter_loss

You should be able to see and set them from the entities tab of integrations. All of these are %'s, so 0.05 is 5%

Your best soc's are fine.

There is a lot to setting up HA and Predbat. I have progressively been improving the documentation to make it easier for newcomers, but it is a powerful tool and never going to get to a 1-click process. Nor to be honest would that be a good idea, you need to understand what you're doing. I learnt lots about my inverter when I started on Home Assistant, trying to script the charge manually with givtcp isn't straightforward!
It is a rabbit hole of sucking you in though..

Cheers

PianSom I've checked another couple of overnight charges to 100%, one started throttling back at 75% to 0.68 and the at 95%. I've averaged those charges that started throttling at 95% and will use these values to start with.:-
95%: 0.97
96%: 0.82
97%: 0.67
98%: 0.52
99:%: 0.37
100%: 0.23

The Black Cat
Thanks for the update.

I really need to work out what to change so I get a decent charge period.

The Black Cat
"v7.15.3 Fix bugs in low power charging predictions, add automatic battery charge curve feature "

From the new apps.yaml:

  # Some batteries tail off their charge rate at high soc%
  # enter the charging curve here as a % of the max charge rate for each soc percentage.
  # the default is 1.0 (full power)
  # The example below is from GE 9.5kwh battery with latest firmware and gen1 inverter
  #
  # Predbat can compute this curve automatically if you have enough data, restart the add-on and look in the logfile for the data
  # once set here Predbat will no longer re-compute the curve.
  #battery_charge_power_curve:
  #  91 : 0.91
  #  92 : 0.81
  #  93 : 0.71
  #  94 : 0.62
  #  95 : 0.52
  #  96 : 0.43
  #  97 : 0.33
  #  98 : 0.24
  #  99 : 0.24
  #  100 : 0.24

Update - throws an error for me. Bug report posted

Update 2 - new release posted already!

PianSom thanks for raising the issue and getting the fix out. My 'detect predbat errors' automation had alerted me to predbat had crashed but I hadn't had the chance to see what the issue was with the auto-updated 7.15.3

Had to do a manual update through HACS to 7.15.4 as the Predbat auto-update I think caches GitHub and so it wasn't pushing the new update through.

I'm not seeing the battery curve appearing automatically in my predbat logfile. I don't have one manually set, so from what I read I am expecting it to be created by predbat. Do you?

geoffreycoan
Nope. And am seeing an entry in logfile.txt saying that necessary info is missing (see below)

Got timed out for this evening; will look again tomorrow…

INFO pred_bat: Note: Can not find battery charge curve, one of the required settings for soc_kw, battery_power and charge_rate are missing from apps.yaml

Edit - fyi I downgraded and then upgraded from the gui, so as to avoid having to play with appdaemon too much!

PianSom I have a matching message

geoffreycoan Geoffrey,
I have found these missing entities within HA entities but they are all disabled.
If I try to activate them via the cog, I get the error message below.

Any advice for what to do?

Thanks Rob

Rbor Switch on Expert Mode

Rbor Two things here:

1. The way that predbat creates entities in home assistant, they don't get created with a unique id, so you can't control them in Home Assistant. That's why this error is occurring and why you can't enable them using the HA UI. You also can't do things like change the unit of measure (eg W to kW) or the rounding

2. But the reason they are not enabled is that these are expert mode controls in Predbat.
   As I said before, a lot of the more complex controls have been moved to an expert mode and you can't change them in 'basic' mode. The idea is that basic mode is good for most people.
   See this bit of the manual https://springfall2008.github.io/batpred/customisation#expert-mode

If you want to change any of these controls then turn switch.predbat_expert_mode on

PianSom can see why I don’t have the required bits in apps.yaml !

PianSom Nope. And am seeing an entry in logfile.txt saying that necessary info is missing (see below)

Got timed out for this evening; will look again tomorrow…

INFO pred_bat: Note: Can not find battery charge curve, one of the required settings for soc_kw, battery_power and charge_rate are missing from apps.yaml

@naltsta

It looks like a bug. These controls are not set in apps.yaml if you're using rest to communicate to givtcp which is the recommended approach

Raised a bug - number of the beast !

https://github.com/springfall2008/batpred/issues/666

Ivan Thanks.
Expert mode has done the trick and I think I have everything set up now.
I can see all the controls, switches, etc and I can even see loss info in the Predbat Plan.
..... and no errors in the Predbat log.
I want to check through all the instructions again and Trefor's videos.
I will also work through this thread again. It has a mine of information and it is all starting to make a lot of sense now.

The big question is 'Will I pluck up courage to try out Predbat live?'

Rob

geoffreycoan i think you need to have them in apps.yaml to create a charging curve even if you are using rest. That’s my understanding anyway… and then once the curve is created you copy that into apps.yaml and can content them out again!

geoffreycoan Thanks as always.
I have tried Expert mode and can see the additional features that it offers (satisfying my inquisitive mind).
I also installed the Auto-entities card which has helped with the switches, controls etc. I can switch Expert mode off and having Read only has allowed me to see how PredBat might work.

The loss discharge defaults seem to be 5% which gives a large reduction (more than I would have thought) with charge and discharge efficiencies of ₇₈% (I have an ac coupled inverter).
When I set up PredBat originally, these were set at 3%. Any recommendations for 'sensible' settings.

My brain has been working in overdrive this week but I am nearly there. Predbat is quite hypnotic.
Since moving onto Agile, I have been very selective in choosing charging slots. It will be interesting to see the effect on cost if I now try PredBat.

Rob

naltsta geoffreycoan i think you need to have them in apps.yaml to create a charging curve even if you are using rest. That’s my understanding anyway… and then once the curve is created you copy that into apps.yaml and can content them out again!

Yes that would probably work, but I don’t think we should have to do that. Those fields are all available via rest calls, my guess is that it’s been coded to use the non-rest entities and not coded (like the rest of predbat) to use either rest or non-rest.

I’ll see what Trefor says in respect to my issue

Rbor The loss discharge defaults seem to be 5% which gives a large reduction (more than I would have thought) with charge and discharge efficiencies of 78% (I have an ac coupled inverter).
When I set up PredBat originally, these were set at 3%. Any recommendations for 'sensible' settings.

There’s other articles (including a very recent one) in this forum on loss rates for givenergy inverters.
GivEnergy don’t publish this data unfortunately but the consensus seems to be from people that have done testing of actual inverter performance that losses in the range of 10-20% are real and do happen ☹️
Lots of factors like temperature, charge/discharge rate, etc.

I personally have mine set in predbat to 5/5/3. I have two gen 1 hybrid inverters

And in answer to your question about cost, you will be surprised at how good a job it can do. Few days this week I’ve been in profit still by the middle of the day (i.e. negative consumption cost).
Today for instance was 33kWh imported, 10kWh exported for £3.29

geoffreycoan The big moment arrives.
I have just switched off 'Read only' and am letting PredBat loose on my system.
I can always switch 'Read Only' back on if I want to bail out.

Rob

Rbor Good luck Rob, just keep an eye on it. It does become addictive looking at it though!

Another thing you might find useful is Octoblock which I use with some Jinja code to calculate when to put the dishwasher and washing machine on in the cheapest agile slots.

@naltsta @PianSom Trefor has responded, it seems REST doesn’t have access to the history so you do need to uncomment those lines out in apps.yaml to create the charge curve

geoffreycoan
See my Github comment - still didn't work for me. Did it work for you?

PianSom Yes I saw your comment which motivated me to try it as well, and mine didn’t work either
I’m sure Trefor will issue a fix quickly, he is amazingly responsive at adding to and responding to issues

geoffreycoan Back in posts ~#213, you discussed metric battery cycle with @The Black Cat
I agree with you – I have bought my batteries and might as well use them. Who knows what may change in the next 10 years anyway with DFS.
I have changed this setting from 2p to 0p and this has made a large difference to the plan. Before, it was concentrating on keeping battery charge high, 100% a lot of the time. Now SOC is shown from one extreme to the other. I can always tweak it up and try Trevor's default of 1p.

I knew none of this a week ago! Now it seems to be dominating my life.

Rob

Rbor Yes, metric battery cycle and the loss figures are very important to get right.

I’ve written a new FAQ on this topic as quite a few people (myself included) when first starting on predbat have questions about the plan it produces https://github.com/gcoan/batpred/blob/main/docs/faq.md#the-plan-doesnt-charge-or-discharge-when-i-expect-it-to which is waiting Trefor’s approval before it gets merged in to the documentation. Happy to make any more enhancements to it. I need to add something about load scaling and modal filter …

Yes it can dominate your life. Then you get into wanting to understand where the rest of your power consumption goes in the house, smart plugs, energy monitors, more automations, etc. Keeps you busy!

@The Black Cat
In case you haven't been following the Github conversation, this is the profile that predbat is suggesting for my AIO.

  battery_charge_power_curve:
    100 : 0.19
    99 : 0.19
    98 : 0.19
    97 : 0.45
    96 : 0.57
    95 : 0.57
    94 : 0.7
    93 : 0.82
    92 : 0.95

Be interested to see whether this is consistent among AIO users?

PianSom I've tried to get the automatic battery charge curve feature to work but I get the message "Note: Can not find battery charge curve, one of the required settings for predbat_status, soc_kw, battery_power and charge_rate do not have history, check apps.yaml".
I'm using REST, so commented that out and used the definitions for soc_kw, battery_power and charge_rate but no joy, so have gone back to REST.
If I look at these entities, soc_kw is set correctly, battery_power is setup by shows zero and charge_rate does not exist. The equivalent givtcp entities exist and are set correctly. Any suggestions on how to resolve this?

The Black Cat I was using REST and had the same issue. Turns out you need to use the non-rest config for these 3 entities as the rest values don’t have the history that predbat requires to calculate the charge curve.
You only need to uncomment out the 3 entities, not swap the entire config over to non-rest

I’ve done this but for me I’m not getting the curve created either. At the moment Trefor is trying to debug why this is happening.

Strange that you don’t have battery power and charge rate, sounds like something spelt wrongly in apps.yaml?
Suggest you add your experience to my GitHub issue https://github.com/springfall2008/batpred/issues/666

The Black Cat
I switched ALL mine over to non-REST temporarily, and then it worked for me.

PianSom I tried that but still no joy. I don't know why the entity charge_rate has not been created.

The Black Cat
You have to look at the predbat logs to see the created schedule. Then paste it into apps.yaml

(A quick “cat logfile.txt | grep curve” gave the timestamp, then I just looked for that.)

No entity is created …

PianSom Yes, I've checked the logs, I still get "Note: Can not find battery charge curve, one of the required settings for predbat_status, soc_kw, battery_power and charge_rate do not have history, check apps.yaml" and if I check for the entity "charge_rate" under the "Devices and Services / Entities" section of HA, it doesn't exist. Don't worry about it, I'm using the figures I calculated before.

The Black Cat I get

Find charge curve with sensors sensor.h_sd2237g395_soc_kwh and number.h_sd2237g395_battery_charge_rate and predbat.status and sensor.h_sd2237g395_battery_power

Find charge curve has 9.0 days of data, max days 9

then the same
Note: Can not find battery charge curve, one of the required settings for predbat_status, soc_kw, battery_power and charge_rate do not have history, check apps.yaml

To be clear, the entity isn't charge_rate, its sensor.givtcp<serial no>battery_charge_rate (my givtcp prefix is h so its different)

geoffreycoan Yes, that's exactly what I get:-

Find charge curve with sensors sensor.givtcp_xxx_soc_kwh and number.givtcp_xxx_battery_charge_rate and predbat.status and sensor.givtcp_xxx_battery_power
Find charge curve has 9.0 days of data, max days 9
Note: Can not find battery charge curve, one of the required settings for predbat_status, soc_kw, battery_power and charge_rate do not have history, check apps.yaml

(I've replaced my actual serial number with xxx)

Hi, I have survived a 1.5 days running PredBat and I am very impressed with the results. The PredBat Plan is hypnotic, even more so as it changes all the time.
My plan seems to charge overnight if there are low rates, then discharges during morning, charges pm and then discharges like crazy (it reduced my battery to 4% yesterday for several hours) until very late evening. The overall result is a reduced cost for me. I guess that it will settle down as it starts to see my real previous day settings (I was just grabbing any low Agile half hour rates before).

I am now trying to understand what all the controls do and I am trying to analyse the charts.
Can you look at my Battery Prediction Chart below. The 'base' doesn't seem to be showing up as expected from Trefor's video. I have filtered down the lines to show just the Actual, Base and Best.
Am I missing a setting somewhere, perhaps in the code for the chart (or elsewhere)?

Thanks for any help here.

Rob

Rbor I deleted the dashboard with my predbat apex charts on it the other day, not realising there were still other tabs on it I needed. Doh.
So can't look at my own charts

but the 'base' will be whatever is already programmed into your inverter in terms of charge and discharge activities, so once you've started using predbat for a while I think it'll be the next charge and discharge that predbat has planned .... assuming you are within X hours of the charge/discharge window.
So pretty useless.
In summer when there's lots of solar it is a bit more useful as it shows how you battery soc will rise with solar and no predbat battery management

geoffreycoan I think I need some more historical data before my charts make sense. (1 day only!)

I am learning and understanding more every day. There are some key switches and settings, such as 'Best SOC keep', 'Battery loss charge', 'Battery loss discharge' and 'Inverter loss'. I am not the only person querying these.

I now need to settle down and see how PredBat works for me, an amazing piece of work.

Rob

Rbor Have a look at this new FAQ I have added that attempts to cover these key settings
https://springfall2008.github.io/batpred/faq#the-plan-doesnt-charge-or-discharge-when-i-expect-it-to

(Although as I re-read it back to myself I am doubting the application of double the 1p battery metric on the cost to discharge the battery. I may need to check my logic again)

geoffreycoan Had a read for your FAQ.
I am running on 4/4/4 with defaults of 0 and 0.1 on the 2 metrics.
My SOC keep is set at 0.5 for straight Agile.
It will be good to see how my plan works tomorrow as that will really be my first 'clean day' on PredBat. When I switched off the 'Read only' switch, my battery was virtually full from the previous night's charging. My batteries drop right down to 4% but I am using them. Tonight, the Plan aims to get me up to 100% by 6 am and the minimum projected is 14% (but who knows how much this could change .......)

We are all chasing that holy grail of 'optimum settings'.

Rob

A day in the life of Predbat.

At 6 am, SOC at 100%
At 10:15 pm, SOC at 4%, gearing up for the overnight charge.
Estimated total cost ~ £1.53 for the day (and this powers a heat pump as well).

Rob

Wondering if anyone can help. I have Predbat installed, givtcp, octopus integrations, all seems to be OK and working together. PredBat is running in read only mode "Monitor" - I have a "plan" but the plan never seems to show when it would charge, all the "state" slots are white, with the plan effectively just showing me running from grid for the next 3 days.

Any ideas on what I should look for?

EDIT: Found an answer on the intelligent PredBat thread (thanks @geoffreycoan): Turn read only mode on, and set it to control charge and discharge.

pacemaker Correct! Monitor mode just monitors the current inverter settings, house load and PV generation.

It is covered in the install instructions but you’re about the 3rd new person to not spot this so I’ll try to make it even clearer !

https://springfall2008.github.io/batpred/install/#ready-to-light-the-touch-paper

pacemaker

Also create a dashboard with the entities listed here to tweak it to suit your tariff:
https://springfall2008.github.io/batpred/configuration-guide/

**Note: There is an error here:

The correct item should be " input_number.predbat_metric_min_improvement "

The easiest way (if you are a noob like me) is to create a new dashboard (call it Predbat Controls), then click the three dots in the upper right and select "Edit Dashboard"

Click "+ Add Card"
Then select "By Entity"

Paste the item name in the "Search Entities" field.
Select the tickbox beside the entity name and then click "Continue". In most cases HA will select the best option for the item:

Then click "Add to Dashboard". Rinse and repeat to add the other configuration items.

Zakalwe Thanks, I have corrected that now.

The whole ‘how to create a dashboard of predbat controls’ needs rewriting as it’s not very clear at the moment, needs more detail adding. Its on my list !

geoffreycoan

Ahh...are you the author of the Predbat Documentation?

Zakalwe No Trefor Southwell the author of Predat wrote the original documentation.
I’ve been progressively updating, correcting and expanding the Predbat documentation, particularly to help newer users.

I see it as a give-back to the community and to help Trefor out with what is such an amazingly useful piece of software

pacemaker I've updated the install instructions in my fork of the predbat documentation to re-clarify what Monitor mode does and doesn't do, and the modes you need to set for predbat to plan your battery activity
https://github.com/gcoan/batpred/blob/main/docs/install.md#ready-to-light-the-touch-paper

Also in this fork is the typo corrections you spotted thanks @Zakalwe

I usually push through a Predbat documentation update about every couple of weeks. There was one earlier this week with better explanation of how days_previous work, a new FAQ on 'why is the charging and discharging not what I expect' https://springfall2008.github.io/batpred/faq/#the-plan-doesnt-charge-or-discharge-when-i-expect-it-to plus a load of other changes I can't even remember now!

Top man!

At the risk of being a nuisance (when has that ever stopped me before!) and of turning this into a Predbat support thread, could I ask you to clarify these for numpties like me? I'm trying to configure the car charging section (on Intelligent Octopus, Tesla Model 3 LR, Andersen A2 charger)

• What "Intelligent Slot sensor" should I be pointing to and how? https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy/entities/intelligent/

• "You will need to set the cars current soc sensor, car_charging_soc in apps.yaml correctly to have accurate results"
  How do I do this? In may case does HA have the ability to read the car's SOC or can it be picked up from the Octopus Energy integration?

Thanks again for the outstanding work you are doing here.

Zakalwe from https://springfall2008.github.io/batpred/apps-yaml/#car-charging-integration

I'll edit the first line 'ensure intelligent slot' to make it clear that this should auto-populate from your octopus energy integration. Its really just the case to check the logfile to see that it did populate correctly.

On the SoC, I don't have an EV so I can only go by what is in the documentation ...

It doesn't look as if the octopus integration provides the car SoC and in apps.yaml it says

# If you have Intelligent Octopus the battery size and limit will be extracted from the Octopus Energy plugin directly.
# Set the car SOC% if you have it to give an accurate forecast of the cars battery levels.

So my guess is that its asking you to find the SoC from a charger entity in Home Assistant. Assuming your charger is visible to HA.

It does say "if you have it" (in apps.yaml) and "to have accurate results" (in the docs) so I'm guessing the SoC is optional, but preferrable to know when the car charging is going to turn off

Thank you again.

I’m confused with my Predbat plan which appears to change every few minutes.

At 11:30 it says that it will freeze discharge at 30.6p import and 15p export even though the PV kWh is showing as 0.37 and the Load kWh is showing as 0.5.

What am I missing? Why would I want to go on grid and not use my battery?

Hi
I am trying to set up PredBat for saving sessions.
The instructions for Energy rates state:

• For Predbat to automatically manage Octopus saving sessions the following additional configuration item in apps.yaml is used. Like the electricity rates this is set in the apps.yaml template to a regular expression that should auto-discover the Octopus Energy integration.

I have checked my apps.yaml file and the saving entry are there, uncommented'.
But when I checked Octopus Energy entities, I see this:

The final instruction states:

• If you do not want Predbat to automatically join Octopus saving sessions and manage your battery activity for the session, simply delete or comment out the octopus_saving_session entry in apps.yaml.

I am unsure quite what this means. I thought that PredBat took over my inverter. Should I switch to 'Read only' during a saving session (Rumours are that there will be one today, 2nd Feb, 5–6 pm).
I use saving sessions for exporting and normally switch off my heat pump during a saving session and have changed 'Load scaling for saving sessions' down from 1 to 0.4. Is this enough or too much? I usually export ~ 2-3 units in an hour and earn _£6 for a 1 hour session (GE AC3 coupled inverter).

I have also just watched Trefor's saving sessions video and I think I have done the right thing.

Thanks

Rob

Following on from my last entry, I have just received a HA notification that PredBat has joined saving session today 5-6pm and the Octopus app confirms that I have opted in. So this stage works.

I will be reassured when battery is well charged and exporting works during the session.

Rob

geoffreycoan I see it as a give-back to the community and to help Trefor out with what is such an amazingly useful piece of software

thanks for all your hard work. I found another issue in the docs:

https://springfall2008.github.io/batpred/what-does-predbat-do/#predbat-status

• Freeze discharging - The battery is covering the load but charging is disabled, thus any solar generated will be exported.
• Freeze charging - The current battery level is held and the grid/solar covers any load. Solar power will also be used to charge the battery.

The above is the wrong way round. Freeze Discharging stops the battery from discharging at all, grid/solar cover the house load.

It's all very clever, to be honest.
Bottlecap dave's Octopus integration has automatically opted me into this afternoon's session. Predbat then picked it up, noticed the change in the amounts for export and has set the batteries to discharge in that period.

I have the same opt in, loving it - however I cannot for the life of me find an entity or sensor that confirms that I am signed up to it. I can see on the octopus website I am, and got a notification from PredBat that I was too. Would have thought there would be some flag somewhere ... any ideas?

pacemaker
Attribute of the Octopus Energy Integration

binary_sensor.octopus_energy_*********_octoplus_saving_sessions

pacemaker

Ignore this, it is right. I had confused myself.

Same for me with being automatic signing up and before the saving session had been advertised.

The 190 entry looks like '£1.75' per unit for saving session and '15 p' per unit for 'normal export'.
And the final cost columns get filled automatically.
The only thing that PredBat doesn't do for me is to turn off my heat pump for an hour.

What an amazing piece of software Trefor has developed, together with Geoffrey's input with documentation.
I haven't tried car charging yet but 1st PredBat saving session for me is enough excitement for the day.

Rob

Arg0t Where can I find this attribute? Back in post 289, I have shown screenshots of this entity in my HA and I can't get any information from it.
Thanks
Rob

Rbor

Go to Settings>Devices & Service>Octopus Energy. Click on Entities. Put "octoplus_saving_sessions" into the search field and click on the entity. In the pop up window click on Attributes

started to build a custom card for my dash, PredBat is so far awesome but very techie, so its helping me get to grips with what's going on:

@geoffreycoan

What's the best way to contact you to highlight anything that I spot?

Under Configuration Guide:

should read "switch.predbat_inverter_hybrid"

Zakalwe Thanks.
I have found the attribute and mine is identical to yours.
Another Predbat mystery solved.

Rob

In the GivEnergy’s portal I’ve got my battery set to charge at 60% power - is there anywhere in Predbat I can tell it this as it currently is taking the charge rate of 6kWh which is a different setting?

You can set charge and discharge rates in the apps.yaml. See https://springfall2008.github.io/batpred/apps-yaml/ - the section on Inverter control configurations

SJB thanks! I got confused as there’s a section that uses the GivTCP sensor and couldn’t find that

Zakalwe done. There were actually 4 missing predbat_ prefixes in that block of text!
And it was one of the documentation pages I had already gone through, so no excuses, sorry.

You can ping me on here, or drop me an email/text or whatsapp message. My mobile is 07720 805620.

pacemaker thanks for all your hard work. I found another issue in the docs:

https://springfall2008.github.io/batpred/what-does-predbat-do/#predbat-status

Freeze discharging - The battery is covering the load but charging is disabled, thus any solar generated will be exported.
Freeze charging - The current battery level is held and the grid/solar covers any load. Solar power will also be used to charge the battery.

The above is the wrong way round. Freeze Discharging stops the battery from discharging at all, grid/solar cover the house load.

It does sound like it might not be correct, but on things like this I have to defer to Trefor (who wrote this text originally). I raised a github issue https://github.com/springfall2008/batpred/issues/689

Rbor Hi
I am trying to set up PredBat for saving sessions.
...
But when I checked Octopus Energy entities, I see this:

As you discovered Predbat should manage the saving session entirely automatically, joining the session, sending an alert to say you've joined, and then changing the import and export rates for the session so that it exports during the session and ensuring you have enough battery charge before the session as well.

The message from HA about the saving session entity not being provided by the integration any more, I can only guess that this is because there has been a gap since the last saving session and the data in this entity had 'expired'. Do you get this error any more? Your following messages indicate it all worked OK.

I think that's all the questions from earlier today, 18 messages in total ! I too have to turn my heat pump off manually. Integrating it to HA is on my future to-do project list, but needs physical modbus wiring so is not something I'm prioritising !

The saving session worked perfectly for me as well, input_number.predbat_load_scaling_saving is very useful new feature that Trefor introduced following my feedback on the last saving session where my inverter went into Eco mode not force discharging. I set the scaling to 0.1 and Predbat did the full force discharge. Result !

Saving session was a success thanks to Predbat!

Zakalwe I've updated the documentation for Octopus intelligent car charging to clarify the point about octopus_intelligent_slot and car_charging_soc

https://github.com/gcoan/batpred/blob/main/docs/car-charge-planning.md

Did you manage to find a car soc sensor in HA you could use?

deanjesper I’m confused with my Predbat plan which appears to change every few minutes.

At 11:30 it says that it will freeze discharge at 30.6p import and 15p export even though the PV kWh is showing as 0.37 and the Load kWh is showing as 0.5.

What am I missing? Why would I want to go on grid and not use my battery?

Predbat runs every 5 minutes and re-evaluates the plan every 10 minutes (by default). Sometimes if its finely balanced between charging and not the plan can appear to flip flop. If you've got some screen shots or a logfile it may be better to raise a github issue for Trefor to look at.

The Freeze statii are perhaps a bit confusing, but per the documentation:

Freeze discharging - The battery is covering the load but charging is disabled, thus any solar generated will be exported.

So Predbat is letting your battery cover the load, not grid importing. Its just not letting the battery charge any further so if there is excess solar it will be exported, and if house load is > PV then the battery soc will decrease as the battery supplies the house.

geoffreycoan ah that makes sense! I thought it meant that all discharging was frozen

geoffreycoan so no excuses, sorry.

You can ping me on here, or drop me an email/text or whatsapp message. My mobile is XXXXXXXX.

Dont be daft. it's a tremendous amount of work and a few proff-reading errors are to be expected.

Might be worth obscuring your moby number...it might get scrapped by a bot and spammed to death?

geoffreycoan Geoffrey, I cannot believe how smoothly saving sessions work in PredBat. I set input_number.predbat_load_scaling_saving at 0.4 and I seem to have exported as much as I can.
It is all an experiment but next time, I will try 0.1, as you have done.

I started to install PredBat less that a week ago, I have watched all the videos at least once and have gone through all the documentation (more than once). What seemed an unnavigable maze is making sense and I am now questioning how I might best tweak the system. I can also find my way around HA properly for the first time.

One further question!
In the Predbat Plan, Export mode with debug exposes the true loss rates based on our settings. Do the 'Cost' amounts in the right-hand columns take into account these losses or are they based on costs without losses? I can't find this anywhere in the videos or documentation.

And a final congratulatory comment on the Trefor's fantastic software that makes up PredBat and your contributions to the documentation. I hope that I will be able to suggest improvements myself as my understanding improves. After less than a week, I cannot imagine life without PredBat!

Rob

Rbor

Great success. Yes it does teach you to learn lots about Home Assistant which is a rabbit hole in its own right.
Predbat is the main thing I am using HA for by far, I do have a few temperature sensors and automations for lights and heaters in smart plugs, but 99% its Predbat.

Rbor In the Predbat Plan, Export mode with debug exposes the true loss rates based on our settings. Do the 'Cost' amounts in the right-hand columns take into account these losses or are they based on costs without losses? I can't find this anywhere in the videos or documentation.

The costs in the right hand columns of the plan are the (estimated) true import and export costs you incur (including the daily standing charge if you have left that to default from the octopus integration - I deleted this line in my apps.yaml as I wanted to just focus on consumption costs)
The left hand columns give the "effective cost rate", i.e. what you would be paying once losses are taken into account per this FAQ https://springfall2008.github.io/batpred/faq/#the-plan-doesnt-charge-or-discharge-when-i-expect-it-to

pacemaker thanks for all your hard work. I found another issue in the docs:

https://springfall2008.github.io/batpred/what-does-predbat-do/#predbat-status

• Freeze discharging - The battery is covering the load but charging is disabled, thus any solar generated will be exported.
• Freeze charging - The current battery level is held and the grid/solar covers any load. Solar power will also be used to charge the battery.

The above is the wrong way round. Freeze Discharging stops the battery from discharging at all, grid/solar cover the house load.

I raised a github query with Trefor and he confirmed that the documentation is actually correct, but the modes are perhaps a bit confusingly named.

I've updated the Predbat documentation to describe better how the two freeze modes work. Draft here: https://github.com/gcoan/batpred/blob/main/docs/what-does-predbat-do.md#predbat-status

geoffreycoan The costs in the right hand columns of the plan are the (estimated) true import and export costs you incur

@Rbor
PS: I have added explanation this to the documentation (draft here: https://github.com/gcoan/batpred/blob/main/docs/predbat-plan-card.md#understanding-the-predbat-plan) and also about the standing charge being included in the Total

geoffreycoan I raised a github query with Trefor and he confirmed that the documentation is actually correct, but the modes are perhaps a bit confusingly named.

Thanks a lot @geoffreycoan - this is the most confusing one:

Hold charging - A type of charge where the target SOC % is the same as the current SOC %, effectively the same as a charge freeze (but without being explicitly selected).

No matter how hard I think about it, I cannot understand why Pred chooses Hold vs Freeze if they are effectively the same thing. Would love a better description of that one, which describes the outcome it achieves that is different between Hold Vs Freeze

I am trying to understand why PredBat thinks that these kind of slots are red (not good import/charge slots). I understand it's basing it on the average import cost, but should it not also consider the export price? It seems that slots like this would at least be yellow.

Have tried playing with the low rate threshold, (values 0-1.5) and it hasn't made a difference. Maybe just misunderstanding.

I have been checking my days previous settings and have the following settings in apps.yaml
days_previous:

• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 14

However after reading geoffs new write up re this he says that the /homeassistant/configuration.yaml is normally set to 10 days mine is set to
recorder:
purge_keep_days: 365
this seems excessive.
I 'm sure I haven't set this, so should I change this, and if so what to? I think it would be 14.
hard disc space isn't an issue as I have a 16gb ssd and ha is showing 10% used.

pacemaker Hold charging - A type of charge where the target SOC % is the same as the current SOC %, effectively the same as a charge freeze (but without being explicitly selected).

No matter how hard I think about it, I cannot understand why Pred chooses Hold vs Freeze if they are effectively the same thing. Would love a better description of that one, which describes the outcome it achieves that is different between Hold Vs Freeze

Yes I find hold vs freeze charge confusing as well. TBH I just let it be. Trefor seems to understand the subtleties of the distinction and I left it at that !

pacemaker I am trying to understand why PredBat thinks that these kind of slots are red (not good import/charge slots). I understand it's basing it on the average import cost

By the time you include battery & inverter losses (try turning HTML debug mode on) I suspect many of these will be unprofitable. Do you have a battery metric set?
If you look at the explanation of the html predbat plan, https://springfall2008.github.io/batpred/predbat-plan-card/#understanding-the-predbat-plan I wrote this by going through the code to see how it actually worked as the colour coding wasn’t clear to me either.

I have noticed that Predbat has a tendency to not exhaustively try to achieve every charge and discharge profit. Maybe there’s a limit to the number of forward slots it plans and focuses on the most profitable because if I look at the period after the peak for me tonight:

Then 19:30 would be profitable to charge and export, but yet it doesn’t plan to do so even though it is coloured green. 20:30 and 21:30 where the rates are lower it does plan to charge up in. I’m not getting fussed about things like this as yes I want to make profit out of the battery but I’m not so desperate to chase every single pence of charge/discharge and battery cycling. The broad plan I am absolutely happy with and indeed most of the detailed plan as well, just not chasing it to the ends of the earth

Wavy Davy recorder:
purge_keep_days: 365
this seems excessive.
I 'm sure I haven't set this, so should I change this, and if so what to? I think it would be 14.

Yes that is excessive.

I watched the HA launch video for when they brought in the new history statistics summarisation features in HA and the authors of HA are now recommending you set history to only a few days.

There’s two types of history now, full history which holds every single change in entity state, and they could be sampled very frequently. So for example all the GivTCP sensors are populated every 10-30 seconds depending on your poll frequency and you are getting all those instantaneous power import, export, battery level, etc, etc held for 365 days.
After the ‘full history’ period HA summarises the entity history, capturing a value every 10 minutes so you get 6 samples an hour x 24 hours a day - this is held indefinitely but is much lower data volumes

(That’s my understanding of how it works in HA)

geoffreycoan Thanks Geoff, Think I'll set it to 16 days, as this will then cover my 14 days look back period.

Wavy Davy I just checked and mine is set to 14 days as well.

You might want to step the history down progressively over a series of days so the overnight purge routine doesn’t have to delete months of data in one go.

I moved mine to 22 days a week or so back, only so I can make sure of having 3 weeks of data for Predbat. But now I am wondering whether "full history" is actually needed ...

(I run HA on Docker on a NUC, so no real issues with resources.)

PianSom I've been looking at the battery scaling for the AIO with respect to it being reported at 15.96 by GivTCP but the "usable" value being 13.58. You said to change metric_battery_value_scaling to 0.85 (13.58/15.96) in this github discussion.
I couldn't see much difference when I set this. However, when i changed the battery_scaling value in apps.yaml from 1.0 to 0.85 instead, all my graphs re-drew themselves showing 13.58 as the the top line and the current actual kWh shown reflected the SOC% based on 13.58, which seemed to be what I would expect from the scaling down of the battery capacity. What is the correct way to use these two options?

The Black Cat
It was actually Trefor (the dev of Predbat), not me, who said to move the battery scaling down to 0.85. I then (wrongly) suggested the way to do this was by changing metric_battery_value_scaling, I was corrected by him (perhaps on anther thread??) and told to edit apps.yaml as you say.

So I believe you are now in the correct place.

PianSom Thanks, that's good to know.

geoffreycoan

You are correct that 365 historic is excessive for Predbat but recorder is not just used for predbat. The integrations are not always stable with entity naming, I've experienced numerous changes that break history and also have my own adventures with integration changes that result in continuity issues with history. I want my energy dashboard to be correct and contain the history since the solar install, including the costs.
Having the DB with a long history enabled a switch from givenergy-local to GIVtcp, updating on the DB level the history to move it to the givTCP entities, when bottlecap dave changed his approach on storing price history, I was shielded by the hiccup with renaming that took place through that change.

Having this at 365 days in a postgres SQL, with an 800+ entity, HA environment costs about 25Gb a year in storage and some compute. I have ample compute and storage for it not to matter and it's fun to learn about postgres with a reasonably sized DB 😃

PianSom

I use 4 weeks with some weighting to prefer the corresponding weekday for previous weeks.
My logic is our routine is fairly consistent week to week but not day to day, and we have no ASHP so the base load is not excessive. When using 2-8, 14, 21, 28, with an equal weighting of 1, the plan was overestimating the load, the weekly activity of kids being home on weekends, cooking the Sunday roast were raising the daytime numbers through the week.
Still keep the previous days in the plan to have some consideration/reaction if the routine changes, eg upcoming half term holidays.

  days_previous:
    - 2
    - 3
    - 4
    - 5
    - 6
    - 7
    - 8
    - 14
    - 21
    - 28
  days_previous_weight:
    - 0.5
    - 0.5
    - 0.5
    - 0.5
    - 0.5
    - 1.0
    - 0.5
    - 0.9
    - 0.9
    - 0.9

SJB

So I set inverter_charge_limit and it decided to update my charge limit to 3630 as per the setting but I don’t want it to do that. I’ve set the battery to charge at 60% power in the GivEnergy portal which is different from the other setting. Is there a way to let Predbat know I only want to charge at 3630w but without it controlling it?

deanjesper So I set inverter_charge_limit and it decided to update my charge limit to 3630 as per the setting but I don’t want it to do that.

I'm not sure want you want to do then.

deanjesper I’ve set the battery to charge at 60% power in the GivEnergy portal which is different from the other setting.

If you are using Predbat to control your charging then whatever you put in the portal will be ignored and indeed anything that Predbat does won't show in the portal settings.

deanjesper Is there a way to let Predbat know I only want to charge at 3630w but without it controlling it?

I don't think so. Looking at the code it will charge either at the maximum charge rate, or the lowest charge rate to meet the charging target.
Predbat takes the charge rate from the inverter's maximum charge rate. This can be overridden by setting the inverter_charge_limit - this becomes the new maximum charge rate. The only other option I can see for varying the charge rate is switch.predbat_set_charge_low_power - which allows the charge rate to be the lowest necessary to meet the charging target.
Predbat also sets the charge rate to 0 in certain circumstances which is probably why it sets the charge rate when starting a charging slot and of course it would be good practice to set the charge rate in case some outside force is giving instructions as well.

Maybe someone else knows of something I haven't spotted (I'm not a Python programmer or a long term Predbat user), or you can contact Trefor via github for advice.

SJB cool thanks for your help. I’m tempted to set the battery charge power to 100% to maximise the potential (I had it set to 60% because I heard it’s better on the battery to charge slower).

SJB deanjesper Is there a way to let Predbat know I only want to charge at 3630w but without it controlling it?

I'm not sure what you mean about "without it controlling it", but if you want to set the rate predbat will charge the battery at, use inverter_limit_charge in apps.yaml:

inverter_limit_charge and inverter_limit_discharge - One per inverter (optional). When set in watts, overrides the maximum charge/discharge rate settings used when controlling the inverter. This can be used if you need to cap your inverter battery rate (e.g. charge overnight at a slower rate to reduce inverter/battery heating) as Predbat will normally configure all timed charges or discharges to be at the inverter's maximum rate.

As @SJB says, if predbat is managing battery charging it will instruct the inverter to charge at a specified rate (default to max inverter rate) or zero (when holding charge). Anything you put in the GE portal will be overwritten by Predbat so you need to tell Predbat (via apps.yaml) to charge at the lower rate

Arg0t My point was 365 historic is excessive for HA not just for Predbat.

Appreciate your rationale for keeping all the full depth history data and for moving it to PostresSQL, my return POV is:

• the authors of Home Assistant recommend you don't need to keep much full depth history any more, the long term statistics (which is still history, just summarised) meets the needs in a much more efficient way. I think it was Frenk who said he was running with just 3 days full recorder history
• different databases are of course still supported in HA, but the advice was that if you do do that (PostgreSQL, Maria DB, etc), you're on your own and have to be your own DBA
• as I said I had my HA db corrupt itself, I think in part due to the length of history I had (30 days) and in the end was unable to recover a stable HA that would run for more than a couple of days without deciding the db was corrupted

So for me I'm keeping it simple and vanilla.

Personally I'd love to have better tools in HA to manipulate the energy history, recover my old data, load in manual spreadsheet data, fix issues when I got the energy tariff wrong and my costs got loaded incorrectly, etc, etc. But none of this exists today. I've looked for solutions but not found anything. My SQL is rusty and I never wanted to be a DBA when I worked in IT so no intentions of starting now!

Arg0t
Thanks. Mine is very similar now.

One thought occurs to me - my load is dramatically altered by both Saving Sessions and Power-ups. These are both “known” to predbat, and so could theoretically be ignored in a future load projection. Have you had any conversation with Trefor about this @geoffreycoan ?

PianSom At the moment you can predict the changed load profile for both future power up events and saving sessions so predbat takes this into account for future battery activity planning, but there's nothing at the moment to adjust the historical forecast.

days_previous and days_previous_weight are both blunt instruments, affecting a whole day's history, there's nothing more granular. I suppose in theory Predbat could use historical import rate over-rides and past saving session dates/times and use these to alter the future plan, it would mean marrying up the actual dates from those histories with the 'N days' history that predbat normally works on. Similar to the logic that must exist for future price overrides only in reverse

How do-able, I don't know. Potentially put an enhancement request in for it, but to be honest I am happy enough with just having enough days_previous for it to get lost in the averaging process and switch.predbat_load_filter_modal turned on to ignore the lowest day's consumption.

If I look at my house load from 27th Jan its been 47kWh, 51 (power up day), 34, 45, 44 (power up), 50, 38 (saving session), 34 (yesterday) so there's no obvious correlation.
The within-day consumption is perhaps where knowing previous saving/power up event timings would be most useful as the load gets moved around with the different events, then we move the washing machine, dishwasher and tumble dryer times to suit the overnight/evening agile prices and for me I know my profile is altered significantly by the temperature outside with the ASHP consumption varying day to day, often being 60-75% of my usage.

So net, it'd be more accurate if Predbat modelled this but I don't know how much real benefit I'd see from it.

For those that didn't know, you can predict different future consumption in power up events with a load scaling factor in the apps.yaml import rate override:

rates_import_override:
    -  date: '2024-01-31'
       start: '20:00:00'
       end: '22:30:00'
       rate: 0
       load_scaling: 3.0

So saying I'll use 3x more energy

And for the saving session, its a HA control to specify the lower consumption:

input_number.predbat_load_scaling_saving

I have mine set to 0.1 so saying I'll use just 10%

geoffreycoan
I think I might just raise it as a suggestion for Trefor. But only if the coding was easy - I sort of agree with you that the game may not be worth the candle.

Looking at my consumption data I can't see an obvious correlation either.

geoffreycoan for me I know my profile is altered significantly by the temperature outside with the ASHP consumption varying day to day, often being 60-75% of my usage.

I wonder if you (and other ASHP owners) need to build yourself a little automation that shifts your load scaling depending on the weather forecast?

@geoffreycoan
I feel reasonably confident with using Predbat now but I hadn't looked at car charging properly before today.
I have found the documents heavy going. Trefor's video is very much focussed on Octopus Intelligent but I am a low mileage Agile user. I couldn't follow the part of the video about automations and I couldn't see anywhere where I could set up charging slots.
The docs state: "Use an automation based on binary_sensor.predbat_car_charging_slot to control when your car charges". Sadly, I have never really got to grips with automations and I am completely unsure how to do this!
A useful video could show how Predbat car charging could be set up for Agile, including the automations step.

For now, I will be scheduling using my Zappi app.
If I am not going to use Prebat for car charging for now, I presume that apps.yaml would contain:
car num_cars: 0

I also feel that the docs need more work to make the car charging instructions clearer as much of the information is about Intelligent Octopus car charging.

Thanks

Rob

PianSom wonder if you (and other ASHP owners) need to build yourself a little automation that shifts your load scaling depending on the weather forecast?

At the moment I have my load_scaling set to 1.15 so if it’s already a cold day predbat will realise that I’m using more electricity than normal and plan accordingly.

For me personally the ASHP uses so much electricity that it’s a bit of a moot point. At the moment I only have a single 5.2 battery (long story, hopefully getting resolved soon, and I’ll tell all when once it is), but even when I do have more battery capacity my ASHP still swamps it in anything other than very mild weather.

Rbor I assume you have read https://github.com/gcoan/batpred/blob/main/docs/car-charge-planning.md and https://github.com/gcoan/batpred/blob/main/docs/apps-yaml.md#planned-car-charging

If you are not using Octopus intelligent then (second option in the car-charge-planning) Predbat will plan the car charging based upon the lowest rate agile slots, the car soc, what the Soc value you want the car to be at, etc. The first bit is to configure the different sensors in apps.yaml. The specific values for the sensors will depend very much on your own EV charger and car details so its not going to be easy to put 100% detailed instructions, but if other people have a Zappi I can include their details in the docs as a worked example.
Which sensors have you managed to configure and which are you stuck on?

The bit about the automation is saying that predbat will set turn the binary_sensor called predbat_car_charging_slot to True when Predbat wants your car to start charging. You need to write an automation that triggers on this being set to True and start the EV charging, and the reverse when predbat wants to stop car charging.

I can help you write the automation, but first, have you got your car charger configured in Home Assistant?

It looks like there is a HACS integration for the myenergi devices that you need to install and configure with your myenergi account details: https://github.com/CJNE/ha-myenergi

Until you want predbat to start planning your car charging, yes leave num_cars set to 0

Are there any specific AIO tweaks I need to make for Predbat? I’ve noticed for the past two nights, my battery is empty at 10/10:30pm and I’m pulling from the grid. Ideally I’d like it to not pull from the grid until 11:30pm when the off-peak starts.

deanjesper I don’t have an AIO so can’t give you a definitive list, but one thing I think you should do is set the battery scaling.

AIO’s incorrectly report the battery capacity as 15.9kW when they should be 13.5 (these numbers from memory so are probably wrong!)

In apps.,yaml:

# Battery scaling makes the battery smaller (e.g. 0.9) or bigger than its reported
  # If you have an 80% DoD battery that falsely reports it's kwh then set it to 0.8 to report the real figures
  battery_scaling: 0.85

Should scale what GivTCP returns to the correct battery size. This being wrong is probably why your battery runs out every night.

I’ll add this specific value to the docs

geoffreycoan much obliged!!

geoffreycoan Geoffrey,
I have read your docs (many times). I can find all the entities in devices and settings/entities and some in the expert choices.
However I cannot find a way to set some of these such as:
binary_sensor.predbat_car_charging
select.predbat_car_charging_plan_time
I can set select.predbat_car_charging_plan_time in the Expert control switches
I have no idea of how to set an automation based on binary_sensor.predbat_car_charging_slot to control when your car charges

In apps.yaml, I have uncommented the following settings and have set my battery size (just a mini).
car_charging_battery_size:
- 28
car_charging_limit:
- 're:number.tsunami_charge_limit'
car_charging_soc:
- 're:sensor.tsunami_battery'

I have no idea what tsunami means and I can't find this outside of apps.yaml. There is nothing in the docs.
I assume that car_charging_limit and car_charging_soc will be set at their defaults of 100% and 0% respectively?

Guidance on settings for the Zappi and an example automation would be useful.
I am floundering here.
I have had the myenergi integrations installed for ages but all the entities seem to be sensors.

I would really like to get this set up through Predbat but without some help am truly stuck.

Thanks. Rob

Rbor However I cannot find a way to set some of these such as:
binary_sensor.predbat_car_charging

That is not something you set. Predbat sets this when it wants to instruct your car to start charging. Remember this is Predbat-led charging, Predbat will select the best slots and will instruct your car to start charging at the appropriate time.

We'll come back to the automation when we've got everything else working ...

Rbor car_charging_limit:
- 're:number.tsunami_charge_limit'
car_charging_soc:
- 're:sensor.tsunami_battery'

I have no idea what tsunami means and I can't find this outside of

In the apps.yaml that is supplied with Predbat there is a sample config, but almost certainly have to tailor for your settings. The Tsunami settings are samples presumably to point to a Tsunami brand of EV charger.
You need to change these two rows to the correct sensors for your EV charger.

There isn't a great deal of documentation for the myenergi integration to Home Assistant. It doesn't list the sensor names so you'll have to hunt through them to see if there is something suitable for these. If not then the charging will just have to do without them (they are optional).

It does say in the doc that there is a:

• Charge mode selector that let you switch between Stopped, Fast, Eco and Eco+ charge modes

So that's going to be the basis of the automation you'll need. First though, plug the car in, find that control (it will I think be called something like select.myenergi_zappi_<id>)
See what the values for this selector are, and when you change it to something such as "Eco" does the car start charging, then stop when set to "Stopped" - this'll prove you have the car charger working correctly in Home assistant

Then for the automation, I can mock one up for you, but it'll be better if you learn how automations work yourself (loads of tutorials on youtube and the automations UI in HA is fairly easy to follow) - teach a man to fish and all that analogy...

The guts of it though is you'll need two automations:

1. WHEN the entity binary_sensor.predbat_car_charging is set to the value True
   THEN select the entity myenergy_zappi_<id> to the value you need to start car charging

2. WHEN the entity binary_sensor.predbat_car_charging is set to the value False
   THEN select the entity myenergy_zappi_<id> to the value you need to stop car charging

geoffreycoan find that control (it will I think be called something like select.myenergi_zappi_<id>)

Mine is select.myenergi_zappi_charge_mode and the choices are Fast, Eco, Eco+ and Stopped.

I am set up to use the Zappi integration (so the charging is controlled by the Zappi, not the car) and the instruction is to leave the setting in Eco+. See https://support.myenergi.com/hc/en-gb/articles/18470101583377-Zappi-Intelligent-Octopus for more details. In particular, see the note at the bottom of the table.

(Disclaimer - My EV is out of commission atm, so I have yet to grasp the Zappi/Predbat nettle.)

geoffreycoan
PianSom

Thanks for the advice. The Zappi is good for charging from solar or from grid. There are workarounds to prevent the Zappi from draining a battery made by others than myenergi. Setting up scheduling on a Zappi seems to be a workaround and I always wait until it is dark before I plug in. Myenergi claims to be able to select cheaper slots but this is only possible using their portal (not in their app). There isn't a public API like GE's givtcp.
PianSom Thanks for the Zappi link – another about Octopus Intelligent Go. I will have to investigate the myenergi help documents further. In the link, Myenergi advise against using a Zappi for OIG.
Being low mileage, I charge my car in quite an ad hoc way and I will probably continue to do so. Last night I topped up the car in my ad hoc way for an hour using negative Agile pricing, which was nice.

I do now know something about predbat car charging, a project I will return to again.
For now, I will do more work on automations. I have watched many Youtube videos but I couldn't follow some, especially the ones that wanted me to access a script as a Service, and others that wanted a long id number without telling me where to find this. There are also automation scripts in other threads in this forum.
I did find a simple Youtube video that taught me how write an automation to switch on a light at a chosen time – a numpty success for me! And my Predbattting has taught me so much about where everything is in HA.

I do have an ASHP (1st winter) and Geoffrey is correct that the heat pump eats energy. I have two 8.2 kWh batteries and, pre predbat, these will get me through the day (supplemented by a bit of solar) provided that my daily load is <20 kWh. I purchased a 2nd battery for the ASHP but using Flux or Cosy, I can't fill them enough. I then moved to Agile in mid January, discovered Predbat, and have never looked back. I do know that Agile can have its moments though!
I do question whether I needed a 2nd battery, especially seeing Predbat make great use of picking up slots form the grid (and outgoing rate settling on 15p a unit). There have beed so many changes in the past year and I wonder whether DFS will become much more mainstream and automatically set up by ESO, National Grid or even suppliers such as Octopus?

My thoughts are to go back to Flux once solar really ramps up and heat pump use reduces. Although, would I do better sticking with Agile? I have a few weeks in which to decide.

For now, I will continue to marvel at what PredBat does. In the last week, my total energy costs are < £1 a day (not including Standing Charges) with the last 2 days leaving me in profit. I ditched gas when my ASHP was installed.
One comment: I notice that Predbat uses the previous days rates before 4 pm in estimating its plan. This is probably a small matter as Predbat is adjusting its plan all the time. I wondered about using estimated rates based on Weather data, in the same way as used by the excellent Octopus Watch app?

Rob

geoffreycoan
I have looked at your automation suggestions:

WHEN the entity binary_sensor.predbat_car_charging is set to the value True
THEN select the entity myenergy_zappi<id> to the value you need to start car charging

WHEN the entity binary_sensor.predbat_car_charging is set to the value False
THEN select the entity myenergy_zappi<id> to the value you need to stop car charging

I fell at the first hurdle because the entity binary_sensor.predbat_car_charging doesn't exist for me in HA entities.
There is: binary_sensor.predbat_car_charging_slot but this seems to want a time, not True

PianSom .
I have found your entity: select.myenergi_zappi_charge_mode. I don't see the options but guess that I type in Eco+ as the Attribute.

Enough for now! I should be able to do this and to get HA to save my automation without returning an error message.
I hate automations ...... and I need to look at some more YouTube videos.

Rob

Rbor In the link, Myenergi advise against using a Zappi for OIG.

Perhaps I'm missing some context? Where does Myenergi advise against using a Zappi for OIG ? Got me a bit worried!
Perhaps you mean the bit about not mixing OIG with Home Assistant ?

Rbor
Sorry - I overlooked your point about being on Agile!

If, in HA, you go Settings/Devices+Services, Integrations/Myenergi, X Devices/Zappi, then under Controls you should see this -

DD Sorry, you are right.
Advice seems to be not to use HA with Zappi on IOG.
I will crawl back to my hole ......

Rob

PianSom Thanks. I have found it under control and then added an automation from the devices and settings/Zappi screen.
I finished up with an 'And with' statement: Current myenergi zappi-20464051 Charge Mode selected option
and I was able to then select Eco+ from the 4 choices.
I also use the Zappi rather than car for taking charge of my car-charging.
So I have part of a car-charging automation.

Rob

@geoffreycoan I've been scouring entities - does the plan exist anywhere other than the "plan in HTML" entity? I was hoping it would be an attribute somewhere, but theres so many....

pacemaker @geoffreycoan I've been scouring entities - does the plan exist anywhere other than the "plan in HTML" entity? I was hoping it would be an attribute somewhere, but theres so many....

No the plan isn't really easily accessible other than the html version, which is why it got added based on customer feedback.
There are the Apex charts, the Energy Rates card, the Home Cost Prediction and the Home Battery Prediction are all the different bits that make up the predbat plan. Each of these are driven by predbat output entities - you can see the specific entities used in the 'series' part of each chart.
But (in my view) the charts are quite hard to decipher and you have to read across several charts to work out what predbat is planning, and so hence how the html plan came about as an easier way of visualising the future plan.

There are also some specific entities, e.g. 'predbat.best_charge_start' is the time of the next planned charge.
I have a little dashboard of the key things I am interested in

Rbor I fell at the first hurdle because the entity binary_sensor.predbat_car_charging doesn't exist for me in HA entities.
There is: binary_sensor.predbat_car_charging_slot but this seems to want a time, not True

Great that you are making progress with automations (and learning lots about HA!).

I mis-typed it, the binary sensor the docs say you need to use to control your car charging in the automation is binary_sensor_predbat_car_charging_slot https://springfall2008.github.io/batpred/car-charge-planning/

binary_sensors are just true/false things, they don't take a time. Maybe you were meaning select.predbat_car_charging_plan_time which is the 'what time you want the car ready by' (per the docs)

make sure you set num_cars to 1 in apps.yaml as otherwise lots of the car sensors don't appear in HA

geoffreycoan Geoffrey.
Thanks for all your help with using predbat for car_charging.

I am admitting defeat for the moment.
I have spent hours on setting up automations today and have made very little progress. I find the initial choice of the type of trigger, condition or action almost impenetrable.

I will now concentrate on getting better with the parts of predbat that I can work with.
I will revisit predbat car_charging at a later date ......

Rob

Rbor
Automations can be complex in HA until you get your head around how they work.

Step by step, the start charging automation

Automations
Create Automation
Create new automation

First bit you need is to define when the automation will be activated. Lots of things can be a trigger (e.g. time, when its 5pm, every 10 minutes, when an entity value is greater than, etc)
For this one we want to trigger the automation when Predbat says that its time to start the car charging, i.e. when binary_sensor.predbat_car_charging_slot is set to On

So, under the When section
add trigger
you want a trigger when something happens to an Entity (in our case the value is set)

You can trigger on Entity having a numeric state, or (wheat we want) it having a State
should see this

type the name of the entity that will trigger the automation in the first box binary_sensor.predbat_car_charging_slot

then you can choose whether the automation is triggered on an attribute of the entity (not needed for us, we are triggering on state)
and whether the entity state is moving FROM something or going TO something

so we trigger on it going TO the value On

click in the To box and you should see a set of values, choose On

you can optionally say that you only want the automation to trigger after an entity has remained in that state for a period of time (the FOR), we don't need that

so the trigger should look like this

now its the THEN DO

add action
you want to change the SELECTor for the my_energy zappi control to Eco+

SELECT

SELECT (a specific option)

should look like this, the select command is chosen

chose what Entity is going to be selected, so click the green Choose Entity

and type the my_energi zappi sensor name, I don't have that integration to so I'll continue with one of my GivEnergy inverter controls, the one that changes the inverter mode (H <id> control mode)

you can change multiple entities at the same time, e.g. turn off a load of lights with a single command, but for now the one entity is enough

and type in the final box the value to want to set the Zappi mode to, I'll choose "Eco" to set my inverter to Eco mode:

and that's the automation done. save it, give it a name, and then try it out you can click the three dots at the top and Run to run the automation (i.e. pretend the trigger has occurred). If you've got it right your zappi should start charging the car

PS: I don't have an EV so all this is informed guesswork from the documentation as to how I think it will work

geoffreycoan I have set up this automation and I 'think' it works.
However, there are some workarounds.
As soon as I plug in my EV to the Zappi, the EV starts charging. In Eco+ mode, charging is solely from solar and none takes place if solar power is less than 1.4 kW. If I set up a scheduled charge overnight, I wait until there is < 1.4 kW (or it is dark) before plugging in to prevent the EV from charging. The Zappi charges by automatically switching to full power at my scheduled charging time, and for how long.

I think a predbat automation could work by doing the same (but not setting up the scheduling within the Zappi app.)
Then I would set the automation to run at my scheduled time by adding a time in the initial 'When' Trigger' region.
I would then set the charging option to switch to 'Fast' at that time.
I could then follow this with another automation that changes the charging mode to 'Stopped'.
I know there is a 'smart' predbat entity: switch.predbat_car_charging_plan_smart to pick out the lowest rates, which I could also incorporate.

I have tried plugging in my car and I have experimented with changing the charging mode in the automation – it works!

But .... I can set this up using the Zappi portal anyway, which may be easier (and safer for me!)

With your guidance, I have learnt a lot more about automations so I should have more in my HA knowledge base.
I presume that the input_number.predbat_car_charging_threshold setting of 6 kW prevents any fast car charging at 7.4 kW showing up in the historic home load.

Rob

been impressed with predbat, until tonight. I dont know why its doing what its doing.

Its holding my battery at 100%, from now until 1500 tomorrow (I cut the image it just continues as is), so running from grid until then in the plan. It just charged it from 90% to 100% in the most expense slot (0.20p/kWh) rather than just waiting till middle of the night when its much cheaper... Losing a bit of faith here...

pacemaker It would be useful to know what your inverter and battery charge/discharge losses are, and what the battery metric is.
If you turn the html debug on you can see the effect of the losses in the charge and discharge rates.

The agile rates are quite flat at the moment so it may well simply not be economic to let the house run off battery overnight (incurring the inverter loss, discharge loss and battery metric costs), only to then have to incur all these again for charge up for the peak period.

My own chart is quite similar, holds charge most of the night

pacemaker
geoffreycoan
I am a predbat 'expert' of 7 days standing and trying to understand how predbat works. Predbat is a wily beast and seems to hunt out any opportunity for making a profit. Before predbat, my policy was to hunt out the cheaper Agile rates and to import then. I hadn't contemplated that I might be making a loss overall because of inverter and battery losses. After 1 week, my view is that predbat is amazing and it can only get better with Trefor's expertise.
Until last night (Wed am) Agile's night-time import rates have been low and predbat's overall strategy has been to charge in the early hours, export in the morning, charge in the afternoon, export 4-7pm, get battery down to 4 kWh and replay the cycle for the next day.
But today, Agile import rates have increased and there is little difference between Agile import rates and Grid rates.
Agile rates are also different across different regions. Comparing yours to mine, my rates seem to be about 0.7 p lower. Your boundary line between import/export/hold will be closer than mine. As Geoffrey states, turn the HTML debug switch on and you will be able to see the predicted rates, taking into account losses.
For comparison, I have shown your snapshot of rates from 00.00 - 02:00 am Wed against mine (I have used Thurs which Predbat copies across before next day rates released). You can then see our different Agile importing rates and the effect of losses on my rates. I run with Agile import and Octopus 15 p export.

I have an AC coupled inverter and my losses will be greater than from a hybrid inverter because of the 'extra' conversion in storing solar (DC->AC->DC).
My predbat plan for today makes much less use of the battery than when Agile rates were lower, but my battery is used more than yours, presumably because of your higher Agile rates. You can compare Agile rates across regions on https://energy-stats.uk

I am sure that Geoffrey will put me right if any of my information here isn't up to the mark.

PS. Predbat seems to weigh up many variables when choosing import/export/hold. I think it weighs up its Import threshold values (e.g. input_number.predbat_rate_low_threshold (expert mode)? which I can't find anywhere. Must be Predbat's secret!

Rob

Rbor that all looks correct Rob, it is super-important to get your own personal balance between charging and discharging with the different loss %'s and battery metric as this is the core of what is planned. Lots of people, myself included, when first starting with predbat have questions about the battery behaviour not matching what they expect it to be.
I recently added an FAQ to try to explain things in more detail
https://springfall2008.github.io/batpred/faq#the-plan-doesnt-charge-or-discharge-when-i-expect-it-to

Its not the entire story and I will at some point come back to expand on it further, there's metric min improvement that also sets a pence threshold as to whether its financially worth charging or discharging.

Rbor PS. Predbat seems to weigh up many variables when choosing import/export/hold. I think it weighs up its Import threshold values (e.g. input_number.predbat_rate_low_threshold (expert mode)? which I can't find anywhere.

It could well be that this is missed from the documentation. Predbat has grown organically and when new features have been added they've not always been documented in the 'obvious' place. Some were documented in multiple places as well. As I have been going through the documentation I've been trying to resolve this; for apps.yaml I went through and exhaustively made sure every config item was in the docs. I've still got to go through the template apps.yaml file and make sure it matches. I've yet to go through the Predbat configuration guide exhaustively, its partially done, but its a big document to do and other things get in the way! Do have all the predbat_ prefixes in the documentation now.
And of course Trefor keeps adding new features all the time...

And yes agree, the agile rates do vary around the country, Surprisingly so. My rates (South East region) for overnight this morning are pasted above and seem to be a touch higher than @Rbor and lower than @pacemaker

Predbat still doing an amazing job, At 12:00 today, imported 11, exported 8kWh, total cost so far today 15p. After a period of cheaper agile rates in the strong winds we seem to be back to more 'normal' prices of 40p in the evening peak, 12-15p overnight.
At least the solar is picking up, 8kW generated so far today

geoffreycoan Good to see that I haven't suggested any dodgy advice.
This thread is fascinating – it shows how many of us have got to grips with how predbat works over time. When I first contributed just 10 days ago, little of this made any sense. Now, I think I have a pretty good understanding of predbat although I still have a lot to learn.
Your documentation is extremely comprehensive and I have learnt so much by working through the .md documents, to say nothing for your willingness to help us all out in this thread with our issues.

In the predbat plan, I have noticed that some import slots are now shown in bold and I assume that these are the 'priority slots' for import (at least until predbat tweaks the plan, as it does every few minutes).
Is this a new feature that Trefor has slipped in? He must do this to keep you on your toes.
Predbat must sit there every day just before 4 pm, in anticipation of the new rates so that the next days plan can be redrafted.

Rob

Rbor In the predbat plan, I have noticed that some import slots are now shown in bold and I assume that these are the 'priority slots' for import (at least until predbat tweaks the plan, as it does every few minutes).
Is this a new feature that Trefor has slipped in? He must do this to keep you on your toes.

I have a feeling that this has always been there, but when I wrote the documentation for understanding the html plan, I didn't mention it, so maybe it wasn't?
Anyway, I've just looked at the code to work out what the bold signifies, and it indicates whether there is some charging (or discharging) planned anywhere in the slot. Predbat actually plans on 5 minute sub-slots that are then rolled up to the 30 minute agile slots and if any of these sub-slots has charging (or discharging) the import (or export) rate is shown in bold.
I'll add it to the docs.

Thanks for the positive feedback on the docs, I'm not finished yet (and maybe Trefor will ensure I never quite do finish!), but if there are things not clear, please say so I can try to improve it.
Compared to some other HA addons/integrations, the documentation is comprehensive. I looked at the myenergi one and its very thin by comparison

geoffreycoan It has been a pleasure getting involved with predbat and I hope that I have progressed from someone who asks 'How do I do this?' to someone who can offer suggestions for improvements or gaps in documentation. The docs are great.

Rob

Predbat's auto-joined me to the saving session and amended the plan.

Plan before the saving session came through, the battery would have been released earlier in the peak to support house load on the (slightly) higher rates:

Updated plan after joining the saving session. Keeps the charge to 17:30, then releases some charge to house load, then a force discharge for the hour's saving session. Note the reduced predicted house load in the s/s as well

geoffreycoan
Very curious - why has the predicted load changed (before, during AND after the s/s)?

In my - clearly erroneous! - mental model I thought the predicted load was simply a function of historic usage plus a few scaling factors.

PianSom two things at play here:

input_number.predbat_load_scaling - scaling of the historical load based on consumption today.
Mine is set to 1.15, so modelling that if its a heavy consumption day already (its cold, the heat pump has been on all night and day so consumption is higher), its likely to be proportionally heavier consumption for the rest of the day

input_number.predbat_load_scaling_saving - scaling down of the consumption during the saving session. Mine is set to 0.1, modelling that during the saving session we'll shift load, turn off the heat pump, etc to reduce consumption so more of the discharge gets exported rather than house consumed

Interesting. I haven't touched these two load scaling settings and this is the plan that predbat produced for me after auto-joining me to the saving session:

I wonder whether predbat would have charged my battery up more from mid-am (mostly on hold) if the savings session had been finalised earlier in the day.

My load controls are set to the defaults:
input_number.predbat_load_scaling = 1.0
input_number.predbat_load_scaling_saving = 0.1
I switch my Heat Pump to 'standby' for saving sessions.

Rob

Hi All, I now have some little weigh scale icons on the plan next to the rates - any idea what they represent?!

In the predbat-plan-card.md document, it states:

Rate symbols (import and export)
.........
? ⚖ - Rate that has been estimated using future rate estimation data (e.g. Nordpool)
........
When in doubt, take a look in the documents. Geoffrey has most things covered.

Rob

Rbor Thanks Rob

Yes, new feature, the plan now shows the source of future rates, either saving session over-ride, manual over-ride, nordpool market estimate, etc

Rbor I wonder whether predbat would have charged my battery up more from mid-am (mostly on hold) if the savings session had been finalised earlier in the day.

Your battery doesn't get exhausted by the end of the saving session Rob, and the saving session discharge rate is so much better than the surrounding rates it'd still be worth Predbat doing a charge now at 14.5p, or even at the start of the peak at 29p if it was financially worthwhile.

Rbor thanks. Had missed the new feature!

Oh, that’s (of course) clever. Predbat moves to a “Callibration” mode when you’re calibrating after a firmware update.

Didn’t have to move it to Monitor, after all.

PianSom yes another new and useful feature.

I've added this to the FAQ's

I put mine into read only mode. I had enough to manually export and for the rest of the night.

I couldn’t understand why it wanted to charge my battery as peak rate.

Hook Hard to tell what was happening without the plan card with debug mode or knowing what your losses and thresholds were. Sometimes if your load today is much less than the historical load, Predbat can over-compensate.
Last night I had the reverse, normally with cooking our battery gets exhausted during the peak period so Predbat sets it to Eco mode to minimise grid import. Yesterday my wife was out at Beavers so we cooked much later and the battery was still at 40% at 18:15 so I set a forced discharge for the remainder to earn a few pennies on the better export rate.

geoffreycoan I am trying to learn more about predbat and this reply is questions!.

1. In your reply you said that you set a forced discharge. I know that I could revert to read only for a time but would I then set up the forced discharge using the GE app?
   The customisation.md document has a section on Manual control which I have been reading. I can't find the select.predbat_manual_discharge selector (and the charge selector) anywhere. Can you help me here!

2. I have also been trying to understand the meaning of all the 'freeze' alternatives that crop up in the stars column of the predbat plan. I think I am getting there (although a few minutes later, it has gone from my fading brain). Why is there 'freeze charging' and 'hold charging'? They all appear somewhere in my plan today.
   What about just 'hold' on its own, which I think I have seen?

3. I have notify set and get loads of notifications. These often differ from what the plan shows. Which is more recent?

Sorry for all the questions today. Thanks for any help

Rob

Rbor

Sorry for the delay in replying, life and other stuff ....

Answering your questions

Rbor In your reply you said that you set a forced discharge. I know that I could revert to read only for a time but would I then set up the forced discharge using the GE app?
The customisation.md document has a section on Manual control which I have been reading. I can't find the select.predbat_manual_discharge selector (and the charge selector) anywhere. Can you help me here!

The "old" way of overriding what Predbat was planning to do was to set predbat to read-only, then do a force discharge in the app or manipulating the appropriate givtcp controls (I have scripts to do the common things so I would just run the discharge script).
But as of Predbat release 7.15.0, about 3 weeks ago, Trefor introduced extra controls to allow you to tell Predbat to do a discharge, charge or idle in a slot.
In the integrations/entities list you should be able to see them:

If you don't hen you may just be on too old a version. I'm on 7.15.21

Rbor I have also been trying to understand the meaning of all the 'freeze' alternatives that crop up in the stars column of the predbat plan. I think I am getting there (although a few minutes later, it has gone from my fading brain). Why is there 'freeze charging' and 'hold charging'?

The different Predbat statii are described here https://springfall2008.github.io/batpred/what-does-predbat-do/
There are quite a few that sound similar and you are not the only one who finds all the different statii confusing, so do read the doc carefully. Hold charge and freeze charge are very similar, quite why there are two almost the same, I don't know.

Rbor I have notify set and get loads of notifications. These often differ from what the plan shows. Which is more recent?

Notifications. Phah. Predbat does generate loads. You should get a notification every time predbat changes state (to charging, to discharging, idle, etc), but sometimes you still get multiples when Predbat re-evaluates the plan (load, current soc, etc) eg: discharging to 20% then discharging to 15% then discharging to 12%.
In terms of the notifications not matching the plan, they should always match, BUT the plan is shown in 30 minute segments and Predbat actually plans in 5 minute slots so there can be occasions where the overall 30 minutes might be one thing but a 5 minutes something else.
There are two toggles for notifications, predbat_set_status_notify (notify on change of status) and predbat_set_inverter_notify (notify on inverter change). The latter is recommended to be off as it will generate many more notifications.
Good news is Trefor has made some changes to reduce notifications - but looking at my phone it still seems to be generating a lot so I have reopened it (bug #748)

geoffreycoan But as of Predbat release 7.15.0, about 3 weeks ago, Trefor introduced extra controls to allow you to tell Predbat to do a discharge, charge or idle in a slot.

@Rbor
This thread is now way out of control, but if you scroll up lots of pages you will find this post of mine with code to put the new controls on a dashboard

geoffreycoan I have checked and I have these entities installed. I am also on v7.15.11. I have set the switch "Predbat automatic update enable" to 'on' and I am picking up any updates.

In the integrations/entities list you should be able to see them:

Thanks, I have now found the selector for manual change and manual discharge. I thought this would be under that 'control' section of the vertical stack card. But it is within the entities list via Device and Settings.
I wonder whether this should to be made clear in the help doc.

There are two toggles for notifications, predbat_set_status_notify (notify on change of status) and predbat_set_inverter_notify (notify on inverter change). The latter is recommended to be off as it will generate many more notifications.
I have just predbat_set_status_notify on. I don't mind the notifications but there are a lot of them because predbat is at it all the time!

I think predbat is brilliant, especially with its constant weighing up about whether it is cheaper to discharge from the battery or use the grid – very selective.
Today, predbat used the grid for most of the time with SOC at 4%. Tomorrow the plan is getting the battery SOC well up. My old way was to charge up the battery and to then use it, taking care not to let SOC fall too much. And to hunt out the lowest Agile slots (very time consuming). I guess that most of us did this.
I now just let predbat get on with it but spend my time looking at the rapidly changing plan.

My big decision for the summer will be whether to stick with Agile or transfer to Flux which was brilliant for me last year.

Thanks for your continued support.

Rob

PianSom geoffreycoan Thanks. I have added this code to the dashboard and the options are all there now. Just need to ensure I don't inadvertently select one!
Isn't adding spaces to get everything aligned correctly in the code frustrating?

At least I am not the first to need help in finding these selectors.

Rob

Rbor Expanding on how to add the predbat controls to a dashboard is on my to-do list. Its not covered in a great deal of detail. I used to have a custom dashboard for predbat controls but finally weaned myself off and am using the dynamic entities card (https://springfall2008.github.io/batpred/output-data/) which automatically generates the controls in sections for you. As I said, its not well explained at the moment.

Agreed once you get comfortable, you just leave Predbat to it. The agile rates this weekend weren't great at all, not really cheap overnight and much the same in the day. Very strange, you'd think weekend would be cheaper with less demand. Tomorrow evening is looking cheap again, hurrah.

Yes, big decision over Agile vs Flux. At the moment I am leaning to staying on agile, but haven't really done anything to model different options. My average daily consumption in Feb is about 40% down on January and I can see I've almost exported as much so far in February as I did in the whole of January!

geoffreycoan am using the dynamic entities card

Is this a possibility for us HA Core users? I can’t quite see how predbat could get the dynamic entity list into the HA container, but maybe I’m missing something

(I’m assuming that your predbat updates the dashboard automatically for new entities- is that correct?)

PianSom s this a possibility for us HA Core users? I can’t quite see how predbat could get the dynamic entity list into the HA container, but maybe I’m missing something

It works the other way round; I don't see why it wouldn't work for all HA user types ...

Predbat publishes controls and output entities to HA where you can add them to dashboards, etc. The dynamic entities card is just a Lovelace card that does a wildcard select of matching entity names (e.g. prefix "switch.predbat_*") and presents them in a list on a standard HA dashboard.
There's a set of different selectors for switches, input numbers, etc, with each set being in collapsable folder-like structure in the Lovelace UI just so you don't immediately get a dashboard of 100 controls in a serial list.
e.g. this is opened at the input numbers with the switches set being collapsed

Since its all UI side manipulation in HA Lovelace it should be OK. Does need two pre-requisite additional Locelace HACS controls installing first.
As I said, needs a better explanation expanding out, on my list alongwith a more expansive description of accessing predbat controls which is all a bit skimmed over

geoffreycoan
Sorry - I obviously wasn't being clear.

When I started out, IIRC the default predbat dashboard entities yaml (which is created by predbat) was - in my instance - created inside the AppDaemon Docker container, and I had to copy it across to the HA Docker container. (Yes, I had to make sure the necessary Lovelace dependencies were in place for it to work.)

But what happens now if that dynamic dashboard file is updated eg because new Predbat entities come into existence? My suspicion is that in your case your dashboard can automatically update itself (because the new yaml can just overwrite the old one). Whereas I suspect mine will not. Am I correct in thinking that? I certainly have not had any automatic updates to my dashboard so far ... Does yours automatically update itself?

PianSom But what happens now if that dynamic dashboard file is updated eg because new Predbat entities come into existence? My suspicion is that in your case your dashboard can automatically update itself (because the new yaml can just overwrite the old one). Whereas I suspect mine will not. Am I correct in thinking that? I certainly have not had any automatic updates to my dashboard so far ... Does yours automatically update itself?

It works slightly differently from the default predbat dashboard entities.yaml which holds a fixed list of all the entities that Predbat has. This is created each time predbat runs and if any new entities are created by predbat they’ll be written to the yaml file, but because you have HA and predbat running in different docker containers you have to copy the yaml file between containers each time.

The dynamic entities is not a fixed list of entities, its client side Lovelace code that builds the list of entities dynamically when it’s displayed on a Lovelace dashboard.

How easily this will automatically work for you or not depends on how the container architecture works. I’m assuming there is some form of communication already in place between the predbat appdaemon container and the HA container? Is that automatic that HA can see the predbat entities or do you have to do some sort of manual config for each and every entity that predbat creates?
I’m expecting that as long as HA knows about the predbat entities (regardless of whether you have to link them across containers somehow or its automatic), the dynamic card should still work as its just building a dashboard based on the entities that HA knows about

PianSom I think it should work for you as well.

If you look at the yaml for this dashboard card, it is written in a way to include all existing 'entities'. Commands are written in the format .......

EDIT - the "asterix * in the code in not displayed in the pasted text below"

filter:
include:
- entity_id: predbat."asterix"cost"asterix"
- entity_id: predbat.rate
- entity_id: predbat.metric

so that all future entities set up in the same naming format will automatically be included. I'm not familiar with Python but I can remember using the asterix in MS DOS commands as an 'include all' many years ago.

geoffreycoan @Ivan
Thanks for the replies. It looks to me as if your dashboards are NOT updated by Predbat (other than for the inclusion of new entities, by dint of the asterix wildcards, but only IF they match).

I say this because the screen shot of Geoffrey's above doesn't match the code of the current dynamic entities card (which is found here) (In fact, even the icons differ, oddly.)

In particular, Geoffrey has the three "Manual" select. entities which are not included in the template. select.predbat_manual* does not appear in Trefor's template and will not be caught by it. It does appear in the code fragment I posted above.

So I assume you added the three entries to your dashboard yourself, Geoffrey? (I did the same, I just put them in a collapsible card, as you will have seen.)

PianSom Thanks for the replies. It looks to me as if your dashboards are NOT updated by Predbat (other than for the inclusion of new entities, by dint of the asterix wildcards, but only IF they match).

Yes it relies on the wildcard matches covering new entities, which pretty much they do do. Originally there was only one select for predbat, for car charging, but over time more have been added (manual overrides, save/restore settings, update version selector), and you’re right, the dynamic entities doesn’t cover these. When I get to it, I’ll fix this, but if you add a select.predbat_* pattern it’ll cover it for you.
Yes I added these selectors manually to mine

PianSom

I added the manual overides as a separate dropdown/collapsable section.

Nice to see do do is back ...

Interesting IOG experience today and wondering if this is normal.

I plugged my car in last night and was given a massive charge session (7.30pm thru to 8am) (it's new and was delivered with no charge). I had set it to 90% target in Octopus and I have a granny charger.. so worked out almost right...

By 06.30am this morning the car hit 90%, so I still had 3 half hour slots at the 7.5p rate, according to the PredBat plan, which I assume the octopus integration is telling it too. The predbat plan continued to run from grid until the planned 8am end.

However looking now at the octopus integration "completed dispatches" attribute in the intelligent dispatching sensor, I can see that the cheap half hour windows stopped at 6.30am, there are none recorded after that. So a few questions:

1) Seems ok behaviour for Octopus, they said they would give me till 8am, charged it to target early, so the extra 3 half hour slots were not charging, so they are not "completed dispatches" anymore, they were removed. Right?
2) Seems these dispatches that aren't "used" or no longer valid, won't disappear from their API until after the fact?
3) If so, should predbat consider the "is charging" sensor to ensure the plan is accurate and against the right cheap or expensive rate?If planned dispatch but not charging, then consider it an expensive rate? seems to make sense?

pacemaker I don’t have IOG or an EV so my comments are based on what I understand from the documentation & code.

If Octopus says that you are being given charge slots from 7:30am to 8am, then that’s what Predbat uses to plan as low rate import, so will charge the battery etc - it gets all this data from the Octopus Energy integration. So if Octopus subsequently decide that a slot is no longer cheap rate (I don’t know if they can do this, but let’s assume they can), or if Octopus throw in an extra low rate slot, then these changes are picked up by the Octopus integration and Predbat updates the plan - all automatically.

How the completed despatches works, I can guess that they record when the car was charged as opposed to what the charging rate was, but that’s a guess and you still got them as low rate slots regardless of whether the car was charging or not. If somebody else on the forum knows, or it may be a question for Bottlecap Dave on the Octopus Energy integration GitHub.

geoffreycoan

thanks - yeah that is the question - if the completed dispatches are just when the car charging was used. I'll ask on the octopus integration - thx

You only get the off-peak rates in out-of-normal-times if the car is actively charging. The integration can sometime under/over estimate the car charging times as there are many variables, such as battery temperature.

If the system offers you out-of-normal cheap timeslots and the car completes charging early then those slots are charges at peak rates. Similarly, the system can give you time slots that can change with no notice. The system is designed to dynamically hit your requested SoC at the time requested. It may get there earlier than planned or by using different charging times. Regardless, it will still get you the requested SoC by the requested time.

pacemaker I was just looking at the Octopus integration docs
https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/blob/develop/_docs/entities/intelligent.md

Has this warning:

If you are using this to drive other automations for cheap rates (e.g. to fill batteries), you should perform additional checks to make sure your vehicle is actually charging. If it isn't, this sensor could be incorrectly on if during a dispatch outside of the standard off peak period and you will therefore not receive the off peak rate.

If you are wanting to know when you are within a guaranteed off peak period, you should use the off peak sensor.

I think you’d better raise a question for Trefor on the Predbat GitHub. Looking at the Predbat docs https://springfall2008.github.io/batpred/car-charge-planning/ it covers how Predbat gets the despatching slots from the Octopus intelligent sensor, but doesn’t make any mention either way of what happens when the car charging stops and as Zakalwe says intelligent dispatching stops.
I’d have expect that Predbat takes care of this, noticing that the charging has stopped and its outside of the normal offpeak rate, but should get this clarified

geoffreycoan

Yeah I think it's clear there needs to be a check on the predbat side, just not sure if that's happening.

I noticed there is a setting in app.yaml that would help this (and wasn't set for me today):

car_charging_now:

• 're:switch.charger'

car_charging_now_response:

• 'on'

I've enabled those now, but also waiting for Trefor to confirm if predbat is in fact checking for that in the IOG charging logic.

Been trying so hard to get this damn thing working before buying a thin client for permanent HA home but I just cant get it working, all the videos I see after setting up the yaml its not adding the info to overview and the card that displays prices and whatnot isn't working either, done the copy and paste job from the guide and it just says this.

I am literally doing fresh installs and following guides pausing and unpausing on two monitors and I just cant do it, spent over 3 hours today alone.

EDIT
I don't even have a log file for predbat

Jellybaby the error in HA is that it doesn’t recognise the card type html-template-card

This is a custom Lovelace template type you need to install from HACS in the first bit of the plan card docs https://springfall2008.github.io/batpred/predbat-plan-card/#displaying-the-predbat-plan

geoffreycoan I typed html but it didnt come up with the exact name but it came up with the same picture as shown here

So I downloaded it as instructed.

Overview didn't update with any predbat info after setting it up and saving changes and restarting home assistant, it didn't create the log file for predbat and there was no info in system log about any errors

Think I might just give up for good, I got no problem with givtcp, setting up octopus or solcast but this thing I just cannot get going and there is absolute no step by step video that I can find for the AIO, ive tried following 3 or 4 different video guides and I basically copy pasted the homeassistant install AFTER getting givetcp and octopus and whatnot set up before I attempted to try predbat so I can just copy and paste the backup version of the HA VM to try again.

This thread might be a lot more useful if the forum software it was based on wasnt complete TRASH and refuses to load the whole damn thread.

Jellybaby I am trying to remember how I set up the HACS cards.
I think I found an html card by searching in HACS/frontend. After doing this, the card showed up as:

From your screenshot, it looks to be the same card but check out by scrolling to the bottom of the custom cards in HACS/Frontend. The extras that you have installed will be at the bottom.
I added the card to a dashboard by selecting 'Manual' (the card didn't turn up in the list).
I then pasted in the code provided in the predbat documentation and saved:
https://springfall2008.github.io/batpred/predbat-plan-card/#displaying-the-predbat-plan.
This then worked.
Whenever I have got stuck, my first port of call is the documentation and the many helpful folk in this thread.

The predbat documentation is second to none. Predbat is a complex beast doing so many wonderful things. It did take me a long time setting it up but since then it has controlled my battery completely, saving me time and money.
I have learnt a lot about how it works and interfaces with HA.

So try this and see if it works. Best of luck.

Rob

Jellybaby Don’t despair, I’m sure together the forum can sort you out.

It looks to me like you have installed the wrong custom component. I just looked and found that there’s “Lovelace html card” which has that picture:

And the card it installs is called html-card:

The card you want is “HTML Jinja2 Template card” which has the same picture!:

But the card name is “html-template-card”:

I’ve tried this card and it doesn’t work. I have also spotted an error in the installation documentation, the corrected steps to follow are:

• In HACS, click on Frontend
• Click in the Explore and download repositories (blue button bottom right corner) and type 'HTML'
• Click on 'HTML Jinja2 Template card', then click blue 'Download' then ‘Download’ again to install it
• When prompted to 'reload your browser', click 'Reload'

This is a Home Assistant front end component that displays the Predbat plan (once predbat is running) so there won’t be any Predbat logging of this.

I can’t tell from what you are saying whether you have got predbat installed and running or not, but follow the above and you’ll get this issue resolved and can then look if something else is wrong.

I will correct the install documentation error. Thanks for explaining what you found

Jellybaby
This is what my HACS/Frontend screen looks like. Note that I too initially downloaded the INCORRECT "Lovelace HTML card", and needed to install the CORRECT "HTML Jinja2 Template card". They both have the image that you posted associated with them. (In my defence, this was before Geoffrey's magnificent work on the docs!)

You will not have all these HACS Frontends necessarily.

geoffreycoan I've updated the Predbat documentation to the correct set of steps for installing the Jinja2 template card, also added a specific highlight about not installing the similarly named "lovelace html card"
Draft updated doc here: https://github.com/gcoan/batpred/blob/main/docs/predbat-plan-card.md

Also added HACS install instructions for Apex charts as that was an easy copy paste. Writing a fuller documentation of setting up the Apex charts and the dynamic entity cards (which are custom repositories you need to add to HACS) is on the to-do list for another day. Not forgotten but will take me longer to do.

geoffreycoan I have just tried adding the HTML Ninja card to a blank dashboard and it worked straight away.
Is it worth adding something about having to use 'Manual' and then just pasting in the code from the predbat documentation? I remember stumbling at this stage, expecting to see the HTML Ninja card in the choices.
The other cards custom cards that I downloaded from the HACS/Frontend page all seem to show up in the card choice, but not the HTML Ninja card.

Jellybaby Please persevere with Predbat – it is worth the effort and, once set up, it seems to look after itself. There is plenty of help in this thread.
Remember that Predbat is an organic and evolving piece of software with improvements being made to the software and documentation all the time.

Rob

Rbor Is it worth adding something about having to use 'Manual' and then just pasting in the code from the predbat documentation? I remember stumbling at this stage, expecting to see the HTML Ninja card in the choices.
The other cards custom cards that I downloaded from the HACS/Frontend page all seem to show up in the card choice, but not the HTML Ninja card.

Thanks Rob for the suggestion, I've added that to the plan card doc - same link as above.
Also expanded the Apex card doc a bit with similar copy/paste advice.

Strange that the Jinja card doesn't appear on the list, I hadn't noticed. Must be a bug, I'll raise it.

Now, got to get back to painting and looking at my lovely replacement 9.5kW battery that arrived this morning (at 7:50am,ugh)...

Rbor I am giving up for the moment, I have spent way over 10 hours over a few weeks trying to get it going, settings auto populate the overview section and if I could get it to pop up there I know id be making progress but ive gone through so many guides I feel like im just wasting my time.

I done everything in the official predbat guide and it didn't even create a log that I could check to see whats going on.

PianSom When I turn gaming PC on later (only thing I got that will run HA atm but 60-80w idle draw is a lot for just HA) ill check see what mine looks like.

geoffreycoan I did have predbat installed and configured and deleted the 2 lines it tells you to to get it working but nada, before I shut PC down for the night I overwrote the home assistant install to before installing predbat so I only have to do that, file editor and card thing again.

I love that I don't have to start fresh and that I could just copy/paste the home assistant VM to where I had givtcp and octopus stuff set up.

Jellybaby No problem, let us know if and when you want to have another go installing Predbat.

I assume you are following the installation instructions at https://springfall2008.github.io/batpred/install/ and are using the ‘combined AppDaemon+predbat’ install route. I’ve tried to make the instructions as detailed as possible, but if you get stuck, do share what you see and we can try to help.

You don’t of course have to use Predbat if you don’t want to. For simple ‘charge the battery up overnight’, the GivEnergy app is more than adequate, or you can write your own Home Assistant automation scripts which is what I did before I started on Predbat. Unfortunately that’s not totally straightforward either, there’s usually several controls you have to set in the right sequence for a charge or discharge, but there’s other people’s scripts on other forum posts if you need inspiration.
Predbat is worth it if you stick with it, but the learning curve for Home Assistant, Predbat, GivTCP, etc is steep. We’ve all been there !

ATB

I set mine up a couple of weeks ago.

I followed this video.

https://youtu.be/44NyYbyd8PY?si=_s-4ERnF6trkNDwr

Now I cant find the config file and clicking the back button doesn't do anything

Jellybaby did you turn the ‘enforce base path option’ off in the file editor? Otherwise you won’t be able to change directory https://springfall2008.github.io/batpred/install/#editing-configuration-files-in-home-assistant

geoffreycoan

This is how it came

Edit
Just seen you said off, ill change it now

I had everything up and running and something was pending restart so I restarted home assistant and card wouldnt work still and when I went to check I saw that I had 2 lovelace items that didnt load properly so I had to redownload them, is this a common thing?

I guess this thing needs a few days of 24/7 reading I guess to get to grips with whats happening.

Where is the drop down for predbat operating status to make sure its read only?

Jellybaby I saw that I had 2 lovelace items that didnt load properly so I had to redownload them, is this a common thing?

No it isn't. Sometimes the different controls of home assistant can take a few minutes to start up after a restart, but once installed they don't need re-installing (in my experience).

Jellybaby Where is the drop down for predbat operating status to make sure its read only?

Adding the different controls for Predbat is something that needs to be explained better in the docs https://springfall2008.github.io/batpred/output-data/

The easiest way to access individual controls is:

Settings / Devices and Services / Entities and that takes you to a full list of all your entities and controls in Home Assistant.

In the search box you can search for specific entries, e.g. 'predbat' or the one you need is 'predbat_mode' to set the mode of predbat and 'predbat_set_read_only' to set it to read only mode

You can click on any entity and change the value from the entities list

Time zone is fine for predbat its Europe/London and even if it wasn't I am not sure what the near 10 minute discrepancy is?

EDIT
think I found the problem, had to change the other one I had a look and it was set as
time_zone: Europe/Amsterdam

But that should have been more than 10 minutes?

Found the drop down as well

Although I got cars set to 0 so not sure why its got a car charge time in there set hehe

Jellybaby Either the clock on whatever you're using to run HA or the inverter's clock has drifted. You need to resync whichever one it is.

Vestas Both are 100% fine, after I made the adjustment in the "appdaemon" config from Europe/Amsterdam to Europe/London its been fine.

maybe its not sorted

Tiume now is 20:58

Not sure why its ok with it most of the time then suddenly out then back to fine?

Jellybaby it looks like either the PC time (which is being reported as app daemon time) or the inverter time is wrong.

You can sync the inverter time in the givenergy portal.

It's a warning not a fatal error but it could cause problems when you start letting predbat control the inverter if the times are different

Both times are spot on though and if there was an issue wouldn't it be a constant one rather than only cropping up every 40 minutes give or take

I have the All-In-One, no EV car and no iboost, I have some inquiries on the following I saw these but I don't know if they ALL relate to vehicle charging or not.
Circle = Should I turn off
Underline = What should I do

Jellybaby answering your questions:

I honestly don’t know why you are getting time synchronisation warnings. I’ve never seen it happen. If it keeps happening then probably need to raise a GitHub issue and provide the log file for Trefor to look at. Weird.

If num_cars is set to 0 in apps.yaml, the car settings car charging hold, octopus intelligent charging will be ignored, but might as well turn them off.
Ditto turn off iboost but it should be ignored if its not configured in apps.yaml
Of the others:

• inverter hybrid should be off as you have an all in one which is an AC coupled inverter. This is used as part of the charging loss calculations as there will be an inverter loss converting DC to AC and back to DC when charging solar power
• combine charge slots. Depends on what tariff you are on. This joins multiple charge slots together into one long charge slot. Safe to leave on
• set discharge during charge. Do you have an export tariff? This setting, if the rates are favourable for both import and charge in the same 30 minute period (e.g. 11p import, 15p export), Predbat will charge and then discharge in the same 30 minute period. If you turn this off Predbat will only do one thing in a 30 minute period. As you are starting off, turn it off for now
• set status notify, leave on, predbat will send an alert to any devices you have the Home Assistant companion app installed on (assuming you have this installed on say your phone as an easier way of controlling HA). The alerts will be sent when predbat changes mode, e.g. from Charging to Idle, to Discharging, etc

Getting there. Be aware that Monitor mode DOES NOT plan any charging or discharging, it just monitors your current load and solar charging. Once you get the hang of seeing what’s in the plan you’ll want to change the mode to something else (e.g. Charging and Discharging) and set read only to true to see what Predbat plans to do, but don;t let it make any inverter changes (which is what the read only setting does)

hhmmmm, the agile prices are working for the plan chart so not sure why its having trouble with standing charge

Appreciate teh info on the other items I inquired about, they have been changed.

Jellybaby can you share the bit of apps.yaml for the standing charge.

Personally I set my standing charge to zero so I only model the consumption in predbat, but the standing charge should work ok

geoffreycoan ofc
Is this enough

EDIT
I think I may have sussed it out, I was on early last years agile tariff and today was the changeover to the December tariff and it went from 37 to 42p, I checked in HA and the one circled here said unknown I guess due to the switch over, its now registering as 42p so ill see what happens.

EDIT
Looking at energy dashboard the costs seem off, as I am on Agile what should I be setting for price tracking and what entity? Also when battery is being charge should charge energy be in the negative?

Jellybaby Looking at energy dashboard the costs seem off, as I am on Agile what should I be setting for price tracking and what entity?

This is described in the Octopus integration docs - https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy/setup/energy_dashboard/

Jellybaby yes sounds like the standing change might have been affected by the switchover day, it looks ok now.
The setup of price tracking in the energy dashboard when you’re on agile is a bit complex as the rates change every half hour, but as @PianSom says, the instructions (wot I worked out and wrote!) are on the octopus integration page

geoffreycoan
You wrote those docs too??!! You really are civic minded - thank you

Jellybaby
geoffreycoan
I started to look seriously at predbat in late January. I spent a lot of time (documents and repeated views of the supporting youtube videos), getting to learn what the system has to offer. On Jan 30th, I switched read only off and activated charging and discharging (as I am on the Octopus outgoing 15p export tariff and import Agile).
I also stumbled with the additional HACS cards that need to be installed but help was forthcoming from this thread.
The predbat documentation is a great source of information: [(https://springfall2008.github.io/batpred/)]
Within this documentation, the configuration guide shows several examples of main settings for different tariffs and use scenarios.
The configuration guide goes much deeper and is a good reference for all sorts of settings. At first, I found this overwhelming but as I have learnt more about predbat, this guide start to make sense.
There is a guide for car charging. I have an EV but I do low mileage on an an hoc basis (manually grabbing low rate slots). I haven't let predbat loose on my car charging and have num cars set to 0 in the main apps.yaml file. I will move over to predbat car charging later.
I also have a heat pump and no gas.
A can't stop looking at the predbat plan, I have made a few tweaks to my settings.
I just let predbat do its stuff. I trust predbat to do a far better job than me for reducing my energy costs.
I also really like being part of this innovative system, rather like a pioneer. It is really good spotting an issue, flagging it, and seeing improvements in the documentation as a result (courtesy of Geoffrey).

You seem to be doing well and are nearly there.

Rob

I to started using Predbat a couple of weeks ago.

For info, I have a HAOS running on a Pi 400. I am not a coder and really do not use HA for much other than monitoring. I really struggle at times with HA as it is far from user friendly. My biggest struggle has been with getting stuff installed. All too often the creator says things which leaves the user on an endless trail trying to work out installing different integrations, trying to decipher different creators ways of explaining things and so on.

Add in to that that very often installing these things requires you to edit YAML files. Great, if you have a rudimentary understanding of coding. Less so if you don't. I am firmly in the latter camp and to be honest I have no interest in learning to code. The amount of time that I have wasted trying to make this stuff work is ridiculous. Especially when the problem was something daft such as having the wrong indent in YAML.

A case in example- many of these cards asks the user to insert a line into ui-lovelace.yaml. I cannot tell you how many hours I have wasted trying to find that file. Or how many forum threads I have read trying to find info on it. Nowhere have I seen it said that all you need to do is create a file, call it "ui-lovelace.yaml" and job jobbed.

Now I am sure that many HA users will be rolling their eyes and muttering "thicko" under their breath. I don't care. I just want to be able to install this, use it and get on with my life. I am glad that you are out there creating this stuff for free, but there has to be an understanding that most people do not want to spend their Friday evening dicking about with this stuff.

Case in point- creating the various charts in Predbat. The user has to install other integrations to make the charts work. Those integrations have their own dependencies. Installing them requires the user to do too much interpretation

Having had this little rant, I do want to shout out Geoffrey Coan for his help and the work he is doing to improve the documentation. And, of course, Trefor for creating Predbat in the first place. After a couple of weeks use I am now comfortable to let it do it's thing. This morning I switched off the inverter notifications as I am comfortable with how it works. It really is worth sticking with as it finally has given me a "killer app" for Home Assistant.

Thanks guys for the kind comments. I too love the power that Predbat gives in controlling my battery efficiently and getting the most out of it, it truly is my only killer app for Home Assistant.
My days of coding are so far behind me and TBH I don’t have the time nor the inclination to want to be adding new features (although I have contributed a few tweaks here and there to the Predbat code). I just started out being happy to share my own knowledge and experience gained in trying to use it, and seeing that others were asking the same questions, started adding to and rewriting the documentation to make it clearer and unambiguous. It is a complicated product, there’s lots of moving parts and I don’t think it would be a good idea to get the instructions down to ‘click this, click that’ as when something goes wrong the user would be stuck as to what to do. Having said that I am trying to add much more detail as to where things are in HA, how to follow the install and config instructions, etc so that people don’t get too lost. Fortunately Trefor lets me!

Installing the charts is way too complex, so definitely an area I will be changing when I get to it. As is the whole output data stuff. I’ve not seen the “edit up-Lovelace.yaml” instruction myself, so if you can show me where it is @Zakalwe I will definitely add more detail of what needs to be done.
TBH I started off with the charts myself, got annoyed that they were hard to read so adjusted them all so I could read them vertically, then mashed some together to show more information on them; but now I never even look at the charts I just look at the predbat plan. I think the charts are too complex to easily understand.

Agree over YAML, it’s too easy to mis-edit it and screw up your installation. I’ll find a suitable ‘introduction to yaml’ video and link it into the install instructions 👍

geoffreycoan I’ve not seen the “edit up-Lovelace.yaml” instruction myself, so if you can show me where it is @Zakalwe I will definitely add more detail of what needs to be done.

IIRC, it is needed as part of adding in some of the other integrations that predbat needed. For example, when installing Apex Charts

It's more of a general point about how HA is set up. You end up having to install further bits to get the bit that you actually want to work , to work. And then you are at the mercy of how well written the install instructions are.

There are integrations that I abandoned months ago that I now have only recently managed to get working. Mainly down to my growing understanding of the platform. Having said that, I also fear updating as at some point an update will bork something else (for example, I have a NS Panel which is configured by a Blueprint. A recent update meant that all of the previous configuration no longer works and the panel needs a compete new configuration inputting).

Apparently that issue I was having was due to having givtcp set at 5 minutes, my portal already refreshes at 1m instead of 5m so thought id set a longer one to reduce the amount of updates on portal since its for the past week or two already been like 4-5x slower than it used to be.

Also I really need to manually sort dashboards at some point all that setting up has just plastered everything on home page and it takes a good 10-20s to load up when I want to check things, I didn't skimp on processor or memory for the VM though.

Zakalwe That’s not particularly expansive documentation is it, and it implies a strong knowledge of HA and the config files.

I know HA gets a lot more complex if you are doing manual installs of the integrations, i.e. not using HACS, or have things running in different docker containers. I don’t know if that is your case but its starting to get outside of the scope of the Predbat documentation.
I’m running HAOS as a virtual machine running on a Windows 10 PC. HACS is an integration to HA and AppDaemon and GivTCP are running as add-on’s within HAOS, so in reality are running as Docker containers, but its all managed by HAOS so there’s no difficult config to worry about.

For me I just installed Apex Charts from HACS and there wasn’t any config files to edit. I know there wasn’t any instructions for how to install Apex Charts in the Predbat docs nor how to add the charts to a dashboard - I’ve added these now in the draft doc update https://github.com/gcoan/batpred/blob/main/docs/creating-charts.md but will be expanding further how to add the charts.

Thanks

Damn, just checked windows task manager and HA tab takes 1gb of memory fresh Home view with all that stuff on the dashboard, no wonder it takes a while to load everything lol, the tab was nearly 2gb before I closed it and reopened it to see what it was like on fresh open.

I finally got my export meter set up this week, it only took 14 weeks, so I decided to let Predbat have a go at doing my first forced discharge at 4pm today. Predbat started the discharge as expected but it was exporting to the grid at 6kW. However, my G99 is limited to 3.68kW and I checked with my installer this week what prevents the AIO exporting at 6kW and he set the "Grid Export Limit" in the remote control portal to 3660. In the predbat apps.yaml file I've got export_limit set to 3680 and the Predbat plan showed an expected export rate of 3.68kW for the time period.

Is there anything else in Predbat I need to set to limit the export rate?

I suspect the problem lies outside of Predbat, where do I need to look to get the export limit set correctly?

Thanks.

The Black Cat However, my G99 is limited to 3.68kW and I checked with my installer this week what prevents the AIO exporting at 6kW and he set the "Grid Export Limit" in the remote control portal to 3660. In the predbat apps.yaml file I've got export_limit set to 3680 and the Predbat plan showed an expected export rate of 3.68kW for the time period.

Is there anything else in Predbat I need to set to limit the export rate?

In terms of Predbat, setting export_limit will model as you’ve found the export limit imposed by your G99.
The only other setting you could make is inverter_limit_discharge
https://springfall2008.github.io/batpred/apps-yaml/#inverter-control-configurations
But that will limit all of your discharge to whatever value you set, so if your house is using 1kW then you’ll only be exporting 2.68kW so its a blunt instrument

AFAIK the export limit imposed by the G99 is set in the inverter config by the installer, it’s a config that is not user changeable.

However, the G99 limit is set by the DNO because they believe that’s the “most” that export that your local grid connection can accept. I thought 4kW was automatically approved so it’s pretty awful if they have imposed a limit less than that. That worst case export is presumably calculated when all the other houses on your transformer connection (which could be 50+ houses) that have solar or batteries are also exporting at full wack. And there is bound to be some contingency built in as the DNO won’t actually do a site visit and physically measure the resistance, cable and transformer sizing, etc, etc.
There is the “just leave it” option. Not that I would suggest that of course.

Jellybaby Damn, just checked windows task manager and HA tab takes 1gb of memory fresh Home view with all that stuff on the dashboard

That is crazy big.

I’ve just looked at my task manager, the Home Assistant Oracle Virtual Box (VM) is consuming 3.5Gb memory and about 50% of my CPU. If I look at the VM config it’s actually set to a maximum of 6Gb.

Microsoft Edge browser, I have 30 tabs open at the moment, with perhaps 6 of them on Home Assistant.
In total the 30 tabs are taking 880Mb of memory and 2.5% CPU.
I clicked on a few of the HA windows and browsed around a bit to stop them idling, the memory usage went up to 1000Mb (now dropped back to 930Mb), but individually the largest windows are only taking 235Mb.

I think you said you were runnng HA on a gaming PC, so it should have enough grunt. Surprising that you are getting so much memory consumed when I am using so little

geoffreycoan I am using my 24/7 PC to view home assistant and it was just the individual instance of chrome that was that high and I had it on top so its never hidden and opened a new tab, default it hovers between 150-200mb then going to overview 1gb.

I got 4 cores assigned to it along with 4gb of memory I believe but I can't edit settings to check as its still running but this is a new singular opening of firefox and waiting for "Home" to load

I had brave browser open in single window only and going back and forth configuring and whatnot and when I looked last night it was nearly 4gb for the browser.

Now I seem to have things more or less sorted im going to power down the VM and wait until I secure a lower power hungry device to run it on, won't be getting a Pi so will be a thin client or mini pc I think.

Current VM is using 4GB Ram, 4 Cores and 32GB Space.

Jellybaby I don’t think the actual vm uses that much resource.

Seems to be your browser that does. What happens if you access it on your mobile phone? Does the pc resource stay the same?

@geoffreycoan
At the risk of turning this into a Predbat support site..... Here's one for you. Last night I had the power go off to the house. I think that a de-humidifier that was drying some laundry popped it's heating element and tripped the breakers. it took me about 10 minutes to work out what went wrong and to get everything rebooted and back online.

Since then, Predbat is displaying this error:

I can confirm that the inverter's time is correct. It has had a time-sync command successfully sent and has been restarted a couple of times.

My HAOS has also been rebooted a few times.

The time in HA is correct. It looks like AppDaemon is running 9 minutes behind everything else.

The timezone is set as Europe/London in appdaemon.yaml:

The timezone is set as Europe/London in the Predbat apps.yaml

Although Predbat seems to be working and controlling the inverter fine, I'm at a bit of a loss to work out why it is displaying this message. Any ideas?

Why does my predbat seem to have a heavy bias towards discharging between 4pm and 7pm? Surely towards the end of the day would make sense?
Does anyone else experience this? I wonder if it's learnt behaviour from the saver sessions.

danerf Higher export rates if its outgoing agile.

danerf

I have this in my apps.yaml, makes the peak time less attractive if you are on a fixed 15p export. Avoiding that you lose out on saving sessions by building an export history in these slots. Counter productive for OE and the grid as they'd like us to export more in this slot in general to reduce generation needs.

  # To improve on saving sessions avoid export during peak periods
  rates_export_override:
   -  start: '16:00:00'
      end: '19:00:00'
      rate_increment: -5

Zakalwe I had this issue that was resolved by changing the polling time on the Givtcp addon, what is yours set at? I was told to set at 30-60s, could the cut have done something to that setting?

Jellybaby
Where's that setting?

Dunno why a power outage would cause it to suddenly act up though?

Zakalwe unexpected shutdowns may cause a lot of weird issues, even in PC's, the setting for changing the time is this one.

Unfortunately since I only got the program working yesterday that is the only experience I have had with that message, if the time looks fine you may have to ask on the github or the Givtcp facebook group which there is a link for in the predbat page.

EDIT
The only reason I have it set at 54 is for some reason it won't go below 6 seconds and if I set it for 54s the refresh interval seems to be 59/60 seconds, its really weird lol.

Ah, OK. It's a GivTCP setting rather than a Predbat one. I'll give that a go.

Good luck, I was told on Facebook that it should be 30-60s as too quick a time will cause problems as well. I originally had it at 5 minutes.

@Zakalwe The frequency that GivTCP polls the inverter is the ‘self run’ setting in the GivTCP add-on config:

As you can see I have mine set to 20 seconds.

If it’s set too high so GivTCP polls infrequently then you could get the warning that Predbat issued that the clock times are out of sync - especially if GivTCP can’t connect to the inverter, e.g. the inverter is still reconnecting to the wifi after a power cut. I find mine can take 10 minutes or so to reconnect and after a reboot I often find that predbat goes into error state for the first one or two runs whilst everything is starting up again. You can always look at sensor.givtcp_xxxxx_last_updated_time which is the time the GivTCP data was last refreshed at.

It is advised to not set the GivTCP poll frequency too high because this can interfere with the 5 minute send of inverter data to the GivEnergy cloud. Equally too high it could disrupt using the GE app in local mode.
So hence I have it set to 20 seconds.
If you are balancing inverters or suchlike then you’ll need a higher refresh rate though.

That worked!

Bizarre how it has been running fine until the power cut. Clearly a glitch in the Matrix!

Zakalwe Glad it sorted out for ya, if this was any other day you wouldn't have got a resolution anytime soon as I had this problem for nearly 2 days lol

Thanks folks. I have added specific guidance to the docs about setting the self run frequency, added a new FAQ for what to do if you see this time mismatch warning, and also added links to some useful videos covering 'introduction to HA, YAML explanation, setting up givtcp, etc'

These are all in my fork of Predbat and will get pushed through in the next week

Boffinboy

I first tried using a Synology NAS as it was already available to me. But you will be better off on a discrete platform running Linux or HASS unless you want to spend a lot of time updating and maintaining the extra infrastructure required to run the containerised Add-Ons.

Runing Core HA Core is easy enough. Adding the other containers to get GivTCP working once was tricky, but I got there. The main issues arose when it came to updating all the pieces - which is almost daily in HA. Most scripting is not in place on DSM and I had to keep adding too many extra modules just to get basic updating services working.

I eventually gave up and bought an oDroid M1 with HASS installed on the eMMC unit, popped in a cheap 1TB SSD and haven't looked back. It just works, with no effort managing the infrastructure. Which leaves much more time to work on the automations.

I got mine from www.odroid.co.uk. Other HA users run on Raspberry Pi. There are lots of hardware choices. The key is that they are running HASS natively and that opens a lot of HA options to you. Even simple but very useful ones, such as having the Add-Ons option visible in HA.

geoffreycoan

"e.g. the inverter is still reconnecting to the wifi after a power cut. I find mine can take 10 minutes or so to reconnect and after a reboot I often find that predbat goes into error state for the first one or two runs whilst everything is starting up again. "

I am curious. Why isn't your router on the inverter's EPS circuit?

spe Bit cheeky to have power+case as separate purchases for that odroid

spe I got mine + 24/7 PC and Gaming PC on a Cyberpower UPS.

spe am curious. Why isn't your router on the inverter's EPS circuit?

It will be - soon. My installer never quoted or even mentioned EPS to me as part of the install 🤷‍♂️

I’ve had to have the fusebox in the garage split into an EPS and a non-EPS box with my older FIT array and the hot tub moved onto the separate fusebox, a changeover switch and earth spike installed.
Am waiting for my installer to give me a date when they will come and connect the inverter EPS to the changeover switch.

geoffreycoan Checked Predbat plan this morning and it had crashed just after 4 am with an 'Exception Error'. I restarted HA and thankfully Predbat came back to life (took about 5 mins).

I checked the AppDaemon Predbat.log(s) and searched for 'error'. I found 72 errors starting at 4:12 am this morning. I have downloaded the file.

I then looked at predbat_debug.yaml. I found a very long file at 4 am but have no idea of what it might tell me.
Has anyone else had an issue this morning?

I checked my GE dashboard and my system seems to be continuing with what was its plan last night, basically charging!

Geoffrey, should I put my Predbat.log and predbat_debug.yaml files on GitHub for Trefor?
I have never posted directly to GitHub before. Where should I post the file and how do I do it?

So immediate panic over for me. But somewhat worrying after smooth running for the last 2-3 weeks.

Thanks.

Rob

Rbor Geoffrey, should I put my Predbat.log and predbat_debug.yaml files on GitHub for Trefor?
I have never posted directly to GitHub before. Where should I post the file and how do I do it?

Yes if predbat itself crashed then it’s a good idea to raise an issue on GitHub and see what Trefor thinks. Since it runs on an appdaemon timer, if there is an exception it should normally just restart itself 5 minutes later, but there may have been a coding bug that meant you had to restart HA to clear it.

Go to the predbat GitHub repository and click the green New issue button https://github.com/springfall2008/batpred/issues
Fill in the template with as much information as you can including attaching the logfile.

You may need to create a (free) github account if you’ve not done so already

Glad to hear that a restart cured it.

Rbor
No issues here. Predbat just doing its standard overnight charge/discharge income generation thing.

spe I just run it in a VM on the NAS and it works as if it’s on a standalone machine 👍

geoffreycoan Thanks as always.
The issue is now posted on GitHub with the relevant log file.
Annoyingly, all my Predbat settings had gone back to default and I have desperately been trying to remember the tweaks I had made. I have even lost Expert mode.
Thankfully my apps.yaml file had not been touched.

I have saved my current settings. Phew – not the best start to the day.

For the record, I run HA on a Raspberry Pi 4 attached to a large 512 Gb SSD (Samsung T7). Really quick response and no chance of running out of memory.

Rob

Jellybaby

I got a Home Assistant Green. Plug and play

Hi @geoffreycoan, I'm looking at how to add a load forecast for our heat pump based on forecast outside temperature. I've had a look through the Predheat docs, and it seems wildly complicated, with a lot of scope for assumptions skewing the results. I've had a bit of a search on here and the wider web, but struggling to find much in the way of help for it (or indeed anyone discussing using it).
I'm wondering if a better bet might be to create a sensor which looks at the forecast temperature, then simply applies a scaling factor based on curve fit from previous data (I've got a fairly decent dataset now from a few months of operation, with a fairly clear trend).
Does this seem like a sensible option? Can you (or anyone else) offer any pointers on how to go about this? I'm not averse to going and reading up and trying things out, but any pointers you can give as to where to look/which methods I need to be learning would be much appreciated.
Thanks.

Josephiah I think the heat pump forecast derived from outside temperatures would be interesting.

It’s something I have been wondering about as well but whilst I’ve got a number of Govee indoor room thermometers feeding into HA, I still don’t have an outdoor thermometer yet. Understanding the correlation between temperature, heat loss and kWh consumed by the heat pump - and ergo, whether changes being made to the heat pump settings are actually improving or not the heat pump efficiency.

First thing to consider is how you want the data to be accessed/viewed because I think this will have a major impact on how to develop such a solution.

I’ve looked very briefly at Trefor’s “sister” project (?) Predheat and can see the strong family resemblance, very similar settings, output, coding etc and even some of the docs being cloned from much earlier Predbat docs - with occasional references to Predbat terms in there as well.
I can see the idea of Predheat and in many respects it looks like a ‘dynamic’ heat loss survey. As you say though there are a lot of assumptions that can have a big bearing on the heat loss calculation - unrelated to GivEnergy but this article on common heat pump issues is v interesting, number 1 being the scope for errors in the MCS survey https://protonsforbreakfast.wordpress.com/2024/02/10/5-reasons-heat-pump-installations-have-problems/
After reading it I’m convinced my own heat pump is over-sized, but how to reduce the impact of that is another Q. Understanding heat pump forecast could be a tool in that thought process.

Anyway, back to what output from the heat loss prediction is wanted and how are you going to use it?

Predheat generates (I think) an hour by hour future forecast for heating kWh, in such a way that it can be graphed (Apex charts) and feed into Predbat. This would be interesting to model future battery activity but for me of limited use because my heat pump more than exceeds my battery capacity. Even when I get my new 9.5 commissioned I’ll still only be able to cover house load not heating. If you do want to forecast detailed time based heat pump demand then going to have to create the time-based forecast as a set of sensor attributes in HA and I suspect this is going to be v difficult to do with template sensors. You can write loops and iterators in Jinja2 but I don’t think it’s a natural language to do so in.

A better programming language approach would be to read the temperature forecast attributes and write the heat pump sensor data from Python code which you could run periodically in AppDaemon in much the same way as Predbat works today. Predbat itself is probably a much too complicated example to start from, I dare say there are other examples out there, but one I have done some modifications to myself is called OctoBlock. OctoBlock runs every 30 minutes, reads your agile price data and writes custom sensors for ‘cheapest X hour’ block of agile time. E.g. we have cheapest 1.5 hours for running our washing machine and dishwasher and I then calculate a time delay offset and display it in a dashboard for these to know the start time delay to program into the washing machine overnight.

That might be all getting too complex, and maybe a simpler starting point would be to create a single value forecast for tomorrow’s heat pump usage based on e.g. the met office temperature forecast. That would be suitable for fine tuning the heat pump config and the prediction model but less useful for feeding into predbat.
There’d still need to be an iterator across the time based attributes of the met office forecast entity but the output would be a single entity value rather than having to create forecast attributes with time stamps. I feel pretty confident that could be created as a Jinja 2 template sensor.

Sorry for the long answer that others may not be interested in….

geoffreycoan
Josephiah
This is an interesting discussion. I have also thought about how PredBat's load predictions could be applied to electrical heating (heat pumps, electric radiators, IR) and have wondered whether the predicted load could be adjusted based on temperature predictions, in a similar way to PV predictions from Solcast.
I have an ASHP which was installed last July. My system is controlled completely by weather compensation and it appears to be the correct size.
My weather compensation sensor typically records about 2ºC higher than temperatures from local weather stations but the ball park temperature is correct. I also have Open Energy Monitoring and my system is visible (with many others) on the public site: https://heatpumpmonitor.org/
My ASHP should deliver 20ºC to the whole house from 6 am to 9 pm, with a setback temperature of 17ºC for the rest of the day and night. PredBat will have picked this up anyway from my historical data.
Looking at my data, in the last 10 days, my daily mean temperature has ranged from 0ºC up to 11.5ºC.
For a mean temp of _10ºC, my heat pump is using ₁₀ kWh per day.
At 5ºC, it is about 20 kWh per day.
At 0ºC, it is ~ 30 kWh per day.
(My base load is only about 7.5 kWh per day so my main winter load is from the heat pump)
So temperature makes a big difference on load, something that PredBat (currently) doesn't consider.
Daily weather forecasts could pick up predicted variations in temperature during the day (as PV data does).
Factors such as altitude can affect the data from Weather stations but this can easily be taken into account by 'scaling' within PredBat settings. I am based on the edge of a large northern city 250 m above sea level. My temperature could be 2ºC lower than the city centre.
PredBat could pick up my venue from information in HA.
I reckon that predictions for load would be more accurate overall than Solcast, which can be real hit and miss.
Has Trefor looked at other predictors such as PVGIS?

My view is that factoring temperature predictions into anticipated Load would be a great addition to Predbat. Whether this is used at all could be controlled by a switch (as with iBoost, etc.)

If anyone is interested, the data on https://heatpumpmonitor.org/ is a mine of information, comparing performance of different types and sizes of heat pumps and installers.

Rob

Interesting discussion. As I said I don’t have an outdoor temperature monitor at the moment, but taking a proxy off the temp monitor in one of our sheds (albeit its an insulated shed so will retain heat), there is a clear correlation of outside temp to kWh for me too although there are a couple of outliers. E.g. 6 degrees=26kWh, 7=28kWh, 8=24kWh, 10=20, 11=16, 12=14, 12=18. My base load is something like 14kWh a day.

Maybe if this is common to a number of people we should put it in as an enhancement suggestion to Predbat for Trefor to look at? Could be to create a load curve similar to the charging and discharging curves based on input sensors for the heat pump consumption an outside temperature.
Simple daily figure or hour by hour?

Rbor I did look at the heatpumpmonitor some time ago but ruled it out as my heat pumps are not internet connected in any way (I have seen a video on connecting into HA via a modbus connection onto the ASHP, but this is very much on my lower list of priorities!). So other alternative was their monitoring box which would need wiring and plumbing into my heating circuit to measure flow rate & kWh output. Definitely interesting but invasive to the heating and expensive.

I do feed my solar generation to PVoutput.org though - scripts for this are elsewhere in the forum

Geoff, Thanks for sharing your activity monitor automation. I have programmed this but I have 2 batteries so what would be the best way to add the second batt details? I could just do 2 automations but wondered if I could add the second one's details into a single automation.

Wavy Davy I have two batteries (and two inverters) so wrote the automation to handle them both, then simplified it for the predbat documentation. That’s the purpose of the ‘inv_id’ and ‘batt_id’ variables in each of the triggers, just duplicate the triggers and set the variables for each of your battery sensors:

  - platform: state
    entity_id:
      - sensor.h_xxxx_status
    from: online
    for:
      minutes: 30
    id: no-givtcp-update
    variables:
      inv_id: inverter 2 (H)
  - platform: numeric_state
    entity_id:
      - sensor.g_yyyy_invertor_temperature
    for:
      minutes: 30
    below: 10
    id: no-givtcp-update
    variables:
      inv_id: inverter 1 (G)
  - platform: numeric_state
    entity_id:
      - sensor.h_xxxx_invertor_temperature
    for:
      minutes: 30
    below: 10
    id: no-givtcp-update
    variables:
      inv_id: inverter 1 (G)
  - platform: state
    entity_id:
      - sensor.g_xxxxx_battery_cells
    to: unknown
    for:
      minutes: 30
    id: battery-unavailable
    variables:
      batt_id: 9.5kW (G)
- platform: state
    entity_id:
      - sensor.h_xxxxx_battery_cells
    to: unknown
    for:
      minutes: 30
    id: battery-unavailable
    variables:
      batt_id: 5.2kW (H)

Here’s a fuller extract of my automation, you can see the repeated triggers with xxxx and yyyy for the different inverters and batteries.

When the trigger fires it sets the appropriate variable as to what has caused the firing, and then uses the variable in the alert message. This means you don’t need lots of different automations that are near identical

I Have a discrepancy between hacs and predbat update status.
hacs is informing me that v7.16.0 is available and predbat says it's already installed. I do have predbat set to auto update, so should I switch this off and just update via hacs? or can I turn hacs update off, as it seems to lag predbat updates.

geoffreycoan correlation of outside temp to kWh

I think this could be done solely from hour by hour weather forecast and monitoring data for next 2 days.
You would need a 'base heat pump' energy which would then be tweaked by predbat depending on temperature, with fine tuning via a PredBat scaling control.
If my heat pump has a heat loss of 700 kW, at 0ºC and my house is set at 20ºC, the heat loss at 10ºC would be half the value: 350 kW with a difference of 35 kW for each 1ºC. Something like this could be the basis of PredBat adjustments based on temperature. This would need mapping to typical temperature distributions across a day.
A heat pump will contribute a large amount to the total load in the Winter months. I suppose this is taken partly into account from the previous 12 days of historical data. But winter temperature can fluctuate greatly.

Could a PredBat plan have an extra column for Electrical heating (as with PV column) with the 'Load' being the base load?

For PredBat, I don't think ultra accurate values would be needed for predictions – just the correct ball park.

I hope I am not writing nonsense here but you should be able to see the idea. Lots of food for thought.

geoffreycoan I did look at the heatpumpmonitor some time ago

Yes, Open Energy Monitoring gear is not cheap, but really nice to have!

Rob

Wavy Davy I Have a discrepancy between hacs and predbat update status.
hacs is informing me that v7.16.0 is available and predbat says it's already installed

Yes I do too. I have 7.16.0 but HACS thinks I am on 7.15.4. Its started since I turned auto update on. I think the problem is that when predbat updates itself HACS doesn’t know about the change.
Also HACS only scans for updated versions once a day (unless you manually do ‘update information’ for each component in HACS) so Predbat can often be ahead of HACS.

There is an issue already logged on this. Whether Trefor can find a way to keep HACS’s idea of what version is installed, I don’t know. I am just ignoring it and relying on Predbat’s auto update

Rbor We should put a feature request in for predicting heat pump load in Predbat for Trefor to look into what’s easily possible. I’d need to graph it out but I don’t think the outside air temperature to heat generation required is entirely linear. For one thing there’s the hot water kWh in the total heat pump consumption, and that varies depending on how much hot water you’ve used as well as the OAT. That’s why I was thinking a correlation curve of average OAT to heat pump kWh based on historical data
Anybody volunteer to raise it?

geoffreycoan We should put a feature request in for predicting heat pump load in Predbat for Trefor to look into what’s easily possible. I’d need to graph it out but I don’t think the outside air temperature to heat generation required is entirely linear. For one thing there’s the hot water kWh in the total heat pump consumption, and that varies depending on how much hot water you’ve used as well as the OAT. That’s why I was thinking a correlation curve of average OAT to heat pump kWh based on historical data

Not a user of predbat, so just an outside observer... this seems terribly specific. Is there a case for just having an abstract sensor which outputs a prediction of how much extra power may be needed. That way, predbat doesn't have to worry about what that load is, just that it should take it into account in its sums. That way, it can be developed, parameterised and tuned separately from predbat itself. (And there can be competing implementations until a winner emerges.)

I've seen this popping up a few times. I'm on Intelligent, so wondering why it would choose to charge and discharge during one 30 minute slot in the middle of the cheap period. I can't see why it would do this?

geoffreycoan I guess it depends what data one has available. In my case, my HP separates out heating and DHW figures, so it doesn't seem like it should be that difficult to take a forecast temp, perhaps apply an offset based on the historical match between that and local measurements, and look up a curve (either lookup table or curve fit equation).
In my case I have an automation for DHW runs based on the best Agile slots, so would need to think about how to apply that appropriately. I don't see the need to run it on the same timeframe as PredBat - I'd have thought hourly would be plenty - anything faster than that might be subject to wild swings when cycling in milder weather.

But DD raises a good point. I can see the argument for including something specific in Predbat (majority of house load, fairly predictable, likely to be an increasingly sought-after feature) and just keeping it separate (difficult to customise for the foibles of everyone's different devices and schedules). So maybe it's better to think how can we use the existing load_forecast input to best effect, and come up with a separate automation/script to produce a suitable input...? I'd like to think I could now write out a fairly accurate forecast on paper of my own heating and DHW usage - just need to figure out how to translate that...

(And yes, is there a better forum for Predbat-specific discussion of this type?)

Josephiah another possible area of research is to consider thermal store as additional sort of battery which can be controlled. It depends so some extent on how tolerant you are to fluctuations in temperature, but it could be possible to run HP very slightly harder when power is cheap (storing heat), and back off slightly when price peaks (discharging heat).
Overnight, power tends to be cheaper, but source temperatures colder, so it's an interesting question of when it's better to tolerate lower cop to charge thermal "battery" when power is cheaper, vs storing the energy in chemical battery to use when outside temp., and therefore cop, is higher.
(I don't yet have a heat pump, but I hope it will be coming soon.)

Zakalwe the "why" is because it is profitable: import is 7.5p but export is 15p. Arguably the 30 min divisions are a bit arbitrary.
I think I've read that there's a param you can set to say whether it's allowed to charge and discharge within a 30-min block.
It's interesting that it chose that block to do it when others seem equivalent. If batteries are happiest around the 50% mark, then earlier might have better. But if they're happier when they're warmer, later might have been better. Perhaps this a compromise.
I suppose later is also better if you have EPS configured - better to charge as soon as possible in case there's a power cut.

Zakalwe strange that you don't have the car column on the table if you're on IOG. It's there for me whether there is a smart schedule or not, showing which slots IOG will be using.

As to your Q is as others say, it's economical. I suspect it chose that slot because that's when the car isn't charging - again hard to tell when there is no car column, but that's the behaviour I see on IOG w/predbat - it takes advantage of half hour slots where the car isn't charging to charge/discharge battery to make some cash.

Zakalwe What are you going to do with your 1p saving? 😃

What are people setting for this in Predbat?

input_number.predbat_battery_loss is an assumed percentage figure for energy lost when charging the battery, the default 0.05 is 5%.

input_number.predbat_battery_loss_discharge is an assumed percentage figure for energy lost whilst discharging the battery, the default 0.05 is 5%.

input_number.predbat_inverter_loss is an assumed percentage figure for energy lost during the conversion within the inverter from DC to AC or AC to DC, the default is 0% for legacy reasons but please adjust.

Currently Mine is set to 3% for both charge / discharge losses and 4% inverter loss. I haven't touched these (so appears to be there on install) but get the feeling they are contributing to incorrect predictions. Are these right for my system (AC + 9.5 batt) ?

Zakalwe
Like you, I'm on IOG and I choose to work my battery hard. So Predbat does several of these charge/discharge slots for me every night.

For example, last night (from midnight) I imported costing £2.21, and exported generating income of £1.09, and ended at 5.30am with a full battery.

So Predbat is dramatically reducing the cost of my nightly charge (even after losses).

regarding the predbat monitoring automation, what is the best way to check if it is setup and contacting correctly without having to disconnect the inverter.

DD Yes, we certainly do this, both when we were on Cosy, and now on Agile, with a fairly simple "build up the temp by a degree or two ahead of the peak period then switch off and coast across it" strategy - worked well with HP alone; even better with battery added.

DHW runs (often the most intensive periods) are fairly easy to schedule for the cheapest Agile slots using the target rate sensor in HA. With the heating, you need to weigh up the benefit of fluctuating to catch the cheapest slots (so the pump will work harder at certain times) vs the efficiency gains of running the same temp 24/7. I recently changed to the latter (albeit keeping our "coast across the 4-7pm peak" bit), and the efficiency gains were fairly startling, in a good way.

pacemaker strange that you don't have the car column on the table if you're on IOG. It's there for me whether there is a smart schedule or not, showing which slots IOG will be using.

I haven't configured it for car charging yet, mainly because I don't have the Tesla integration yet. The documentation refers to this integration: https://github.com/alandtse/tesla which states that it needs Tesla Tokens to generate the API authentication. However Tesla Tokens doesn't seem to be listed on Google Play any longer? Maybe another one for @geoffreycoan to amend?
So, I have no way to read the car's SoC. I do have a CT clamp on the cable feeding the car charger, so I am part way there, just need to extract my digit and work out how to set it all up.

danerf What are you going to do with your 1p saving? 😃

Spend it all in the one shop! 😃

DD the "why" is because it is profitable: import is 7.5p but export is 15p. Arguably the 30 min divisions are a bit arbitrary.

I'm not convinced. 30 minutes export nets 7.5p before conversion losses. It's pointless in the grand scheme of things.

PianSom Like you, I'm on IOG and I choose to work my battery hard. So Predbat does several of these charge/discharge slots for me every night.

For example, last night (from midnight) I imported costing £2.21, and exported generating income of £1.09, and ended at 5.30am with a full battery.

So Predbat is dramatically reducing the cost of my nightly charge (even after losses).

Same here. At the moment it's discharging at full pelt, down to the minimum SoC that I have set (18%)

It seems to make sense to me that this is how it should work....judge the timings so it can discharge to hit the minimum SoC just at the start of the cheap period and then recharge the batteries back up. I just don't get why it would interrupt that charging to discharge for a few minutes. It would seem more logical to charge continuously back up to 100% and then discharge? For example, it finishes charging to 100% by 5AM. It could then start to discharge?
Maybe it's giving itself some room to ensure that it guarantees to hit 100% by the end of the cheap period?

It's not a massive issue...we are only talking about pennies after all. Overall I am very pleased with how it is working. It seems to be maximising the batteries to earn their keep.

14 messages to reply to on this thread!

@Josephiah & @DD Agree we should make any prediction of heat pump house load as generic as possible. The load_forecast is one way to get it into Predbat but it has a very specific format required. Looks like its a single daily value with a 'last updated' timestamp.
I was thinking we could let Predbat do the calculation based on (1) historical daily consumption figure, (2) historical average temperature and (3) future predicted average temperature and as long as these were all configurable sensors it could serve many people. But equally could be outside of Predbat as a bolt-on piece of code. Not precious either way,

@Zakalwe the charge and discharge in the same half hour period is as has been said because its cheaper to import than it is to export, even after losses are taken into account. You can turn this on or off with switch.predbat_calculate_discharge_oncharge if you want to. I do find it strange that Predbat doesn't do this all night when rates are suitable - in your example the soc only just reaches 100% by the end of the night in the cheap period, so only opportunity for 1 discharge period,
If I look at my own plan for tonight, with rates low, you'd think there would be the opportunity for more active discharging to make more export income, but if it did then maybe I'd be getting stressed about the impact of over-active charging and discharging of the battery. I just trust Predbat to get it more right than I could do manually and let it get on with it

pacemaker my losses are charge 0.05, discharge 0.05, inverter 0.04.
If you look on this forum there are posts where people have measured their losses and come up with figures in the range 10-20%. Yours at 3, 3 and 4 is therefore on the low side. Mine at 5, 5, 4 is around the midpoint. 20% seems too extreme to me even if it may be accurate. It does seem there is no single right answer.

Wavy Davy you can shutdown the givtcp add-on to simulate a failure and test that the failure check automations are working OK. For the predbat running automation just set one of the critical sensors in apps.yaml to something invalid, e.g. the load sensor, to force predbat to crash.

@Zakalwe no idea about Tesla tokens, sorry !

Zakalwe I haven't configured it for car charging yet, mainly because I don't have the Tesla integration yet. The documentation refers to this integration: https://github.com/alandtse/tesla which states that it needs Tesla Tokens to generate the API authentication. However Tesla Tokens doesn't seem to be listed on Google Play any longer? Maybe another one for @geoffreycoan to amend?
So, I have no way to read the car's SoC. I do have a CT clamp on the cable feeding the car charger, so I am part way there, just need to extract my digit and work out how to set it all up.

I can't help with the google play part, but you could consider using Tessie, and the Tessie integration in HA. It has all the same entities that Predbat can use, and frankly seems more stable than the Tesla Integration. I have both running right now and Tessie updates way faster, and has all usable entities (whereas there is some bugs on the Tesla integration). The only downside is that Tessie is $5USD a month, but there are a lot of extras you get that might be interesting to you.

Alternatively there should be other ways to get the Tesla API auth key, like https://about.teslafi.com mentioned in the integration above.

pacemaker The only downside is that Tessie is $5USD a month, but there are a lot of extras you get that might be interesting to you.

I'm too tight to pay that, especially as I'll be changing the car later this year. #Scrooge

My MG4 has no HA integration without losing the app functionality (you can only use it on one device). I have made three custom helpers.

• Desired SOC
• Current battery capacity (KW) in the car
• Hypervolt car charger cannot tell if the car is plugged in. So, another to say if it plugged in or not (manually changed)

I considered putting a guide on my unique use case in the predbat documentation. Which section do you think this example would fit into best?
I'd have to google how to modify the documentation on Git Hub. It's all new to me.

danerf I considered putting a guide on my unique use case in the predbat documentation. Which section do you think this example would fit into best?
I'd have to google how to modify the documentation on Git Hub. It's all new to me.

Thanks in advance for the contribution !

I’d suggest you add it to https://springfall2008.github.io/batpred/devices/ which details what 3rd party devices Predbat works with - Zappi Wallbox, Ohme, Tesla, etc.

There’s actually a guide to developing and enhancing Predbat including updating the documentation https://springfall2008.github.io/batpred/developing/ - the suggested mechanism is to use Codespaces which provides the Visual Studio editor with plugins for checking documentation markup and Python coding standards.
This is how I edit the documentation. I created my own fork of predbat then run Codespaces to edit the docs. When finished I push commit the changes in Codespaces (checking no errors on the bottom of the screen), sync the changes to my GitHub fork, and then in GitHub I create a pull request to tell Trefor that my changes are ready for review and incorporation into the main Predbat code base.

geoffreycoan Are you sure it's that section? None of them are third-party integrations and are manually done.

danerf I suggested it went in there as that page covers how to integrate with 3rd party devices such as Tesla charger, so thought your MG4 could follow the same pattern.

Car charging is actually spread over different bits of the documentation. As well as the above page there is:

• specific things to set in apps.yaml https://springfall2008.github.io/batpred/apps-yaml/#car-charging-integration
• how to approach car charging (Intelligent Octopus or Predbat-led) https://springfall2008.github.io/batpred/car-charge-planning/
• and the HA customisation & config items for car charging https://springfall2008.github.io/batpred/customisation/#car-charging

As you've developed custom sensors then the other logical option is to put it in the apps.yaml doc, at the end, and signpost it from earlier on. But I still suggest the devices is a good match, and there needs to be signposting adding from apps.yaml doc to the devices page as at the moment there's really nothing in apps.yaml about configuring for specific chargers/cars.

I'll probably restructure the devices page as well at some point because at the moment I can see that Nordpool, Solcast and Octopus Energy all repeat stuff that is elsewhere in the docs and one of the things I've been doing is to remove duplication and improve internal cross-referencing so things are said only once and with sufficient detail for newcomers to understand

Anyway. just my 2p worth

Inquiry for the more advanced Home Assistant users, you know the default stuff that gets plastered on the overview page BEFORE you take control (apparently you cannot take control and have it auto add stuff) how would one go about setting those particular cards up, is there a guide for that somewhere?

Only asking as having all the default Givtcp, predbat and octopus stuff plastered one one page causes quite the delay in the tab fully loading lol

Jellybaby
IIRC when you change from automatically managed to manually managed it converts your existing "auto" dashboard into a manual equivalent.

After that, setting up dashboards is pretty easy - you can just create a new one under Settings, then go ahead and add cards to do whatever it is you want.

You have proxmox or some other VM system don't you? Why not just go ahead and try it; you can always go back to a backup if you get in to problems.

Jellybaby I'm sure there is a guide somewhere but I'm not that expert.
I recently went through the exercise of moving items from the Overview Dashboard to separate dashboards.
You can create new dashboards in Settings>Dashboard.
You can then move cards by editing the Overview dashboard, clicking on the 3 dots in the lower right hand corner of the card and selecting move to view where you can specify the dashboard to move the card to.
The are also copy and paste options on that menu if you are so inclined.

Alternatively when you add a new dashboard you can choose to copy from an existing one - then you can removed the cards you don't want.

For simple list cards you can also add entities to a dashboard from the device page (Settings>Devices and Services).

Alternatively when you add a new dashboard you can choose to copy from an existing one - then you can removed the cards you don't want.

oooooooooooooooooooooooooooooooooooooooooooooo that is good to know, thanks.

SJB @PianSom agreed

I leave the default dashboard with everything still defaulting on it as its useful to have a full reference page, but most things are on a custom dashboard with tabs for:

• GivTCP status & inverter controls, Powerflow control, weather and solar forecast and a few predbat entities
• Agile rates (predbat plan) and auto-calculated entities to show when its cheapest to put the washing machine on
• Power meters for all the metered things in the house
• Temperature charts for all the room temp monitors
• Soc history, import history
• Predbat controls using the auto-collapsible cards
• Predbat graphs (don’t use these much now)
• Power up controls

This and the Energy dashboard do most of what I want

You can change the default dashboard that opens for a user when they connect

geoffreycoan
What I really want in my HA is something that replicates and replaces the standard Power Graph picture on the GivEnergy portal (the one showing grid in/out, load, PV in, battery in/out and SoC) . Then I can just never use the portal again.

But I rather think it may involve me getting data exported to Influxdb/Prometheus, using Grafana to create a graph, and then using HA to display it

I keep on meaning to go and have a search to see if anyone has beaten me too it - they normally have. You haven't come across such a thing, have you?

PianSom I use the GivTCP battery card and PowerFlow Plus to give an instantaneous view of what’s happening. The latter is very similar to the GE app home page

That and the Energy dashboard give me what I need.

I’m assuming you want something like this? Should be straight forward to do with Apex charts on the standard db.

PianSom I keep on meaning to go and have a search to see if anyone has beaten me too it - they normally have. You haven't come across such a thing, have you?

There are a couple out there. Have a look at Oliver's "Speak To The Geek" Youtube channel- he details how to set them up.

https://youtu.be/6IbdPoZb5zc?si=3Jfo1vc3_4PPOEo5

https://youtu.be/C4Zh35E9wJE?si=rGgXqKiez0tGXzmO

I've set my PredBat dashboard up like this:

with another view showing "at a glance" whats going on with the numbers:

geoffreycoan I just knocked this up in Apex. Need to sort out the + and - axes and scaling SOC, but sort of what you wanted?

I use a set of bar charts to show what the power breakdown across the monitored devices is:

Thanks @geoffreycoan @Zakalwe

Yes, that's the graph I'm after Geoffrey. Although much the same info is on your dashboard Zakalwe, I particularly like the portal graph.

The beauty of using Grafana is that - like the portal - it makes isolating the individual data series for examination very easy, and I am familiar with it already. That said, I wouldn't mind giving up that advantage if an Apex chart was easy to create. I've not used it other than as a casual user, so I will take a look at the docs.

EDIT - hmm, that WAS quick! I am now impressed @geoffreycoan

geoffreycoan I leave the default dashboard with everything still defaulting on it as its useful to have a full reference page, but most things are on a custom dashboard with tabs

this is the way!

started to get into custom card dev after I installed predbat, I needed a cleaner way to know WTF was going on.

You can see my custom predbat card just under the power flow card. It has the predbat status and short explainer, my IOG plan (when available) and the best daily cost I'm gonna hit with predbat.

I also customised the predbat table into a new card

I'm not even sure its better, but at the time I found the original card just too hard to read.

pacemaker
Nice work! Much food for thought. I really need to put some effort into dashboards.

For the power flow in the top left, how do you find it compares to the Inverter app (of which I am a huge fan - lots of info nicely presented)? Personally I'd also include some temperature readings too (of the AIO inverter, battery - which are on Inverter - and my PV inverter).

I do like your smoother solar vs forecast graph - much better that the default Energy dashboard one, which is bucketed by hour.

Like you, I am not a huge fan of the Predbat plan layout. For me the columns are in the wrong order - I don't much care about the Import/Export cost (which seem to stand out prominently, as they are first), but am interested in the projected state, SoC and Load. And it is just annoying that the running cost column is so far away from the cost columns.

PianSom

Adding to the mix.
2 pages. A dedicated page for battery prediction, the basic set of apex charts, the plan and all the switches and entities, second page mixing predbat data with GivTCP and Solcast data. Leaning heavily on mini graph card.

Predbat status, next predbat charge and discharge events, chart with last 12 hours of grid, pv and consumption data graphed with current power, solar power, battery power, grid power and battery SOC.
House is using 485, no pv, battery discharging 567w, no grid, SOC at 11%.

Solar profile by string with string voltage. Solcast forecast with actual total and per string. SOC history with % per battery and predcat predicted remaining run time. GivTCP consumtion with some individual power graphs.

Grid usage with GIVtcp total import andtotal export, Octopus current import and export rates. Grid costs for the day showing day cost, day import cost, day export income.

PianSom I've put a feature request in to allow user configuration of the predbat plan
https://github.com/springfall2008/batpred/issues/782

Could be useful for some people

@pacemaker +1 for the solar prediction graph. Like it.
One thing I did on my dashboard was to change the units of all the power entities I want to display to kWh/kW and display precision to 1dp, e.g. 2.6kW - made it a lot easier to read

@PianSom @geoffreycoan

feel free to use the yaml to set up the forecast chart:

https://github.com/pacemaker82/HA/blob/main/forecast.yaml

Its assumes you have solcast integration and givtcp add on. It uses the apexcharts card via HACS

PianSom Have a look at this - https://github.com/springfall2008/batpred/issues/301

pacemaker I love the predbat table. Can you please share the code for that? I want to use it 🙂

Oh wow - lots of food for thought there. Thanks everyone!

That's a great chart @Ivan I can see me using that and @pacemaker 's solcast one as my mainstays. Though I think I'd prefer to keep power history and forecasts separate, personally.

@Arg0t - why the timestamp label? And what is the x axis on your charts - today, last 12/24h?

I am totally in awe by all these suggestions.
My dashboards pale into insignificance compared to these.
We could do with a repository where folk could upload the underlying code along with the the charts and customised cards.
Keep them coming and thanks so much to everyone who have posted their charts.
👏👏👏
Rob

PianSom @Arg0t - why the timestamp label?

Trefor has been through all the Predbat entities and resolved some issues with missing ‘units’. The date/time outputs have this ‘timestamp’ unit of measure. Personally I don’t like it, it takes up too much space on the screen but haven’t thought of a better value to set it to yet

@Arg0t I like the graph of load, PV etc above. Haven’t got round to looking at the mini graph card yet. Apex is OK but it’s quite slow with things like this chart which is heat pump daily consumption vs outside temperature as it has to take the ashp_today_energy and do a max() on all the values across the day. Should be an easier way to read the end of day value. It also doesn’t seem to read long term statistics either, only works on the main 15 day history in HA so I can’t go back any further than the 2 weeks. Maybe Grafana is the answer but seems a lot of hassle and data duplication.

geoffreycoan Trefor has been through all the Predbat entities and resolved some issues with missing ‘units’.

Ah, that explains it, thanks. Yes, it does look rather odd

Did you know that some are still "*"?

I cant get nothing to go horizontal, I got the predbat plan card on fresh window and copying and pasting stuff over it just all goes below it and it taking 7-8 presses of page down to reach the bottom.

Also for those with Octopus for Gas how did you add that to Home Assistant?

Jellybaby It's part of the Octopus Energy Integration. I don't remember doing anything other than setting up the integration and it gave me the gas entities. The only setting I have is the calorific value.

Jellybaby I cant get nothing to go horizontal, I got the predbat plan card on fresh window and copying and pasting stuff over it just all goes below it

What do you have the page layout set to? The default ‘Masonry’ I find is hard to use, tiles get arranged to form a brick pattern but if you move them around they don’t always move where you expect them to.

I personally use the HACS front end component ‘layout card’ for most of my dashboards, and in particular the Grid layout https://github.com/thomasloven/lovelace-layout-card
Even if you’re not setting up a grid it does things like spread cards to be full screen width

geoffreycoan ill take a peek at that next time, thanks.

Wavy Davy Thats what I meant, what entity did folks add to gas consumption, there was only a short list when I looked earlier.