In the first year ‘first night live on Predbat’ has collected nearly 3,200 comments on our collective experiences, questions, answers and discussions on using Predbat to manage our batteries and solar systems.

https://community.givenergy.cloud/d/3696-first-night-live-on-predbat/

That’s an awful lot to read for any newcomers so its time to start the year 2 thread

Always happy to help

Geoffrey

Useful links:

• Predbat documentation https://springfall2008.github.io/batpred/
• Predbat add-on https://github.com/springfall2008/predbat_addon
• Predbat application (raise any Github issues here) https://github.com/springfall2008/batpred
• Predbat YouTube channel https://www.youtube.com/@springfall2008
• Predbat Facebook group https://www.facebook.com/groups/1477599886299106

Well done for starting this 2nd year thread. 👏👏👏

I can't believe that we reached 3,192 comments.
I would never have got to grips with Predbat or HA without so many helpful comments.

Rob

Rbor I completely agree.

geoffreycoan
Rbor

Thank you both for helping me get HA etc up and running this year. I would never have been able to do it without your help. Hope you have a great Christmas and a happy New Year. 🎄🍺

Daveb01 👍

Rob

There was a Predbat update this morning, so have said in my mind this will be the last one I will do before Christmas, I pressed the button and all good phew.

geoffreycoan That’s an awful lot to read for any newcomers so its time to start the year 2 thread

Err... Either this thread will contain all the same tips, or a newcomer will still need to read the whole of the first thread too .?
Is predbat on 3.0 now? Would that make sense as a more logical split?

DD Err... Either this thread will contain all the same tips, or a newcomer will still need to read the whole of the first thread too .?

Possibly they would, and that is of course recommended, but for any newcomers I will summarise the 3100 posts on the other thread:

• Read the documentation, the answer is (probably) in there already

Is predbat on 3.0 now? Would that make sense as a more logical split?

Latest version is v8.8.12. Version 8 was a fairly major update, I think it was the one where the codebase got split into many modules, but the numbering system is a bit ‘Trefor’ so who knows.

We agreed to split onto a new thread at the 1 year mark. It was going to be 3000 posts but we sailed past that. The split has happened, onwards and forward !

So i think the recommendations was to set the metric for export to 5p

Any ideas on the one above it?

TX200 The metric min improvements are the minimum you have to save in the half hour slot by lowering the battery SoC or doing a forced export. https://springfall2008.github.io/batpred/customisation/#battery-margins-and-metrics-options

I have mine set to 0 and 4 respectively. 0 and 5 or 6 are fine

Finally done it, after running Predbat 8.5.3 which has been quite stable for the last two months, I upgraded just now to the latest Predbat version, 8.8.13.

Interesting comparing the plan before and after:

8.5.3 plan, slightly sub-optimal, I have noticed it had a tendency to occasionally freeze charge unnecessarily e.g. 1900, preserving the SoC for no obvious reason when rates were dropping, and not always discharging when it could do eg 23:00

8.8.13 plan, the two issues identified above on the 8.5.3 plan are gone, but a new query over why Predbat doesn’t start releasing the SoC at 15:30. This may have just have been that the plan cutoff prematurely because the latest plan does show the SoC releasing then.

I thought the 8.8.13 Predbat plan wasn’t that good, overall a bit more expensive than the old 8.5.3 plan.

But 10 minutes later, the latest 8.8.13 plan has improved considerably:

And now its forecasting £1.61 by the end of the plan, so just normal predbat flip-flopping.

Don’t like the new Demand status but guess I’ll have to get used to it. 18 inverter writes since installing, so 9 per inverter. Seems quite a lot when the inverters are Idle/Demanding. Hmm

geoffreycoan yes I’ve noticed my plan has started changing massively at times. I go to bed in the knowledge that Predbat has got it all under control with what seems like a clear and logical plan and then wake up to find it’s actioned something totally different. It almost seems to be reactive at the moment rather than proactive. Agile rates have been good today but in one hour I had 14 register writes which seemed totally unnecessary to me as the load prediction was stable and I hadn’t made any changes myself.

I've found one cause of the extra inverter register writes, the battery pause end time is being repeatedly set to 23:59:00 then 00:00:00 in each Predbat run

Logged as a github issue https://github.com/springfall2008/batpred/issues/1781

Goshiki2 if you see obvious things in the plan changing unnecessarily then do log them as github issues. Waiting for the new 'less inverter writes' logic to settle down was part of the reasons why I hadn't upgraded for a while.

The Predbat plan can change significantly particularly in the long term forecast if one scenario is very close to the same cost as another. Slight changes in house load vs predicted load can cause the plan to flip flop. I tend not to pay too much attention to the longer term plan for just these reasons.
Predbat plans the next 4 hours slightly differently from the longer term plan so the immediate forward plan should be more stable

geoffreycoan
This is interesting.

I have been looking though my logs, trying to work out some reason why, at this time of year when I have an empty battery pretty much every evening, Predbat chooses to charge for 15 mins at the start of my cheap IOG period at 23.30, then discharge for 15 mins, before doing a full charge. I had been wondering what "special" thing could be happening at midnight to cause such odd and predictable behaviour. I had been wondering whether the code had a < when it should have a <= .

I wonder if your issue is the one I have been seeking?

eg logs look like this

20174 2024-12-22 18:55:44.883614: Not setting export as we are not yet within the export window - next time is 12-22 23:45:00 - 12-23 00:00:00
20173 2024-12-22 18:55:44.883589: Next export window will be: 2024-12-22 23:45:00+00:00 - 2024-12-23 00:01:00+00:00 at reserve 4
20172 2024-12-22 18:55:44.883531: Adjust demand (idle) time computed is 12:30:00-23:59:00

EDIT - I've seen Trefor's reply. The hunt continues.

geoffreycoan Since Trefor added the register writes entity I’ve been averaging 35 to 45 writes per day as Agile prices have been high and the plan was pretty straightforward. Yesterday when Agile prices plummeted it was 145 writes for the day and that’s when I noticed the plan being more reactive.
From 4pm today when tomorrow’s rates were confirmed, this was a screenshot of the plan with export due to start at 18:00. I had to intervene at 17:55 to delay the export until 19:00 as it was in my opinion discharging the battery unnecessarily early.

Then at 19:05 just after it had started exporting the plan changed to this

I updated to the latest release yesterday so I’m going to go through all the settings to confirm against default but I’ve not really seen this behaviour before.
Edit: and now at 19:40 the plan has changed again:

Goshiki2 It would be worth looking at the right hand Total cost column to see how it is changing across the different plan iterations. It could be that the benefit of one plan over another is quite small and so the plan can change significantly for small financial gain.

Would expect more inverter writes when the agile activity is “high” but I think I too am seeing instability in the plan. Will keep looking at it.

Goshiki2 geoffreycoan
Over the 11 months that I have run predbat with Agile, I have learnt that predbat changes the plan often as events happen, whether that be more load than initially planned, disappointing PV, etc.
See comments by geoffreycoan on 'the next 4 hours'. Consequently, I don't worry too much if confronted with strange predbat plan well before Nordpool, 4pm rates and the 'last 4 hours.

I grant predbat permission to control my inverter. I do step in (rarely) with forced charges or exports when I think that 'I know best' but I have learnt to let predbat get on with it.
I am safe in the knowledge that Trefor is in charge of predbat and we help Trefor to improve predbat and to identify bugs with our feedback via GitHub comments.

At the moment, Agile rates are all over the place and predbat is very active, charging during lowest rates and exporting when rates increase. The overall aim is to minimise costs.

'Up and down' Agile rates are always going to lead to an increase in register writes but we have been waiting for such rates! The last 2 days, I have had 187 and 132 daily register writes. But in the doldrums before, I was sometimes getting just 20 daily register writes. I am averaging about 60 register writes since v8.8.0, which introduced register writes entities, 3 weeks ago.

We have one more night of low Agile rates before winds drop and the low rates disappear. I just need some reasonable rates overnight to get battery charged.

Rob

geoffreycoan I upgraded just now to the latest Predbat version, 8.8.13.

Well done on catching up and even overtaking me as I didn't notice that v8.8.13 had hit the streets.

You missed the fun when Trefor split switch.predbat_calculate_secondary_order_slots into two separate switches in v8.8.10, and then changed their names and defaults in v8.8.11.
I am hopelessly bemused by what these switches are doing and am using the default settings on the basis that "Trefor knows best".
I have read the documentation repeatedly but it remains largely a mystery.
Latest documentation states that defaults for switch.calculate_import_low_export and switch.calculate_export_high_import are True and False respectively but defaults in webUI are True and True. The release notes for v8.8.10 and v8.8.11 confuse me further.

Rob

PianSom I have added a comment on Github following on from Trefor and Geoffrey.
Could this all linked to the two new switches?:

switch.calculate_import_low_export 
switch.calculate_export_high_import 

Rob

Rbor
I don’t think so. This behaviour long pre-dates the new switches 🙁

I've just seen that Trefor has sent us all an early Xmas present: v8.8.14.

Rob

Done 2 predbat updates in a row and NO issues. Whoopee and thank you Trefor.
On a different note is there a entity for daily register writes?
Can only find a total one, but would like to know how many per day.

Try this yaml code in a new 'manual' card:

type: markdown
content: >-
  {{ (as_timestamp(now()) - as_timestamp("2024-12-02 21:28:00")) |
  timestamp_custom("%j")| int }} days

  {{ states('predbat.inverter_register_writes') }} total writes

  {{((states('predbat.inverter_register_writes') | int) / ((as_timestamp(now())
  - as_timestamp("2024-12-02 21:28:00")) | timestamp_custom("%j")| int)) | int
  }} avg per day

Rob

And another one showing a neat 24 hour running view against status (easy to change the number of hours.)

Here's the yaml which you can just copy into the card.
This one can be improved.

title: History
type: history-graph
hours_to_show: 24
entities:
  - sensor.register_count_daily
  - predbat.status

Rob

Rbor Cheers Rob.

I put my code in the Predbat card so I can see it all in the same place 😀

Rbor Seems I have a problem with the graph, don't have the entity "sensor.register_count_daily".
Maybe its because I have a hybrid gen 1 inverter?

I went to 8.8.14 today soon after it was released. Was seeing some weird behaviour with freeze charging when it didn’t make sense to do so, hoping that this release fixes that.

Thanks for sharing the YAML Rbor I have been fiddling around with trying to create a utility meter to give a daily figure. I’ll keep fiddling and if not I may start hacking the code (after the next batch of documentation changes of course …)

3 days so far with the inverter writes being counted, some of the first day was false incrementing of the pause start/end time sensors that don’t work on my inverter firmware, but my average is currently 133 per day, so 65 per inverter.

Wavy Davy I can't take credit for the code though.
@TX200 contributed the code, 3 weeks ago, on the thread: "For those of us thrashing the inverter" when we were discussing register writes.

Rob

Wavy Davy i think you'd have to create that attribute using a helpers object. Also discussed in the thrashing topic.

I made a slightly better version of the above code, with variables, so you only have to set the date once (the date you upgraded to the version that contains that value)

{% set datediff = (as_timestamp(now()) - as_timestamp("2024-12-02 07:33:00")) | timestamp_custom("%j")| int %}
{% set totalwrites = (states('predbat.inverter_register_writes') | int) %}
{{ datediff }} days
{{ totalwrites }} total writes
{{ (totalwrites / datediff) | int }} avg per day

TX200 Thanks.
I have adapted my code to accommodate your improved code.
It works!

Rob

Wavy Davy Trefor introduced the entity with v8.8.0:
Total register writes (all inverters) 'predbat.inverter_register_writes'

It may have been subsequently improved.
I added the code to the 'history card'.

Which version of predbat are you on?

Rob

Rbor I'm on v8.8.14.
I do have that sensor (predbat.inverter_register_writes) but that is the total writes.
I have followed the posts on the other forum to create a daily sensor, but as yet it isn't showing any writes and the graph isn't appearing. I hope it's just waiting for a value to appear in the daily sensor, as I think it must just increment starting at 0.
According to the plan its due to do a write at 22:30 but may just force a charge to get a write and see if it works.

Wavy Davy Do you have the history chart in your charts?
If I select the register write entity in devices & services, I get a chart.

I then select 'Show more'. If I select the 3 vertical dots, there is an option to 'add current view as card'. The option isn't there until I 'Show more'
Then try just adding the card to a dashboard.

Rob

Think I must have done something wrong. I get entity unavailable. So will have a look through what I did and see if I missed something.

Wavy Davy Strange.
It's the entity I copied a few posts ago.

Rob

If you mean the entity "predbat.inverter_register_writes" that one is ok. It's the daily one that's unavailable

Wavy Davy There isn't a daily one! My workaround was to show the chart over 24 hours. I the have to eyeball the number in latest 24 hours as the chart returns to zero at midnight.
My current chart is showing 13/14 writes from midnight to 21:47.
Needs some code to show last complete 24 hours only.

Rob

have redone it. Now getting the daily writes showing 925 which is the total register writes.
Does it have to reset at midnight to show the daily writes?

Just seen your last post. I thought the daily sensor reset at midnight? so using the graph with that entity is just the writes that day,

I ThiNK I have it correct. I have a created a named sensor called "sensor.writes_today". Using this as the graph entity it now shows a 0 reading, which is correct as there has not been a write yet. Will know for certain at 22:30 when it starts a charge.

Well it has incremented to show 1 write. So I think I need to let it run for a while to see how it goes.

Have a look at "For those of us thrashing the inverter" posts 125-145.

You will get an idea of the rigmorale that I had to go through!
Hope it all makes sense. I had a lot of help from @geoffreycoan and @PianSom

I had to create a helper of type template.

See if any of this makes sense but that is where my entity came from: sensor.register_count_daily

Rob

Rbor
Thanks for your help.
That is the posts I used, just took me a little bit to get it working (I think).
I will see if it resets at midnight.

🤞

Rob

Rbor OK I have a solution to counting just today’s inverter writes. Bit of a pain because there’s no way in HA/Jinja to update an attribute value without resorting to HACS add-on’s and configuration.yaml changes like this https://github.com/pmazz/ps_hassio_entities

My solution requires one additional helper and an automation:

1. Create an input_number helper, give it a very large max value:
   

2. Create an automation that triggers at midnight to capture the current value of the Predbat inverter register write count:

   alias: "Predbat: Capture midnight inverter register write count"
   description: ""
   triggers:
     - trigger: time
       at: "00:00:00"
   conditions: []
   actions:
     - action: input_number.set_value
       target:
         entity_id: input_number.predbat_midnight_inverter_register_writes
       data_template:
         value: "{{ states('predbat.inverter_register_writes') | int }}"
   mode: single

3. Amend the dashboard so it can show the count of today’s inverter register writes:

   - type: markdown
     content: >-
       {% set datediff = (as_timestamp(now()) - as_timestamp("2024-12-22
       17:20:00")) | timestamp_custom("%j")| int %}
       {% set totalwrites = (states('predbat.inverter_register_writes') | int) %}
       {{ datediff }} days, total {{ totalwrites }} inverter writes
   
       {{ totalwrites - (states('input_number.predbat_midnight_inverter_register_writes')|int)
       }} inverter writes today
   
       Average {{ (totalwrites / datediff) | int }} inverter writes per day

Merry Christmas !

Anyone upgraded to 8.8.14?

My battery didn't charge overnight, despite the solar forecast being poor.

It planned to charge for 30mins circa 3am, but didn't.

Predicted load is low though, so maybe it thinks it can make it beyond the evening peak.

TX200 Predicted load is low though, so maybe it thinks it can make it beyond the evening peak.

This could be the case. I am predicted 4.67 kWh today and the sun has recently risen and is visible for me.
My batteries did completely recharge overnight but I do have a heat pump which will likely consume about 15 kWh in today's projected temperature. That is roughly the capacity of my batteries!

Rob

TX200 Yes I’ve been on 8.8.14 all the way through Christmas. Yesterday all the cooking was much earlier in the day on grid import as Predbat held the battery SoC for the evening peak. I did consider putting some force Demand’s in to use the battery earlier but didn’t want to run out of battery in the peak so didn’t, and of course we ended up with the batteries half full at the end of the peak.

Rates were not great overnight, mainly at 20p on Agile with only a couple of 18p slots so Predbat didn’t do a lot of charging for me either. Today much the same, 23p most of the day, 40p peak. I suspect Predbat didn’t see much financial benefit in charging the battery

Well, I've just updated to HA OS 14.1 from 13.2

I was patient this time, took almost ten minutes for Predbat entities to appear and the status below to clear. Which they did and its now back in demand mode.

Nervous moments lol!

TX200 It is always a nervous (few) moments updating HA versions.
I am on HAOS 14.0 and Core 12.3
I am glad that it worked out for you.

HA is trying to entice me to update to 14.1 and 12.5 but I will stay where I am for now.
For predbat, I am on v8.8.14

Rob

I got bored, have pressed the button. Seems to be working OK 👍

Plus there was an Octopus one.

New Shelly advert in Stuff magazine Merry Christmas

Daveb01 I have a few of the Shelly things already, they integrate very easily to HA via MQTT.

Have:

• 3 x Shelly EM1’s (2 channels each) CT clamps to monitor my ASHP consumption, FIT generation, hot tub and cooker consumption
• Shelly 2PM to control the cooling fans under my inverters
• Shelly 1PM mini to monitor the fridge electricity consumption
• And a bunch of other 1PM’s intended to make some of the lights like the porch and upstairs landing into smart motion sensor lights, but still not got round to it…

I use Local Bytes smart plugs and Govee T&H BLE sensors, both of which were cheaper than Shelly.

Looks like MrBat is saying charging the battery is to close to not being efficient (mine is set to default), Geoffrey I think you said yours is at 4, is your looking similar please?

Daveb01 I was on 8.8.14 and Predbat was planning to let the battery discharge from the current 14% SoC (one battery is already empty) to both being empty, then fill it up in the slightly cheaper overnight slots, and hold in between:

I then upgraded to 8.8.15, today’s release 😆 and the plan consists of a lot more freeze charging to preserve the SoC, very similar to yours Dave:

This plan makes more sense, the Agile rates are fairly flat tonight and not really enough cheap slots to overcome the ₁₅% combined battery and inverter losses

Mine has probably got more charging than yours Dave as I have less battery capacity than you and with the ASHP a higher daily demand so Predbat wants to fill the batteries up to preserve me from peak draw.

geoffreycoan Hmm, the plan must be very finely balanced because 20 minutes later and still on 8.8.15, its now decided to release the battery SoC and fill from empty overnight.

If I look at say 5am 100% SoC across the 3 plans they are all within 10p of each other

Upgraded HAOS to 14.1 today, no drama, just installed and everything restarted OK. Gives me a chance to see how well the daily inverter writes utility meter I created in configuration.yaml works

Tried updating everything this evening and I have lost my status history!
Just have a loop with History loading state history.
Notice the 'i' alongside the 'status'.

See screenshots

I have restored from a full backup earlier today but no luck.

Any ideas?

EDIT: I had upgraded to HA 12.5
With the restore, I was back to 12.3

In desperation, I have updated to 12.5 again and the status history mysteriously reappears.

Another example of a HA update causing issues.
But looks like I am back in action. A 2 hour panic.

Rob

geoffreycoan I hope I am back in action again with all the latest updates.
My HA update broke two of my integrations along with predbat status. But I seem to now be on 12.5 and 14.1

I have added your code for the daily register count. I have spotted an error:

• Stage 3 has another superfluous '-' before 'type' in the first line.
• I deleted the hyphen and unindented all lines.

I will now be able to see if this works at midnight.
But that will be for me to look at tomorrow.

Rob

Rbor So the status was there, you just couldn’t see the history of the status entity.

Did you look at the HA core logfile, were there any clues as to what HA was doing there?

Sometimes I find event history can be a bit flakey, taking absolutely ages to load history. Changing the time period you look over can result in the data appearing when it was stuck otherwise.

Curious that your status has been freeze charging all day, right through the peak period?

Rbor I have added your code for the daily register count. I have spotted an error:

Stage 3 has another superfluous '-' before 'type' in the first line.
I deleted the hyphen and unindented all lines.

Yeah it often does this when I copy and paste parts of my dashboard.

The code I provided was a snippet off my dashboard because that’s the easiest way to copy it using the iPad Companion app. If I select an individual card and edit the YAML it often gets copied as rich text with everything on one line and spaces converted to %20 for example.
So I tend to edit the raw dashboard YAML which includes the dashes for the start of the card, and the indenting for where the card is on my dashboard.
B**dy HA.

The helper with an automation to reset at midnight so that the dashboard can calculate a daily sensor is working fine for me. I now have a utility meter working which once I confirm it rolls correctly over midnight, I’ll share as well.
This is probably simpler

geoffreycoan B**dy HA.

At least I have found that I am good at doing something in HA: hunting down superfluous hyphens and finding out glitches in yaml indentation. I couldn't have done that even a few months ago.

This is what I got overnight from your '3 steps' for daily register write.
I changed the as_timestamp to match when I started my count tally on 2nd December:
as_timestamp("2024-12-02 21:28:00")

Thanks for the code. It nicely summarised everything. I will add a chart to this in my dashboard.

Curious that your status has been freeze charging all day, right through the peak period?

Late last night, I restored HA from a backup from 10:25 am yesterday.
I lost about 12 hours of data but I did get my history working again. Yesterday afternoon, I had worked through the energy dashboard so I have to repeat that work again.

The history glitch has shattered my HA and predbat confidence.
I blame the HA upgrade as everything else was working well including predbat up to v8.8.15.

On the plus side, my PV generation has got a boost recently. Good sunny day yesterday with 7 kWh and, if today stays as it has started, this should be beaten and get my December total into 3 figures.

Rob

A couple of people have reported issues with Predbat not updating correctly to 8.8.16, probably best we don’t update yet https://github.com/springfall2008/batpred/issues/1796

geoffreycoan Alternative solution to counting Predbat daily inverter writes to the solution posted just before Christmas, this creates a utility meter that will automatically reset at midnight.

Unfortunately as pointed out earlier you can’t create a utility meter wrapping around the Predbat ‘total inverter writes’ sensor using the HA user interface as the sensor is in the ‘predbat’ domain not the ‘sensor’ domain and the UI validates the utility meter configuration.

The way round this is to create the utility meter in YAML by adding the following to the configuration.yaml file:

utility_meter:
# Predbat daily inverter writes utility meter
  predbat_daily_inverter_writes:
    source: predbat.inverter_register_writes
    name: Predbat Daily Inverter Writes
    unique_id: predbat_daily_inverter_writes
    cycle: daily

Add this to configuration.yaml and restart HA, and it will create a new entity sensor.predbat_daily_inverter_writes that is automatically updated each time that predbat.inverter_register_writes changes

It won’t include any register writes so far today when you create it, but will count correctly from tomorrow

geoffreycoan Have to say miracle of miracles 🤞 I am running 8.8.16 without any problems that I'm aware of.

Wavy Davy Trefor reissued the release so I think its fixed now

For those shy, rabbit-like creatures emerging blinking into the daylight of Home Assistant, I have a late Xmas present.

I just came across this list of like-minded programs - self hosted, often open source programs which are currently the state of the art. HA - of course - is on there.

I've played with a few of these and they vary from the absolutely essential (HA and Plex would certainly be on my list there) to the fun to play with (Frigate was impressive). But quite a few look cool and have been added to my 2025 list of things to do (looking at you Syncthing and WUD).

Enjoy! Or ignore!

https://www.osswire.com/r-selfhosted-recommends-essential-self-hosted-tools-of-2024/

Wavy Davy I thought you might have learnt by now!
But a good upload for you and let's hope that v8.8.16 is sorted now by Trefor.

Rob

It's not every day that this happens. See below.

That's 2 days on the trot for me with almost wall to wall blue sky and sun. There are advantages in living at 800 feet in the lee of the Pennines. I could look down at the mist over the lowlands.
It won't last of course but brings my December generation >100 kWh.

Rob

Wavy Davy On your recommendation, I have also updated to v8.8.16 successfully.
After all my problems yesterday with the pesky HA update, that was the least that I deserved.

Rob

geoffreycoan At long last, I have a register write from the utility meter method.
I set this up mid afternoon and inverter hasn't budged until 22:30pm.

Rob

Rbor Interesting. I'm averaging about 60 writes per inverter per day, the Agile charge rates were not that contiguous last night nor today, then there's the peak Demand mode turn on for me.
I'm seeing a bit of weird behaviour of Predbat flipping between Charge/Freeze Charge/Hold Charge and today I even saw a NoCharge which I can't remember when I last saw it. Some of these are only lasting for 5 minutes or so. Trying a fixed main version from Trefor at the moment to see if this improves this instability and reduces inverter writes further.

Rbor That's 2 days on the trot for me with almost wall to wall blue sky and sun.

Grey and cloudy for me today, 2.6kW generated and much the same forecast for tomorrow then brightening up. 110kWh generated so far this month

geoffreycoan Grey and cloudy for me today, 2.6kW generated and much the same forecast for tomorrow then brightening up. 110kWh generated so far this month

This is my breakdown. I like the bar above the chart which shows the different actions with the writes in colours. And I can burrow down easily to get the detailed status.
With the colours, red is demand, purple is hold charging, blue is freeze charging and yellow is charging.

I was on v8.8.15 yesterday and I upgraded to v8.8.16 yesterday evening, which is responsible for today's writes. Your utility meter gives the same daily value.

Yesterday, I even managed to export 2.8 kWh of sunshine during 'Hold charging' (at 100%) despite running a HP! I am hoping for a repeat day today provided that the mist stays in the low lands and valleys. You need to get above the grey in your mechanised 🪁.

I'm up to 103 kWh for December now with 35% of that coming in the last week. So I am catching you up. I know it won't last though

Rob

Don't know what I've got wrong but my my registry writes was averaging 40. yesterday it was 156 and today at 09:30 it has already done 60. In about 3 or 4 days average has gone from 40 to 51.

Rbor December generation >100 kWh

<sigh> only 81 for me this month so far, well, well, well below MCS and PVGIS forcasts for the month 😢

My generation is only 23kW this month. 😢

So far this month I have achieved 101 with 15 left to harvest.
This is my first month, and my proposal predicted 128. It looks like I'm going to be 12KWh short of target.

Henry3rd My MCS forcast was 133kWh and I'm only at 81kWh so just over 50%!

what is a MCS forecast?

Wavy Davy The standard generation forecast provided by MCS installers (Microgeneration Certification Scheme). You need an installation by one of these installers to be able to export energy out to the grid

I have a MCS certificate didn't know they did a forecast.

CW Octopus are (or at least were) piloting a scheme for export registration when you didn't have an MCS certificate, e.g. a non-MCS installer. Trouble was they asked IIRC £200 'admin fee' for the extra paperwork.

All feels a bit protectionist this MCS registration thing. You needed an MCS certificate to get the government RHI heat pump installation grant and I presume the BUS grant as well.

MCS is nothing special, it just says you've followed a prescribed methodology for calculating the heat pump sizing/solar generation and there's supposedly transparency on pricing, but seeing my invoices they were clearly bending the system with how they detailed the bill of materials - mine has a 'supply of PV system' with the price and then the breakdown of panels, inverters, installation labour, mounting rails, etc are all zero cost items. Phah.

Anyway, off topic. After studying the quote a lot before install I have never since been back to look at it to see how it compares to reality, so I went to look now ...

My projection didn't have monthly estimates, only 20 years of annual figures.
The year 1 estimate was 7934kWh and my Feb 23-Jan 24 actuals were 7635kWh.
Most recent full year actuals of Dec 23-Nov 24 were 7581kWh.

I'd say they were both within the margin of error.

PVGIS is another website that a number of YouTubers use for their solar forecast, never used it myself.

geoffreycoan in that case my certificate only has a yearly estimate which is 3900kWh which by a strange coincidence is the similar to the panels capacity of 3.9 kWh.
so far this year generated 3550 kWh. So I suppose just about par.

Well that was interesting, managed to break Predbat for most of the night by accidentally purging my sensor history too much

2024-12-28 04:15:00.401280: Error: Unable to fetch history for sensor.house_load_today
2024-12-28 04:15:00.422180: Warn: record_status Error: Unable to fetch history from sensor.house_load_today
2024-12-28 04:15:00.422677: Error: Exception raised 
2024-12-28 04:15:00.424191: Error: Traceback (most recent call last):
  File "/config/predbat.py", line 973, in run_time_loop
    self.update_pred(scheduled=True)

Tried multiple attempts to fix it, different sensors that had similar data in them, reducing days_previous, and none of them worked. Had to resort to manually initiating a battery charge this morning to fill the batteries up ahead of today's agile peak.

Eventually resurrected Predbat by swapping to using the GivEnergy cloud data for the sensor load/import/export history instead of the HA sensors https://springfall2008.github.io/batpred/apps-yaml/#givenergy-cloud-data

Never done this before but it worked well and Predbat is now back up and running. Several of my Apex charts are still broken in a weird way but I can live with that.

Always new things to learn with predbat ...

Wavy Davy In my quote I had projected performance tables like this:

Several of the assumptions made are dubious such as the export rate starting at 5.5p and that 50% of generated energy is used onsite, but I guess these are laid out in the MCS requirements.
I'm getting a much better ROI than they suggested, payback including additional batteries that weren't in the original price will be in about 5 years.

CW It is definitely luck of the draw with the weather at the moment.
I have had days where I have generated 2 kWh max for the day with some barely 0.5 kWh. If there is a sunny day, it is surprising that some meaningful kWh can be generated, despite the sun being so low in the sky and our panels having to contend with shading from trees and buildings.

Rob

Henry3rd
101 looks good against your 133 target. Generation varies so much depending on weather.
In Sept 2023, I generated 696 kWh but in 2024, this was down to 543 kWh.
My May generation fell from 1,136 kWh in 2023 to 907 kWh in 2024.
Last December, I generated 111 kWh and this December should just beat it.

For me, this year has been disappointing compared with 2023.

Rob

My quotation didn't have monthly figures but did have Yearly ones.
This year predicted 3111 against 3550 generated so quite bit better.

Have to amend the generation figure. its 2758kWh not 3550 so not so good as I thought. 400 less than predicted.

I've had panels since January 2011 (original FIT scheme). Generation generally varies year to year - with 2024 (3466 kWh) being the worst so far - nearly down 20% on 2022 (4245 kWh). Average annual generation since 2011 has been 3880 kWh - the MCS design figure was 3336 kWh.

My monthly December generations since 2011 have been 107, 85, 77, 91, 80, 106, 139, 114, 109, 85, 73, 121 and 85 kWh - currently at 79 kWh for 2024.

Ivan Thanks for posting data on your historical PV generation.
It really shows how much PV generation can be different year-by-year.

We are all coming to the conclusion that 2024 will finish up as a poor year for solar generation.

Rob

Ivan Likewise my annual generation from my 4kW FIT array and FIT payment income each year. Generation either side of 3MW but there’s quite a bit of variation.

2024 figure to start of December, plus a further 36kW so far this month means this year won’t be the worst but also not the best either

Hi all, just browsing and spotted this at the top of “Developer Tools - States” any idea why I have 3 and only one is working?

I prefer xxxx_update (without any numbers)

Why is there three Solcast updates (I was expecting just one)

Nothing urgent btw

Just found these after looking further, can I delete the ones with the / through the icon and rename The one working (bottom 3)

Daveb01 you appear to have multiple solcast automations. Look at your automation list

There's a sensors for each automation of when it last ran etc

Wavy Davy For my quote I had a daily average kWh generation by month

geoffreycoan

Your right I have three, so can I delete the two not working since Sept and rename the one that is to just _update ?

Or do I need to dig further to see where these extras are on any yaml etc?

It's been a few weeks since I installed predbat, and all seems well. I have started looking at logs and this error comes up. Is it important?

Logger: homeassistant.components.recorder.db_schema
Source: components/recorder/db_schema.py:624
integration: Recorder (documentation, issues)
First occurred: 19:45:19 (13 occurrences)
Last logged: 19:46:15

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

Daveb01 Yep, just delete the two automations that are disabled and the sensors will go as well.

Then rename as you wish. What you are seeing there is the automation name, there is an automation id as well which if you click the 3 bullets and then settings you can change if you want, and also change the icon, e.g. here’s mine:

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

This is in the Predbat FAQ’s, you can suppress the warning https://springfall2008.github.io/batpred/faq/#predbat-is-causing-warning-messages-about-exceed-maximum-size-in-the-home-assistant-core-log

Deleted as superfluous

geoffreycoan Worked a treat. thanks. My New Years resolution is read the manual cover to cover 🙂

geoffreycoan

Thank you sorted, I changed the icon as well.

Folks, be aware that the latest Predbat release 8.8.17 crashes in freeze charge mode at least on my multi-inverter system.
This release contained bug fixes for mult-inverters where Predbat was getting confused and setting the mode incorrectly, resulting in swapping between freeze charge, hold charge and charging in short order.

Unfortunately it doesn’t seem to be working at least for me so suggest you don’t upgrade just yet https://github.com/springfall2008/batpred/issues/1793

geoffreycoan fixed version from Trefor ⭐️, 8.8.18 which isn’t crashing in freeze charge mode for me any more. I’m going to see how well it works tonight.

There can’t be many other open source software products that get this quick a bug fix turnaround

geoffreycoan Agreed. Thanks for keeping us all in the loop.
I just stand back in amazement at Trefor's speed in addressing issues.

I will try this tomorrow.

Rob

Getting nervous here… battery at 3% since 6am

Supposed to be some sun today!

TX200 It's been a rubbish end to the year.

PredBat changed its mind, due to lack of sun, decided to charge to 17% in the lowest of the slots.

Still hoping for some sun, but it's not looking great so far!

Will we get some negative prices Monday evening??? 🤞😀

When I initially set predbat up, I incorrectly followed some original videos which caused me to install Appdaemon. I subsequently followed the manual and realised Appdaemon was no longer required.
I still have the Appdaemon files lurking in my system. I am sorely tempted to delete them for neatness, but I am tempered by the old adage, 'if it ain't broke, etc.'
When you all moved from Appdaemon, did you simply abandon these files to aimlessly wander the ether?

Henry3rd I removed appdaemon once I had installed Predbat standalone.
But wait for more confirmations before doing likewise on my recommendation alone!

You will find appdaemon lurking as an add on and there are also files alongside the Predbat files accessible using file editor.

Rob

TX200 Will we get some negative prices Monday evening???

The runes are looking that way. 😄

Rob

geoffreycoan

I have a question please, in this version there was an update for “Forcast Planned hours”
Think it was 48 then 24.

I have had a look at apps.yaml and Predbat config, they say both, which is not right.
What do you experts have set please, both 48 or 24?

How come apps.yaml 48 is not the setting (I thought that was the Boss?)

Daveb01 In apps.yaml, I have 48 hrs, same as you.
But in the webUI, configuration shows default as 24 hrs.

Looking at release notes for v8.8.17, it looks as if 24 hrs is the default for non-expert mode.
I am on expert mode and I have been seeing 24 hours anyway.

So does the apps.yaml line stick at all?
Or is this still buggie? Certainly looks inconsistent.

Rob

Rbor

I am in expert mode as well, so would have thought both should be 24 and we have the option to change it to 36 or 48. However apps.yaml never gets changed, but as you say is this line in yaml have any affect?

We will have to wait until Geoffrey has a look and see what he says?

Daveb01 Same here.....

Rbor

So to keep mine as it was in yaml, I have changed the setting from 24 to 48. Then I can see what people say and decide if I want to change it down.

Both settings are now 48

I am unsure what my forecast hours are!

My plan goes forwards to 02:30 on Tuesday which looks more like 36 hours!
.... not that is really matters but it would be good if everything tallied.

Rob

Daveb01 But how many hours does your forward plan show?

Rob

Rbor

Now showing Sunday 15:10 - Tue 14:30

Perhaps Predbat is now a car sales man as well.

You have 24 set, yaml says 48 so we shall settle on 36

Daveb01 It is (like several things) in Predbat-land, complicated… (perhaps more so than it needs to be, but it is what it is)

forecast_hours in apps.yaml is the number of hours that Predbat forecasts ahead https://springfall2008.github.io/batpred/apps-yaml/#forecast_hours

input_number.predbat_forecast_plan_hours is the minimum length of the Predbat charge plan, and is the number of hours after the first charge slot to include in the plan
https://springfall2008.github.io/batpred/customisation/#calculation-options

So think of it as being the apps.yaml is the total length of the Predbat forecast but the input number then is how much plan is produced within that forecast duration.

I have my apps.yaml set to 48 and my input_number to 24. The input_number used to be higher but I reduced it as I didn’t see any value in having an enormous long plan given things will change (not least import prices) and in winter at least I use the whole battery every day. Note that its 24 hours after the first charge, my first charge is at 02:00 tomorrow (Monday) so my plan currently goes up to 01:30 Tuesday.

I think Trefor changed the input_number default for non-expert model in the latest release.

TX200 I’ve got a 3 hour Octopus power up event tomorrow (11-2pm) and have seen a Met Office Wind warning for Wednesday so I think we’re going to see some lower prices this week.

Went flying today, nice to get up, but dodging between cloud layers

Henry3rd I’ve still got my appdaemon installed but shutdown. Since I’ve been running fine on Predbat add-on since early October I have taken the step and uninstalled it today. When you uninstall appdaemon you’ll find there are vestiges of Predbat still in the /config/appdaemon directory which don’t get removed even if you tick the ‘remove data option’. You’ll have to manually delete this directory

geoffreycoan

Thank you for explaining, that makes sense, I have changed it back to 48 & 24 same as it was.

Good pic up in the clouds btw.

Seems the sun I was promised yesterday has arrived today instead.

Wonder if I'll end the day on 0p - a good chance with some evening export.

PredBat guessing 4p total by midnight, but that might change.

Upgraded from HA 2024.12.3 to HA 2024.12.5 just now as I had a long 3 hour power up event so the batteries were charging and I figured I had a bit of time to fix predbat if things broke after upgrade.

Absolutely flawless upgrade process, HA came back up, all the Predbat sensors were unknown and it did complain in the log about the connection to HA:

24302	raise WSServerHandshake Error(
24301	File "/usr/local/lib/pyth on3.10/dist-packages/aiohttp/client.py", line 821, in _ws_connect
24300	self._resp = await self ._coro
24299	File "/usr/local/lib/pyth on3.10/dist-packages/aiohttp/client.py", line 1167, in __aenter__
24298	async with session.ws_c onnect(url) as websocket:
24297	File "/config/ha.py", lin e 184, in socketLoop
24296	2024-12-30 12:42:41.613298: Error: Traceback (most recent call last):
24295	2024-12-30 12:42:41.606054: Error: Web Socket exception in startup: 502, message='Invalid response status', url=URL('http://supervisor/core/api/websocket')
24294	2024-12-30 12:42:41.596716: Info: Start socket for url http://supervisor/core/api/websocket
24293	2024-12-30 12:42:37.080255: Error:
24292	2024-12-30 12:42:37.079799: Info: record_status Error: Exception raised
24291	2024-12-30 12:42:37.078896: Warn: Failed to decode response from http://supervisor/core/api/states/predbat.status
24290	2024-12-30 12:42:37.072690: Warn: Failed to decode response from http://supervisor/core/api/states/predbat.status
24288	ValueError
24287	raise ValueError
24286	File "/config/predbat.py" , line 246, in get_history_wrapper
24285	self.pv_power_hist = se lf.history_attribute(self.base.get_history_wrapper(self.base.prefix + ".pv_power", 7))
24284	File "/config/web.py", li ne 71, in history_update
24283	self.web_interface.hist ory_update()
24282	File "/config/plan.py", l ine 880, in calculate_plan
24281	self.calculate_plan(rec ompute=True)
24280	File "/config/predbat.py" , line 575, in update_pred
24279	self.update_pred(schedu led=True)
24278	File "/config/predbat.py" , line 974, in run_time_loop
24277	2024-12-30 12:42:37.061161: Error: Traceback (most recent call last):
24276	2024-12-30 12:42:37.055060: Error: Exception raised
24275	2024-12-30 12:42:37.054765: Error: Failure to fetch history for predbat.pv_power
24274	2024-12-30 12:42:37.049616: Warn: Failed to decode response from http://supervisor/core/api/history/period/2024-12-23T12:40:00+0000
24273	2024-12-30 12:42:37.042960: Web interface history update
24272	2024-12-30 12:42:37.042569: Warn: Failed to decode response from http://supervisor/core/api/states/predbat.plan_html
24271	2024-12-30 12:42:37.036735: Warn: Failed to decode response from http://supervisor/core/api/states/predbat.plan_html
24270	2024-12-30 12:42:37.024112: Warn: Failed to decode response from http://supervisor/core/api/states/predbat.best_export_end

But Predbat carried on running and the next run through it sorted itself out, populated all the sensors and all the dashboards are looking fine.

The HA upgrade also fixed an issue I had with my Apex charts that some of the entity values in the top row titles were coming up as N/A. But it was random, the current agile rate on the agile price predict, all the solar forecast values were not working, but most of the Predbat charts were OK, home cost prediction no errors but the low and high thresholds on energy rates were N/A but everything else fine. Weird. The HA restart cured that issue so maybe just HA weirdness and a normal restart would have resolved it for me.

But suffered from entity spikes that mucks up the energy dashboard. It seems the problem is related to utility meters; I had turned turned on the 'sensor always available' option on the UM but this didn't fix the issue:

• both the utility meters that wrap the 'today' givtcp battery discharge entities spiked with negative values at 12:40
• no spikes on the underlying 'total' or 'today' givtcp battery discharge entities
• negative value spikes in import utility meter that wraps 'today' import givtcp sensor, both the free and day tariff sensors and the day cost sensor all spiked

Strangely the energy dashboard showed a big spike in battery discharge in the 12-13:00 period even though I'm using the battery discharge total sensors and the actual spike was in the import utility meters that I'm using.
Ultimately may have to move away from using utility meters but I'll still need a way to handle the free/paid Octopus tariff...

geoffreycoan Went flying today,

Great picture. Hope you were wrapped up warm.
The photo is not dissimilar from the view from my house during the past week, 800' up, looking down on the clouds. My panels have slurped up about 45 kWh (12.7 kWh today so far) and pushed my December production up to 140 kWh, well in excess of last year. My comeuppance will come as I can just as easily be in hill fog or with panels covered in snow with minimal PV generation.

How high up do you fly?

Upgraded from HA 2024.12.3 to HA 2024.12.5

I did the same several days ago and lost my status history. See here: Rbor
I then restored back to 12.3, losing 12 hours of history but got predbat back.
Then back to 12.5 and all was well.

These HA updates can throw up issues. Makes me wonder whether the developers should slow down these updates.

Looks like we will be getting some nice low Agile rates during the next 2 nights. But getting cold later on in the week with some snow forecast for me.

Rob

Fyi👍😀🎄

I have been experimenting with - input_number.predbat_metric_min_improvement_export.

I have tried the default - 5
Geoffrey’s - 4
I have also tried - 3 & 6

I have concluded (for me and my system, 2 x AIO and GW) 4 is the best option.

Daveb01 Thanks.
I had default of 5 set.
Now changed to 4 on the strength of good recommendations.

Rob

v8.8.19 has just dropped.

Rob

I need to add another EV to my PredBat charging function! Has anyone got good experience living with 2 EV’s that have different battery size? I have the Soc sensor for the second one and know the battery size, it is only temporary as my brother is visiting. I think I just add the sensor into the apps.yaml be
Ow my existing sensor and change the number of cars to 2. Anything else?.

Rbor Great picture. Hope you were wrapped up warm.

Yes I was, flying suit, heated jacket, heated gloves (motorcycle Gerbing stuff), heated insoles. Quite comfortable.

My panels have slurped up about 45 kWh (12.7 kWh today so far) and pushed my December production up to 140 kWh, well in excess of last year.

6kW for me today and yesterday, haven’t had anything like 12kW since the end of November. I have been tidying up my tracking spreadsheet for the year end and some interesting and quite surprising results. Will wait a couple of days for the year end to finish and my Octopus bill to arrive then will share it.

How high up do you fly?

Typically about 1500-2000’. I was planning on flying around the edge of Luton airspace (Stevenage, St Albans, Dunstable etc) yesterday so that’s all under the London controlled airspace from 2500’ for planes coming into the London Airports. But as I headed south the broken clouds on the photo joined up together to a solid sea of white and I decided that that wasn’t safe as at some point I needed to get back down to the ground. If I’d completed the circumnavigation and the clouds had filled in behind me I’d be in real trouble so I turned back. But about 2200’ most of the time.

Upgraded from HA 2024.12.3 to HA 2024.12.5

I did the same several days ago and lost my status history. See here: Rbor

Yes I saw your tribulations. Strange that I didn’t have any issues at all. It is part of why I don’t upgrade to every release, usually leave it a week or two to settle down and upgrade to the .2 or .3 release rather than the first ones.

Looks like we will be getting some nice low Agile rates during the next 2 nights. But getting cold later on in the week with some snow forecast for me.

Yes looks good, I have another 2.5 hour power up event tomorrow morning and likely to be more if the winds continue. A nice end to the year but then the Agile price prediction goes back up again.

geoffreycoan Typically about 1500-2000’.

You would safely clear my house but could run into difficulties across the highest parts of Peak District at 2000'. There are quite a few wrecked 2nd World War aircraft that didn't quite make it littering the Peak District 'tops', a bit higher than the Chilterns The western edge of the Peak District is below the main descent flight path for aircraft heading for Manchester airport. Another potential hazard for microlights and hang gliders!

I have another 2.5 hour power up event

Another one! It is about time these power ups were spread out to more regions. They seem to have been quite lucrative for you.
The folk up here is tight with their money and this must rub off on Northern Powergrid.

Anyway, I have drifted way off topic so back to predbat for next contribution.

Rob

@geoffreycoan I have hit exactly the same GiVTCP bug you've reported on Github. Pretty wild that a remote inverter restart doesn't also include a date/time write and that it has to be done separately.

Hi all, anyone seeing a weird Predbat plan? This is mine and not happy 😡

Battery is flat, so no emergency power and Predbat is keeping my battery idle?

It plans to charge later in the week but the ready remains at 5%

Spent the last hour reverting VM snapshots as I thought 8.8.19 had screwed something up. I should read other threads on this forum 😃

Daveb01 Looks like you've had the inverter bug too and Predbat is running off cached data. Go into your inverter cloud page and force a manual date/time refresh. We've (nearly) all been affected.

browellm Yeah it was a fun night last night trying to work out what had happened with Predbat and GivTCP, tried loads of things to fix it before I worked out it was a corrupt date/time and that resetting the time fixed it.

So pleased that I found a fix as I had had to revert to setting up a manual inverter charge, wouldn’t want to do that for too much of the time.

Slept in this morning!

Daveb01 is yours a problem with the date/time as well? Always worth checking the Predbat status, logfile and givtcp log if things go weird

I rebooted HA and it looks like it’s all back now, I have also done a time sync as well (thanks for this)
Had a look at the logs and loads of errors started at 04:10. REST connection failure

This is my predbat status:

My inverter is offline so can't do anything with it. I have spent about 90 minutes trying to go through the horrible dongle setup process with dongle local network dropping out all the time.
I have all the settings as they should be but no luck. My dongle persists in flashing blue rather than steady blue.

Go into your inverter cloud page and force a manual date/time refresh.

So where is the inverter cloud page?
I have tried the normal portal inverter page and have tried resetting inverter, and tried to reset time.
Which page? I have tried remote control but the portal tells me my inverter is offline anyway! Same with the app.

In big panic mode. My batteries were drained last night so I am now on my solar PV inverter. (There are advantages with having an AC coupled inverter). But only got 708 W so far today.

Thanks

Rob

Looks like I have the same problem.
2024-12-31 11:20:08,260 - GivTCP - read - [ERROR ] - inverter Update failed so using last known good data from cache: ((<class 'ValueError'>, ValueError("time data '2024-12-31T11:20:08.250249+00:00' does not match format '%Y-%m-%dT%H:%M:%S%z'"), <traceback object at 0x7fb720f89c00>), 1687)
2024-12-31 11:20:08,261 - GivTCP - read - [ERROR ] - runAll2 Error processing registers: ('KeyError', 'read.py', 1825)
Have reset inverter to defaults, and inverter time is correct, but predbat is still not displaying correct data. Showing SOC as 4% as it has been since last night. Have restarted predbat and rebooted PC.
What have I missed?
Cant be inverter dongle as I can talk to it via GE Cloud and other apps.

Rbor Rob I guess if your dongle is also borked then the cloud status and config pages will also be inaccessible.

If you manage to get the back up and running your remote inverter control page will of the format
https://www.givenergy.cloud/inverter/SAxxxxxxxx/remote-control

Re-syncing date/time is an option on that page

Rbor

I just rebooted HA and everything came back, I then did a time sync.i hope you get things going again soon.

@Rbor The page details browellm gives above are correct, its the inverter remote control section you need to go into to force a send of date/time from the portal to the inverter.

Curious that a ‘reset to defaults’ from the portal doesn’t re sync the date time, you have to do it separately.

But does need your inverter to be online for this to work, mine was online throughout, I was receiving the inverter meter data in the portal, although I have seen local control fail when the portal connection is OK, so that wasn’t a guarantee of much. I did try wifi network and inverter restarts before finding the date time fix.

As an alternative to using the GivEnergy portal there is the option to ‘set time’ in the BBC basic app. That has a direct connection to your inverter so as long as you are on the same network, it should work and will restore GivTCP local comms

Wavy Davy it is the same problem, the inverter time is fine but the date is corrupted, the inverter thinks it is 1st of the 13th month 2025! You need to resync the time from the givenergy portal and this’ll cure the givtcp error and thence the predbat REST errors

Resyncing the time worked for me. Like Geoff says strange a reset to default didn't sort it. Anyway back up and running now.
Luckily I noticed it last night about 01:00 and managed to program a charge using the GE cloud app.
Also lucky that there was 5 hours of reasonably cheap slots, so I could use timed export as my inverter only has 1 charge slot.

Remote control page:

Account settings page:

Notifications:

The dongle setup instructions refers to resetting as follows:

What small button?????

My GE inverter and batteries are useless, batteries 2 big paperweights.

Wish I'd gone with a Solaredge battery. The SE inverter has purred along for 2.5 years without a whimper.

Rob

Rbor the button is on the dongle itself?

Assuming you don't have the one with the inbuilt WiFi? In which case there might be a button near all the various ports.

Rbor You can regain local control using the BBC app, available for Android, iOS and other platforms
https://community.givenergy.cloud/d/5051-bbc-basic-inverter-app-significant-update

The BBC app makes a direct inverter connection so you just need to be on the same network as your inverter. In the app, do ‘set time’ and it should spring givtcp to life

In terms of resetting your dongle, I’m not familiar with the AC3 but is it similar to the Gen 1 hybrid, there is a white dongle stick plugged in underneath the inverter that points downwards ?

I believe from the instructions that the button is on the bottom of the dongle itself, not the USB port on your inverter.

But if you haven’t changed your home wifi or anything major and givtcp is still connecting to it, then its likely your dongle is still setup fine, its just that its not connecting to the givenergy portal. Shutting down and restarting the inverter can fix this problem.

BTW Solaredge batteries are supported with Predbat but have their own set of challenges about not charging and discharging reliably.

New version of Predbat add-on just released by Trefor v1.2.2, increases the number of generations of Predbat log files retained. I introduced this change in September but didn’t get the for() loop quite right so its now been fixed by Trefor.

Still testing new versions of the multi-inverter support, a new version every day !

So had a look at GE Cloud logs, it seems everything went wrong at about 6am ish, and no connection until I rebooted at 11 ish

Another Trevor update 👍🎄🥂

TX200 geoffreycoan You are both correct, the cover and reset button are at the bottom of the dongle.

Now reset and I need to leave it for a while before going back through connecting to the dongle. I know the steps off by heart now.

As I have had dongle issues before, I assumed that was the source of the problems. When I checked out the inverter, the dongle was flashing blue.

Pesky dongle with no LAN option for this inverter.

The problem with my GE kit is that I have spent a small fortune on it: AC3.0 inverter ('small' amount) but two 8.2 kWh batteries – not cheaper).
And then GE bring out the AIO with no upgrade path, abandoning us early pioneers. Our only solution is really to continue using the GE kit until it is well out of date with technology and/or tariffs.

Rob

Rbor Other problem is that it has no resale value, as it has to be installed and recommissioned by a registered installer.
I understand the reasons why they do this but it means in the real world no-one wants to buy them second hand.

Oh dear, I said it was all working but still something wrong, GE Cloud says OK but HA and GivTCP not sure. AIO-2 is not looking good in HA.

Daveb01 Oh dear, I said it was all working but still something wrong, GE Cloud says OK but HA and GivTCP not sure. AIO-2 is not looking good in HA.

What's in your givtcp logs and if you look in the logbook do you see your gateway and both AIO's providing regular updates to HA:

Might be you need to reset the date on each AIO and the gateway??

@Rbor glad to hear you are getting there. Yes its frustrating the money we have spent to find it has "fragile moments". I feel we are still on the early adopters part of the curve, as you say GE's focus is now all on the AIO. If I was buying now I would buy the AIO or maybe a Tesla Powerwall 3 (although price premium for that) or Pylontech batteries as I can install them myself.
One big advantage of our kit is the superb predbat and HA software, I don't think there is anything like the same level of control and support for other inverters and batteries and when it works it works brilliantly

geoffreycoan

Tried that and it said time and date transferred OK, so went for a AIO-2 reboot, back to normal and charge was the same as AIO-1, both now at 23% and charging, phew

geoffreycoan If I was buying now I would buy the AIO or maybe a Tesla Powerwall 3

I have (and love) my AIO, but I think that the AIO is not compatible with the AIO2, so I will be restricted to additional AIO's if I expand. I wish the AIO2 was out when I was looking as I really like the whole design (such a tidier install with the hybrid built in).

So do we know what caused this issue for everyone please?/. as I am guessing like me I was not very happy this morning and I fixed it quite quickly.

Oh just seen this

https://community.givenergy.cloud/d/5448-a-number-of-inverter-clocks-are-reporting-strange-daymonth

Any ideas for getting me back in action. I have been on this since 8:30 am this morning, done the dongle dance countless times, resting dongle, turning inverter off, disconnecting batteries, rebooting router, replacing ethernet cable from my fibre connection to main router.

app and portal show inverter is 'offline' throughout.

Looks like I may have to get in contact with installer and I bet the earliest they could came out will be sometime next week.

Could I get some action by trying GE cloud on predbat?
Documentation refers to a long API key. Would I need to generate one?
Sadly, I don't see this working.

predbat log just shows failure to write to the inverter.
givtcp log fails to find the old IP address.
My router isn't allocating an IP address any more to inverter.
Scan for inverter in app fails.

I have tried the BBC basic inverter app but this cannot make contact to the inverter.

I can't resync time/date if inverter is offline.

What a disaster! 😠😖😡

Just going to try the dongle thing again now!

Rob

Rbor

https://kb.givenergy.cloud/article.php?id=1

Rbor The first thing you need is to get your inverter back online onto your router. Without that there is nothing more you can do either locally (with GivTCP or the BBC app) or remotely via the GivEnergy Portal.

Using ge_cloud with Predbat isn’t going to help you as that relies on your inverter talking to the GivEnergy Cloud and it’s not doing so.

As Rubikcube says, follow the steps in the Wifi connection guide, but first, some things to check:

1. What sort of Wifi have you got, is it a mesh, if so, turn off features like fast-roaming
2. Make sure that WPA2 is selected as the encryption method on the router
3. Your inverter ONLY connects to the wifi using the 2.4GHz signal. Quite often your router will be broadcasting both a 5GHz and a 2.4GHz signal using the same SSID and will be setup to ‘prefer’ devices to connect to the 5GHz network. THIS WILL ALMOST CERTAINLY STOP YOUR INVERTER FROM CONNECTING TO WIFI. Turn the 5GHz network off, let your inverter connects to the 2.4, allocate a fixed IP address for it on the router, then you can turn the 5GHz network back on.

When you connect to the inverter wifi hotspot and scan for networks, do you ‘see’ your home wifi network, and what happens when you tell the inverter to connect?

First step is getting the inverter onto the home wifi, anything else comes after that.

Also, when trying to connect to the inverter wifi hotspot, you might find your phone/tablet/computer will try to connect to a better wifi to find Internet that works.

You may be best doing this connection from a laptop and might have to tell the laptop/device to forget (or at least not auto connect to) each wifi that is in range of you.

Dear All,

Thanks for all your suggestions. I am packing up with this for the day, having spent the best bit of 10 hours trying every possibility. I have used the GE Dongle instructions, I already had an address reservation for the inverter set at the router. I am exhausted and so fed up........

And as for that pesky little reset button.

Rob

Rbor I already had an address reservation for the inverter set at the router

You might have issues with the DHCP allocation table in the router, might need to purge it.

Try removing the address reservation. I keep mine simple, I leave the inverter configured with dynamic IP allocation so it is not trying to tell the router what address it wants to have, I leave the router to allocate the IP address, and once allocated I change the router so that that device's MAC address has a fixed IP (that it had just allocated).

There's always tomorrow, good luck !

I hope I am the conveyor of good news.
An old year ending in tears 😭 has had an uptick 😃.

I have finally got my inverter online, connected to HA and gicvTCP and to our beloved predbat.

Although I have been using grid energy since about 1 am last night, there couldn't be a better time to get everything back in action with mostly negative rates overnight:

• Two 8.2 kWh batteries, both empty.
• A dishwasher crammed full,
• washing machine primes
• EV ready for topping up in the really low spots
• And HP hot water (topping up a bit higher temp than usual.

I just hope that the steady blue inverter light on the dongle persists.

My technique was:

• Put on food
• Then flip off the battery breaker between batteries and inverter.
• Turn off main red switch to the inverter and leave for 10 minutes.
• Turn red switch back on whilst holding the reset button of the dongle in until I got a blue flashing light (about 30 seconds).
• Go through the well-rehearsed dongle dance which rewarded me with a steady blue light.

I could then ping the inverter, log onto an online inverter and update date and time.
I restarted givTCP and predbat and the logs show that they are now behaving normally.

The GE dongle is a real weak part of the setup. It shouldn't be this hard to connect an inverter to wi-fi. In contrast, when I got my new mesh system a couple of months ago, my SE PV inverter just connected itself.

Again, thanks for all your suggestions and support. It hasn't been a good day to put it mildly.

A happy Predmass to all

Rob

Sadly, I could not persuade my wife to wait until 22:30 to heat the mince pies. 🙁

Rbor Well done Rob, perseverance pays off 🎉🥳👏.
So frustrating but glad you got it sorted to take advantage of tonight’s cheap wind-powered rates.

“Happy Predmas to everyone”, like it!

Rbor well done.

Yeah agree re the dongle. Even the inbuilt wifi on the gen3 was a pain. My installers just couldn't get it to work.

In the end, I got some help direct from the amazing Paul and together we cracked it whilst my installers just tidied up everything.

Looking back, I first noticed an issue at 8:30 am this morning and reset my inverter.
Unfortunately, I hadn't checked out forum threads and I noticed that my dongle was flashing blue. That prompted me to suspect the dongle which initiated my dongle woes..
I wonder whether the time and date issue prevented me from logging on after resetting the dongle.
Catching up on all the comments now, I can see that I wasn't the only one experiencing problems. And it looks like Libbis have been affected also.

After trying various implements, I discover that could hold the connector at the end a usb C cable between my fingers, making it perfect for depressing the reset button on the dongle.
Screwdrivers, pencils, etc all seem to slip off.

After today, it is good to see my Home mini displaying 12 kW of charging over the next half hour for –4.20/unit. And then Predbat is exporting a chunk of this back at 15p/unit because the import rate is 'only' 2.52 kW/unit. Overnight, Predbat has me making about £1.50. 😊

Rob

I was thinking solcast must be broken.

Prediction of 11kWh tomorrow and the weather looks absolutely shocking.

Then I realised tomorrow is Thursday as it's gone midnight. Today's solcast looks right!

Happy new year all.

😁🤦‍♀️😁

TX200 Oh wow, yes, what a difference a day makes

Today, 1.6kWh forecast, peak power generation on my East array 120W !
Tomorrow, 14.6kWh, peak power generation 14.6kWh

For the second night in a run, GivTCP is throwing a bucket full of errors at me.

Lost communication to the inverters and timing out all the time.

All the power’s gone off apart from my HA server and the internet which are protected by a UPS that’s now beeping like mad. I just realised that the internet repeater in the garage is of course off in the power cut, but it’s a bit moot because there’s no grid to supply anything anyway!

Just hope the engineers fix it within the predicted 2 hour window, I’ve got loads of cheap electricity to consume tonight…

geoffreycoan did they fix your power within the window they indicated?
We had a 2 hour power outage on Sunday and although my office is protected by a UPS the EPS from my inverter didn't work and just kept tripping out.
Five hours after our power came back on I got a txt from northern power saying they hope to get the power back soon!

geoffreycoan no EPS socket off the inverters? Assuming the inverters are in the garage too, couldn't the wifi repeater be powered from that?

Although not much you can do with it, no charging or discharging!

Did you find the silence UPS button? Mines got one thankfully, but not sure they all do.

Firstly, I hope all with power cuts issues are back on line.
Collectively, we have had an 'interesting' time since start of yesterday (31st Dec).

My screenshots from yesterday and today from midnight, summarise my experiences from 'donglegate' yesterday and recovery from about 20:30 pm yesterday and overnight with my batteries going from empty (4%) up to nearly full (and on very low or negative Agile rates).
31st December, all day

1st January midnight – 09:20 am

But we all have our own tales to tell .................

My energy dashboard for yesterday is pure fantasy. Solar shows as a single peak 8pm-9pm when I got my inverter back. I will be able to correct this to spread generation over the day.
........but my energy usage is shown as 2,845 kWh! Thankfully, Octopus shows this in line with my GE chart above with low usage during the times my inverter was down.

After today, the next few days look sunny, I have 14.6 kWh forecast for tomorrow and days are getting longer. ............ although I can so easily lose all solar with just a light dusting of snow.

Rob

I posted my message above about the power cut at 1:26 and then went to bed, but I could hear the UPS beeping away with increasing frequency as the battery ran down so got up and shutdown my HA server so that it didn’t crash when the UPS ran out.

Maybe a bad move because according to UK Power Networks they restored power at 01:46 which can’t have been that much later on. And that matches what I see in the GivEnergy portal that the inverters started re-sending data to the cloud at 01:46.

I assume Predbat must have already sent the first set of charge up commands to the inverters because they charged up through the night on the cheap electricity. Didn’t get the intermediate exports because the HA server didn’t restart automatically ☹️. Shutting it down to prevent a crash meant it didn’t restart itself when the power resumed. But at least I woke up at 7am and was able to power it back on for Predbat to export ahead of this morning’s power up event from 9-11:30.

geoffreycoan Glad that you are back in action.
Yesterday, you alerted us all about the date time issue and provided a fix.
You didn't deserve a power cut!!

We now march forwards.
The nordpool predictions are not great but it looks as if Predbat is planning to charge my batteries from my predicted solar PV from Solcast for tomorrow. Solar should increase from now on with less reliance on low grid rates.
....... and the next Agile events will arrive .......

Rob

Rbor Umm you haven't noticed the snow forecast for most of the UK? Saturday through Monday, we're forecast for stupidly high amounts (20cm+) and that's East Mids.

After the shutdown of the gas pipeline through Ukraine today I reckon its batten down the hatches time again for Agile users from this weekend onwards (99.99p again). Either that or flip tariffs for a couple of weeks if it doesn't affect your standing charges.

Agile has not been great the past month or two… wondering if I should return to Cosy, especially now it has the third low rate slot. Agile was great last winter, but at the moment Cosy is looking very attractive…

Boffinboy Yeah, Agile prices have had some bad days the last couple of months, but also some good days.

Have a look at https://community.givenergy.cloud/d/3678-making-the-most-of-octopus-agile/524 where @Windy Miller shares his analysis. For him it looks like there would have been a slight saving for Cosy over Agile.

I've done some simple comparison of my own consumption on Cosy vs Agile. For November 24 (excluding any standing charges rate difference), Cosy would have been ~ £18 cheaper, for December 24 would have been ~ £21 more expensive. Approx 10% on my monthly import bill and feels like its in the margin of error to not be worth changing.

Of course everyone's consumption pattern is different.

Boffinboy Also consider increased SO by changing to Cosy.
Your choice of course but do check out relative actual costs.

In Nov 2024, my average Agile rate has been 14.96 p/unit
In Dec 2024, my average Agile rate has been 10.72 p/unit
(Source Octopus watch reports from 30 min actual costs)

I have looked at Cosy but decided on balance to stick with Agile, as I have done for nearly a year now.

Rob

Rbor I have just now renewed my Agile for another 12 month term.

December 2023 Agile (I’m on now) standing charge 42.01p
new October 2024 Agile standing charge 48.79p

£25 a year increase

Cosy from 1/1/25 48.788p so for me, not a lot in it (but for Rob in Yorkshire or those in the South West, 66p, and North East its 70p).

My Yorkshire increase in SO for 2025 equates to £104.90 a year increase! Yikes.
My only saving grace is that my import rates are less than the cheaper SO regions.

Rob

@geoffreycoan I have just seen your marvellous piece of work on reducing the size of the HA database.
Looks like a long term project for me as I crawl up the HA learning curve.

Thanks so much for this.

Rob

Rbor Thanks Rob, it’s taken a while and there’s a lot of different techniques in there. But some quick wins on disabling sensors and filtering out sensors you don’t need the history of.

I will put some of the predbat-specific stuff in the documentation but will wait to see what the feedback is first.

Cheers

Rbor

As it is my Solar and battery, can I not charge Octopus a standing charge to use it?

I was thinking 50p but will discount it to 48.79p 😎✅

Can anyone point me in the direction of a fix for this error? I have looked at the manual but can't see it (there again, I can't find a tin of beans in the store cupboard!)

"Entity sensor.givtcp_fd2319f635_soc_kwh from integration mqtt has state class total_increasing, but its state is not strictly increasing"

Henry3rd "Entity sensor.givtcp_fd2319f635_soc_kwh from integration mqtt has state class total_increasing, but its state is not strictly increasing"

It’s a givtcp bug. The battery soc can increase or decrease and the sensor has been incorrectly defined as always increasing by givtcp

Rbor my average rates have been above Cosy for the past few months, occasionally pulled down by the few windy days where Agile goes super low. Last winter Agile was much cheaper than Cosy. Octopus Compare is not loading for me, but plan to check how it thinks they would have compared.

My spreadsheet suggests my average Agile rates in Jan, Mar, May, Nov, and Dec were higher than Cosy. nice thing about the new 3 slot Cosy is the consistency - which means I can also run my A2A and reduce some gas use. The three dips also mean not far of all load would be at the lower rate, but can’t get super low.

Just logged in to HA and loads of logs in Predbat.
Plus weird plan in next few hours? No idea what’s going on, I have just rebooted HA and will see if it is still the same in an hour

Daveb01 My predbat and givTCP logs are fine.

Have a look at your predbat and givtcp addon logs rather than webUI.
You are getting this repeated line:

There is something wrong. Your inverter seems stuck on pause and the have a strange burst of charging Sat 03:30 - 05:00 am.
I am not sure what 'charging pause means!' At night, your cost doesn't change.

Also have a look at your GE dashboard to see if that offers any clues.

In my predbat log, I have a load of Historical day gap warnings but I tidied up my energy dashboard for 31st Dec when my inverter was down and any values were thrown all together at the end of the day.
My status report is clean showing demand at moment and no earlier glitches.
e.g.

So I think there is an issue with your system rather than another givTCP hiccup.

Rob

Daveb01 Rbor is correct, a series of REST errors and errors writing to HA inverter sensors point to an underlying givtcp issue, have a look at the givtcp logs.

Do you have the predbat autorestart of givtcp configured in apps.yaml. This usually resolves such transient issues

Also do you have the givtcp and predbat error monitor automations running https://springfall2008.github.io/batpred/output-data/#automated-monitoring-that-predbat-and-givtcp-are-running-ok ?

Rbor

This was the GivTCP log just now

This is the Predbat log just now

Look at the last line in the givTCP log:

The HA discovery isn't working.

Have you tried restarting predbat or mqtt?

This was my starting sequence last time I restarted givTCP. You can see that givTCP is responding as it should after publishing HA discovery messages.

Rob

The plan now looks like this. I know it could change but something does not look right and I have not seen this before.

Rbor

Rebooted again now get this

Daveb01 There’s no point in looking at the plan really for Saturday as the rates will change.

But looking at Friday, it looks OK to me

overnight the Agile rates are poor, charging is paused and your battery drops from 75% at 22:20 to 57% by 8:30.

Then from 8:30 onwards your solar prediction is higher than your load prediction and your battery charges from solar from 57% to 83% by 16:00 on Friday. Then the plan is cutoff but your battery is at 53% by Saturday 00:00, compare that to Friday 00:00 where it was 72%, yes its lower but a long way from being empty.

What do you think the plan should be doing?

geoffreycoan

I guess it was all the planed charges, even during the peak time and battery at 100%, why would it predict that?
Plus why would it say Charging Paused all night and not demand?

It just did not look right.

Daveb01 I guess it was all the planed charges, even during the peak time and battery at 100%, why would it predict that?
Plus why would it say Charging Paused all night and not demand?

The Saturday stuff does look weird, and maybe there is a Predbat bug there that you’ve exposed by having a long plan duration (as I said I only run my plan for 24 hours after the charging so I never look that far ahead).

Feel free to raise that on Github because it does look wrong.

As for Charging Paused not Demand, mine does Freeze Charge often at night rather than Demand, I take it as just the way Predbat does its thing….

geoffreycoan

Thank you for the reassurance, I have rebooted everything again and something has changed again. It does now not go to Saturday it stops Friday now plus the is thick line after 23:30 today and tomorrow?

Think I will leave it as is now and have a look in the morning. Thank you again for the help 🍺

P.s. I changed my [reduction back to 24 ages ago, do you think the 48 stuck until I repotted a few times?

For the record and for comparison, here is mine:

Tomorrow (Sat), you can see that my projected PV generation is greater than load and predbat wants to use this to charge my battery.
My problem though is that the ASHP is energy-hungry at these temperatures ..... and there won't be that amount of PV excess to get the battery SOC up to what predbat wants.

Perhaps I should up input_number.predbat_load_scaling up from its default of 1.05.
I was sure that I had increased this to 1.2 but looks like a case of 'predbat knows best'.
I am going to up this to 1.2 and think about 1.5.

Daveb01 Looks like your ERROR line has disappeared from your givTCP log.
It would be nice to see an instruction added as the first HA discovery message but your 1st change in your plan is not until midnight.

Rob

When you restart HA, I don't think the add ons like givTCP and predbat and MQTT are restarted. @geoffreycoan will put me right if I am wrong here ......

Rob

Rbor my load scaling is 1.15 already and I could increase it further, but its all a bit moot as my ASHP consumes far more than my battery capacity (e.g. today, ASHP 40kWh).

Predbat basically charges overnight in the cheapest rates it can then holds the battery to the start of the peak. Maybe a bit of pre-peak charging if the batteries have dropped a bit or solar wasn’t enough.

Think we will be in for a few expensive days coming up. Even with a 2 hour powerup earlier today, I’m up to £9.19 today. Hey ho, plenty of account credit still to consume

Rbor When you restart HA, I don't think the add ons like givTCP and predbat and MQTT are restarted. @geoffreycoan will put me right if I am wrong here ......

You are correct, a ‘default’ restart HA only restarts HA. You have to click on. the ‘Advanced options’ and ‘Reboot’ to restart HA and the addons (Predbat, GivTCP, Mosquitto broker etc)

geoffreycoan My increase to 1.2 has made hardly any difference.
Today (2nd Jan), my ASHP has eaten 26 kWh with mean temp of –2C (4 defrosts during day)
On 31st Dec, my ASHP consumed 12 kWh with a mean temp of 8C, a mere snack.

What a difference the ∆ of 10C makes across the 2 days.

We need those Agile days to see us through .......
Looking at the new rates, Cosy low slots are up by 0.6p and standard Cosy slots up be about 2p.
As Agile use wholesale prices, they will doubtless creep us.

To be fair to use, should the export rates be increased?

Rob

geoffreycoan Perhaps I will shortly be able to graduate from my rabbit level, although my 'stupid' comment about linking a PV inverter directly to AC coupled inverters sent me scurrying back to my warren.
My excuse is that I had spent all of 31st Dec sat in front of my inverted and my AC inverter is positioned next to my PV inverter.

Rob

Rbor Looking at the new rates, Cosy low slots are up by 0.6p and standard Cosy slots up be about 2p.
As Agile use wholesale prices, they will doubtless creep us.

its the other way round. Agile is wholesale prices so we see increases and decreases on a half hourly and daily basis.

The other tariffs are priced based upon predicted wholesale rates for the quarter ahead.

So the quarterly price review and SVT and all the other tariffs going up or down doesn’t affect us on Agile or Tracker, we are already paying the true market rates.
Potentially changes in the electricity model of variable vs fixed parts of the Ofgem charging calculation (i.e. how much of the wholesale costs are levied as variable and how much as fixed standing charge) may filter through to a revised tariff with revised SC, but that seems to be much less frequently than annually, and we’re on a fixed duration tariff anyway so our standing charge doesn’t change until the 12 months is up.

geoffreycoan And April rates are now projected to rise as well:
https://www.cornwall-insight.com/press-and-media/press-release/price-cap-forecasts-rise-amid-wholesale-market-volatility/

Rob

Rbor hopefully it is sunnier this year than it was in 2024........

Rbor

Looks like everything went back to normal, after the second reboot. Yes I used the reboot HA & apps.

BTW the battery went down to 8.7 deg in the night (it’s in the garage) outside temp went to -3.7 deg here (Fareham). First time below 10-12 deg which is the norm in winter. I hope those with their battery outside did not have any issues.

Thank you both again.

Daveb01 My battery cell temperatures were between about 15 and 20 degrees overnight and the BMS between about 12 and 32. My batteries are in the garage as well. I have chosen not to upgrade to BMS 3017 from 3015 as 3015 work fine and I know 3017 introduces the temperature rate limiting.

I do have low power charge mode turned on.

My outside porch temperature sensor read 0-1 degrees

Heat pump has not been too bad, 8kW used so far today of which 1.4 was the 3:30 hot water cycle. Looks like the heating came on almost precisely every hour at 4:30, 5:30, 6:30, 7:30 and 8:30 to boost the house temperature back up. Won’t be especially cheap for me for the next few days

Daveb01

Ooh err 5.3 deg :0

After the plunge rates as the old year changed into the new year, it's looking like an expensive few days on Agile ........... 😠

Solcast is predicting PV generation of 0.0 kW for me on Sunday!

Rob

Anyone else had a power up message from Octopus with no date or info?
Bit strange.

Rbor Got you there, I'm forecast 1.72 kWh tomorrow and a whopping 0.36kWh on Sunday.
Mind it forecast 3.1kWh today and I generated 1.5 so less than 50% of forecast.

Rbor

Not as bad here down south. Today was only .2 out.

Daveb01 I was up on forecast for today 😎:

But your subsequent days looks positively tropical compared to mine:

Just look at the state of my predicted Day 2 (Sunday) and Day 3 (Monday)!!!!

From weather forecast, it looks as if I might disappear under snowdrifts. Let's see.

Rob

I’m still getting some generation, today was forecast as 14.8kWh forecast, I achieved 10.7kW, just scraping in at the 10.7 PV10 forecast which is unusually bad for me.

Tomorrow 5.2 forecast but the Sunday is 1.8.

With the cold weather my ASHP consumption has shot up, you can very clearly see the correlation between average outside air temperature and heat pump consumption

Looking at the power vs temperature I can see that most of the day the heat pump has been trying to recover the house temperature from the 17 degrees overnight setback to 19 degrees target temperature with plenty of 10kW spikes as the heat pumps run at full chat.

So tonight am trying a different strategy, keeping the central thermostat at 19 degrees with no setback. Will be higher consumption overnight but hopefully lower during the day.

Cost of all this on Agile has been £17 so far today. I did a quick envelope calculation, Cosy would be about £15 and SVR £20. Not a massive difference.

No empty power up emails for me BTW, don’t think I’ll see any until maybe late Sunday when its windier

My HP so far today has eaten 24.5 kWh.
Like energy cost for me today from predbat £6.35.
It's actually above freezing currently and have had some fine drizzly rain – should freeze over treacherously for the morning. 🥶

In your 1st chart, is the x axis date correct as the last bar looks as if it is for 4th Jan, which is tomorrow?

Rob

Rbor In your 1st chart, is the x axis date correct as the last bar looks as if it is for 4th Jan, which is tomorrow?

Damn, I was hoping that you wouldn’t ever find out I am a time lord ….

Either that or I’ve forgotten to configure the Apex chart to allow for these being day-end total figures.

I keep getting alerts from my battery automations telling me that the battery temperatures are 7.3 and 9.7 degrees C.

My kit resides in my large porch which had a nice big radiator.
Lowest temperature at night is 19C!
So for me, I don't have a worry about low temperatures affecting battery performance.

Rob

My inverter is in a cupboard in the porch with the batteries in a alcove underneath. Min. Inverter temp has been 26 and batteries 12.

My GE inverter gets to min of 31C overnight.

In the early hours last night when inverter was working away, it got up to 55C, with batteries getting up to 28C. The inverter is clearly the workhorse of the setup.

Rob

I have battery temperature envy!

Oh dear it’s happened again at 04:30. Battery was idle when I got up this morning.

I have the automation in Predbat that restarts, but GivTCP lost its connection to MQTT for some reason?

I will have another look at the link you sent me Geoffrey.

Daveb01 what happened after that Dave and what happened in the Predbat log?

In my own GivTCP logs I get the occasional error communicating with the inverter that either gets cleared by GivTCP trying multiple times and then flushing the cache and restarting itself, or Predbat deciding to restart the givtcp addon. And then rarely the givtcp activity monitor deciding that givtcp or mqtt isn’t working and restarting them.

Together this seems robust. I rarely look at the givtcp log, but looking just now I see typically 1 set of noisy errors a day

geoffreycoan

MQTT looks ok and carried on as normal.

So just GivTCP and Predbat.

I have this in yaml

Daveb01 your yaml looks OK but it looks like Predbat didn’t restart GivTCP when it got all those rest failures. You should raise it on GitHub with the log files for Trefor to take a look as I think it should restart GivTCP and that would have cured the problem.
Interesting that its only set discharge rate is failing; at 4:32 in the givtcp log it sets the charge slot OK

If its still persisting, restart givtcp

geoffreycoan

Thank you, I restarted GivTCP this morning after I spotted it and it’s been ok since.

Daveb01 in the logbook were the other givtcp entities updating ok ?

geoffreycoan

Had a look in the logbook and can see these, but as I am still a Rabbit, I do, pt quite understand it yet.

Daveb01 so what I was particularly looking for as the ‘inverter time’ entity changes, these are appearing regularly and show that givtcp is polling the AIO’s and gateway OK (there are a number of sensors shown you could possibly disable, but that’s for another time).

If givtcp is regularly talking to the inverters then my error detection automation won’t detect that givtcp has stopped working, and it looks predbat is only reporting a warning not an error so again the external automation won’t pick that up. It is down to predbat to try the givtcp restart if it keeps failing, and under normal circumstances that’s what I see happen on mine

Sunday morning 5th January.

At least Solcast was predicting me 0.0 kWh today ........

Rob

Rbor

So does Solar radiation (not sun) not work through snow 😛

I am surprised some clever cloggs has not invented windscreen wipers on Solar panels yet?

End of Sunday dad jokes 👍

OOPS inadvertently pressed "send saving session to predbat" button and now have

and
2025-01-05 11:30:02.051255: Warn: record_status Bad start time 2024-12-12:00 provided in energy rates

How do I get rid of message or will it just clear in time?
Tried restarting predbat and full restart of HA but still there.

The snow had slid off my panels by 9.30am.

Not much sun though, 0.2kWh so far.

Slightly off topic but found this article interesting.

However charging a battery from 5% to 60% in 5 mins will give Trevor new year challenge?

Daveb01 Solid-state batteries are a bit like nuclear fusion - lots of "could be's", "problems scaling up" and "expected to begin" statements in articles 😉

This article sounds like someone in Germany is pumping up expectations which isn't surprising since the Chinese are basically annihilating German car manufacturing (long overdue IMHO).

I wouldn't expect to see volume production inside a decade. If it works.

TX200 During the day, snow slid of half my panels.
It is always good to exceed predicted solar, even if it is just 0.4 kWh with a max of 0.2 kW.

For the next 2 days, I am predicted 0.17 kWh and 0.94 kWh, ASHP is eating up electricity either generating heat or defrosting.
An expensive few day although it looks as if we will be getting some better overnight Agile rates to fill the batteries.

Rob

Also 0.4kWh here today with heavy rain now.

Tomorrow 1.69kWh predicted and 7.41kWh for solcast day 3 which i assume is Tuesday?

I don't like to rub it in, but....

Rbor
Me Neither..😆

Managed a whopping 0.7 despite the day long drizzle

Oh dear, loads of updates, HA, SolarEdge, HACS, Octopus.

Leave it a few days and see what you guys say? No chance this time button pressed just now.

😜✅

I have updated everything with no apparent issue.

Why doesn't someone start an updates discussion about any updates they have uploaded and user experiences.
Call it HA updates

SteveCook

Sorry I won’t do it again in this post

I’m very much a if it’s not broke don’t fix it type of person. I’m still on appdaemon-predbat and am on the latest version v8.10.0.

I just want to check there are no plans to deprecate this version. Are all giv products supported on this version?

I have a gen 1 inverter so pretty basic.

Hook Trefor has said that he will at some point stop supporting predbat running under appdaemon.

The documentation for the appdaemon-predbat addon has been removed, Trefor saw that as an interim step from appdaemon to the full predbat addon.

I was on appdaemon for ages, only upgraded when I found a replacement for the octoblock app I ran in appdaemon and Trefor introduced the predbat manual API so I could send power up events into predbat.

Wavy Davy How do I get rid of message or will it just clear in time?

It won’t clear as you have set a rate override via the manual API. But its easy to clear it, bring up the select.predbat_manual_api control and just set it to [off] and it will remove all manual API configs. Or you can remove a single entry if you want to.

Rbor During the day, snow slid of half my panels.

Looks from the energy dashboard that my snow must have come off at 11:00 as the solar production jumped from zero to 0.36 across the 3 arrays. Woo. 2.3kW in total.

My experiment with running the heat pump through the night was expensively disastrous, it worked and the house was warm on Saturday but it gobbled so much electricity. Think I had the heat pump turned up too much because I dropped it 2 degrees and flattened the weather curve a bit and consumption dropped dramatically.
Yesterday (Sunday) I started the heat pump back up in the middle of the night on the slightly cheaper electricity and the consumption was quite reasonable. The house reached temperature around lunchtime and the batteries latested to 22:30 which is unheard of for me in winter.
I need to continue fiddling I think ….

geoffreycoan Helped to clear the road for 4 hours yesterday which was exhausting.
I live on a steep hill and, at one stage, we dug out a 4x4 which couldn't get up. By end of day, snow had slid off most of my panels.
...... then the snow returned overnight, undoing yesterday's hard work. 🥶😩

EDIT: 2 hours later and a very hazy sun has been sighted. I need to do some more snow-shifting and then up a short ladder to brush the snow off my extension panels. Some snow is sliding off anyway.
I need some sun and panels to generate to help to contribute to my energy costs.

Should I clear the snow from the top of my heat pump or leave it on as insulation? I suspect 'clear it off', as it freezes to the top.

I hope you are all coping better than I am.

Rob

Rob

geoffreycoan Geoff, Where is "select.predbat_manual_api"?
the only reference I can find is in predbat is the GUI. which says it's off but doesn't allow me to change it.

If setting it to off clears it, don't understand why it still shows settings.
Also In the documentation it says you can clear from the selector but you have to set them using a service call. Which maybe explains why I cant now change it manually, but can it be reset it using the command line?. If so what command would I use?

Rbor it snowed Saturday night into Sunday so white everywhere, then rained for much of the day and all the snow has gone. I’ve got a cold though so laid up not doing very much at all, didn’t go onto the forum until late last night.

Wavy Davy the predbat manual control is in the list of entities the same as any other entity:

you should be able to set the value to ‘off’ (no square brackets, mu mistake)

or I have it added to my predbat control dashboard alongside all the other predbat manual select’s:

or if you want to poke the command manually, go to developer tools/actions and (based on editing the script I wrote to send commands to the predbat manual API for power up events):

    action: select.select_option
    data:
      option: off
    target:
      entity_id: select.predbat_manual_api

Thanks Geoff, I used the manual command method and that cleared it. Have since added it to my dashboard, although I will try not to cock it up again.
Thanks for the help (as usual)..

Is anyone else getting slightly weird plans with Predbat v8.10.0?

Here is the plan under v8.9.3, which looks pretty normal to me (charge from empty to full rate in the cheapest overnight slots):

But v8.10.0 is suggesting this instead (note the strangely low charge rate and prolonged charging periods):

Josephiah

I have had two incidents that look similar. My issue was GivTCP was not talking to MQTT and Predbat was then having issues.

If you look at the logs in Predbat and GivTCP you may see some errors, however it will not fix the issue. Restart MQTT, then GivTCP then Predbat. Then wait about ten mins for Predbat to recalculate.

If that does not work reboot HA (under advanced HA and all apps) then wait 10 mins to see if it’s ok. If that works, then you can go back to the logs to see if you can work out what caused it.

If it did not work then you may need to screen shot the logs so the experts on here can help.

I tend to not look too closely at overnight plan until after 4pm when we get the official rates.
And then, I identify good slots for dishwasher, washing machine, etc

But, as far as predbat is concerned, it can flit around until a relatively stable plan emerges.

Rob

Rbor I’m the same. I’ve got the Nordpool rates indicated but to be fair I don’t think Predbat really does anything with them and they were so far out today that I’m not totally convinced there is any value in adding them. My plan changes regularly and in the morning it’s often charged the battery very differently to how it was predicting before I went to bed but so far it seems to be working well for me.

Goshiki2 I don't think I have ever seen the 4pm rates so far adrift from Nordpool.
A real disappointment.

Rob

Rbor Rob, are you looking at the nordpool data on the plan or is there a site that shows them?

geoffreycoan is there an easy upgrade document?

Or is it starting from scratch again?

Hook geoffreycoan is there an easy upgrade document?

Assume you are asking about upgrading from appdaemon to the predbat add-on.

Don’t fear, I already have you covered, the steps to follow are in the installation guide part of the documentation https://springfall2008.github.io/batpred/install/#upgrading-from-appdaemon-to-predbat-add-on

Once setup, you can quite easily revert and swap between the predbat addon and appdaemon just by stopping and starting the appropriate addon’s.

Daveb01 thanks. Not seeing any obvious errors in the logs for any of those three, either before or after doing the restarts. To me it seems like an algorithm or settings issue rather than a comms one.

The restarts do seem to have solved the apparent slow charge rate thing, so both plans (under v8.9.3 and 8.10.0) are effectively the same thing now, just implemented differently.

However, there's another aspect (affecting both versions) that I've noticed quite a bit lately: why is the algorithm ignoring cheaper slots in favour of more expensive ones (evident in both of previous screenshots, and also highlighted below)? My initial thought was the "combine slots" setting, but that's switched off. Anything else that could be causing this?

Josephiah why is the algorithm ignoring cheaper slots in favour of more expensive ones (evident in both of previous screenshots, and also highlighted

Have you got switch.predbat_set_charge_freeze turned on or not?

If its not turned on then predbat won’t be able to set charge freeze between these cheaper slots and the next charge period, so after charging up the battery wil then discharge for little financial value

(Nice for once to see someone else’s plan that’s spending more on electric today than me !)

geoffreycoan Thanks. Yes, that one is switched on. And it is managing to schedule freeze slots without issue (e.g. 03:00 in the screenshot above). It's a weird one. This is one of the simpler optimisation challenges (fill from empty to full - basically just a case of ranking the slots and picking the cheapest 6 or 7), and yet I can knock 50p off Predbat's suggestion easily. I'm used to it managing far more complex scenarios with apparent ease...

Yeah, the heat pump is not enjoying this sleety weather/temps!
(Edit: you may remember we had a discussion a few months ago about predicting heat pump usage from forecast temperature using a curve fit - that part works nicely, but I've never quite got to the bottom of what Predbat then does with the info fed into load_forecast... I'm pretty sure it does something, but I'm not convinced that it's not double-counting something, as my actual total cost at the end of the day is rarely as bad as the threatened costs look earlier on...)

Josephiah geoffreycoan Thanks. Yes, that one is switched on. And it is managing to schedule freeze slots without issue (e.g. 03:00 in the screenshot above).

Ah yes, I see it now. I’m not particularly used to the icon version of the predbat plan, I have old skool words on mine as I find it easier to read at a glance.

It's a weird one. This is one of the simpler optimisation challenges (fill from empty to full - basically just a case of ranking the slots and picking the cheapest 6 or 7), and yet I can knock 50p off Predbat's suggestion easily. I'm used to it managing far more complex scenarios with apparent ease...

Predbat does it in a more advanced way than that, it looks at future rates, charge and discharge rates, solar generation, load forecast, etc to optimise the plan.

But anyway, I haven’t upgraded to 8.10.0 yet. The release notes suggest Trefor has made some biggish changes to the optimisation algorithm so perhaps worth you sharing what Predbat is doing in the field with him.

I sometimes throw a few manual overrides in to the plan if I don’t like what it’s doing, but less than 4 hours out from execution it should be getting the plan right.

Yeah, the heat pump is not enjoying this sleety weather/temps!

I’m back to fiddling with my heat pump settings again to see if I can improve it further.
I was running on a 19 degrees inside temperature with 17 degrees setback overnight which was fine, but when it turned really cold the end of last week it took all day for the house to get back to 19 degrees so I’ve been trying variants of the overnight setback. Leaving it on 19 degrees overnight was ruinously high consumption so have tried stepping back to 18 in the middle of the night when the Agile rates are a bit lower so the first hit of the ASHP is on cheaper rates.

Your consumption through the night looks consistently high, do you not set back the temperature overnight?

geoffreycoan I have old skool words on mine as I find it easier to read at a glance.

Ah yes, sorry, I've tended to default to that card as I can get it compact enough for my phone screen.

geoffreycoan Predbat does it in a more advanced way than that, it looks at future rates, charge and discharge rates, solar generation, load forecast, etc to optimise the plan.

Yes, I understand that - was making the point that under these conditions (high load, no solar, battery only just enough to convert the agile peak) that's what the problem effectively reduces to. Maybe it's just that that fact makes errors much easier to spot as the plan is (or should be) very intuitive.

geoffreycoan But anyway, I haven’t upgraded to 8.10.0 yet. The release notes suggest Trefor has made some biggish changes to the optimisation algorithm so perhaps worth you sharing what Predbat is doing in the field with him.

I don't know when it started - I first noticed a few oddities a few weeks ago, but assumed it was just some of those "Predbat will sort it out as we move forward through the schedule" things, but I don't think that anymore. It must precede the latest changes - it has exactly the same behaviour when I revert to 8.7.3. Will raise a ticket when I get a moment.

geoffreycoan I’m back to fiddling with my heat pump settings again to see if I can improve it further.
geoffreycoan Your consumption through the night looks consistently high, do you not set back the temperature overnight?

Lots going on here - will come back to this in another thread later when I find a moment.

Hi all, another Predbat for newbies question. It seems to not charge my battery fully sometimes. This morning it left 2.5hrs to charge my battery (9.5kwh) from empty and it only managed to get to 84% by the 0530 IOG end of cheap rate. These days I need a full battery to just about make it to 2330. If I do any washing/tumble drying then obviously I'll run out of battery early in the vening so I think Predbat should be trying to hit 100% charge at 0530. Battery temp wasn't an issue as it'd charged and discharged from 2330-0300. I've got a battery charge curve setup in the apps.yaml file so I assume it should incorporate the slower rate of charging from 91% in any planning. Is there another setting I should configure? It has been on holiday mode from 24th Dec - 4th Jan. Could that be throwing off Predbat's usge assumptions meaning it thinks it doesnt need to fully charge the battery? I'm using Predbat 8.10 BTW.

Lincs_Will lots of good questions

first thing is whether you have got predbat setup correctly for your battery

What inverter do you have, its max charge rate, and what BMS are you on? If you have 3017 or 3018 then these slowdown the battery charge rate when the battery cell temperature is below 20 degrees, and unless your battery is in a heated part of the house this could well be affecting your charge rate. You say you don’t think temperature was an issue but were was the battery cell temperatures?

There is a discussion on github about incorporating battery temperature curve logic into predbat because at the moment Predbat doesn’t know that your battery won’t achieve what the inverter says it will.

You can adjust input_number.predbat_battery_rate_max_scaling and limit_battery_charge in apps.yaml to better reflect what your battery/inverter can achieve, e.g. I have my battery_rate_max_scaling set to 0.92 as my battery only ever charges at 2.4kWh not the 2.6 the inverter says it can do.

Yes predbat will incorporate the battery charge curve in the plan so should take account of the slowdown in charge rate from 90%. It might be worth you comparing the charge curve to the actual charging results to see whether the curve is correct, if Predbat generated it, it should be, but still worth checking.

Being in holiday mode previously shouldn’t affect the predbat forecast going forward https://springfall2008.github.io/batpred/customisation/#holiday-mode but if you were away then the historical load will probably be incorrect. Might be worth shortening the duration of days_previous you are using in apps.yaml whilst you build up historical load to match what is more typical.
Have you got load scaling set to a value, this should help Predbat recognise if you are using more than the load forecasts, and turn switch.predbat_load_filter_modal on to ignore the lowest days_previous history

Josephiah I think I am coping with the current weather reasonably well.
My 10 kW Viessmann ASHP system runs entirely on weather compensation. I have no gas, so solely electricity.
I am in a 1920s detached: typical insulation (except loft) well below modern standards.
My system is set at 20C 6am-9pm and at 17C setback overnight 9pm-6am.

I have an internal temperature sensor in main open plan living room and this settles to 20C daytime (higher if there is any solar gain) and drops only to 18.7C at lowest overnight. The internal sensor does not control the HP at all.

I have experienced minimum temperatures down to –4C and daytime below zero (–0.3C now at 11:15am).
My weather curve is set at 0.6 slope and 0.2 level (not all HPs have level).

Setback certainly saves costs and doesn't seem to affect the established thermal mass much.

My SCOP is 5 but in current cold snap, COP has dropped nearer to 4. I am getting defrost cycles every 2 hours on average. My peak electrical energy input has been 34 kWh and 30 kWh (Sun and Mon) and matches last winter's coldest days.

So worth looking at your HP settings.

With predbat, I do have solar which can help (if panels have no snow on them!).
I am on 8.8.10 and it is too soon to see if this version has affected me. My max daily cost is near to £8, very high for me.
My technique is to let predbat do its own thing. I very rarely intervene, and this has worked well.
There are some current discussions on battery temperature. My batteries are in a large porch where temperature is house temperature, about 20C. But batteries can be adversely affected by cold temperatures which may affect historical data and predbat may respond by predicting a greater load. Your load during the night looks high.

I hope that there is something in my reply to help alongside the replies from @geoffreycoan
My comments are more focussed on your wider setup rather than just predbat.

Rob

geoffreycoan Thanks! Ive got a Gen 2 5Kw inverter and I'm using BMS 3017. I've checked the logs of battery cells temps. They were all above 20 degrees from 0300-0530 so the temp throttling shouldn't have been an issue.

GIvenergy specs say my inverter should charge/discharge and 3.3/3.6KW and looking at the battery power recorded by GivTCP last night it managed 3.3-3.4kw and charged from 7% SOC to 84% between 0300-0530. I don't know what Predbat thinks my inverter can do as I've not set it anywhere. Maybe it assumes 3.6KW as I think thats what the battery can do? I've changed input_number.predbat_battery_rate_max_scaling to 0.92 as thats the ratio of 3.3KW to 3.6KW and I'll see how that goes.

I do remember discussion in 2023 when I 1st got my system installed about battery calibration and SOC drift. I wonder how the inverter/BMS handles that with Predbat more or less constantly trying to charge & discharge as I think it needed to be left to realign the SOC.

I tried the HA update and did HACS 2.0.2 at the same time and it seemed to break apexcharts (not sure which update did it) so I reverted to this morning's snapshot. Haven't had time to diagnose yet.

Lincs_Will GIvenergy specs say my inverter should charge/discharge and 3.3/3.6KW and looking at the battery power recorded by GivTCP last night it managed 3.3-3.4kw and charged from 7% SOC to 84% between 0300-0530. I don't know what Predbat thinks my inverter can do as I've not set it anywhere. Maybe it assumes 3.6KW as I think thats what the battery can do? I've changed input_number.predbat_battery_rate_max_scaling to 0.92 as thats the ratio of 3.3KW to 3.6KW and I'll see how that goes.

Predbat assumes what the inverter says it can do unless you override it with the input number or the inverter limit in apps.yaml. It should report the charge and discharge rate its using the in logfile but it does sound like that would be a cause of your issue.

Late tonight do a screenshot of the predbat plan and then look afterwards to see how well it executed it.

Lincs_Will I do remember discussion in 2023 when I 1st got my system installed about battery calibration and SOC drift. I wonder how the inverter/BMS handles that with Predbat more or less constantly trying to charge & discharge as I think it needed to be left to realign the SOC.

Its not the best of behaviour to charge then discharge then charge the battery which is what I think you said predbat is doing to get the most out of IOG. The SoC tracking is improved by letting the battery rest for a bit for the voltage to stabilise.
Maybe periodically set predbat to Control charge only, and turn low power charge on so Predbat doesn’t force export the battery and does a slow and low charge in the overnight period. That would help the battery rest-calibrate itself

browellm Yesterday, I updated HACS and Octopus which both went fine.

I also tried to update HA and, as is often the case for me, I had problems, one that I hadn't seen before.
When HA come back on stream, I no dashboards would load on my iMac. Everything else worked fine. I tried restarting HA but no luck.
I then tried a different browser and dashboards worked. They also worked using the same browser on a laptop. Dashboards also worked on the iOS app on iPhone and iPad. Predbat, running on my pi4 was still working just fine
I then copied the URL for HA/dashboards from my laptop to my iMac and this worked! It is as if the URL got corrupted.
......... the saga continues .....my history wouldn't load. Left it 30 mins but just a sign telling me that history was being loaded.
I then restored back to previous version of HA (12.5) and history worked.

I hate HA updates and I will delay another attempted update until later versions.

Rob

Regarding the updates, I don't know if it's coincidence but after the upgrades yesterday, I had 2 hours of free lecky today from 14:00 to 16:00. Predbat saw that and planned for charging during the full 2 hours. However after 1 hour and at about 56%, although it said it was charging it wasn't. I waited for about 7 or 8 minuits no change. Plan said to charge, predbat status said charging but not charging. I set a forced charge until 16:00 and it charged immediately and charged upto 91% without problems.

Rbor After most updates all the history-graphs show messages but dont load the graphs. Like you other browsers work but I have to press ctrl-F5 on Chrome to force a refresh ignoring cached items and that reloads the page with everything working. This is on Windows and I don't know iMac but I presume there is a similar thing you can do to get the cache to be ignored on your browser. It might not help but give it a go next time it plays up.

Wavy Davy two hour power up for me as well today was nice, but tomorrow’s Agile rates, ugh !

Zaz Thanks. I will do.
I was using Safari, the standard Mac browser, but I only had the problem on one of my Macs.
I tried refreshing but no luck.
Chrome opened the dashboards fine.

I do wonder whether HA are producing too many updates in the time.
I encountered the same 'history graph' issue when I last updated HA and only got the history charts back by restarting HA again. The time before, I had to restore from a previous version to get HA running properly.

Rob

Have updated everything and phew no issues. All the graphs are OK as well.

I have started to use Reboot System instead of Restart Home Assistant.

Zaz On my MacBook if I do an update, quite often I don't get the predbat plan showing, it shows a error message instead.. If I edit the predbat dashboard (pencil icon), edit the predbat plan, it will show the plan in the preview window. I then press either cancel or ok (doesn't matter which), select done for the dashboard edit and all is well.

Wavy Davy These definitely sound like browser caching issues. I pretty much exclusively use the iPad companion app and it doesn’t seem to have the same disappearing content issues; mind I never clear the cache when updating either

geoffreycoan I use the app as well on my MacBook and my android tablet and phone. Does seem to be better recently. not done it for a little while, including yesterday and just now.
The message I got was this.

But it didn't seem to clear by itself.

Wavy Davy Who knows. A not particularly good error message.

I should say, I use the Companion app on my iPad and iPhone but on my Windows PC (that HA runs as a gesture VM) and my Macbook I just use the Edge or Safari browser respectively with no memorable issues.

But then I also never upgrade to the .1 release, I will wait until 2025.1.3 typically before I upgrade. Let someone else debug it. There always seems to be plenty of. bug fixes in each patch release with unintelligible descriptions of what the bugs fixed. Usually ‘xxx bumped to version nnnn’ which means nothing to me

Bhah

geoffreycoan it's not particularly a problem, as I said it doesn't seem to have happened for a few updates now, and when it does I just use the edit process to sort it. After a restart It does take a minuit or two to get all the messages to clear and start running, but no biggie.

I restarted HA and it came back OK but additional sidebar icons, such as energy, HACS, etc were not there.
Then magically after about 10 min, they all reappeared!

Rob

geoffreycoan Your consumption through the night looks consistently high, do you not set back the temperature overnight?

From a closer look just now, I was right to suspect that Predbat is doing some double counting when it comes to the load_forecast input. Or perhaps more accurately it does nothing to compensate for the the additional predicted load I am adding in by feeding it with an input here, so the final load predicted ends up being historical prediction PLUS load_forecast. There needs to be some kind of ongoing subtraction in there, but I'd have to think about how (or even if) that would work...

So in short: those readings are significant overestimates of actual usage. I've now turned off my Predbat heat pump load_forecast until I can work out a way to deal with it properly - keep meaning to ask Trevor how it is supposed to work!

Rbor So worth looking at your HP settings.

Thanks. Your setup and setting sound very similar to mine. 12kW Vaillant heating a 5-bed house via 22 rads. After a fair bit tinkering during our first winter, last winter, I'm very happy with the performance - SCOP of 5 over the last year, but more like a COP of 4 in the current conditions, similar to you. Heat curve edged down to 0.4, which improved the efficiency massively compared to the installer's setting of 0.75.

I don't use a setback except for coasting across the Agile peak, where I do 20°C target from 1300-1600, 18°C setback from 1600-1900, then 19°C the rest of the time. With the heat curve set so low, the lengthy recovery times from setback render them almost useless. And I figured that the full extra 1.0 of SCOP gained in my settings optimisation goes a long way towards covering the energy saved from an overnight setback, once the post-setback extra recovery energy is factored in.

Video for you @Rbor https://youtu.be/JonHjjKvg6s?si=eIcB_JTXGiI20CGH …..

(non AC3 owners can look away at this moment)

geoffreycoan Thanks.
Not seen this one.

It recommends using the installer app. The setup procedure looks a lot more straightforward than following the tiny screens using GE dongle wifi instructions.

As I have my AC3.0 inverter connected, I am not touching it!
But useful info to know.

Rob

I presume predbat uses relative pricing for the colours of each half hour slot? 99.99 is showing as yellow for me, would usually expect it to be red. 🤣

Josephiah I like your idea of tweaking temperature during the day.
Looking at your 0.4 heating curve slope, I have tweaked mine down from slope 0.6 and level 2 to 0.5 and level 1 (at least for today – hoping to get a bit of solar gain). This has reduced my flow temp from 35C to 32C. I'm interested to see if my load is reduced (it should be) compared with my predbat predictions.

Rob

Rbor Earlier in the week I saw a definite drop in power consumption from my heat pump when I dropped the weather compensation curve down by 2 degrees. I was getting power peaks up to 8kW rather than 10kW and there was a corresponding drop in energy consumption.

I had been experimenting with reducing the heat pump setback temperature part way through the night so the heat pump first fired up on the relatively cheaper overnight rates. Concluded that this wasn’t making a material difference to things so changed back to a single 2 degrees setback from 23:30 to 10:30 yesterday.
But I accidentally turned the heat pump thermostat off.

I did wonder why the electrical consumption stopped climbing in the evening, I’d assumed that it was because the house was at temperature 🤦…

The results on house temperature were quite surprising though:

The heat pump was yesterday consuming about 10kW every 3 hours. I accidentally turned it off at 19:00 and other than the lounge (where the wood burner is), the individual room temperatures moved less than 1 degree.
You can see when my wife lit the log burner.

So at the moment this is my nuclear plan. Light the wood burner and turn off the heat pump for the afternoon and peak evening.
This is probably what Octopus are trying to get us to do with Agile, reduce our consumption when grid load is high. I’m just slow to react …

TX200 I presume predbat uses relative pricing for the colours of each half hour slot? 99.99 is showing as yellow for me, would usually expect it to be red. 🤣

Weird, its all red on mine

The colour coding logic is explained in the oh-so-wonderful documentation https://springfall2008.github.io/batpred/predbat-plan-card/ - I had to reverse engineer the code to work out how it works. Its all down to import rate threshold apparently

TX200 geoffreycoan
Mines all red as well

Had a slight covering of snow last night covering panels. Although there's some hazy sun, the snow isn't budging. There's a bit of PV generation but not much.

And areas outside that melted yesterday are just sheet ice.
External temperature has just risen to –3C (and that is at 11 am!)
🥶🥶🥶

I had been experimenting with reducing the heat pump setback temperature

I have abandoned my experiment of reducing my heating curve settings. Since 8 am, temperature is creeping down in the house. So I have cracked and have moved slope and level back to where they were.

I need some exercise to get warm so off out to shovel some more snow. Temperature forecast to rise over weekend and into next week ..... 😎
But –7C forecast overnight 🥶

Rob

DFS saving session today https://community.givenergy.cloud/d/5364-dfs-sessions/22

I thought there might be, looked, there wasn’t one announced, and now there is, 5-6pm with 99.99p Agile slots either side.

The session is not appearing in event.octopus_energy_ACCOUNTID_octoplus_saving_session_events either as an available or a joined event so Predbat isn’t scheduling it. It might appear or might be back to using my manual API override script again to program it in.

I turned the weather compensation down another 2 degrees so now its -4 off the curve. The house temperature is slowly rising through. Not warm but not awful either. Think I will still turn the heat pump off to ride the peak

Rbor mines red now, lol 🤣

The good thing is being able to do a rates_export_override and let Predbat do the heavy lifting of working out whether it's worth importing from the grid to my flat battery to export later on. Predbat says no.

TX200 mines red now, lol 🤣

Good news,
You shouldn't feel out of things now.

Rob

I got the email from Octopus at about 13:40.
Yes, I dropped in a rates_export_override with 65 as the override into apps.yaml and predbat has come back to me with this:

Looks like my battery will just maintain some juice before 20:30 when the main peak subsides. I will still turn heat pump off during the hour. I have also tweaked my heating curve down again in preparation.

I certainly was asking myself why there was no saving session today as media is going on about possible blackouts.

Rbor Am I being thick ? I can’t find this entity “rates_export_override” at all.
Edit: found it in apps.yaml 🙄

Goshiki2 I think I am am being thick I cannot see the Export override I can see the import. Any pointers what line it should be on please

Rodmac76 This is mine for today.
I have placed it immediately below rates_import_override and then saved apps.yaml.

  # For DFS sessions.
  rates_export_override:
    - date: '2025-01-08'
      start: '17:00:00'
      end: '18:00:00'
      rate_increment: 65

You should then find that the predbat plan changes. This is mine covering the peak rates:

See also documentation:
https://springfall2008.github.io/batpred/energy-rates/#manually-over-riding-energy-rates

Rob

Rbor I did mine via the predbat_manual_api via the screen and script I shared for the last DFS session.

I used a rate increment of 72p as I don’t normally export anything in the peak and the Octopus FAQ’s confirm we still get the normal export amount. You might want to set a load_scaling factor as well if you are turning the heat pump off for the DFS hour.

Its actually OK with the heat pump off since lunchtime. Its a bit not-hot in the kitchen but the lounge, hall and upstairs are warm enough from the morning heating and the . Earlier this afternoon the batteries were full and I was actually exporting a bit !
Predbat is planning a 1 hour export for a £4.21 export payment across the two slots. Woo!

I’ve got a strange situation now. All my dashboard cards relating to Predbat apparently do not exist on my iPad. They are all visible and active on my iPhone.
I’ve restarted Predbata number of times but the iPad is not recovering but the phone is absolutely fine. Any help would be appreciated.

Anyone else not got tomorrow's Agile prices through yet? All of my various apps are just empty after 11pm...

Josephiah Nothing yet. But nothing on the Octopus app, either.

Rbor

Hi Rob, I did not need to charge my battery or use extra electric so did not change the import override this time.

This is my default on yaml. Yours is a little different and you set yours to 65. Can you let me know why you chaged it to 65 please?

When I change the date and time, the rate in the plan goes to zero and charges the battery. So was wondering why you set 65?

Still no agile rates here East Midlands. Must be a complicated balancing mechanism tomorrow, Elexon shows reasonable wind resources.

Nothing in the south. Says :we normally get them around 16:00, any time now." Think their clocks have stopped...

geoffreycoan I have checked on Github Code/Templates. Line 378 onwards:
https://github.com/springfall2008/batpred/blob/main/templates/givenergy_givtcp.yaml

rates_export_override isn't shown as an example.
There are introductory comments introducing rates_import_override and rates_export_override but only an import example is shown.

Should a corresponding example for rates_export_override be added to the template?
And of course there are templates for other inverters.

Rob

Wavy Davy There are only 7 slots left before we run out of official Agile rates. The deadline is 23:00.

It sounds as if NESO were in a real panic today, trying to ensure that there was enough electricity in the system. They were paying ridiculous amounts to get gas power stations switched on.
We lost access to two interconnects as well from France and Netherlands. It looks like France is back up but Netherlands link is on a big fat 0 GW.

Rob

What time does predbat stop checking? 🤣

Daveb01 Octopus were paying 72p/kWh
72 is a bit less to take into account small amount that my battery might discharge to house.
The Octopus range shown on my plan was 80.00 ± (73.73).

I think that the rate increment has to be positive from export override but negative for import override. But happy to be corrected here.

I have re-read the section in documentation and I am unsure that I really understand rate_increment!
https://springfall2008.github.io/batpred/energy-rates/#manually-over-riding-energy-rates

Rob

Rbor I ended up putting mine in as a 62p increment. Similar, accounting for some usual export.

And yes, it was positive on mine and the maths looked right on the predbat plan.

Rbor prices are live now and have appeared in my predbat plan.

Not the cheapest overnight, but still better than my old intelligent flux off peak rate.

TX200 thanks, just got my rates in Predbat as well. That’s the latest I think I’ve ever seen them arrive.

My ‘turn the heat pump’ off strategy worked. Not convinced everyone else in the house liked it, but its 15 minutes to the rates getting to a more normal 29p and I’ve still got 1 kWh in one battery, and that’s after exporting 4.7kWh in the DFS sesssion (£3.38 on top of the normal 70p export payment). House temperatures are on 16, 17 degrees and 21.7 in the lounge (wood burner).

There seems to be different opinions of setting the export rate override. There’s two options when specifying the rate to use for the override, either:

• rate which is the replacement rate to use, or
• rate_increment which is a delta to add to the rate, can be positive or negative

And setting load_scaling is useful if you expect to change your home consumption during the override period, e.g. 0.1 to indicate you’ll only use 10% of normal.

You get paid the standard export rate plus the 72p DFS supplement so to my mind you either set rate to 87 (72+15) or set rate_increment to 72 which is what I did.

Where this breaks down is that DFS is paid on the extra you export or the less you import. No ealy way to specify that in Predbat. So if you normally export then some of the export won’t get the 72p premium and perhaps then you specify a lower value. If like me you don’t export in the peak then you’ll get the full 72+15.

In terms of the givtcp template not including a rates_export_override Rbor I am trying to reduce the amount of info in the sample apps.yaml and put it in the main documentation. In some cases the apps.yaml explanation was the only source of describing how something worked, and that was by its nature limited in detail, plus as you say it becomes a pain to keep up to date for all the different inverter templates and frequently doesn’t happen.
And of course people never look at the latest apps.yaml template, changes made there get missed.

I much prefer to have more in the documentation and to point people there. I have a plan to restructure the templates and change the way they are maintained which should improve this, but down the road right now.

Daveb01 I think you are getting confused between import_override (reducing what you pay for import, e.g. a free electricity event) and export_override (increasing what you pay for export, e.g. a DFS saving session).

You really don’t want an import rate of 0 for today at all as it will start charging as you found out!

Goshiki2 I had a similar experience after trying to update to HA 2025.1.
My iMac couldn't open any dashboards but everything else was fine.
My MacBook worked fine, as did companion apps for iPad and iPhone (and the iMac!)
This was using Safari. I tried Chrome on iMac and it worked!

I restored HA back to previous version but no luck.
Eventually, I copied the URL from dashboards on my MacBook and copied this into the iMac.
That worked.
You could try that.

Someone suggested that I clear the cache.
There is a wealth of hints following a Google search on clearing cache on iPad.

Hope this helps.

Rob

Rbor Thanks Rob. After I had restarted everything for the umpteenth time I started digging around more. When I went in to integrations there was an error in HACS and when I clicked on ‘configure’ it told me there was an update available. I did the update, restarted HA and everything is back to normal. I just can’t get my head around why my phone dashboards were unaffected.

geoffreycoan

Hi yah, I set up the Voltage card in HA you sent me and had a look to see if the same could be done for Temprature. I thought what you would do, copy the voltage card yaml and create a new card. It then only needed the word voltage changed to temprature.

Note:- there are only 12 temp sensors compared to 24 voltage.

I will do all the others now I know it worked and very easy to set up.

Daveb01 👌

That’s a crazy amount of cell temperature monitors in the AIO, I only have 4 in each of my batteries.

Mind, I think the 3 phase batteries have 16. Lots of data

Labels are worth getting into (system/areas labels and zones):

Or you can create labels directly from the entity list. You can attach labels to entities and then selecting the label is an easy way to select a number of entities, e.g. in the history graph or logbook

I use these often for adhoc looks at things as well as pre-built dashboards

Could anyone shed any light on why my solar forecast for tomorrow shows the wrong value in the heading? I have looked, but can't see anything unremarkable in the code.

Henry3rd I think Apex does weird things sometimes. I had a period a week or so ago where some of the heading values came up N/A but some worked. It only cleared when I did a HA update

On that chart BTW I have the following config:

apex_config:
  chart:
    height: 300px
  legend:
    show: false
  xaxis:
    labels:
      format: ddd, dd

So I see day of week rather than just date and legend show: false turns off the useless stuff at the bottom of the chart

geoffreycoan Thanks, I have added your tweaks, and it looks neater.
I shall see what happens when I next update HA.
It's not a big deal, but I am slightly obsessive when something isn't quite right.

And thanks from me. Really tidies up the chart, removing all the guff.

Rob

@geoffreycoan do you know if Predbat had started actively throttling charge rates as part of its plans?
Today of all days woke up to a half-full battery, and found that Predbat 8.10.1 had set the charge rate to 760W:

Switching back to v8.9.3 yields this rather more sensible plan, charging as close to full rate as GE's new temperature profiling will allow. This change happens consistently when I flip between these versions.

Looking at the inverter portal, it is clearly Predbat making these changes.
Actually, let me rephrase my initial question: I know it's doing it - do you know if it's intentional?!

Edit: argh, images not loading, which I can't stop to fix now! First image should show plan taking several hours to get to 100%; second is much more normal looking.

geoffreycoan And just like magic, all is well again.

@geoffreycoan

Hi yah, a quick question please on battery temp now I have the graphs. You mentioned Low power mode.

Do you turn this on say for 3 months jan - mar, or do you keep an eye on things and turn it on and off when it indicates it is going to be say below 5 deg outside?

A snapshot of temperature since start of Thursday 800' up in Yorkshire.

... and how solar OV should come to my rescue during daylight hours:

Rob

Josephiah Predbat adjusts its plan as more evidence comes in. I think that @geoffreycoan has said that 4 hours before is likely to be the best prediction.

You may have raised this previously but your PV is almost non-existent. Compare with the projected PV in my plan that I have just posted above. It is only 09:25 and I am already getting 1.5 kWh of solar today which is protecting me. You are pulling from the grid to cover your load all the time, pushing up your costs with current rates.

Rob

Rbor My Predbat is throttling the charge to the battery (frzexp).
But the battery is still expected to reach 100%, the slow charge will be helping battery temperatures. But as you say the lack solar seems to be the issue for @Josephiah

Henry3rd Predbat has tweaked my plan now I am getting the same now with some freeze exporting, same as you.

Rob

Josephiah I know it's doing it - do you know if it's intentional?!

Have you got ‘set low power charge’ turned on?

I have and I noticed that my plan was similar, charging through the night and into this morning at a low rate. This is better for the batteries than a full rate charge and then idle, and helps keep the temperatures more consistent if its charging all the time rather than sprinting with a full rate charge and then going cold afterwards.

This to me is all deliberate, why its different in an older predbat version I don’t know.

Rbor
Henry3rd
Thanks, but I think we may be talking at cross-purposes here. At this point in the year we have high usage (heat pump) and minimal solar, as you say - but this isn't the issue I'm describing.

Expected behaviour (as it has always done, and does under v8.9.x):
charge battery fully at full rate 3.6kW (or a bit lower when colder under GE's new charging profile - at the temps in our garage (12-15°C), this tends to be 2.7kW until it gets over 20°C, then 3.6kW. Fast, anyway!) on the cheaper slots overnight.

Behaviour under v8.10.x:
Predbat has artificially set the charge rate to 760W (and systematically re-applies this if I change it back in the inverter portal), so battery is only partially charged in the morning.
I was curious whether @geoffreycoan had any insight on whether this is intended behaviour? (Edit - ah, sorry, just seen your response, which hadn't refreshed for some reason - will check out the setting you suggest - thanks)
In the meantime, I've reverted to v8.9.3, and will raise an issue with Trefor later.
Thanks all!

geoffreycoan
Ah, thank you, this seems to be it - wasn't aware of this setting before.

Totally on board with that in principle for the reasons you mention, but in this particular case it seemed to be throttling very aggressively - particularly noticeable on a day with 9x 99.99p slots! Do you know if there's a way to control how aggressively it throttles the charge rate, or choose the circumstances under which it does so?
(I guess the latter might be fairly readily automate-able by just toggling that setting...)

geoffreycoan In 'Words of Caution' in the manual it does suggest:

"Given different inverter designs may have different limits it is a wise precaution to avoid your plan being too busy if it doesn't gain you very much. Things you can do to have a less complex plan include:

Keep calculate export during charge off
Set metric battery cycle to a small non-zero value e.g. 0.5
Ensure inverter losses are set to a representative value
Turn off charge_low_power mode"

What are your thoughts Geoffrey?

Josephiah No to my knowledge there isn’t any further configurability to this.

I was worried about this myself last night but looking at what actually happened, most of the low rate charging was before 7am when the import rate was 20p or less. The batteries were at 80% at that time so comparatively little was charged at the increasing rates this morning (and from 90% SoC the battery charge rate steps down anyway)

You can simply turn it off of course, and I do that when I have a power up or free electricity event, that’s what I do to ensure that I charge at full rate

Leeshore Things you can do to have a less complex plan include:

Keep calculate export during charge off
Set metric battery cycle to a small non-zero value e.g. 0.5
Ensure inverter losses are set to a representative value
Turn off charge_low_power mode"

Sensible advice from Trefor. There is no single right answer for everyone, and got to balance inverter writes and the theoretical risk from those vs getting value out of the expensive boxes you have bought. Having them idle does nothing for you.

Of that list, I have:

• calculate export within charge slots off, this means you have much less charge and discharge in the same 1/2 hour period when Agile rates are less than your import rate
• metric battery cycle set to 0, I don’t like this as an artificial “cost” on using the battery, I bought it and want to use it, but I do have metric min improvement export set to 4 so I only export if profit over the slot is > 4p
• inverter losses, I try to get those correct
• charge low power mode on because of the advantages this brings to keeping the battery warm overnight

Also I’d add to not turn Predbat’s inverter balancing on if you have multiple inverters

Personal choices

geoffreycoan

I have just checked my settings and they are the same except for low power mode, I am going to give it a go, not sure how the AIO’s will think about it.

Do you leave it in low power mode say Jan-March or do you switch it on only if it goes below a certain temperature?

Also does this setting get affected with the yaml power curve setting?

(I saw your note about turning it off for power ups etc)

I have just thought of another random question, Predbat does not always charge the battery up to 100% when there is plenty of Solar, I understand the money side of things and it’s better to export.

Could you ask Trevor if he is thinking about a switch we can turn on/off to prioritise this over money? Especially if there are grid issues or the rates are very high later, I personally would like a full battery for free from solar rather that the cash?

Daveb01 Do you leave it in low power mode say Jan-March or do you switch it on only if it goes below a certain temperature?

Also does this setting get affected with the yaml power curve setting?

I personally haven’t given it any specific handling for time of year or temperature. I leave it turned on all the time so Predbat will charge at the slowest rate it can in the charge time period to still achieve batteries at the desired target % by the end. Slow charges are generally better any time of year so I leave it on regardless. YMMV

Yes the power charge curve is then a further overlay if the battery slows down beyond 90% charged. Predbat should include this when working out what the low power charge rate is

Not sure I follow your logic on a potential extra switch, but feel free to add it as a github feature request. I would say though that in general Trefor is trying to avoid adding continually more settings and options as it gets confusing for users and as much as possible its better to let Predbat do things automatically.

Daveb01 I’m the same. I’ll try low power mode as it seems sensible to try it

Leeshore let us know how you get on - I'll be interested to see if it throttles it as much as mine!

geoffreycoan No to my knowledge there isn’t any further configurability to this.

Interestingly, this entity "low power mode margin" popped up in my controls list, albeit disabled. A future feature that's being worked on, perhaps...? Having this functionality, but with a little more control, would be great.

Currently, I'm not getting any obvious consistency with it - setting it now doesn't seem to be making any noticeable difference - it's just the typical 6-7 slots to get to full charge - which is why this morning's antics were such a surprise.

Josephiah I just checked the docs, had forgotten about low power charge rate margin https://springfall2008.github.io/batpred/customisation/#inverter-control-options

Reasonably new field. Its not disabled on mine, probably an expert mode control. You could set it to a large value to ensure predbat doesnt charge in the most expensive slots

geoffreycoan thanks. As far as I can see, that one is just a kind of safety margin (settable between 0-30mins only) to make sure the final slot actually gets you to full charge, so I'm not sure it helps particularly. I've raised a ticket (not quite sure if it's a bug report or feature request!) regarding the unpredictability of it.

It would be nice if there was a little more control over it, such as being and to set a minimum charge rate, or to manually set a target time it needs to be at 100% for. I wonder if it was the auto-calculation of the target time that was thrown by today's exceptional/weird Agile pricing profile...?

Josephiah thanks, I saw your ticket and have added some comments to it on my own experience from last night.

Got my Topdon thermal camera out today (Christmas present)

Bit the bullet and made the switch to Cosy. Going to give it a go and use the electric heating more extensively for a bit! Hoping Predbat picks it all up smoothly. No doubt sods law means Agile will suddenly become amazing rate wise now, so you’re all welcome if that’s the case 😂

Daveb01 very nice! I’ve thought about getting one, but there is a place here that loans them for free so going to give that a try. Unfortunately it will show all the slot vents that builder stupidly put through the frames of our triple glazed windows 🤦‍♂️

Boffinboy I did sign up last winter to get a loan thermal camera from Octopus, and they contacted me to say I could borrow one. I had bought a Kaiweets KTI-W01 for £161 which I thought was a good price and works well

They have code return10 for 10% off but I think I got 1/3 off so may be able to find better offer codes than this.

Great. What is the blue lump in lower right of image at –3.6C?
I have one of those thermal cameras that slots onto phone but has never worked very well. Battery would last for a few minutes and connection was iffy.

So I've spent a bit of time reading reviews on thermal cameras and watching some videos.
I cracked and have ordered a topdon from amazon, arriving tomorrow!
Costly but came with a £40 off voucher. I got the last one!

Hope it's OK. If not, I can always blame @Daveb01 😆

Rob

Rbor

That’s the Chest freezer in the garage.

I got this model as I have an iPhone and needed the new USB-C connection. Previously they only did them for Android.

TC002C-for iPhone 15 Series and iPads Onwards.

I don’t think HA and Predbat cater for thermal cameras so sorry for the post😀🎄

Also I think I need to fiddle with the settings as it is not -3.6c in the garage 😀👍

I’m having a recurring issue with Predbat. When I have excess charge (like I do today, as I am away) then it decides to export at 7.30pm. But it exports too much, and then I have to import (small, but annoying) before the cheap rate starts at 11.30pm

Anyone got any suggestions?

PianSom

Just had a look at mine and it’s not right. I don’t know what to suggest at the moment.

Holding the charge for so long plus planning a charge when the battery is already full. I know in 30 mins it might change again. I will check the logs especially GivTCP.

PianSom I’m having a recurring issue with Predbat. When I have excess charge (like I do today, as I am away) then it decides to export at 7.30pm. But it exports too much, and then I have to import (small, but annoying) before the cheap rate starts at 11.30pm

Anyone got any suggestions?

it sounds like your calibration/configuration of what the inverter delivers could be wrong.

Predbat will assume that if your inverter does a full rate discharge then it will exactly discharge at that rate.
e.g. my inverter reports a max discharge of 2600W but actually discharges at 2734W (or something like that).

I set 'input_number.predbat_battery_rate_max_scaling_discharge’ to 1.04 so predbat knows about the difference.
And there is a similar scale factor for charging.

Might want to add a bit to best_soc_keep to keep something in reserve and increase best_soc_keep_weighting to give more importance to keeping this.

Assume you have calculate in day adjustment on to adjust the load forecast based on what is happening today?

Daveb01 Just had a look at mine and it’s not right. I don’t know what to suggest at the moment.

Holding the charge for so long plus planning a charge when the battery is already full. I know in 30 mins it might change again. I will check the logs especially GivTCP.

I don’t see anything especially wrong with the plan. The rates are relatively flat so no advantage to charge the battery and equally no advantage to discharge the battery to the home - both will incur inverter conversion losses.
Instead running off grid import will be cheapest and preserve the SoC for later higher periods like at 00:30 when the import rate increases and Predbat starts discharging.

The charging when already full, for a start its most of a day away so things will change, but its much the same, rates are flat so holding the battery full. Charging when 100% SoC is same as freeze charging

geoffreycoan it sounds like your calibration/configuration of what the inverter delivers could be wrong.

Thanks Geoffrey - it seems to be exactly that. My AIO 6kW inverter seems to be discharging at 6.35kW.

I will make the necessary adjustments

However, I’d also prefer it if Predbat would delay the discharge until later, in case of unexpected load. I wonder why it decides on 7.30pm?

PianSom However, I’d also prefer it if Predbat would delay the discharge until later, in case of unexpected load. I wonder why it decides on 7.30pm?

Have you got switch.calculate_export_high_import (expert_mode) turned on https://springfall2008.github.io/batpred/customisation/#calculation-options ?

This should give what you want in terms of delaying the export to as late as possible

In between feeling awful with a cold, almost lost my voice, I am back on updating the documentation again. Lucky me. Added the stuff about utility meter and dashboard for inverter writes, continuing adding the list of tweaks I have accumulated from here and from github issues.
I do need to do something about the whole ‘saving space in the database’ topic but maybe not in this PR

Oh and BTW I am on the latest 8.10.2 Predbat, and was on 8.10.1 until the new release came out. No adverse issues with any of these that I’ve seen

geoffreycoan

Thank you again for the reassurance. The only thing I have changed was to select low power mode.

This is what is says this morning, not sure why it says planned charge for so long

Daveb01 This is what is says this morning, not sure why it says planned charge for so long

Much the same as last night, your forecast solar generation will more or less cover your forecast house load, and there isn’t much variation in rates so again no material benefit to charge or discharge the battery - bearing in mind the 3p or so conversion losses.

If you tweak the input_number.predbat_metric min improvement figures down it might do a bit more, but your plan is pennies across the morning. Get a heat pump and you won’t have this problem, 9am and mine is reporting 22kWh of heat pump consumption overnight already.

My own plan shows not a lot happening, battery in freeze charge for most of the slots, a demand at 10 (but its almost empty anyway), and then start charging at 11:30 when I have a power up event.

Do you have switch.predbat_set_charge_freeze turned on? If not this might be why you are seeing charges at 100% when I see charge freezes

geoffreycoan

Thank you again. Yes set charge freeze is on. I will just leave Mr Bat to get on with it as you say.

I hope you feel better soon, and a big thank you for replying to post when you felt crap. I had it over Christmas so was a bit Grinch (so the other half said) 😎

Daveb01 geoffreycoan For comparison, this is my plan pre-4 pm today.

Compare loads showing contrast with my HP. Not as high as @geoffreycoan – up to 9.10 kWh so far today, but certainly affects costs against no HP (but no gas costs). Not much cost to add though now as I will be emptying battery in the evening. Night is main opportunity to fill battery.

Looks like solar north is predicted to outshine solar south this morning 😎 with PV covering most of my load. And the temperature has risen to –0.5C (up from –6C previous night).

Have you got switch.calculate_export_high_import (expert_mode) turned on

This wasn't aimed at me but mine is switched on.

If you tweak the input_number.predbat_metric min improvement figures down

Mine is on 0, same as default.

Oh and BTW I am on the latest 8.10.2 Predbat, and was on 8.10.1 until the new release came out. No adverse issues with any of these that I’ve seen

Same here. I don't understand what the tweaks are doing or what is in Trefor's mind but no issues with any of recent predbat updates for me anyway.

PS. Other recents: I have:
set charge low power mode OFF and
calculate export slots within charge ON
set charge freeze ON,
Mostly all defaults. My plans are looking good.

Rob

Daveb01 I hope you feel better soon, and a big thank you for replying to post when you felt crap. I had it over Christmas so was a bit Grinch (so the other half said) 😎

It started last Saturday, I felt better on Tuesday, and now its come back again even worse with a 90-a-day voice to match. Bhah. Just not doing much.

Rbor Compare loads showing contrast with my HP. Not as high as @geoffreycoan – up to 9.10 kWh so far today, but certainly affects costs against no HP (but no gas costs).

As we’ve discussed before your heat geek designed ASHP pays dividends and is cheaper to run than mine. I’ve said before I am convinced mine is over-sized and by connecting into the 15mm radiator run rather than the core 28/22 the flow rate isn’t as good as it could be either.
Anyway it is what it is, in all bar really cold days it costs less than £10 a day to run so paying to get more radiators changed or the pipework altered would be a false economy. Does mean my consumption remains stubbornly high.

Here’s the Apex chart I shared before to look at long term temp vs consumption:

      - type: custom:apexcharts-card
        apex_config:
          chart:
            height: 400px
        span:
          offset: '-1day'
        graph_span: 30d
        series:
          - entity: sensor.ashp_energy_today
            name: ASHP
            type: column
            offset: +1d
            statistics:
              period: day
              type: state
              align: end
            show:
              datalabels: true
              offset_in_name: false
          - entity: sensor.grid_import_today
            name: Grid import
            type: column
            offset: +1d
            statistics:
              period: day
              type: state
              align: end
            show:
              datalabels: true
              offset_in_name: false
          - entity: sensor.porch_temperature
            type: line
            stroke_width: 2
            offset: +1d
            group_by:
              duration: 1d
            statistics:
              period: day
              type: mean
              align: end
            show:
              datalabels: true
              offset_in_name: false

In this cold snap I have turned the weather compensation curve 5 degrees down, is resulting in the house being held at a lower temperature for less electricity consumption. Looks like the forecast is for milder weather coming in the next day or so.

One of the things I find annoying is the lack of heat pump info I have which makes optimising the setup hard - the ASHP control boxes are in the loft so its a pain to go up and change the weather curve or see what the flow temperatures are. I’ve bought some cable to relocate the control boxes downstairs and a couple of DS18B20 temperature probes so that I can get flow temp and HW tank temps into Home Assistant. But not going to be doing those until I feel better….

geoffreycoan Have you got switch.calculate_export_high_import (expert_mode) turned on

Sadly, yes I have it on. But still get the early discharge. 🙁

Get well soon!

So had (low power mode pn for quite a while to see what it did and how 2 x AIO’s would react. It looks like it Mr Bat was wanting to charge for a lot of 30 mins slots (see above)

It had just planed another 10 slots later in the day. I have decided to turn it off and it’s all gone back to normal.

So my advice at the moment if you have an AIO don’t put on low power mode 🙁

geoffreycoan I set 'input_number.predbat_battery_rate_max_scaling_discharge’ to 1.04 so predbat knows about the difference.
And there is a similar scale factor for charging.

Hmm, I had input_number.predbat_battery_rate_max_scaling_discharge set to 0.85, which given that the actual value should it appears be 1.055 explains my. issue.

At some point I set it to 0.85 as I thought this was the input_number used by Predbat to override the GivTCP stated battery size (15.96kWh) to the stated size (13.5kWh). On reading the docs now it is clear that I should be using battery_scaling - which I already am. How odd that I have had the same mistake for so long!

geoffreycoan I hope you recover quickly from whatever you have caught.
I guess that the microlight that came over my house yesterday wasn't you on a northern foray!

Rob

geoffreycoan Nice Apex chart.

As we’ve discussed before your heat geek designed ASHP pays dividends and is cheaper to run than mine. I’ve said before I am convinced mine is over-sized and by connecting into the 15mm radiator run rather than the core 28/22 the flow rate isn’t as good as it could be either.

My HP installer split off from the initial core 28/22 after plumbing into water cylinder and only when the 15mm radiator runs split around the house. I don't have a buffer. I have heard that many installers deliberately oversize and use a buffer so that they can't be accused of installing an inadequately sized HP by the owner. 'Less potential hassle' for the installer but less efficiently for the user. I think that Octopus install heat pumps 2 kW greater than the calculated heat loss.

One of the things I find annoying is the lack of heat pump info I have which makes optimising the setup hard

My HP is a Viessmann. The app is adequate but doesn't give info on flow rate, flow and return temperatures. I can get this info from the Viessmann display unit but that is a pain.
However, Viessmann do have a HA integration which provides all this info.
I also have the OpenEnergyMonitor kit which provides all this info and more.
OpenEnergyMonitoring also have a HA integration which provides better info that the Viessmann app.
So I am spoilt for choice here. The OEM kit is expensive although mine wasn't!

Which make is your ASHP?
I have looked on HA and there seem to be few HP manufacturers with integrations. I was surprised that Vaillant, the commonest, is absent.

I am at least above freezing now. There was an almighty thud outside late yesterday evening as the snow finally slid off my last 3 snow-covered panels so PV generation should now finally be back to normal.
Good solar PV over recent days has pushed up my Jan generation and has helped to provide energy for the heat pump. I have even exported 3 kWh of excess PV today!

Defrost cycles are a drawback of a HP in low temperatures. They use up energy and space heating for the house stops until the defrost cycle is complete.

Rob

PianSom With so many settings, it is not surprising that we lose track of changes that we have made or the reason why we made the changes. It is great to have Geoffrey's excellent documentation to refer back to and knowing that Trefor is striving to look after us all with his incessant improvements to predbat.

I regularly go to the WebUI config page, check what the defaults should be, and the entities/switches that are not defaults.

Things are looking up for us all. We have gained nearly 30 min of daylight since the shortest day and the sun is creeping higher in the sky. So our PV generation should steadily increase.

Rob

geoffreycoan Have you got switch.calculate_export_high_import (expert_mode) turned on https://springfall2008.github.io/batpred/customisation/#calculation-options ?

This should give what you want in terms of delaying the export to as late as possible

PianSom Sadly, yes I have it on. But still get the early discharge. 🙁

But - aha! - the docs say:

So I need the switch turned OFF - correct?

PianSom it is not well worded, and having a look at the code and improving the description is on my list. I had missed the last sentence “by default with this option disabled …”, so yes, does sound like disabling it would give you what you want, even though it is NOT the default.

New Predbat 8.11.0 out today incorporating battery temperature charge curve, i.e. varying the charge curve based on the cell temperature. A brilliant addition from Trefor

geoffreycoan does sound like disabling it would give you what you want, even though it is NOT the default.

You'd think, wouldn't you?

Yet here we are, a few hours after turning the switch to off and ... nope. Maybe it will resolve as we get closer.

geoffreycoan New Predbat 8.11.0 out today incorporating battery temperature charge curve, i.e. varying the charge curve based on the cell temperature. A brilliant addition from Trefor

Tried updating. Didn't change anything (as I am an AIO user so am less sensitive to battery temperature issues). Predbat fail with repeating errors of "Error: argument of type 'float' is not iterable" type. Reverted to previous version.

Just me?

PianSom Worked fine for me, although I cant say I fully understand how this battery temperature charge curve works (I havent noticed any difference on the plan on my 9.5kWh battery after adding the config lines).

PianSom Worked fine for me also.
As my batteries are cosy inside, I have just upgraded.
I presume that I would copy the code into my apps.yaml but it doesn't seem relevant to my setup.
I may add the code to my apps.yaml but would then comment everything out!

Rob

PianSom Just updated mine (running AIO). No problems but I’m not bothering with adding anything to apps.yaml as it doesn’t seem to be affected by temperature.

I’ve updated with no issues. My battery in garage so battery temperature does go down to 10C sometimes. Grateful to let Trefor do his stuff. May need to use old duvet

I haven’t upgraded yet, but from a quick read of the changes https://github.com/springfall2008/batpred/compare/v8.10.2...v8.11.0 , there is:

• new temperature sensor and battery temperature charge (and discharge) curve configs to add to apps.yaml
• a new predbat.battery_temperature entity that I am pretty confident will need excluding from the recorder in configuration.yaml
• a new Apex chart of battery temperature against predicted temperature

Whether you need to configure the temperature curve and what your configuration will be depends on your firmware and battery type. I don’t believe the AIO’s suffer from temperature related battery charging curves, its only the older so called ‘low voltage’ 2.6, 5.2, 5.12, 8.2 and 9.5 batteries
And its something that newer BMS’s 3017 include, so if old firmware such as Gen 1 450/451 then there is no slow down

I do see temperature related battery charge slowdown so for me this will be useful once I work out the config, e.g.:

The 9.5 charges at 2.4kWh even with lower temperatures, but the 5.2 charges at 1.7kWh (blue arrows) until the cell temperature gets above 20 degrees (red arrows) when it too charges at 2.4

geoffreycoan I don’t believe the AIO’s suffer from temperature related battery charging curves, its only the older so called ‘low voltage’ 2.6, 5.2, 5.12, 8.2 and 9.5 batteries

It's perhaps worth noting for other AIO users that there is a recent new setting available on the Inverter tab on the portal:

A note on the beta forum reminds us that at the end of the 10 min period Forced Charging is turned off again and so any other forced charging slots will not be actioned.

geoffreycoan Is there any thought that I should use the givtcp_dxetc_battery_temperature sensor or one of the sensor for one of the cell temperatures which seem much stabler?

Henry3rd

Henry3rd Option 2

Henry3rd For this to work you need to use a battery cell temperature. What’s referred to as ‘battery temperature’ is actually the Battery Management System (BMS) Motherboard which gets hot and cold much more quickly with use than the individual cell temperatures

In GivTCP V3 the temperature names have changed and there is a new sensor introduced, but it appears (and I, Trefor and others believe) that the sensor names for BMS and battery cell average have been swapped round https://github.com/britkat1980/giv_tcp/issues/329

So, givtcp v2 use any of the cell_temperatures, for v3 you can also use the cell temperatures or bms_battery_stack_temperature which despite the name we are confident is a cell temperature average

geoffreycoan a new predbat.battery_temperature entity that I am pretty confident will need excluding from the recorder in configuration.yaml

I excluded it and the plan just discharged the battery. After removing it from recorder exclusions the plan restored to normal. I have added it to an automation to purge after 1 day....

Predbat struggling to come up with the optimal plan for me tomorrow morning, planning a slow rate charge from 01:30 to 10:30 despite the rates increasing in the morning peak

Turning low power charge mode off doesn’t fix it, but putting a force demand in at 07:30 seems to ‘break’ the charge activity and then Predbat does more what I’d expect it to do

Added this to an existing ticket about issues with low power charge https://github.com/springfall2008/batpred/issues/1866

I can't believe that our plans are so different.

This is mine:

I got 10.1 kWh of solar today which helped. Over the last few days, Solcast has predicted way down on my actual (today Solcast predicted just 5 kWh against my actual of 10 kWh).

I am running v8.11.0. I haven't put any of the battery temperature lines into my apps.yaml as my batteries and inverter are above 20C all of the time
Low power mode is OFF (I have never turned it on).
Most of my settings are defaults. Any tweaks are minor.
I do have switch.predbat_calculate_export_oncharge set to true.
I think we have similar inverter and battery setups apart from you have 2 inverters, each serving a battery. I have one AC3 inverter serving 2 daisy chained batteries.

But why are our plans are so different?

Rob

Rbor they are quite different Rob

The differences probably due to:

• your slightly higher battery capacity, 16.4 vs 13.7 of mine
• my higher daily load especially the heat pump, my batteries will generally only last through the evening peak rates so Predbat generally aims to have me at 100% by 4pm (this plan was 92% at 4pm draining to 4% by 19:00) whereas your plan is 54% at 16:00 draining down to 19% by 19:00
• your rates are about 1.5p/kWh less than mine (but higher SC)

Today I generated much less solar than you, 6.6kWh vs 6.9 forecast, but yesterday was over 10. Fortunately have been helped by power up events today, yesterday and the day before. But unfortunately not tomorrow.

All very strange

geoffreycoan At 4pm today, my battery was at 95% SOC. I even exported 3.8 kWh during the day.
I have switched my ASHP settings back up to where they should be: 0.6 slope and 2 level. Last week, house was losing thermal mass and I was down to 18C during day. Now back to 20C with temps much higher.
So far today, HP has eaten 15 kWh. Last week it was 25-30 kWh.

Of course, no power ups for me.

I think the Agile prices are really being affected by gas prices, with all the geopolitical influences.
Europe is in a real pickle, losing gas left right and centre, and I have noticed that less electricity is coming to us through the interconnects. I wonder what will happen to SVT come April.

Rob

a few seconds before I did this screen shot all the blue hold charge's were green charge's.
Will see what it actually does.

Changes quicker than kier starmer

Think I might downgrade a couple of versions.

Mine are all green charge still.
Your plan isn't that dissimilar to mine overnight.
My tariff rates definitely win .........

Rob

It's green all the way to 6:30 for me.

Just checked HA this morning and looks like Predbat error again at 06:15.

Rebooted and all back. This is the third time 😡 best to keep an eye on things.

Daveb01 Looks like it is failing with a divide by zero error on battery rate max charge which presumably it gets from givtcp. If that call failed then maybe thats why its getting a zero value.
Anything in the givtcp log at that time?

What happened afterwards, did predbat try to run again 5 minutes later or it remained in a heap? If the latter then you should raise this as a github log because predbat really should be able to recover from transient errors if they occur,

Do you have the predbat error detection automation running, it should restart predbat if it detects it has stopped running.

Daveb01
geoffreycoan

Is this one for sending Trefor as a 'debug log' in GitHub issues, especially as you have had this problem 3 times now. Trefor seems to like a debug log for spotting predbat problems.

Is this on v8.11.0?

Rob

Rbor definitely worth always sending a debug log if you can do

the debug log is another of Trefor’s new changes to Predbat, it basically dumps all of your predbat config from apps.yaml and HA entities into a YAML file so Trefor can recreate your predbat configuration and settings. For things like ‘plan not right’ this is invaluable.

Since this has happened just 3 times and from the error I think its a temporary thing caused by bad/missing data from givtcp, the log won’t necessarily be needed, but better to supply if you can do.

I upgraded to v8.11.0 yesterday and there were no untoward surprises. Still working on calibrating the temperature charge curve though.

geoffreycoan

MQTTHas no errors in the log.

GivTCP has errors but it seems after 8:00, and the last good write was at 05:30.

I rebooted at about 08:25

geoffreycoan What happened afterwards, did predbat try to run again 5 minutes later or it remained in a heap? If the latter then you should raise this as a github log because predbat really should be able to recover from transient errors if they occur,

The log is huge so do not want to post it here really. (I have tried 3 times to do the ‘’’ thing and failed, so not having a good day.

geoffreycoan Do you have the predbat error detection automation running, it should restart predbat if it detects it has stopped running.

I have the one in yaml, but not the other one you posted. So may have to look at that again.
If I restart GivTCP Predbat restarts, if Predbat goes wrong nothing happens it seems.

Rbor Is this one for sending Trefor as a 'debug log' in GitHub issues, especially as you have had this problem 3 times now. Trefor seems to like a debug log for spotting predbat problems.

I have never got round to doing anything in GitHub so at the moment I have no idea how to send a log or report an issue to Trevor. You guys have always sorted it or it has never gone wrong for the same thing more that once especially in the night.

Thank you both as always for looking at this and your advice 👍🍺🍺

Daveb01 looking at the givtcp log it looks like givtcp threw a wobble and predbat didn’t handle it well either.

Think its worth you logging this as a predbat issue in the first instance because if Predbat gets an error from givtcp then it should (via the apps.yaml config) restart givtcp to get things going again. It doesn’t look like this happened so its a predbat thing to look at.

There are two automations I provided in the predbat documentation (output data section). One to check that givtcp and mosquitto are running OK and providing data stream to HA, and one to check that predbat is running and the plan updates regularly.
They are not absolutely bulletproof but they do catch most ‘stopped working’ type errors so worth trying them.

I’m seeing some unexpected behaviour with the temperature curve and low power charging mode overnight https://github.com/springfall2008/batpred/issues/1875

Interesting discussion on another github issue about how to calculate the temperature charge curves for your inverter. I will be using this to calibrate my own curve and add something to the documentation https://github.com/springfall2008/batpred/issues/1844

Oh, and still ill with this cold and cough. Living the dream….

I would still be into having something like a a very simple predheat-lite control within predbat that takes an external temp sensor and models a % uplift to electricity use.

Use-case for me is a 2kW electric underfloor heating mat in the kitchen which kicks in pretty hard when temps get around 1-2C and below.

browellm

So are you say saying your going to treat your battery to a new years present and stand it on a heated mat, incase it gets a bit cold 😜

It will be asking for a beer soon or Champagne 👍

browellm I would still be into having something like a a very simple predheat-lite control within predbat that takes an external temp sensor and models a % uplift to electricity use.

You can do this with the select.predbat_manual_api

Basically you want to set an import_rate_override for the time period (and date), don’t specify a rate or rate_increment but set a load_scaling_factor for your house load (its a % of current load not a +/- of kW though)

You can manually add this rate override in apps.yaml or write a script that will set select.predbat_manual_api to the override details (I use this technique for handling Octopus power up and free electricity events - see other forum posts on this).

Then just need to trigger an automation based on the external temperature sensor (or a weather prediction of low temperature), the automation calls the script. Just need to work out what the time period is based on the triggering criteria.

Might need to think about why you are telling Predbat about this extra load and what you want Predbat to do about it. In general predbat is for planning longer term battery activity so it’d be better to trigger all this based on forecast weather so predbat can charge the battery ready for the low temperature activity.

Or if you want to trigger it based on ‘its cold and there will be extra load right now’ then the options for predbat are perhaps more limited - do you want to switch predbat to demand mode to let the battery take the extra load, or do you want to set it to freeze charge to stop the battery going into the floor heating and instead keep it for the later peak. If this latter than you might just as well be served by setting the select.predbat_manual_demand or similar manual controls to force predbat into a mode you want

So I am loosing faith with Mr Bat, it seems to think my batteries should go into Idle during the peak period.

The only thing I have changed was to upgrade Predbat yesterday.

We have been out for a few hours, checked the logs just now and it looks like it’s Predbat. So going to a backup.

geoffreycoan Just reading through the github posts etc about the temperature curve. Think I'll wait until the clever people like you come to a conclusion as I am struggling to understand the technical jargon.

Daveb01 Mine seems Ok and up to date with predbat upgrades:

Have low power mode charge to True as the only change from default config

Daveb01 the predbat log shows the same divide by zero error you had this morning. I’d try restarting predbat and givtcp and this should clear it.

And rather than restoring a backup you can always just downgrade predbat to the last version, select the version you want from select.predbat_version

8.11.0 is running fine for me, doing what it should no crashes

@Leeshore you can run the latest version just don’t update apps.yaml if you don’t want the temperature curve stuff running. The default curve is probably OK, can be improved, but its better than having no curve.
Having said that there are some weird things happening with low power mode and temp curve so as you are using low power mode then perhaps not defining the temperature curve is a good thing until Trefor has taken a look at the reports we’ve made

Daveb01 When I have had real issues, I have loaded a previous backup.
But first downgrade to a previous version of predbat as @geoffreycoan has suggested.

I have experienced most issues following a HA upgrade. I did try 2025.1 and backtracked to 2024.14.5 which got me back on track.

I have even completely shutdown HA and have got things back then.

It is easy to submit an issue on Github and Trefor often spots the problem from uploaded logs.

Rob

Rbor
@geoffreycoan

Thank you both. I restarted everything, Mr Bat was not having that.
Downgraded Mr Bat as suggested, he took the warning and looks like it’s all back. But for how long?

I will now keep an eye on it more often (again). Ahhh is that the issue, I was not looking at it as often as I was, tying to step back a bit and Mr Bat did not like it 😛

P.S - I rebooted GivTCP only to test the auto restart of Predbat and that works, so if MQTT& GivTCP is OK, Predbat does not restart.

Daveb01 What does your latest predbat log look like?

Rob

Evening all - I used Predbat all the way through 2024 on Flux, had zero issues with charging and exporting until late November and then despite subsequent daily plans having charge slots early mornings it failed repeatedly so I essentially dropped it into monitor mode as I could no longer trust it and didn't have the time to troubleshoot. Since then I've upgraded to GivTcp 3, re-installed Predbat as an add-on and the Octopus Energy Integration and I turned it back on this week in charge/discharge and it's been working as expected - phew.

I swapped to Agile yesterday, restarted everything and I started to get a new Predbat plan, it's been charging as you would expect, but what I've not seen, despite the battery at 90-100% is any export in the plan. The config is all defaults and I just can't see what the problem could be. I would just expect it to do some exporting in the plan?

Any pointers would be gratefully received !

I have had no export for a while. Predbat tries to fill the battery to 100% from solar.
It's more cost effective to avoid exporting at 15p when it's costing 20p to charge in the first place plus the losses through conversion.

Henry3rd - Now I didn't think of that ... Maybe I just need to wait and see what happens as the days get longer - Thanks

Northwarks One thing to check:
The Flux tariff incorporates import and export.
The stock Agile tariff is an import tariff.
To export, you need to apply for Outgoing Octopus:
https://octopus.energy/smart/outgoing/
There are two varieties and the usual advice is to enrol onto Outgoing (fixed 15p/kWh), rather than Agile outgoing which usually has lower export rates.

So first check that you are on an export tariff.

If you have already done this, many people have found that export can take a little longer to set up.

Hope that helps.

Rob

Agree re export, hardly any for me in recent weeks, it's not worth it - import Vs export price not great.

Plus import price is fairly high overnight - so PredBat saves the energy for me to use, and I agree. It makes sense.

Rbor

Looks good phew

It’s happened again

Daveb01 Givtcp log?

Have you touched your apps.yaml?

Rob

Daveb01 the problem is not predbat. Predbat tries to set the discharge rate and gets a bad response back which it rejects.

Its either:

• givtcp
• comms from Home Assistant to your AIO gateway
• your AIO gateway not accepting the responses

Since you have restarted givtcp once already I would hazard a guess that it’s the last of these options. Try doing a ‘reset to defaults’ of your gateway and AIO’s from the givenergy portal and rebooting them all.

You have restarted givtcp before but the other thing to try is to delete all the /config/GivTCP/*.PKL files (cache files) and restart givtcp again. In fact do a complete shutdown and restart of HA and all addons to be sure

Rbor

Nope yaml not touched for about 6 months

geoffreycoan

Here are the two logs together, so it seems to me it maybe the Gateway?

Daveb01 Just an observation from me. Do you know why Predbat is setting a discharge and charge rate of 0?
in effect telling the invertor to discharge or charge at a rate of zero, which would cause some confusion.
I would expect it to be 3600 or a percentage of your max invertor discharge rate. Is the discharge rate set ok in YAML?
Has the temperature charge curve muddled things? It looks like 0% charging is effected when the battery temp is at zero deg.

Henry3rd

The thing is I have not chaged any settings just update HA, Predbat etc. As I have AIO’s I have not updated yaml with Temp curve etc. as not needed.

geoffreycoan

So doing one thing at a time:-

Not touching yaml
Have gone back to Predbat 8.10.2
GivTCP rebooted only (will remove cache files next)
MQTTRebooted but no errors in the log so think this is OK.

HA
Core - 2025.1.2
Supervisor - 2024.12.3
Operating System - 14.1
Frontend - 20250109.0

Henry3rd Just an observation from me. Do you know why Predbat is setting a discharge and charge rate of 0?
in effect telling the invertor to discharge or charge at a rate of zero, which would cause some confusion

I have definitely in the past seen Predbat set charge or discharge rate to zero when it wants to do a freeze operation, but looking at my sensor history I don’t see this happening at the moment so maybe its been optimised out in favour of using PauseDischarge which is used a lot.

Be worth seeing if things settle down on an older Predbat version and then reappear with the latest version which would indicate a predbat bug, although not one I am seeing.

Henry3rd

I will keep an eye on this as just seen this again on Predbat Log
This is what the GW settings are and have been for months

geoffreycoan

I have deleted all the *.pkl files now.

No more errors at the moment, it not going to sleep well as battery was nearly flat this morning.

Looking again at the logs, predbat breaks down with:
givTCP breaks with Setting Discharge Rate failed: ( 'ZeroDivisionError', 'write.py, 447)
predbat does the same with Inverter 0 set discharge rate 0 via REST failed got 6000
Previous pause instructions worked fine.

Is it worth looking on the GE portal and looking at the charge and discharge settings?

And in predbat webUI/configuration, are there any rogue settings?

Another observation: When you restarted predbat, immediately after the probate files being 'watched', you are getting warnings:

19:12:49.453722: Warn: Inverter 0 set discharge rate 0 via REST failed got 6000
19:12:49.492214: Warn: record status Warn: Inverter 0 REST at Failed DischargeRate to o got 600
19:13:20.755865: Warn: Inverter 0 set charge rate 0 via REST failed got 9960
19:13:20.797640: Warn: record status Warn: Inverter 0 REST failed to setChargeRate

I don't see anything like this. I go straight from the 'watching' lines to the first instruction with no warnings.

Finally, which version of givTCP are you running?

Rob

@Daveb01 did these errors only start appearing and continue to appear on Predbat 8.11.0, or are you getting it happening on older Predbat versions as well?

When you upgraded to 8.11.0 I think you said you didn’t define a battery temperature charge curve in apps.yaml?

Did you define anything in apps.yaml at all for the new version, a temperature sensor, temperature history sensor, or just left apps.yaml unchanged?

If there is a strong correlation between this starting to happen on 8.11.0 then I am wondering if this is a side effect of the temperature curve logic, determining from the temperature that it needs to assume a charge and dischare rate of zero which is what causes the fail. Maybe? I know I can set 0 for my inverter charge and discharge rate but maybe the AIO gateway is different?

You could be working yourself up to your first github issue Dave

Daveb01
geoffreycoan

You go here: https://github.com/springfall2008/batpred/issues

Have a look at how others have submitted issues, including someone called gcoan

And attach screenshots/downloads.

Rob

Daveb01
Final final thought here:

geoffreycoan
Be worth seeing if things settle down on an older Predbat version and then reappear with the latest version which would indicate a predbat bug,

So try downgrading predbat back to v8.10.2

Rob

Rbor

So this maybe because I have these set in GW (see pic above). I noticed Predbat did not change these and was importing exporting at max 12000 even when I set them to lower 9n yaml.

So to sort out this should I put them back to 0 or do what Geoffrey has suggested (reset to defaults?)

geoffreycoan

I have only noticed these errors since upgrading to the latest version. I down graded earlier tonight. I have not had any errors since however this 0 setting is still worrying me.

I did not do anything with the new temperature setting in yaml, so it should not have been that.

Daveb01 I don't know about Gateways and the AIO.

Anyone AIO users out there who may be able to help?

Rob

Daveb01 So are predbat and givtcp behaving themselves now?

I notice that you are on HA 2015.1
I tried this but it broke my setup.
I got my system back by restoring to my most recent backup: 2014.12.5

But first, see if your setup settles down on predbat v8.10.2.
I must admit that I don't understand what is going on with the battery temperature changes in v8.11.0. Although I am running v8.11.0 myself, I haven't added any of Trefor's code lines to my apps.yaml.

Rob

Daveb01 So this maybe because I have these set in GW (see pic above). I noticed Predbat did not change these and was importing exporting at max 12000 even when I set them to lower 9n yaml.

So to sort out this should I put them back to 0 or do what Geoffrey has suggested (reset to defaults?)

Predbat should set the discharge and charge rate to the limits specified in apps.yaml, setting the battery charge rate and discharge rate when it needs to. The Charge Rate AC and Discharge Rate AC are I think derived from the raw charge/discharge rate.

But then you say despite what the dashboard says the inverter is going at full rate. The REST errors indicate that predbat was trying to change these to zero but this was rejected and it was getting a response of the original value.

Its hard to tell precisely what is going on, but I suggest a reset to defaults will at least get the inverter into a known clean state, and then either you or predbat can set the battery charge/discharge rate to what you have in apps.yaml and it should then be back to normal.

Daveb01 I did not do anything with the new temperature setting in yaml, so it should not have been that.

No but it may be that Predbat expected you to have configured it in apps.yaml and because you didn’t, it defaulted to an empty temperature charge curve and hence got to setting the rates to zero.

I don’t know for sure, lets try the above and leave it running on 8.10.2 and let it run overnight. Then can try upgrading later on.

Rbor is that an o rather than 0?

"DischargeRate to o got 600"

I don't fully understand this new code as I'm not using it myself (my battery is unlikely to get cold) but that looks a bit suspicious.

geoffreycoan

Morning all, thank you for the help so far, and your continued help on the new puzzle.

There were a few issues again in the night (see logs below). I did not have time to reset my system, so that is number 1 on the list today. I looked at Predbat first and can see errors but good to see this time auto restart. It has benn working the rest of the night and still ok at moment. Battery at 100%. Iaw the plan.

Daveb01 According to Predbat you had a time skew of 59.25 minutes to the inverter. Is this related to your problem? Is it worth an inverter time resync first before you move on to anything more drastic?

Goshiki2

I saw that, not sure why that happened.

The plan looks ok during the day but the goes into planned charge for hours?

Surly Predbat knows the battery will be full and not keep trying to charge?

geoffreycoan

I will wait until you have commented on the logs etc, before I reset to defaults as suggested,

Goshiki2 I was looking at that as well. Its weird:

Daveb01

2025-01-17 23:45:10.083432: Info: record status
2025-01-17 23:50:51. 028724: Info: Freeze charging target 13% record_status Freeze charging target 13%
2025-01-17 23:55:10.595215: Info: record status Freeze charging target 13%
2025-01-18 00:00:40.225126: Warn: Invertor time is 2025-01-18 00:59:56+00:00, Predbat computer time 2025-01-18 00:00:40.224944+00:00, this is 59.25 minutes skewed, Predbat may not function correctly, please fix this by updating your inverter time, checking HA is synchronising with your inverter, or fixing Predbat computer time zone 2025-01-18 00:00:40.261416: Warn: record status Invertor time is 2025-01-18 00:59:56+00:00, Predbat computer time 2025-01- 18 00:00:40.224944+00:00, this is 59.25 minutes skewed, Predbat may not function correctly, please fix this by updating your inverter time, checking HA is synchronising with your inverter, or fixing Predbat computer time zone

Predbat checks the time of the clock it is running under and the inverter clock it gets back via GivTCP to make sure they are in alignment. If they are wildly different then any commands Predbat issues to start charging/discharging at a specific time obviously won’t happen at the time Predbat expects them to occur.

This also serves as a check that GivTCP is correctly polling your inverter and there’s no break in connectivity,

What normally happens with a time check error is that Predbat detects that Predbat time is ahead of inverter time so we’re not getting data from the inverter via GivTCP, and predbat restarts GivTCP to restore the comms.

But the text of the error says that inverter time received from GivTCP is an hour ahead of the predbat time. This is unusual. Tends to suggest that the inverter time zone or the inverter time is set wrong, but there are normal OK transmissions beforehand and then when predbat restarts givtcp its all OK afterwards. If the time/time zone was wrong you’d expect further errors. Very strange.

The POST error at 08:01 I wouldn’t worry about too much, I get those maybe once a day as well and Predbat retries and it carries on working.

Daveb01 The plan looks ok during the day but the goes into planned charge for hours?

Surly Predbat knows the battery will be full and not keep trying to charge?

This is OK. Firstly you’re looking at the end of the plan more than a day away so all the prices are rolled over and will change, but more, the plan only goes through to 6am when you’ve got very little load, flat Agile rates, and no solar generation so Predbat doesn’t really know what to do with the battery. Given the rates are flat it makes sense to hold the battery full rather than let it discharge. As the plan rolls forward and predbat can ‘see’ your solar generation, load and prices for Sunday it will update to something more meaningful.

My own Sunday plan is much the same except its got a bit more forward window than yours and at 8:30 when (rolled over) rates increase it lets the battery discharge a bit

It’s what I would expect.

Worth you still doing a reset to defaults and resync the time zone & date/time, won’t do any harm

geoffreycoan
Daveb01
This reminds me of the date change glitch we had on 1st Jan (see back around post 136 onwards).

It won't do any harm going to GE portal and doing a sync time in account settings and then again in remote control.
In screenshot of your predbat log in post 420, there is a green line:
[19:11:17) INFO: Configuring timezone (Europe/London) ...

I don't think predbat is cause here. It looks more likely to be givTCP and/or communications with mosquito broker.

Dare I say that there is an update to mosquito broker (and hacs)! But let's see what is going on here before going there.

Rob

Daveb01

Looks like you same synchronised suggestion delivered to you just now:

geoffreycoan

Worth you still doing a reset to defaults and resync the time zone & date/time, won’t do any harm

and

Rbor It won't do any harm going to GE portal and doing a sync time in account settings and then again in remote control.

Rob

Daveb01
This is givTCP issues on GitHub. Lots of log traces which may give a clue:
https://github.com/britkat1980/giv_tcp/issues

Rob

geoffreycoan

Thank you for the comments. I will go and get a cuppa do the reset to defaults and a time sync.

I now have the time of all three devices in my home card and they look good.

Looks like my setup has come out in sympathy for @Daveb01
Just got this error:

This is the predbat error monitor automation from documentation.
https://springfall2008.github.io/batpred/output-data/#predbat-error-monitor

Predbat is running fine. Just has this exception raised at 7:45 am this morning.

Rob

geoffreycoan

As it looks like yaml auto restart is working most times, I will not touch this. I think you also posted you had extra checks, should I leave it as is at the moment or looks at trying to install these as well?

Goshiki2 According to Predbat you had a time skew of 59.25 minutes to the inverter. Is this related to your problem? Is it worth an inverter time resync first before you move on to anything more drastic?

Does anyone have an automation set up that is able to sync the invertor on a daily/weekly basis?

Rbor Looks like I have resolved the error reported. HA had changed the name of my iPhone from iPhone to iPhone2.

But doesn't tell me what the exception was caused by. This is predbat log around 7:45 am when exception was raised. Could this be linked to the woes of @Daveb01 ? Although there is a complaining line about battery size which I have highlighted with ** around it? Any ideas?
2025-01-18 07:31:27.266859: Info: record_status Demand
2025-01-18 07:35:12.328554: Info: record_status Demand
2025-01-18 07:41:35.716493: Info: record_status Hold charging target 95%-91%
**2025-01-18 07:45:05.362427: Error: Reported battery size from REST is 0.0, but it must be >0**
2025-01-18 07:45:05.362655: Error: Exception raised
2025-01-18 07:45:05.372372: Error: Traceback (most recent call last):
File "/config/predbat.py", line 994, in run_time_loop
self.update_pred(scheduled=True)
File "/config/predbat.py", line 565, in update_pred
self.fetch_inverter_data()
File "/config/execute.py", line 629, in fetch_inverter_data
inverter = Inverter(self, id)
File "/config/inverter.py", line 354, in __init__
raise ValueError
ValueError
2025-01-18 07:45:05.412828: Info: record_status Error: Exception raised
2025-01-18 07:45:05.413035: Error:
Traceback (most recent call last):
File "/config/hass.py", line 184, in timer_tick
item["callback"](None)
File "/config/predbat.py", line 999, in run_time_loop
raise e
File "/config/predbat.py", line 994, in run_time_loop
self.update_pred(scheduled=True)
File "/config/predbat.py", line 565, in update_pred
self.fetch_inverter_data()
File "/config/execute.py", line 629, in fetch_inverter_data
inverter = Inverter(self, id)
File "/config/inverter.py", line 354, in __init__
raise ValueError
ValueError
2025-01-18 07:51:25.517158: Info: record_status Demand
2025-01-18 07:55:11.617502: Info: record_status Demand

Rob

Daveb01 Thought you would be interesting in this post with code. From someone on Trefor's predbat page on Facebook, posted at 09:17 this morning:

Any tips on monitoring this situation. It’s happened twice now in as many weeks. Clearly a GivTCP issue but is there anything I can monitor in Predbat to kick GivTCP into touch? Is there a binary status sensor?

Look familiar?
I will keep an eye out to see if anyone has any suggestions.

Rob

Rbor

No change to my mobile setting.

geoffreycoan
@Rbor

Hi all, have reset to defaults and sync time, hacked the logs in Giv Cloud and all was processed successfully. Phew part one completed.

I took a screen shot of settings before I did reset and a few things have changed. So the question is do I leave them as default and see or put them back to how it was?

Also I hope my batteries charge and discharge at the correct rate as I don’t want to export and import at 12000 (the DNO will have a dicky fit)

Changes:-

Enable AC charge upper % limit - was on now off
In GW control - Enable Charge Target - was on now off

Another thing I tried and was successful. I moved the slider for all these settings and Predbat put them back to the correct ones. (So a good hint to try if you get the same issues as me). I have made a note to move them to a random number now and then to see if Predbat moves them back to my yaml settings.

Henry3rd Does anyone have an automation set up that is able to sync the invertor on a daily/weekly basis?

It shouldn’t of course need it, the inverter should keep reliable enough time, its mains powered and on all the time so its not like its a PC with a button cell battery that fails after a few years.

I believe there is a givtcp command to enable resync but on 31/12/24 when we had all these date issues someone raised a github issue that it didn’t work. I don’t recall seeing any responses to that issue so its probably lower down the priority list.

Interestingly there was a github issue last week about exactly the same failure as occurred on 31/12/24, givtcp falling over due to invalid date conversion. I got the person who had the issue to install the BBC inverter app and he confirmed it was a corrupt date on the AIO. Resyc’d it via the portal and all cured. Weird.

Rbor 2025-01-18 07:41:35.716493: Info: record_status Hold charging target 95%-91%
2025-01-18 07:45:05.362427: Error: Reported battery size from REST is 0.0, but it must be >0

Your error looks like bad inverter data returned from givtcp Rob, Predbat objected, the error monitor picked up the error and tried to send you an alert but couldn’t due to your phone id changing in HA.

geoffreycoan Your error looks like bad inverter data returned from givtcp Rob, Predbat objected, the error monitor picked up the error and tried to send you an alert but couldn’t due to your phone id changing in HA.

I suppose the exception was just one of those things that happens from time to time. Predbat is working just fine apart from this one exception.
I have fixed the automation (I hope) by correcting the iPhone label. I tested the alert part of the code and an alert happened on my iPhone, or should I say iPhone2.

My next Agile Octopus 12M tariff started today. Here's the bad news from 53.95p 😥

My only compensation is that my unit rates at about 2p less than areas with lower SC. Good news at this time of year but bad news in the summer when I will be importing little.

Rob

Rbor 28 days left on my current Agile tariff paying 42.01p standing charge then goes up to 48.79p

Have to say I don’t understand the regional variations in standing charge, that it costs 25% more to distribute electricity in Yorkshire than it does in East Anglia? I suppose that unless you are going for a truly national cost base there will be regional differences and they have to be allocated one way or another. Daresay it leads to postcode splits where one side of a street pays less than the other.

As for paying a lot of SC in summer when you are importing less, but you are exporting loads and the cost of providing your grid connection - maintaining the transmission network, NESO, having the field engineers, etc all remains the same year round and you’re not paying an export service charge.

Be interesting to see what happens with the consultation about giving the option for no-SC bills. Whether we will see no SC versions of all the tariffs and then would we be switching between the SC and no SC in winter and summer ?

Rbor HA had changed the name of my iPhone from iPhone to iPhone2.

If you go to Integrations / Mobile App / select iPhone2 device

You should be able to rename the device and all its entities

geoffreycoan I have looked back to posts #377 – #379 where we both posted out tariff rates. Looking at rates around 20p/kWh, I was about 1p cheaper than you.

In January so far (17 days), I have imported 500 kWh. Compared with Eastern England, this would have cost me about 500p less.
Taking our new respective SC rates (66.26p against 48.79p), I would have paid nearly 300p more.
So overall, I am about £2 better off.
In the summer, my import costs will be minimal so I would be worst off in the summer.

Over the whole year, I suspect that there would be little difference in our overall energy costs as winter and summer SC would balance out compared with winter import costs.

SC in winter and no SC in summer is an interesting idea!

If there were a tariff with no SC, I wonder how much unit prices would be increased by?

At the back of my mind, I wonder how long the 15p export rate will be maintained. If import unit rates increase, export rates should also increase but ...... If they are kept at 15p, really they are decreasing compared with import costs.

I am glad that I have 9.75 kWp of PV and you have more.

Rob

geoffreycoan Thanks. I will give this a try and then change the automation back from iPhone2 to iPhone. I guess that this happened when I upgraded my old iPhone nearly 2 years ago.

Rob

Daveb01 Enable AC charge upper % limit - was on now off
In GW control - Enable Charge Target - was on now off

@geoffreycoan
@Rbor

Any idea on what I should do with these settings that have changed after the reset to default?iam now not 100% sure what they were actually doing, so may have to go back and look at the posts to see why I changed them in the first place.

1. Leave them as it now and keep an eye on them
2. Change them to what they were and keep an eye on them

Daveb01 Can you get any clues by looking back at the early threads you started:

Basic Config of Predbat (after staring from scratch)
How to use Predbat (from scratch)
Setting up Energy Cardin HA

I will look at this anyway later but you may get some ideas from these threads.

Rob

So this is Mr Bat’s plan, not sure I agree with it as normally I am using the battery.
Not going to touch anything btw, just looking 👍

Daveb01 Enable AC charge upper % limit - was on now off
In GW control - Enable Charge Target - was on now off

Enable AC charge upper % limit is used in conjunction with AC charge upper limit which specifies an upper % you want to do grid charging up to. e.g. 80% if you want to leave some space for solar next day.

My upper limit is set to 100% so Predbat can charge the battery as it wishes, but the switch is off so this feature is disabled.

Enable charge target I can’t see in my GE portal but in HA it is turned off as well. I would guess its something to do with when you are charging up to a target %, but if its working fine and charging OK then I wouldn’t worry about what it was before.

Rbor At the back of my mind, I wonder how long the 15p export rate will be maintained. If import unit rates increase, export rates should also increase but ...... If they are kept at 15p, really they are decreasing compared with import costs.

I have been digging through my emails trying to find what I was originally receiving on Octopus Flux. When I first joined Flux and started receiving export payments in August 2023 the day rate was 19.72p but in September following Ofgem’s rate decreases the daytime export was reduced to 16.932p. Flux peak rate export dropped from 32p to 28.1p.

Since then I’m pretty sure the SVR rates have increased overall but yet Flux in my area would pay 13.64p for day-time export and 27.44p for peak rate export.

Octopus did at least remove the 8p export rate for Go customers, giving them the same 15p rate as available on IOG and other tariffs but I get the feeling that they’re not being as fair as they could be. Eon pay I think 16.5p.

But given that 10-12% of my annual electricity import is on the Power up and Free electricity events this gives a strong impetus for me to remain with Octopus. We shall see I guess

Daveb01 So this is Mr Bat’s plan, not sure I agree with it as normally I am using the battery.
Not going to touch anything btw, just looking 👍

It looks OK to me. The Agile rates are fairly flat overnight (and expensive again) so there’s little benefit in using the battery, so its being charged in the lower rate period and then held full when rates increase through Sunday afternoon.

The effective import rate with losses (figure in brackets) gives you an idea of whether Predbat will want to use the battery or not. e.g. Sunday 11:30 rate 24.59 effective rate 27.35 - this means that it would cost 27.35p to be replenishing the battery from grid import whereas its only 24.59p to be using direct grid import.

So unless there is a load of cheaper electricity coming up later on in the plan that Predbat can use to refill the battery (which there isn’t) its going to be better to keep the SoC.

After 16 months of looking at the effective rate alongside the actual rates I have gone brave and turned the html debug off so I only see the real rates now.

geoffreycoan

Thank you so much, I will leave them off. Good timing btw as I have been searching all the posts for over an hour and had enough.

Daveb01 I have looked at my controls on my AC3.0.
All my 4 battery charge/discharge are on full buy the AC3.0 means that: 3 kW charge and 3 kW discharge. So no correlation to AIO and I don't think I can help here.
What are your default settings for battery charge and discharge anyway?

My overall conclusion is to let predbat do its stuff. It needs a break as do you.
Bearing in mind the problems you have had over the last couple of days, if your system is working now, just let it work. If you change things now, you could reintroduce the same, or new. issues.

Also look carefully at what @geoffreycoan has just written about losses and the merits at times to work from the grid rather than batteries.
Put a padlock around predbat and report back tomorrow.

Rob

Rbor Thanks. I tried this but I failed! Whether I should have left things longer or restarted HA, I don't know. 'iPhone' doesn't show up in Developer Tools but iPhone2 does (even after changing). But I have iPhone shown in Devices & Services.

I have gone back to iPhone2 as the name and in the automation. This works and I will live with it.

Rob

Daveb01 My plan overnight and into tomorrow is much the same as yours.
So don't worry ......

Rob

Rbor what precisely did you change?

I think its the device name here:

the notification script calls notify.mobile_app_geoffrey_s_iphone_12

I actually have a notification group setup for my ipad, ipad mini and iphone and use that instead so notifications get sent to all my devices, but the principle should be the same for a single device.

If you rename the device in the above screen and then go to developer tools / actions / search for notify what notify services do you get, the new phone name or still the old?

geoffreycoan I tried changing the name here to iPhone but in the sensors, I lost the BSSID and SSID settings so the iPhone cannot then communicate to my wifi.
In Developer Tools the name was still iPhone2.

I also tried renaming via the 3 dots to the right.

If I do this, BSSID and SSID stay but the name accessible by the pencil doesn't change unless I change this as well.
Either way, Developer Tools keeps the old setting that I had changed.

Anyway, I have just gone back to iPhone2 which works just fine.

Rob

Rbor I would have thought the BSSID and SSID like all other companion app sensors are just mirroring what is on your phone, so loosing them wouldn’t have affected your phone connectivity?

There are an awful lot of sensors produced by the companion app that TBH I never look at at all. I thought I had disabled some of them in my database reduction quest but don’t seem to have had; they’re really not adding value to me. Other than notifications the only use I have ever seen for these is the geo location stuff, e.g. open the garage door and turn on the outside lights when you are arriving home.

Another way to fix your iphone2 thing could be to uninstall the companion app, delete the device and entities out of HA, reboot HA then reinstall the companion app. The 2 would annoy me!

Has anyone come across this Givtcp error?
Inv1 - sync - [ERROR ] - Connection to (192.168.0.41, 8899) failed: timed out. This is coming up with regularity.

I have just completed an IP scan, and it shows that this device is online and I am able to ping the device which I assume is the invertor.

Henry3rd If you look on your router you should be able to see what IP your inverter has, it usually has the name HF-A21 or something like that, but it is likely it is your inverter IP.

You shouldn’t be getting repeated connection failures from givtcp to your inverter. It suggests either your inverter is going deaf (a reset to defaults can sometimes cure this), or there’s an underlying network problem such as poor signal strength.

Just to check, how is your HA server connected to your home network? Is it wifi or wired ethernet? I think I used to get timeouts on givtcp when I first started with HA on wifi even though it was less than a metre from the router. I swapped to an ethernet cable and it became a lot more stable.

geoffreycoan we have been having a few network problems lately which has been affecting the TV etc. It could well be that everyone is inside playing on their xboxes.
I shall do a complete shutdown and reset of the router later today.
The invertor is hard wired.

geoffreycoan I've partly sorted it but in a bizarre way.
But not completely fixed. I wonder whether there is a bug in HA.

On my iPhone/about, the name is iPhone.
I deleted the HA companion app from my iPhone and installed again afresh.

In Devices&Services/Mobile app, if I select the pencil, I can change iPhone2 to iPhone. This changes all the device parts of the entities to iPhone.
BUT the device itself is still called iPhone2. I select the 3 vertical dots to change this to iPhone.

I check configuration.yaml.
default_config is there.
I add iOS: (not really sure what this adds!).
This adds an iOS integration, which I probably don't need. A candidate for removing and purging.

I then restart HA.

BUT the predbat error monitor automation only works with:
action: notify.mobile_app_iPhone2
I have an apple watch and the alert comes through to the watch also
If I change to iPhone, I get this error message. Action notify.mobile_app_iphone not found

In Developer Tools, under action, I see notify.mobile_app_iPhone2 but not notify.mobile_app_iPhone.

I have tried notify.mobile_app_ipad and that works (but Developer Tools shows this action name also)

So something within Actions seems to clinging on to iPhone2. A hidden cache?

Been on this for 2 hours now.

On the plus side, the automation was never going to send me an alert anyway from iPhone, just from iPhone2.

I hope that all makes some sense as I emerge from another HA rabbit hole!
Off out for some fresh air. The murk has reached Yorkshire after 8 days of nearly unbroken sun, averaging nearly 10 kWh daily! From recent weather forecasts, I wonder whether my part of Yorkshire, in the foothills of the Peak District, was the only region in England that escaped grey skies.

Rob

Rbor So something within Actions seems to clinging on to iPhone2. A hidden cache?

Google is your friend. I haven’t tried this but these two articles cover the same ground, seems a combination of uninstalling the companion app, clearing the companion app cache and restarting HA is needed to get the new device name to be recognised

https://community.home-assistant.io/t/changing-device-name/156812
https://community.home-assistant.io/t/phone-renamed-in-companion-app-notify-service-not-rename-how-to-solve/606568

Rbor I add iOS: (not really sure what this adds!).

according to my configuration.yaml its needed to enable actionable notifications https://www.home-assistant.io/integrations/ios/

Rbor The murk has reached Yorkshire after 8 days of nearly unbroken sun, averaging nearly 10 kWh daily!

Rubbish solar all week, a couple of kW every day. Last decent day was 13th January. Tuesday is forecasting 9kWh. Summer will come one day…

Henry3rd The invertor is hard wired.

Is your Home Assistant server also hard wired? I found it improved stability of my givtcp connection when I hard wired mine

@Rbor
@geoffreycoan

As suggested, I did not go into HAafter the reset yesterday. Just gone in and all looks OK.
So the Reset to Defaults & a time sync was a good idea.

Thank you all again I can now have a relaxed Sunday

👍👍

geoffreycoan Is your Home Assistant server also hard wired? I found it improved stability of my givtcp connection when I hard wired mine.

Yes it is, we have network problems regularly so I hard wire everything if I can.
Interestingly, if I run diagnostics on the network, it shows everything as being perfect! However, when I speak to Sky it seems to fix itself shortly afterwards.
Hmmm!
I have just pulled the plug on the router, so let's see.
I no longer just switch it off at the socket because I don't want to disrupt my pi more than necessary. I need to see how to safely shut it down.

Henry3rd The restart of the router has reduced the number of communication errors. Now just 1 every 6 minutes or so. I shall keep a watching eye out and give Sky a ring on Monday if things deteriorate.

geoffreycoan I 'think' I have resolved the iPhone/iPhone2 problem.
The HA links you provided to me gave solutions for the Android companion app.
One challenge for me was finding the companion app settings. I found it eventually under 'Home Assistant'/settings on the iPhone. Nothing about the iPhone in the companion app but I did notice 'Server'. In desperation, I selected this, I was greeted by the initial login HA screen for username and password. I completed this and found that I now had 2 inputs, both for 'rob'. On selecting each, one referenced iPhone, the other iPhone 2. I deleted the login in for iPhone2.
For good measure, I restarted HA. In Developer Tools/Actions, I now see iphone and not iphone2.
I then went to the predbat error monitor automation and tested the alert sequence which generated an error message (it still had iphone2 as this was my automation).
I changed the iphone2 to iphone in the automation and the alert worked, sending the alert to my iPhone.

It looks as if this has been an ongoing issue for years!
What a ridiculous way to spend/waste so much time.

While I am on a streak, I may upgrade to HA 2025.1.2. Wish me luck.

Rob

Rbor

I bet that’s a weight of your mind getting iPhone 2 sorted. I hope you don’t get any issues like I had.

Daveb01 Dave re your home card do you have the yaml for it? Like the look of it but cant find the entities such as HA CPU.

Wavy Davy Dave re your home card do you have the yaml for it? Like the look of it but cant find the entities such as HA CPU.

Have a look at the older threads Dave created on setting up HA and Predbat they should cover the dashboards.

You’ll need to install the system monitor integration for things like CPU https://www.home-assistant.io/integrations/systemmonitor/

Beware these are quite ‘noisy’ and need to be purged in the database regularly

Wavy Davy

Here you go, I have tried to paste it in here but the code did not look right and I don’t want to get demoted from Rabbit by Rob. So here is a pdf

In my lurking capacity over at Trefor's facebook page, I have come across this contribution from Trefor. It helps to explain why predbat sometimes uses the grid when many of us question why predbat isn't charging the battery. Food for thought .....

You can view the actual context for this in Predbat Github issues here:
https://github.com/springfall2008/batpred/issues/1873

Rob

Rbor I haven't set either of those metrics.

I did increase the inverter and battery loss by 1-2% each, didn't want to think everything was perfect but in fact end up having decisions that actually cost me money.

My values are 0.05 for battery charge and battery discharge loss and 0.04 for inverter loss.

20% is often mentioned as the typical round trip loss. The above comes out at 18%. I suspect 13% is a bit low.

Rbor

I think we had a discussion about this and we agreed 5 was the best setting. Now I have read this should we put it back to defaults?

My current plan looks like this and it has a few idle at the moment?

TX200 My values are 0.05 for battery charge and battery discharge loss and 0.04 for inverter loss.

20% is often mentioned as the typical round trip loss. The above comes out at 18%. I suspect 13% is a bit low.

Daveb01 I think we had a discussion about this and we agreed 5 was the best setting. Now I have read this should we put it back to defaults?

Trefor has added the above FB post to the Predbat FAQ’s; the key thing I’d take away from this is the reminder that the inverter loss acts as a double-whammy as you get inverter losses on the way in and the way out of the battery, so be careful of increasing that too much.

I personally think 13% which is what you get with the predbat defaults is a bit too low and we should be more like 15-20%, but what the right figures are, and whether they the same for low voltage AC/Hybrid inverters and batteries and high voltage AIO and 3-phase 🤷‍♂️
The losses do also vary with temperature and with SoC.

I have my inverter loss set to 0.04 and the battery losses to 0.055 and 0.05, so a total of 17.3%.

If you set the overall losses too low then predbat will use the battery too much, losing you money on the conversion in and out, if you set it too high it will use grid more when the battery might have been cheaper.

The best way to get your own answer is to measure the charge in and out but its not made easy by solar generation (having less lossses) and AC vs DC measurement differences in the inverter data. If I look at my total battery charge in December its 715.8 kwh and total discharge its 604.9kWh. (715.8-604.9)/604.9 gives 18.3% total battery losses.
What does this say for sure, I don’t know, but it does err me towards the circa 20% losses than 13%.

geoffreycoan The best way to get your own answer is to measure the charge in and out but its not made easy by solar generation (having less lossses) and AC vs DC measurement differences in the inverter data. If I look at my total battery charge in December its 715.8 kwh and total discharge its 604.9kWh. (715.8-604.9)/604.9 gives 18.3% total battery losses.
What does this say for sure, I don’t know, but it does err me towards the circa 20% losses than 13%.

Just looked at my data for last year: Total battery charge is 3176.02, Total battery discharge is 2887.11. So (3176-2887)/2887.11 = 10% for Gen3 3.6 hybrid inverter with 9.5kWh battery

Geoff, Are you including solar into the battery?
If I do that for December using your formulae my figures are +8%. If I exclude solar into the battery they are -16.67%

This is data from givenergy dashboard.

Something not quite right!

Sorry not December for the full year...
Senior moment...
Just December figures are

So 8% losses? seems very low.

Wavy Davy This is where it all starts to become difficult because some of the figures you get out of givtcp and see in the portal are AC figures and some are DC. It depends how they are measured in the inverter.

DC figures will be after inverter losses so should measure the battery losses

I read an article last week from Michael Podesta which I can dig out on how he measured his Tesla powerwall capacity year on year, and he looked at battery in and out but only on days where there was little solar generation. To get a true picture we have to do similar, but this is starting to get a grey area.

Might be worth starting a separate non-predbat discussion because other people have measured it before and I personally don't know whether there is a truly right way or not.

geoffreycoan
And looking at mine (AC3.0 inverter) for last year using GE Annual summary and your formula
I get: (4983.03–4644.11)/4644.11 = 7.3% which seems very low.

I have my losses all set at 0.04, so using Trefor's formula, I get
0.96x0.96x0.96x0.96 =0.849 and 85%
This is what Predbat will be using for its plan.
If I have debug HTML plan set, the bracketed value agree's with Trefor's formula.

So Trefor's defaults gives 0.97 x 0.96 x 0.96 x 0.97 =0.867 and 87%
0.04 for all gives 0.96 x 0.96 x 0.96 x 0.96 =0.849 and 85%
0.05 for all gives 0.95 x 0.95 x 0.95 x 0.95=0.815 and 81.5%
.... all within same ballpark.

From my annual solar production, only 10% went into my battery, 25% to my home and 65% to the grid, earning me £640 (to get me through Nov-Feb). So nearly all input into my battery is from the grid.

Rob

geoffreycoan I agree Geoff, have just done the same calc for Jan, Feb, Nov & Dec all of which have a lower solar input, and all give rubbish figures.
I'm using 0.4 and 0.5 on my plan

geoffreycoan Trefor has added the above FB post to the Predbat FAQ’s; the key thing I’d take away from this is the reminder that the inverter loss acts as a double-whammy as you get inverter losses on the way in and the way out of the battery, so be careful of increasing that too much.

And this is the crunch.

I have looked in the predbat FAQs and the section on losses is excellent, read alongside the main section on losses:https://springfall2008.github.io/batpred/customisation/#battery-loss-options

Losses depend on many factory and any values that we use are at best guesstimates. For me I think 0.04 for charge, discharge and inverter looks 'about right' ... to me.

Rob

Wavy Davy Same here. My Dec values from GE showed only a 10 kWh difference between charge and discharge, producing rubbish results.
I have looked at GE data sheets and for AC3.0, they claim 97% efficiency. Nothing against batteries.
Using the 'hand test', my inverter gets warm to the touch when really active, much more so than batteries. My Solar Edge PV inverter gets barely warm.
But my setup is in a nice environment where temperature is rarely likely to drop below 20C.

Rob

Rbor

I was on 5 all have changed mine to 4 all, looking at the evidence. Very interesting topic.

It would be even more interesting to see someone that has 2 x AIO’s and sets all 4 but gets different results because there in a different part of the country, so solar is not the same, it maybe colder, they use there battery more etc etc.

Rbor I have looked at GE data sheets and for AC3.0, they claim 97% efficiency. Nothing against batteries.

The batteries are probably close to 97% efficient at an ambient temperature of 25C. ie there's 3% chemical losses.

However that's a minor part of the losses. On a G1 Hybrid....

The charge/discharge circuitry in the inverter is around 85% efficient for AC charge and 90% for solar charge (full rate charge/discharge cycle).

Round trip losses for my usage are 15-20% although this is temperature and load dependent. Edit - they also appear to be increasing slightly as the system ages, but that's a subjective observation for now.

G2/G3 inverters are apparently somewhat better in terms of losses.

Rbor My setup is a gen 1 hybrid and like yours indoors (in a cupboard in the porch), the batteries are also in the porch in a alcove under the cupboard, so batteries never get below 10, generally runs about 15 to 20 in winter.
Invertor runs a bit hotter, 30 at the moment.
Useful in winter to keep the porch frost free.

geoffreycoan I read an article last week from Michael Podesta which I can dig out on how he measured his Tesla powerwall capacity year on year .....

I was reading this earlier and I really like his scientific approach, always presenting evidence:
https://protonsforbreakfast.wordpress.com/2025/01/10/powerwall-battery-degradation-winter4/
Michael has many other really interesting articles and well worth investigating.

Rob

@Rbor
@geoffreycoan

I have been monitoring things for the past few days and it looks like everything is back to normal.
There was an update for Octopus today, so took the plunge and updated, everything looks OK

I am not not sure about updating Predbat to v8.11.2. What’s you opinions please?
I do not need the temperature curve or settings in yaml.

If I don’t update and Trevor brings out the next update what do I do, as not been in this position before?
(Will the newest update e.g v8.11.3 contain the temperature things, so I can not get away with it?)
(Or can I install v8.11.3 and not worry about v8.11.2?)

Daveb01 I've updated and no issues except this
2025-01-20 16:25:02.232930: Warn: Historical day 2 has 25 minutes of gap in the data, filled from 9.85 kWh to make new average 10.02 kWh (percent 98%)
which started at 10:00 long before I did the update, so all good.

Rbor yes that's the article I was referring to. He writes some very interesting articles on heat pumps, batteries and solar panels. Packed full of analysis and detail. I've been a subscriber for a few months now.

Answering your question about 8.11.2 Daveb01 yes each predbat release builds on the one before so if you skip a version or two then when you do upgrade you get all the features of the releases in between.
I'm on 8.11.2 and seen no side effects, will be watching it tonight to see if it fixes some of the 'sawtooth' behaviours on low power charge that I was seeing on 8.11.0

@Rbor did you configure the temperature charge curve in apps.yaml when you upgraded or did you not bother given your batteries and inverter are inside the house? Just from the issues Dave had I was suspecting there might be an issue if the temperature curve isn't configured. I suppose I could remove my own config, but I need to test these fixes in 8.11.2 first

Dave probably worth you leaving it if you see no reason to upgrade and will give us the chance to check that predbat without temp curves being configured works ok

Wavy Davy I wouldn't worry about this.
I have seen this pattern often and I find that it works its way through the system until the historical day gap move from day to day until the end of the HA limit on historical day records (probably 10 days if you haven't changed this).
The warning should then disappear.

Rob

geoffreycoan @Rbor did you configure the temperature charge curve in apps.yaml when you upgraded

I have ignored the temperature curves entirely and haven't added them to my apps.yaml.
I judged that nothing would then happen.

In 'What's changed' for v8.11.0, Trefor has written:

Max charge rate temperature curve adjustments by @springfall2008 in #1869
This feature allows you to model temperature dependant charging and discharging of the battery.

I read this as the feature being optional and it was up to me to try it out if I wanted to and I have 'ignored' it. I have updated to v8.11.1 and then 8.11.2 and I haven't noticed anything untoward operating with no temperature curves..

..... I hope I am right! Do we need some guidance from Trefor here?

Rob

Rbor

I thought the same, that’s why I upgraded. Bit I was not expecting the issue, so as you know I have down graded.

So we have a good test on the go between the three of us (although we have different batteries)

1. I have not upgraded
2. Rob has upgraded but not changed yaml
3. Geoffrey has upgraded and updated yaml

Daveb01 correct summary of our situations.

And yes Rob, I believed it was optional to configure the temp curve stuff in apps.yaml, but Dave didn't and had random errors setting charge and discharge rate to zero so I wondered if it was connected

After you reverted Dave, Trefor posted this bug on GivTCP https://github.com/britkat1980/giv_tcp/issues/334 - wondered if this was the same error you saw?

Daveb01 Dave, like Rob, I've upgraded and not changed the yaml. As I have a Gen 1 Hybrid and its inside just ignored it.

Rbor Interestingly I sort of know the man he posted about ( https://protonsforbreakfast.wordpress.com/2025/01/05/gordon-edwards-1941-2025/ ).

Way way back in the 1990s a colleague of mine was working on the test/setup procedure for the monitors which went into the UK AWACs aircraft. Prime contractor for the consoles was Siemens and lets just say there was a BIG difference between German and English QA - ie they all got rejected by Siemens when the QA over here couldn't see a problem ("it's good enough" attitude which is still prevalent).

One of the many and varied issues was chromaticity - ie colour. Specifically white.

This ended up with NPL and my colleague investigating over the course of several months whether they needed to redefine what "white" was. The consensus was that they probably did but it'd take several years (if not decades) to get international agreement. At this point the German QA guys relented on chromaticity 😃

Daveb01 So we have a good test on the go between the three of us (although we have different batteries)

I have not upgraded
Rob & Davy have upgraded but not changed yaml
Geoffrey has upgraded and updated yaml

I'm on 8.11.1 which I believe includes the temperature curve stuff.

I've not edited the yaml.

Gen3 hybrid.

As far as I'm aware, no issues.

Oh no there is now an HA Core update. So what’s the plan guys?

Daveb01 Have a look at the readme and see if any of the bugfixes covers anything you care about. Probably not.

I will probably wait until the end of the month and upgrade to the last HA patch of the month, or may just wait until mid February and go straight to the 2025.2.2 release. There's no real benefit in taking every single patch upgrade and equally I think its prudent to wait for the first couple of releases of each version to come out to wash out any early bugs

Daveb01 The plan is to let @Daveb01 install it and see what happens. 😉

Leave it alone! Follow @"geoffreycoan advice above.
You don't need to risk a repeat of your panics last week. We have only just got you up and running after that.

I actually updated HA over the weekend and my system shows this:

So how am I supposed to work out whether I have the latest version of all these HA varieties?

So I don't know whether I am on latest version of Core (I don't see any HA update showing though).
Remember that I had issues with my history charts and ended up restoring back to previous version.

Out of all the updates we see, I have had more issues from HA updates than any other and I would prefer to leave them for a while.

When you do decide to update HA, take a full backup before before doing so.

Rob

I went for it!

Can anyone advise how you reduce or eliminate these 15m slots? Someone asked on facebook group but not getting anywhere - want to do the same. To reduce the “on off on off” in such short spans

pacemaker turn off 'calculate export within charge slots' - this stops most of the split export and charge slots

I tried that and it seems not do what I want. It eliminates the 15m slots but then doesn’t export anything at all because it’s cheap rate. I still want it to export, just in 30m increments (assuming that would reduce register writes too?)

From

To

Rbor I updated to latest version with no issues 🙂

geoffreycoan

to add to my last comment, I changed my plan calculation from 24 hours to 48 hours and its eliminated any planned export slots completely by using that setting. When I set it to 24 hours it at least had export slots following the charge (even though I have NO IDEA why it would plan to do that)