https://youtu.be/aipVIi_bKr0?si=CtWWxihYmbnH05DW
Useful explanation of Predbat and how the instructions to the inverter are stored.
Also the rated life span of the chip involved.
Worth a watch to understand the impact of too many writes to the inverter..
M_J Its also clickbait.
I have warranty until 2032. I dont believe there is anything in the warranty about number of writes
SteveCook That’s my view as well, the warranty covers the inverter and there’s nothing in the warranty about not using an external automation and indeed GivEnergy publish the API for you to use it as you want.
Its a valid point about high number of read/write cycles could brick the inverter but Oli’s particular concern came from his balancing software that runs every 30 seconds or so and tries to stop the inverters cross charging.
The highlight of Predbat is in my view misleading. Predbat runs every 5 minutes and only writes to the inverter when the inverter settings don’t match what the plan requires the inverter to be set to. So if the plan hasn’t changed or you haven’t manually changed the inverter settings, Predbat won’t write to the inverter and thus the risk is much reduced.
Its a genuine risk, but that’s what the warranty is for
Vestas Alas most YouTube videos are and if it was of no value then I would not have flagged it here.
For me I found it useful as it explained how the underlying architecture works on the GivEnergy AC inverter and made some useful points on if you over use it.
As for warranty well the company has to still be in business to honour it, and even if it is still around it's not a certainty it will honour it.
My problems with my inverter seem to occur when I have been "thrashing" it with attempts to maximise the export potential. Is that related? Who knows but it's food for thought for us who are trying to maximise the battery ROI...
Just my 2p and everyone has absolutely the right to take a different approach...
One question would be, when predbat makes a change, how many writes actually happen?
Eco mode would be two writes I think.
Going into timed export, would that be five writes? Start time, end time, percentage and two for turning off eco? Or is it one, four total?
But ultimately I agree, the video title was clickbait, and it doesn’t sound as bad as long as you have more modern firmware (RAM workaround) and things don’t change every five minutes, they only change when they need to be changed.
We (well me & @DD ) discussed this being a possible issue ages ago: https://github.com/hoggyhoggy/givenergy-modbus-async/issues/34
Had Givenergy not got all lawyery about it a good year or two ago then my teardown would have survived and everyone would know it runs on:
TX200 One question would be, when predbat makes a change, how many writes actually happen?
Eco mode would be two writes I think.
Going into timed export, would that be five writes? Start time, end time, percentage and two for turning off eco? Or is it one, four total?
I’ve been trying to work it out how many changes are actually being sent to the inverter. Setting charging or discharging on changes the start time, end time, target percentage, charge rate (optional) and enable charge/discharge schedule switch on - so 5 GivTCP controls in HA. Turning charging or discharging off just turns the schedule switch off I think.
Looking at the GivTCP log files for a few random days, the logs are not all that well formatted to make counting the number of writes easy, some commands have the command then a success message, some have just the command:
2024-11-26 00:21:51,295 - write - [INFO] - Setting Charge Target 34 was a success
2024-11-26 00:25:09,654 - write - [INFO] - Setting Charge Target to: 35
2024-11-26 00:25:11,424 - write - [INFO] - Setting Charge Target 35 was a success
2024-11-26 00:30:14,521 - write - [INFO] - Setting Charge Slot 1 was a success
2024-11-26 01:02:12,502 - write - [INFO] - Setting Charge Slot 1 to: 01:00 - 06:30
2024-11-26 01:31:59,444 - write - [INFO] - Setting Charge Target to: 58
2024-11-26 01:40:10,215 - write - [INFO] - Setting Charge Target to: 59
2024-11-26 01:41:51,664 - write - [INFO] - Setting Charge Slot 1 to: 01:00 - 07:30
2024-11-26 01:50:10,371 - write - [INFO] - Setting Charge Target to: 60
2024-11-26 01:55:10,829 - write - [INFO] - Setting Charge Target to: 60
2024-11-26 02:21:50,111 - write - [INFO] - Setting Charge Target to: 62
2024-11-26 03:22:16,338 - write - [INFO] - Setting Charge Slot 1 to: 01:00 - 07:30
2024-11-26 03:22:26,879 - write - [INFO] - Setting Charge Target to: 92
2024-11-26 03:32:26,444 - write - [INFO] - Setting battery charge rate to: 2600 (50)
2024-11-26 03:41:41,130 - write - [INFO] - Setting Charge Slot 1 to: 01:00 - 07:00
2024-11-26 03:52:23,823 - write - [INFO] - Setting battery reserve target to: 96
2024-11-26 04:30:19,045 - write - [INFO] - Setting Charge Slot 1 to: 04:30 - 07:30
2024-11-26 04:40:12,679 - write - [INFO] - Setting battery charge rate to: 725 (7)
2024-11-26 04:42:37,429 - write - [INFO] - Setting Charge Slot 1 to: 04:30 - 07:30
2024-11-26 06:02:01,310 - write - [INFO] - Setting battery discharge rate to: 2600 (50)
2024-11-26 06:02:09,557 - write - [INFO] - Setting battery reserve target to: 4
2024-11-26 08:00:09,893 - write - [INFO] - Setting battery reserve target to: 95
2024-11-26 08:31:43,444 - write - [INFO] - Setting battery reserve target to: 94Most days my GivTCP logs have about 100 rows in them, the lowest I found was 60, the highest 160, so I’d suggest about 100 commands is a fair daily approximation.
If the practical limit as suggested in the video is a million writes, this gives about 27 years.
I’m on Agile so will be doing far more writes than someone on IOG or Flux.
geoffreycoan 27 years - doesn't sound like an issue then...........
Leeshore Agreed. If there is a more accurate way of counting the number of inverter writes then I’d be happy to look further, but at the moment that’s my conclusion as well
This is my givTCP log from 5 am this morning.
Single AC3.0 inverter from August 2022, updated from inverters produced earlier in 2022.
The inverter can be used with 'new firmware' in givTCP3.
Firmware D0.205-A0.205 (latest for AC3.0) installed August 2024.
Charging two daisy-chained 8.2 kWh batteries
Running Agile.
2024-11-30 05:31:48,317 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 04:30 - 06:00 was a success
2024-11-30 05:31:48,815 - GivTCP - write - [INFO ] - Setting Charge Target 94 was a success
2024-11-30 05:31:49,316 - GivTCP - write - [INFO ] - Setting Charge Target 94 was a success
2024-11-30 06:00:12,482 - GivTCP - write - [INFO ] - Setting Charge Schedule to disable was a success
2024-11-30 06:00:12,982 - GivTCP - write - [INFO ] - Setting Charge Target 100 was a success
2024-11-30 06:00:13,474 - GivTCP - write - [INFO ] - Setting Charge Target 100 was a success
2024-11-30 13:30:11,855 - GivTCP - write - [INFO ] - Setting battery reserve 83 was a success
2024-11-30 13:30:12,320 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-11-30 13:30:12,344 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-11-30 13:30:12,885 - GivTCP - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-11-30 13:30:13,405 - GivTCP - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-11-30 13:34:12,381 - GivTCP - read - [ERROR ] - Battery Object empty so skipping
2024-11-30 14:00:13,665 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-11-30 14:00:13,692 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-11-30 14:00:14,217 - GivTCP - write - [INFO ] - Setting battery discharge limit 3000 was a success
2024-11-30 14:00:14,747 - GivTCP - write - [INFO ] - Setting battery discharge limit 3000 was a success
2024-11-30 14:00:15,243 - GivTCP - write - [INFO ] - Setting battery reserve 4 was a success
2024-11-30 22:04:44,013 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 22:30 - 23:00 was a success
2024-11-30 22:04:44,509 - GivTCP - write - [INFO ] - Setting Charge Schedule to enable was a successI don't know how many writes this has produced but nothing recorded for 8 hours: 2 pm-10 pm when it was on Predbat 'demand'.
Rob
I had a look at the video by Speak to the Geek, although I am new to Predbat, I am not worried.
His video was saying he has used Predbat to balance two batteries an old one and an AIO (his choice to do that) if he has written helpers and the likes to look at this balancing and it now has an impact on the life of his inverters and GE now know this because he has said it in public, then his warranty should be looked at.
I don’t think he should have named and shamed Predbat like that. If anyone has a setup that GE has not really approved or was really in there design it could be considered an issue.
If he has done a workaround to sort it and that’s what he wanted, it’s not really acceptable the rest of us should suffer.
End of rant (sorry it’s now officially Christmas 🎄🥂🍺)
Daveb01 His video was saying he has used Predbat to balance two batteries an old one and an AIO (his choice to do that) if he has written helpers and the likes to look at this balancing and it now has an impact on the life of his inverters and GE now know this because he has said it in public, then his warranty should be looked at.
It’s actually worse than that, he has written his own custom automation scripts to balance his AC3 inverter and his AIO so that they don’t cross charge. He does not use Predbat at all.
He has looked at his balancing scripts and identified that they could be impacting the life of his inverters and has assumed that Predbat could be doing something similar, so puts out a video to explain the issue and links it to Predbat.
There is no analysis of Predbat’s behaviour, only his own script behaviour.
There is according to the comments made by one other person on the video that 3 inverters have been reported as having failed due to excessive writes. Predbat is suggested to be linked to those cases but no more details than that. It is clearly a risk but not clear what inverters types they were, what firmware they were on, how Predbat was being used (was it alongside some other balancing automation, or somehow configured to be more aggressive), and was the failure actually excessive writes or just some other inverter failure.
As I said in my comment on the video, it’s misleading. I have asked if GivEnergy have more details of what inverters/firmwares are potentially are at risk of excessive writes.
geoffreycoan I thought it was a GivEnergy developer that wrote the balancing script and shared it on Facebook. The Geek then added it to home assistant and published how to do that.
TX200 IIRC it was the head of product testing Paul Landregan but I'm unsure whether he worked at GE at the time or not.
Like I said in the other thread, for those of us with G1 inverters installed prior to February 2024, this is a complete irrelevance as there's no "fair usage" mentioned in their Hybrid Inverter Limited Warranty 2021. Inverter dies due to flash memory failure = warranty repair. No ifs, buts or maybes.
As GE no longer "publish" warranty documents for hybrids, those of you with G2/G3 inverters installed prior to February 2024 should check your own documentation to see what the warranty exclusions are. Pretty sure it'll be the same as G1 inverters.
I see the title of the video (but not the thumbnail) has been changed from “Predbat Breaks Inverters! Extend the life of your home battery” to “Is Predbat Breaking Inverters? Extend the life of your home battery”
Better but still feel it could have been handled much better with engaging with Trefor before posting a clickbait video with an incomplete analysis of the causes of the problem. Could have had a much better story of ‘here’s what not to do and here’s what’s OK to do’.
Meanwhile we are left with an incomplete analysis of what inverters are affected, how real the problem is, and a promising that some time in the future there will be a firmware fix - all inverters, some inverters ? 🤷♂️
I’m not stressing about it, I paid for the inverter and batteries and plan to use them. If they do die prematurely then its a warranty replacement.
Vestas that was my recollection as well, that Paul L initially wrote and shared the AIO/non-AIO balancing script on Facebook and then Oli used/adapted it for his setup and made a video on what he’d done.
geoffreycoan I'm not commenting on the youtube thread but people there seem to misunderstand where this flash memory is. Its inside the processor die (ARM) so when that goes "pop" then so does the processor.
You and I have the earliest revisions of the design - and hence less wear capacity due to flash memory size. We're not getting any mitigation via f/w so you may be the canary in the coalmine regarding "normal" use of predbat, so to speak.
G2/G3 - who knows. They have different processors so....?
geoffreycoan Yep, as far as I know, it was Paul L and i am 99% sure that he now works for GE.
After combing through some facebook threads, I need a walk in the fresh air now that the rain has stopped before light disappears. Then I will hunt through FB contributions by Paul L to see if I can find out more about these 3 inverters, and check out the earlier Geek video on how to set up his original automation.
While he was changing the title to his controversial video, he should have removed Predbat entirely. He continues to justify it though.
Rob
Rbor 99% sure that he now works for GE.
He's worked at GE for a couple of years now.
Hi,
I have combed through all responses by Paul L in the GE-related facebook forums and I can see none that refer to flash failures linked to predbat.
The only evidence seems to be quotes in the comments to this video much as 'my sources at GE have told me' and 'there have been 3 cases ....'. But all just anecdotal. Were they trying to balance inverters using Geek's automation which he provided in a previous video?
It would be good to move forwards from this unfortunate episode.
Rob
3 inverters - that's not a massive sample. Is that the only 3 inverters they have ever had flash fail or 3 inverters that happened to be running Predbat, and there's a wider pool?
I don't deny that writing excessively would eventually finish these off (early Teslas fell for that too) but I'm unsure as to what the magical touted "improvement" is likely to be if stuff is already in RAM anyway.
(Some sort of EMS-Lite box - given the EMS already lobotomises the inverter and shifts all the actual thinking to the EMS is the solution to link even single units to one of these and run that instead (with a lot more flash to wear through?)
Wow Trefor has already updated predbat to 8.8.1 which logs inverter writes. How good is that.
Every real geek knows flash memory has limited write-erase cycles.
The inverter design is not simple. As hoggy points out there are 3 microcontrollers each with some flash memory. I don't know which flash is used for which purposes.
The DSP data sheet can be found here
https://www.ti.com/lit/ds/symlink/tms320f28069.pdf
and section 7.14 gives the flash endurance as minimum 20k cycles, typical 50k cycles.
Determining cycles is not as simple as counting register writes. The STM32 chip has 512k of flash organised into 8 sectors, 4 sectors of 16k, one of 64k, and 3 of 128k. Sectors can only be erased as a whole. We don't know how the firmware is organising the storage, but there will be many register writes per erase cycle.
In my humble opinion, and I may be wrong, if you keep to below 1 register change per hour (i.e. 24 per day) you will be fine.
My app in theory allows you to make one change every minute, but that is not the intended use. The examples I give for various tariffs, keep well within the 24 a day limit.
https://givenergymonitor.wixsite.com/tutorials/tariffs
My app is no different to Predbat in this respect. Anyone who piles more than 24 commands into the daily schedule does so entirely at their own risk.
hoggy Minor technical correction, the DSP (in my HY3.6) is running at 20MHz. The operating range is 2MHz to 90MHz, but the board I have is using the x1/x2 internal oscillator with a 20MHz crystal.
Does anyone know how frequently the meter data is saved to flash?
When you power off and back on your inverter, the meter values may "go backwards". This is because they are lost from memory and revert to the last values saved to flash. I think they might be saved once per hour, but not sure. Has anyone powered down their inverter and can look back at what happened to the figures? How far did they go back?
When the values go backwards it can really mess with the energy graph. If you power off near midnight it can result in some crazy numbers.
If we know how often the meter data is written to flash, we can use it as a guide for how often we can safely update settings held in flash.
Rubikcube Does anyone know how frequently the meter data is saved to flash?
I get the impression from the video and the discussion in the comments that the write to flash is more frequently than once an hour and its this frequency that is being suggested to be reduced. Wouldn’t surprise me if it is once every 5 minutes at the same time that the inverter sends the data snapshot to the GivEnergy cloud.
Rubikcube In my humble opinion, and I may be wrong, if you keep to below 1 register change per hour (i.e. 24 per day) you will be fine.
The problem with that is what you count as a “register change”. A start charging command requires several different bits of data to be sent to the inverter - the start time, end time, target charge % and then turn on ‘enable charge schedule’. Logically these would be different inverter registers.
It is suggested that due to the way the RAM cache and the flash is paged, a million writes is “ok”, but again how do you count what is a write and is that million a correct extrapolation of the hardware limits. You say minimum 20k writes, the video said 10k limit.
Too many unknowns.
There is a risk but I think it’s being escalated out of proportion. The author of the video had been hammering his inverter with cross charging control for months and hasn’t had it go pop, so I do feel we have some latitude for more typical charge/discharge control even on Agile. Trefor has made changes to improve Predbat and that’s a positive step forward
geoffreycoan You say minimum 20k writes, the video said 10k limit.
There are 3 chips in the inverter, one DSP and two ARMs. The data sheet for the DSP says 20k cycles, the data sheet for the ARMs says 10k cycles. The chips are made by different manufacturers.
Predbat v8.8.1 has been updated to reduce writes ( if they were writes...), Trefor has also released a YT video, and also included a write counter in the latest version, not sure if that's a daily count, or since v8.8.1 installed: 
I could not help myself & added a comment
Rubikcube Thanks for that - at least they are not running right at the extremes as well!
I never got much further into it (given I was warded to stop) so thought my time was better spent elsewhere!
Rubikcube I think with the super cap on the board it'll just hurriedly commit everything to flash on it's last gasp so perhaps hard hard to see it, but would be interesting to test.
The simplest solution for Giv (should RAM allow) would be to keep the charge power, times, all the stuff that Predbet etc change a lot in RAM and only ever write on loss of power for recovery later. (This might be what Giv are intimating as a solution? It's all very drip fed this, quite a lot by someone who doesn't actually work for Giv, so I'm always very cautious of comments on socials being the whole story.)
Although just saying that is the easy part...it's the making that part happen that the FW guys have to sort.
geoffreycoan The problem with that is what you count as a “register change”.
... and what counts as a register write?
I upgraded to v8.8.1 at 9:28 pm last night.
It is now 9:36 am the following morning, so a 12 hour snapshot.
So what does this mean?
givTCP logs from 23:57 pm
These show the type of register interaction.
2024-12-01 23:57:14,638 - GivTCP - write - [INFO ] - Setting Charge Schedule to disable was a success
2024-12-01 23:57:15,110 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-01 23:57:15,137 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-02 00:00:31,607 - GivTCP - read - [INFO ] - Midnight, so resetting Day/Night stats...
2024-12-02 00:01:03,015 - GivTCP - read - [INFO ] - Midnight, so resetting Day/Night stats...
2024-12-02 00:01:54,723 - GivTCP - write - [INFO ] - Setting Charge Schedule to enable was a success
2024-12-02 00:01:55,209 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-02 00:01:55,240 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-02 00:30:07,562 - GivTCP - read - [INFO ] - Saving current energy stats at start of night rate tariff (Dynamic)
2024-12-02 00:30:12,822 - GivTCP - write - [INFO ] - Setting Charge Schedule to disable was a success
2024-12-02 01:00:14,098 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-02 01:00:14,121 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-02 01:02:38,255 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 02:15 was a success
2024-12-02 01:02:38,754 - GivTCP - write - [INFO ] - Setting Charge Schedule to enable was a success
2024-12-02 01:02:39,231 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-02 01:02:39,257 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-02 01:42:33,324 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 04:00 was a success
2024-12-02 02:12:04,768 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 05:00 was a success
2024-12-02 02:22:10,528 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 05:30 was a success
2024-12-02 02:42:06,685 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 05:00 was a success
2024-12-02 03:02:05,116 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 04:50 was a success
2024-12-02 03:42:08,408 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 05:00 was a success
2024-12-02 04:00:22,756 - GivTCP - write - [INFO ] - Setting Charge Schedule to disable was a success
2024-12-02 04:00:23,236 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-02 04:00:23,260 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-02 04:30:21,876 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 04:30 - 04:50 was a success
2024-12-02 04:30:22,376 - GivTCP - write - [INFO ] - Setting Charge Schedule to enable was a success
2024-12-02 04:30:22,862 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-02 04:30:22,890 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-02 04:30:24,477 - GivTCP - read - [INFO ] - Saving current energy stats at start of day rate tariff (Dynamic)
2024-12-02 04:50:13,205 - GivTCP - write - [INFO ] - Setting Charge Schedule to disable was a success
2024-12-02 04:50:23,996 - GivTCP - write - [INFO ] - Setting Discharge Slot 1 to: 00:00 - 05:01 was a success
2024-12-02 04:50:24,751 - GivTCP - write - [INFO ] - Setting Timed Export mode was a success
2024-12-02 04:50:25,253 - GivTCP - write - [INFO ] - Setting battery reserve 86 was a success
2024-12-02 04:52:45,599 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 04:30 - 05:00 was a success
2024-12-02 04:52:46,086 - GivTCP - write - [INFO ] - Setting Charge Schedule to enable was a success
2024-12-02 04:52:47,114 - GivTCP - write - [INFO ] - Setting Eco mode was a success
2024-12-02 04:53:07,908 - GivTCP - write - [INFO ] - Setting Discharge Slot 1 to: 00:00 - 00:00 was a success
2024-12-02 04:53:08,398 - GivTCP - write - [INFO ] - Setting battery reserve 4 was a success
2024-12-02 05:00:12,186 - GivTCP - write - [INFO ] - Setting Charge Schedule to disable was a success
2024-12-02 05:02:11,518 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-02 05:02:11,543 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-02 05:12:11,537 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-02 05:12:11,564 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-02 05:22:12,117 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-02 05:22:12,147 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-02 05:27:57,776 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-02 05:27:57,803 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to Disabled was a successRob
hoggy it's the making that part happen that the FW guys have to sort.
...and of course that's not going to happen for G1 kit as its EoL.
Vestas My inverter is AC3.0 Gen 1 from August 2022 still being sold today.
This produced logs above.
I believe that there was an earlier version of the AC3.0 Gen 1 sold up to 1st half of 2022 with lower import and export.
Rob
Rbor All of the G1 hybrids are EoL. If GE can't make a business case for rolling out existing f/w (which prevented overvoltage on all batteries with the "10 step charge") then I can't see any business case in developing and rolling out f/w for edge cases such as flash failure due to "excessive" writes.
Plant maybe different but nobody with a G1 hybrid has seen a production release of f/w in over 3 years.
Vestas The ‘fast change’ firmware for G1 hybrids is out in beta, I’ve been running it very successfully since April and it’s a step up on 450/451. “Coming soon” as a production release but who knows when that will be given it is caught up in the issue that ‘old version’ Gen 1 hybrids can’t take the upgrade.
But getting back to the topic in hand, I’d expect that G1 hybrids and AC coupled are precisely the kit that GivEnergy would want to be targeting with these firmware upgrades as they are the ones with the older processors, less RAM and thus more likely to be at risk of fail. Also have been out in the field for longer so will have experienced more writes already.
And if not, then its a warranty claim if it fails.
Rbor Interesting, good that Trefor’s counting of operations correlates with the GivTCP logs.
My only slight concern is that this counts the number of ‘operations sent to GivTCP’; without pouring through the GivTCP code and checking the conversion from REST commands to modbus writes the assumption is that its 1 to 1. I doubt this is the case. Some operations such as set charge start and end will be almost certainly two registers
But its better than no visibility at all of the operations
Looking at the logfile it does show how Predbat could potentially be optimised to be less “changey”
2024-12-02 01:42:33,324 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 04:00 was a success
2024-12-02 02:12:04,768 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 05:00 was a success
2024-12-02 02:22:10,528 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 05:30 was a success
2024-12-02 02:42:06,685 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 05:00 was a success
2024-12-02 03:02:05,116 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 04:50 was a success
2024-12-02 03:42:08,408 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 05:00 was a successIt changed its mind several times about how long the charge period should be for. Probably the cost analysis was right on the edge of the benefits of charging or not
And then later on it repeatedly paused and resumed the battery (swapping in and out of Freeze Charge mode), twice.
Could have done this just once for half the period rather than swapping in and out:
2024-12-02 05:00:12,186 - GivTCP - write - [INFO ] - Setting Charge Schedule to disable was a success
2024-12-02 05:02:11,518 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-02 05:02:11,543 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-02 05:12:11,537 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-02 05:12:11,564 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-02 05:22:12,117 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-02 05:22:12,147 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-02 05:27:57,776 - GivTCP - transparent - [CRITICAL] - Function code 86 recieved. Gracefully handled
2024-12-02 05:27:57,803 - GivTCP - write - [INFO ] - Setting Battery Pause Mode to Disabled was a successI suspect Trefor will be looking at this further now he has more data to analyse. And doubtless more Github tickets!
All to the good of course
geoffreycoan And then later on it repeatedly paused and resumed the battery (swapping in and out of Freeze Charge mode), twice.
Could have done this just once for half the period rather than swapping in and out:
Looks like this has already been reported https://github.com/springfall2008/batpred/issues/1681
geoffreycoan The "fast response" f/w has existed for over 18 months now. There isn't going to be any production rollout.
Pretty sure I said this before but GE can't see a business case for doing it and frankly if they were willing to take the hit on damaged batteries (no 10-step charge on old f/w) then the hit on bricked inverters is going to be orders of magnitude lower.
I rather wonder if what we're speculating about in terms of "f/w flash/cache update" is actually a f/w update for AC plant which may currently be running with two inverters and running a balancing script.
I also note that the "new" battery pause options we got with 191/193 are not persistent* so aren't written to flash. Can't help wondering (in retrospect) if those options were included for balancing dual inverters. If so then this isn't a new issue as 191/193 dates back to summer 2023.
*it defaults to disabled on reboot
geoffreycoan I plan to look at correlation (if any) between givTCP instruction, Trefor register count and status change using time as the link. Will report here when done. I need to look at this latest GitHub issue as well.
Could you switch on balancing inverters just to see how 'Trefor registers' are affected, givTCP instruction and status change? And then switch it off again once you have some evidence.
Have you been able to install v8.8.1?
Rob
geoffreycoan RE: is a "Predbat Write" 1 write or more...
It depends. I don't know enough about how Predbat works but underneath the library may or may not be doing multiple writes. Particularly around setting times & enabling / disabling discharge will most certainly be writing to more than 1 register.
A very rough example would be if it is calling "setChargeTarget" which to Predbat would look like 1 call/write, but depending on what the value is, will potentially be writing to 2 registers underneath GivTCP in the library itself.
Add on setting charge times as well (I'm assuming Predbat doesn't just set the times to 00:00-23:59 once and then toggle AC charge on and off based on an internal timer when needed? again I don't know enough about it.) and you have a few more there.
Vestas Looking on GE knowledge base, I see that hybrid Gen 1 hasn't received any firmware update since 14/10/2021 (D450-A451) and since then Gen 2 and Gen 3 appeared. Not good and the hybrid Gen 1 is definitely eol.
An upgrade to AC3.0 Gen 1 has never appeared and this inverter has received several firmware updates since I received it in Aug 2022.
In Aug 2023, the update added pause. In Feb 2024, some support for EMS was added.
I am on A205-D205 introduced in May 2024. This actually qualifies for 'new firmware' within givTCP2 and 3.
The niggle with the AC3.0 is that it hasn't been updated to say an AC5.0. But I guess, if it had, it would have followed the same fate as the hybrid Gen 1. I have two batteries and could get a 2nd AC3.0 (old technology) with 1 battery on each – expensive and I would be in the 'balancing inverters' scenario.
GE's eggs seem to be in the AIO basket although that will shortly enter Gen 1 and Gen 2 territory.
Rob
A quick question please. As I have 2 x AIO’s and the instructions are going via the GW does this change things around a bit?
Also would the count be the same so instruction to GW, GW instruction to each AIO? If that makes sense.
Daveb01 As you say the GW sends all instructions on to the connected AIO’s, so in theory the update count is the same for each device - the GW, AIO1 and AIO2.
But I think the GW does a bit more than that doesn’t it, it balances the two AIO’s so they both charge and discharge evenly? So this to me would imply that the GW is sending additional controls to the AIOs itself of which there is no external visibility (e.g “AIO1 pause discharging as the SoC on AIO2 is a bit higher”, then once AIO2 has dropped to match AIO1, the pause is stopped).
Without a clear statement from GE, we are guessing really as to what is affected and by how much. I would expect the AIO’s being newer kit have more memory and thus less likely to suffer this issue and probably have better caching of operations with more RAM.
Rbor Could you switch on balancing inverters just to see how 'Trefor registers' are affected, givTCP instruction and status change? And then switch it off again once you have some evidence.
Have you been able to install v8.8.1?
I haven’t upgraded yet, still running on an older version and I plan to stay on this until I get back from France (another week or so now). There are some screen shots of the way the inverters are behaving with the balancing code on the issue I logged a few months ago https://github.com/springfall2008/batpred/issues/1397 - basically the inverter charge rate gets swapped between maximum and zero to start and stop the balancing activity. It runs every minute, doesn’t make a change every minute, but most minutes it does, so probably 50 or so writes an hour all through the night.
I did experiment with setting pause charge https://github.com/springfall2008/batpred/issues/1031 to do the balancing, and a simple setting pause charge when there’s no solar forecast (and not doing grid import) works quite well with obviously minimal inverter writes. Interesting that the pause command isn’t saved to flash memory, seems fair to me
geoffreycoan I am well on with checking across status, registers and givTCP. News will follow at some time!
Pause seems to match 1 Register change
Rob
hoggy Add on setting charge times as well (I'm assuming Predbat doesn't just set the times to 00:00-23:59 once and then toggle AC charge on and off based on an internal timer when needed? again I don't know enough about it.) and you have a few more there.
No predbat doesn’t do this. One of the design ethos is that it sets the commands in advance to the inverter so it doesn’t rely on Predbat running and having to initiate the planned charge/discharge. As much as anything else this improves accuracy of executing the plan, e.g. you want to charge from say 01:00-01:30, then if you send the commands to the inverter at 12:00 then the inverter will automatically start charging itself at 01:00.
Alternatively if you rely on Predbat to toggle the AC charge on/off, then chances are that the charging won’t start until 01:01 or 01:02 because it takes Predbat a few minutes to re-evaluate the plan each time it runs, and sending the inverter commands happens at the end of the plan evaluation.
What this does mean is that it has to send the start and end time and charge target /battery reserve for each charge / discharge operation which increases the write operations quite a bit, especially if the plan keeps being refined as I highlighted above
geoffreycoan See attachements. I tried to save as xlsx and csv files but no luck.
So 2 screenshots.
And there's another screenshot showing Trefor's register changes for my setup, starting from when I upgraded to v8.8.1 at 21:28 last night.
I hope that there is some sense here. If it's garbage, just ignore!
Now to look at your earlier GitHub links.
I was really trying to see if there was correlation between status changes, Trefor's register changes and givTCP lines, especially givTCP calls and leaps in register calls.
It was sometimes difficult working out the time for Trefor's register changes.
Rob
Rbor Looks very much that they correspond 1 to 1 of GivTCP log file entries to Predbat’s recording of “register writes”.
So notwithstanding that some of those writes are as discussed above actually written to multiple registers, my estimate of circa 100 writes (GivTCP log file entries) on my current Predbat version gets to the “million writes limit” in 27 years which doesn’t worry me. The new Predbat reduces this further, all good.
Do feel it’s a storm in a teacup for most Predbat users, even those on Agile. Only risk area is if you are doing inverter balancing which by its nature is going to be writing a lot of commands to the inverters to shut and start them up from cross charging.
geoffreycoan Only risk area is if you are doing inverter balancing which by its nature is going to be writing a lot of commands to the inverters to shut and start them up from cross charging.
Though if the pause mode is not written to flash, as suggested earlier, that could be implemented in a safe way.
I'm on agile, had 9 writes since 1030hrs (when I upgraded)
I wonder if we multiply that by 3, would that be about right for the average number of registers changed per predbat write?
Some might just be 1 (e.g. percentage target), others might be five (e.g. charging instructions).
With regards to inverter balancing, I think Oli now sets one of his inverters to do a constant discharge to cover part of his house base load. Plus stops it discharging on sunny days. Plus force charges it off peak.
Maybe predbat could offer a similar method for balancing. Not a concern for me, just the one inverter, but throwing the idea out there.
TX200 I don’t think you need to multiply the Predbat writes by 3 to get to the registers changed.
Charging for example is 3 distinct GivTCP settings: set charge start and end time, set target, enable charge schedule.
These (per Rob’s analysis above) appear as 3 in the predbat count and 3 in the givtcp log.
Probably these all map 1 to 1 with inverter registers except for charge start/end time which maps to two. This is a guess though, would need to check the code to be sure.
DD if the pause mode is not written to flash, as suggested earlier, that could be implemented in a safe way
Agreed, if the pause mode is universally not written to flash rather than it being a Gen 1 hybrid 191/193 special kludge, then using pause mode would be a great solution for balancing. Predbat’s current balancing logic just changes the battery charge rate up and down and doesn’t use pause mode (pointed out in my github ticket of a few months ago).
At the moment I just live with the cross charging. In winter with the heat pump so higher consumption, its much less prevalent as both batteries are supplying the house load. It’s in the summer I get cross charging when one inverter discharges and the other charges up so I end up with one full and one empty battery. Its not a runaway cross charge, generally fairly gentle so I tend to live with it at the moment.
TX200 I now have exactly 24 hours on v8.8.1 and you can see my logs up to 12:30 pm a couple of posts ago. With just one inverter, I am not into balancing inverters.
At 21:28 pm, the logs were identical as I had been solidly on 'demand' for 9 hours with no register writes.
My conclusions from comparing Status values, Register counts and givTCP logs are:
NOTE. Out of 55 givTCP lines, 12 were 'transparent' and a further 4 were linked with change of time at end of the day, around midnight. So the 'relevant' givTCP calls might only be 39.
The 55 register writes might reflect more than one register change per write.
I will continue monitoring and, as always, please alert me if any of my conclusions are wrong. I am trying to learn but getting to grips with HA and predbat takes a long, long time.
EXTRA NOTE. Would a hybrid inverter potentially have more flash register writes than AC coupled to account for the PV side of things? My separate solar inverter deals with that side of things.
Rob
geoffreycoan Linking your reply with my contribution written at the same time:
My 12 'transparent' lines were all followed by a pause line. If pause doesn't count, there would be 12 fewer writes (although comparing givTCP log with Trefor's registers suggests that there is 1 register write for transparent + pause). Some of the pause lines match freeze charge/discharge.
I included the 3 * scenario.
Either way, for typical predbat use, I don't see an issue at all.
But Trefor is still trying to do as much as he can to minimise register writes. Truly amazing.
Rob
Vestas I also note that the "new" battery pause options we got with 191/193 are not persistent* so aren't written to flash.
This statement is only true if GE firmware is bug free!!
Suppose the main copy of the registers is held in RAM and somehow flash is used as a backup. The code somewhere will say that when any register is changed, write the new information to flash. There will also be some other bit of code that runs at startup. Suppose that code has "for i in 0 to 179" ... to load the registers from flash into RAM. And suppose that whoever changed the code to add the new registers didn't realise the startup code needed changing too. Easy error to make.
The old inverters had 180 registers and the newer ones 360 registers I think. Pause mode is register 318 apparently. Out of interest are any of the new registers (for the extra slots, etc) persistent over a restart?
Addendum for C programmers: for(int i=0;i<180;i++)
Rbor NOTE. Out of 55 givTCP lines, 12 were 'transparent' and a further 4 were linked with change of time at end of the day, around midnight. So the 'relevant' givTCP calls might only be 39.
Looking again at your spreadsheet from earlier, some of the counts don’t quite line up properly, eg 19 and 22. Possibly just inconsistent layout because 26 includes the count of the changes from 22.
Anyway, what I was going to say is that its hard to tell what the ‘transparent’ correspond to, it looks like GivTCP is receiving a command (86) from Predbat that its ignoring. Whether it should be ignoring, or it’s a Predbat problem, not clear.
The midnight and start of night stats are functions in GivTCP I believe, as well as the ‘total’ and ‘today’ sensors in HA there are night and day rate sensors that are not a lot of use for us, this is GivTCP doing housekeeping
geoffreycoan I will check back at my data and intend to continue monitoring.
Foolishly, I was reading each value from Trevor's register write chart and have just discovered that I can download as a .csv file after selecting 'see more'. That will speed things up and should get rid of values and times that I was trying to align by eye. I also wondered whether there was an initial rush of register writes following my update to v8.8.1.
As another snapshot, from 9 am yesterday to 9 am today, I have gone from 51 to 81 writes: 30 in 24 hours. My batteries were not 'exercising' that much (e.g. charge on, off, off, etc in short length of time) but it did include an overnight.
It would be really good to know how flash writes corresponds to register writes for different instructions, especially charge, discharge and pause.
Is it worth me flagging command 86 as a potential predbat issue, together with 'transparent'? Do you get these with your v2.4.9 setup? (I suspect not as I think they appeared with givTCP3).
The 'CRITICAL' command 86 transparent line always precedes a pause instruction.
When you get back, it would be interesting to compare register writes with v2.4.9 before you upgrade. When you do upgrade go for givTCP 3.0.4 which seems to be the 'most stable' version.
I watched the Geek video again last night and he seemed to really want to trash predbat towards the end, wanting to blame it for his self-inflicted balancing automation, which he had published for others to use ('at their own risk'). I have seen some posts where some has been put off using predbat because of this. Not good to destructively criticise. The contest with Trevor's humility is his video is significant.
Rob
Rbor the Critical 86 thing is not a Predbat issue, it's an inverter firmware bug which shows it's hand in certain situations.
As for the vid, like bug bounties or just common courtesy, contact really should have been made to Trefor before releasing it rather than broadsiding him. A far more useful process where Trefor could have even joined in near the end and explained variations mitigations implemented/roadmap would have turned this on it's head.
(which would actually then align with this comment if that were the case: "I should add that whilst clicks and likes are great, my primary motivation here is one of education and helping to extend the lives of inverters")
Not to trash talk too much but I believe the other videos of his Giv install when the AIO first went in have the "paid promotion" banner. To what extent (if any) said install was contributed by the sponsor we'll never know but something to bear in mind.
hoggy To what extent (if any) said install was contributed by the sponsor we'll never know but something to bear in mind.
I've always viewed him as GE's paid mouthpiece.
Vestas Tref has fired on a counter which is showing people having 200+ cycles just to do a timed charge from 0030-0530... That's some pretty naff coding if you ask me. 228 cycles a day you hit MTBF within a decade. I can manage that charge with 0.
There was even someone on FB yesterday that's burnt out their gen1 using balancing.
So think what you like, but he's spot on.
SteveCook there's a statement about fair wear & tear. You might find that having software that does excessive writes goes against that 
Sharticus
If it ever goes bad, I may have to test it in law.
That's a bit like saying dont do too much typing on your laptop keyboard in case you wear it out and invalidate the warranty!
I think they would struggle, for one, how could they prove it
SteveCook easily, 3rd party commands are saved in the portal, that's how they figured out it was predbat that's killed inverters already.
Sharticus OK , I get that 3rd party commands are saved in the GE portal, that makes sense, but how can that be tied back to predbat?
If too many writes can be considered excessive wear then it should be defined. I would suggest that definition is too loose to stand up.
Sharticus So think what you like,
I thought that of him before all this - simply because he's always banging on about GE.
If it were Tesla he'd be their paid mouthpiece, etc etc.
There may be people on youtube who aren't trying to monetise their "content" one way or another but I've yet to see them. Likewise there may be people happy to promote a given product/manufacturer on youtube for free, but again I've yet to see them.
In terms of the problem - its entirely GE's problem warranty-wise, they won't get anywhere arguing that the end-user "abused" the product when there was no warning that any issue existed prior to purchase, nor was there any reasonable expectation that there would/may be an issue.
Might be helpful to think about it as a video recorder* which can only record a certain number of programmes before going pop. If there was no explicit warning to the end-user that this would be the case before purchase then you cannot enforce that as a warranty exclusion after purchase. The customer would rightly argue that they may/would have chosen a different product had they known the limitations.
tl;dr GE don't have a leg to stand on re warranty exclusions
*similar sort of lifespan expectation
Hi all, I took the plunge this morning as had another update as well from Solcast. Am now on Predbat 8.8.1. I can not find the new reading on how any events are written?
Any idea where to look please?
Daveb01
predbat.inverter_register_writes
Sharticus Tref has fired on a counter which is showing people having 200+ cycles just to do a timed charge from 0030-0530... That's some pretty naff coding if you ask me. 228 cycles a day you hit MTBF within a decade. I can manage that charge with 0.
It’s not the experience of inverter writes that I and @Rbor are seeing from analysing our logs.
My guess and I haven’t seen the - presumably Facebook - conversation about this, is that it’s the coding for IOG that isn’t optimised. I guess that it treats each IOG block as an individual standalone charging period and sends commands to control the battery charging for that block. So hence why overnight you get a lot of writes from a lot of IOG sessions.
I’m sure it will be quickly improved.
The comparison of “I can manage the charge in 0” isn’t the same at all. You can set a scheduled charge to run every night and then it doesn’t need any inverter commands. Predbat isn’t doing that, it is a generic system that runs every 5 minutes to generate and execute an OPTIMAL inverter battery plan that MINIMISES your import bill, regardless of what tariff you are on. That optimal plan takes as input your predicted house load in 5 minute segments across the next day, the predicted solar generation, the import and export tariffs you are on and from all that data it generates and executes the best plan. For IOG it will handle both regular IOG slots and any ad-hoc IOG slots that Octopus give you, ensuring that your battery does’t discharge into your car when the car is charging.
So think what you like, but he's spot on.
He identified a risk yes based on his own custom inverter balancing scripts which he highlighted could have burnt out his inverter with its excessive writes, but didn’t do any analysis of what Predbat does nor attempt to discuss the issue with Trefor beforehand. He just assumed Predbat did something similar. He doesn’t even use Predbat.
Daveb01 easiest way is to go to entities and type 'reg' in search field. Will be invested to see you reg writes. Update from me before 10 pm showing my 2 days of data.
…. And Trefor is doing more work to try improving things even more, and all for us.
Rob
Weasel predbat has a pattern which it writes, that won't be difficult to identify in logs
Vestas why not compare it to a graphics card, designed for playing games. Yet people do mining on them, that leaves very specific usage patterns in it and manufacturers deny warranty claims when they die. Perfect example.
Sharticus graphics cards are a bad example really because most decent graphics card warranties specifically exclude claims arising from mining as it’s classed as commercial use. GE warranty description is much more generic and open to interpretation.
Goshiki2 no, it's a spot on example. Graphics didn't exclude mining originally, many managed to get cards replaced under warranty, but when the failures started happening more and more it was deemed as commercial use and the rest is history. Givs warranty has a fair use clause, there's been a few inverters replaced already but now 3rd party changes are being logged is it such a big stretch to see what can happen next?
But sure, those 200+ cycles during a fixed time charge might earn you an extra 3p a day.
On the subject of unnecessary writes... The official givenergy app now gives me access to all 10 charging timeslots. If I change just one value, it sends updates for the entire set to the inverter: my app records writes to registers (because the acknowlegement is sent to all connected clients), and I see:
holding reg HR_94 now 0
holding reg HR_95 now 0
holding reg HR_96 now 1
holding reg HR_242 now 100
holding reg HR_243 now 2
holding reg HR_244 now 530
holding reg HR_245 now 100
holding reg HR_246 now 0
holding reg HR_247 now 0
holding reg HR_248 now 98
holding reg HR_250 now 0
holding reg HR_251 now 100
holding reg HR_252 now 0
holding reg HR_253 now 0
holding reg HR_254 now 100
holding reg HR_255 now 0
holding reg HR_256 now 0
holding reg HR_257 now 100
holding reg HR_258 now 0
holding reg HR_259 now 0
holding reg HR_260 now 60
holding reg HR_261 now 0
holding reg HR_262 now 0
holding reg HR_263 now 75
holding reg HR_264 now 0
holding reg HR_265 now 0
holding reg HR_266 now 60
holding reg HR_267 now 0
holding reg HR_268 now 0
holding reg HR_269 now 50As promised, here is my breakdown after 2 days (48 hours). I have tidied up yesterday's data.
I am now on 88 register writes after 48 hours, so I am averaging 44 per day.
This system won't allow csv files or even txt files to be uploaded so it has to be screenshots as before. See below.
There is a really good correlation between Trevor's register writes and givTCP logs.
In first day, I had 55 registers writes.
Rob
Rbor good for you, but you aren't everyone.... Again, 3 dead inverters and countless examples provided by others of 200+ writes to do a fixed time charge.
Rbor oh and just remember the predbat count is just the instructions it sends to GivTCP, not what actually happens. Plenty instructions are 2 or 3 commands.
Sharticus Can you let us know when you have written your own general purpose battery management software for GivEnergy and other battery systems? So we can all jump on board and use it.
Trefor has done a great job of writing something for his own use and then extending and expanding it for the general community to use. It did the job and many people were happy to use it and to add to the community with identifying bugs and feature requests. Trefor has continued to enhance and extend Predbat considerably.
Just to put some balance into this issue, until a few days ago there was no suggestion being made anywhere, certainly not from GivEnergy that there as an inherent inverter limitation of write commands to the inverter.
As DD highlights above it seems GivEnergy are just as guilty of not thinking about inverter writes in their app.
Oli has quite rightly raised a potential risk with the hardware and that’s shone a light on something that hasn’t up to now been a concern for anyone.
Despite the (I believe) ham-fisted way he did this, Trefor has released a new version within a day with instrumentation to identify the issue and improvements made.
Following that instrumentation being out there, more issues have been identified and people are trying Trefor’s further improved version already.
I’m not saying that Predbat is perfect, no software ever is, but he is an enthusiastic developer and we should try to give the guy a break. He’s written some great (totally free) software that a lot of people are using but if you don’t want to use Predbat or think that it will possibly break your inverter, then fine, there’s no compunction for you to do so. If you want to produce an alternative to Predbat then feel free to do so.
Sharticus Your 12th really positive comment(and second name) since joining the community 16 hours ago. I'd go back on X if i were you.........
Leeshore
I noticed a new user pop up in the Octopus forum yesterday with a very similar agenda " you'd drink Trefors p*ss if he bottled it " was one their contributions.
I'm on agile and so far averaging 40 writes a day according to the new counter thing.
I'm wondering if the issue with the 200+ writes is due to the way Intelligent Octopus Go works.
Does Octopus announce the slots, over the API, in 30 minute chunks, next tariff change at 12am, or does it say next tariff change is at 5.30am.
In an ideal world it would just set one instruction, charge to 100% between 2330 and 0530.
I guess sometimes you might want to leave room for solar, but with 15p export it probably makes more sense to export excess solar.
I guess the easy fix is to turn on combine slots, although not everyone would think about that.
Would be interesting to see what impact that has on writes.
There's also Intelligent flux and others. I wonder what Givback does.
It would be good to see givTCP log posted from anyone on Intelligent Octopus Go
or similar. Mine is posted for Agile Rbor.
I have just looked at my latest register writes and, in the last 20 hours, I have gained 21 writes.
I have also looked at the GE portal to compare with evidence from DD. I will compare this with givTCP logs.
As above, can anyone with AIO post some givTCP logs to get some idea of writes?
Rob
Sharticus The manufacturers had to write SPECIFIC clauses in their warranty regarding mining. Prior to that attempts to deny warranty claims failed. Ask Asus about it. Ask PNY. Ask MSI. Ask any NVidia manufacturer who sold in the EU....
Frankly GE's reputation is so far into the toilet already this is just the cherry on the cake. Shonky batteries, shonky inverters, shonky firmware, retrospective changes to charging behaviour and on and on. No bloody wonder Octopus binned them!
Its perfectly obvious that GE were unaware of the issue until recently and the issue is a design defect. Just goes to show how little the UK staff understand the products.
geoffreycoan you are aware that Giv have said they have been working on a solution? So it's been known longer than the video.
Thank you, found it. I was going to add it under status of this card but no ID to add it 🙁 (yet)
Here is my graph so can use this, however as Geoffrey said my system is also balancing my 2 x AIO’s via the GW using GE software & I cannot see that reading (yet).
I would love to see Speak to the Geek graph to compare? Purhaps we should ask him to show us 48 hrs worth?
Daveb01 it would be blank as he doesn't use predbat.
Daveb01 Thanks for this and also from 2 x AIO running Agile.
17 writes but we don't know how many register interactions this is.
Download the givTCP log (last 100 entries is plenty) and compare with my screenshots posted earlier.
Most of my activity overnight in givtcp log is alternating between Charging and Pausing.
Predbat status shows Charging and Freeze charging.
Looking at mine overnight for same time slot as in your chart, I also had 17 register writes.
Rob
Vestas so by looking at the evidence of dead inverters I get called a sock puppet. Great community.
geoffreycoan My guess and I haven’t seen the - presumably Facebook - conversation about this, is that it’s the coding for IOG that isn’t optimised. I guess that it treats each IOG block as an individual standalone charging period and sends commands to control the battery charging for that block. So hence why overnight you get a lot of writes from a lot of IOG sessions.
IOG user (and battery thrasher) here. I updated yesterday afternoon, see below. Is there somewhere that Trefor is collating feedback?
TX200 Does Octopus announce the slots, over the API, in 30 minute chunks, next tariff change at 12am, or does it say next tariff change is at 5.30am.
I would think they would do it in 30 min chunks - consistant with the most granular pricing frequency we currently have - would keep it simple for the developer as well
2024-12-02 20:00:11,474 - GW - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-02 20:00:11,936 - GW - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-02 20:00:12,398 - GW - write - [INFO ] - Setting battery reserve 5 was a success
2024-12-02 20:30:11,290 - GW - write - [INFO ] - Setting battery reserve 90 was a success
2024-12-02 20:30:11,760 - GW - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-02 20:30:12,230 - GW - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-02 20:30:12,751 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 20:35:12,003 - GW - write - [INFO ] - Setting battery reserve 89 was a success
2024-12-02 20:35:12,520 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 20:37:09,274 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 20:40:11,342 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 20:45:11,628 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 20:47:05,371 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 20:50:10,921 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 20:55:11,224 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 20:57:04,888 - GW - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-02 20:57:05,356 - GW - write - [INFO ] - Setting battery reserve 5 was a success
2024-12-02 21:30:10,338 - GW - write - [INFO ] - Setting battery reserve 88 was a success
2024-12-02 21:30:10,802 - GW - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-02 21:30:11,318 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 21:35:11,100 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 21:37:00,549 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 21:40:11,405 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 21:45:11,439 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 21:47:01,903 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 21:50:11,751 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 21:55:12,016 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 21:57:01,507 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:00:11,912 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:05:12,331 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:07:03,752 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:10:13,159 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:15:10,476 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:17:01,952 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:20:11,364 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:25:11,663 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:27:01,213 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:30:12,527 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:35:11,814 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:37:00,354 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:40:10,734 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:45:12,823 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:47:01,361 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:50:10,432 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:55:11,241 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 22:56:58,746 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:00:11,132 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:05:11,219 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:07:12,054 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:10:13,129 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:15:11,412 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:17:12,219 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:20:11,402 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:25:11,661 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:27:10,390 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:30:11,479 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:30:14,853 - AIO-1 - read - [INFO ] - Saving current energy stats at start of night rate tariff (Dynamic)
2024-12-02 23:30:15,282 - AIO-2 - read - [INFO ] - Saving current energy stats at start of night rate tariff (Dynamic)
2024-12-02 23:35:11,777 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:37:11,502 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:40:11,546 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:45:11,877 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:47:11,692 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:50:11,770 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:55:13,064 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-02 23:57:15,345 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:00:35,382 - AIO-1 - read - [INFO ] - Midnight, so resetting Day/Night stats...
2024-12-03 00:02:03,436 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:05:10,766 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:10:10,966 - GW - write - [INFO ] - Setting battery reserve 89 was a success
2024-12-03 00:10:11,495 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:12:01,020 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:15:11,389 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:20:11,610 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:21:59,083 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:25:11,435 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:30:11,720 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:32:02,258 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:35:10,586 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:37:10,054 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:40:11,421 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:45:10,812 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:47:02,331 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:50:10,187 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:55:12,951 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 00:57:03,500 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:00:11,073 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:05:10,749 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:06:46,209 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:10:10,102 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:15:10,391 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:16:47,878 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:20:11,336 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:25:11,682 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:26:46,123 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:30:11,474 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:35:10,797 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:36:48,364 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:40:10,747 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:45:12,060 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:46:48,646 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:50:11,026 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:55:10,317 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 01:56:45,754 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:00:11,590 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:05:11,651 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:06:47,104 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:10:11,992 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:15:11,301 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:16:46,472 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:20:10,321 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:25:10,662 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:26:45,101 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:30:11,536 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:35:10,798 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:36:46,238 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:40:10,628 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:45:10,883 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:46:46,293 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:50:10,715 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:55:13,037 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 02:56:48,477 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:00:10,886 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:05:12,185 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:06:49,646 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:10:11,212 - GW - write - [INFO ] - Setting battery reserve 90 was a success
2024-12-03 03:10:11,733 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:15:10,816 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:16:46,323 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:20:10,741 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:25:11,596 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:26:47,172 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:30:11,517 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:30:22,271 - GW - write - [INFO ] - Setting Charge Slot 1 to: 03:30 - 05:00 was a success
2024-12-03 03:30:22,739 - GW - write - [INFO ] - Setting Charge Schedule to enable was a success
2024-12-03 03:30:23,199 - GW - write - [INFO ] - Setting battery reserve 5 was a success
2024-12-03 03:35:10,953 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:36:48,380 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:40:11,277 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:45:11,580 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:46:46,790 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:50:12,420 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:55:12,716 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 03:56:47,941 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:00:21,541 - GW - write - [INFO ] - Setting Charge Schedule to disable was a success
2024-12-03 04:00:22,001 - GW - write - [INFO ] - Setting battery reserve 100 was a success
2024-12-03 04:00:22,519 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:05:10,599 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:06:48,028 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:10:14,647 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:15:10,712 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:16:48,191 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:20:11,559 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:25:10,831 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:27:05,607 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:30:11,716 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:35:11,483 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:36:49,398 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:40:10,757 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:45:11,527 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:46:50,075 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:50:11,448 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:55:10,828 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 04:57:07,610 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 05:00:10,643 - GW - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-03 05:00:11,102 - GW - write - [INFO ] - Setting battery reserve 5 was a success
2024-12-03 05:30:08,505 - AIO-2 - read - [INFO ] - Saving current energy stats at start of day rate tariff (Dynamic)
2024-12-03 05:30:19,874 - AIO-1 - read - [INFO ] - Saving current energy stats at start of day rate tariff (Dynamic)
2024-12-03 05:57:06,815 - GW - write - [INFO ] - Setting battery reserve 99 was a success
2024-12-03 05:57:07,286 - GW - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-03 05:57:07,812 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 06:00:11,100 - GW - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-03 06:00:11,568 - GW - write - [INFO ] - Setting battery reserve 5 was a success
2024-12-03 12:28:02,118 - GW - write - [INFO ] - Setting battery reserve 100 was a success
2024-12-03 12:28:02,586 - GW - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-03 12:28:03,105 - GW - write - [INFO ] - Setting battery discharge limit 0 was a success
2024-12-03 12:30:11,795 - GW - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-03 12:30:12,269 - GW - write - [INFO ] - Setting battery reserve 5 was a success
2024-12-03 21:30:10,621 - GW - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-03 21:55:11,126 - GW - write - [INFO ] - Setting battery charge rate 9990 was a success
2024-12-03 22:00:11,431 - GW - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-03 22:30:11,267 - GW - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-03 23:00:11,137 - GW - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-03 23:30:10,250 - GW - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-03 23:30:17,051 - AIO-2 - read - [INFO ] - Saving current energy stats at start of night rate tariff (Dynamic)
2024-12-03 23:30:29,370 - AIO-1 - read - [INFO ] - Saving current energy stats at start of night rate tariff (Dynamic)
2024-12-04 00:00:21,621 - AIO-1 - read - [INFO ] - Midnight, so resetting Day/Night stats...
2024-12-04 00:00:27,729 - AIO-2 - read - [INFO ] - Midnight, so resetting Day/Night stats...
2024-12-04 00:00:52,717 - AIO-1 - read - [INFO ] - Midnight, so resetting Day/Night stats...
2024-12-04 00:00:58,826 - AIO-2 - read - [INFO ] - Midnight, so resetting Day/Night stats...
2024-12-04 00:30:10,586 - GW - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-04 01:00:10,876 - GW - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-04 01:30:21,316 - GW - write - [INFO ] - Setting Charge Slot 1 to: 01:30 - 05:00 was a success
2024-12-04 01:30:21,779 - GW - write - [INFO ] - Setting Charge Schedule to enable was a success
2024-12-04 02:00:21,927 - GW - write - [INFO ] - Setting Charge Schedule to disable was a success
2024-12-04 03:41:05,273 - GW - write - [INFO ] - Setting Charge Slot 1 to: 03:30 - 05:00 was a success
2024-12-04 03:41:05,742 - GW - write - [INFO ] - Setting Charge Schedule to enable was a success
2024-12-04 04:00:21,672 - GW - write - [INFO ] - Setting Charge Schedule to disable was a success
2024-12-04 05:00:10,348 - GW - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success
2024-12-04 05:30:04,495 - AIO-1 - read - [INFO ] - Saving current energy stats at start of day rate tariff (Dynamic)
2024-12-04 05:30:10,583 - GW - write - [INFO ] - Setting Battery Pause Mode to PauseDischarge was a success
2024-12-04 05:30:30,315 - AIO-2 - read - [INFO ] - Saving current energy stats at start of day rate tariff (Dynamic)
CW I would think they would do it in 30 min chunks - consistant with the most granular pricing frequency we currently have - would keep it simple for the developer as well
You'd think so, but a couple of recent examples...
2024-11-30--01:58: {'start': '2024-11-30T02:30:00+00:00', 'end': '2024-11-30T03:00:00+00:00', 'delta': '-1.36'}
2024-11-30--01:58: {'start': '2024-11-30T08:00:00+00:00', 'end': '2024-11-30T08:11:00+00:00', 'delta': '-0.65'}
2024-11-30--01:58: {'start': '2024-11-30T08:11:00+00:00', 'end': '2024-11-30T08:12:00+00:00', 'delta': '-0.04'}
2024-11-30--01:58: {'start': '2024-11-30T08:12:00+00:00', 'end': '2024-11-30T08:30:00+00:00', 'delta': '-1.06'}
2024-11-30--01:58: IOG(timestamp=1732931881, count=1, s1=16, e1=17, s2=0, e2=0, s3=0, e3=0)
2024-12-01--05:13: {'start': '2024-12-01T04:30:00+00:00', 'end': '2024-12-01T05:00:00+00:00', 'delta': '-1.77'}
2024-12-01--05:13: {'start': '2024-12-01T05:00:00+00:00', 'end': '2024-12-01T05:28:00+00:00', 'delta': '-0.66'}
2024-12-01--05:13: {'start': '2024-12-01T05:30:00+00:00', 'end': '2024-12-01T06:00:00+00:00', 'delta': '-1.77'}
2024-12-01--05:13: {'start': '2024-12-01T06:09:00+00:00', 'end': '2024-12-01T06:30:00+00:00', 'delta': '-0.64'}
2024-12-01--05:13: {'start': '2024-12-01T08:00:00+00:00', 'end': '2024-12-01T08:15:00+00:00', 'delta': '-0.53'}
2024-12-01--05:13: {'start': '2024-12-01T08:15:00+00:00', 'end': '2024-12-01T08:30:00+00:00', 'delta': '-0.84'}
2024-12-01--05:13: IOG(timestamp=1733030019, count=2, s1=11, e1=13, s2=16, e2=17, s3=0, e3=0)(The IOG line is my attempt to merge adjacent half-hour blocks and discard anything already inside the standard off-peak period.)
Daveb01 Thanks for this. Most is the same repeated line:
Setting battery discharge limit 0 was a successI am assuming that GW is gateway.
Are you able to match other log lines to when register writes have been recorded?
Rather than reading from the chart, you can download the register write times by selecting the entity, then 'show more' and a download option appears under the the 3 vertical dots, top right (HA seems to delight in hiding info – I don't understand why you need to select 'Show more' for it to appear!)
And see what your predbat status changes are. 'Pause' aligns with 'Freeze' for me.
Rob
DD I think the 30 min slots are subdivided more by the masters who control all this (10 min?)
But we see the 30 min slots.
I think I found more info on Nordpool site but I can't find it now.
Rob
Vestas so you support the person killing inverters, but not the person telling everyone about it... What a jeenyus
So got to the three dots stage and click download on my iPad and nothing happens, hhmmm. Will have a think and see if I can do it another way.
I have had a couple of days to think about this new inverter read issue and have decided it is not just one thing that could cause a failure. Let’s say hypothetically the only automation you’re using was Predbat and Trevor fixed it, then the issue would go away. However it’s not as simple as that.
People can write there own automations
GE are doing there own read/writes within there systems
Energy companies and GE are taking control of our batteries/Inverters (if you want this type of control)
The hardware components are all different and it’s not clear which ones may or may not be affected
If anything happens to my GE system I will be claiming on the warranty, I will be asking what has failed. If they don’t honour the warranty then I will ask for proof it was caused by any automation.
If GE still fail to honour the warranty then I will be getting a PW3 or one of the new systems coming out or SolarEdge to match my PV Inverter.
I don’t think this would ever happen but GE could go into administration if it did and others did the same thing.
It would be made worse if say all those with Gen 1 inverters had a failure in say 8 years time? if it was one or two then no issue.
It's probably possible to do a man-in-the-middle and suppress any reporting of local changes up to the portal.
PianSom so, it looks like it charges (at 7.5p is it?), exports (15p seg?), charges again?
One of the benefits of predbat may be part of the problem?
You can make money via the above, but it causes more cycles on the battery and more writes too?
Still if it stuck to one instruction (or set of) per 30 minute slot or even per hour, that might be better? Charge for an hour, discharge for an hour, charge again. Or even charge for 2hr, discharge for 1hr, charge for 2hr? I forget how long the off peak is.
Of course some of that export might end up in the car, at which point it is probably pointless. Just getting round trip losses with no export payment?
So for IOG users is the best approach no overnight export at all?
TX200 So for IOG users is the best approach no overnight export at all?
Well, it depends - of course!
If the kit (cells + inverter) lasts 10y and are not covered by the 12y warranty then I reckon my overnight strategy would recover the capital cost, and I end up making a nice net positive return from other activity (time shifting consumption, basically). But that depends on many things, including static tariffs.
On balance, I think the game is worth the candle, so am not bailing just yet.
PianSom yeah and with a few tweaks to the logic, spread out the changes, less risk.
I haven't got an EV, so I'm not sure how people would make sure the EV battery doesn't get filled from the house battery.
I guess in some cases it is down to the house wiring. In others, automation and sensors.
Daveb01 When I click on Download, I get a box stating 'Do you want to download history.csv?
I select Download. The box doesn't go away but at top right of screen you should see a 'down arrow' with a file inside. Then click on it to view it.
Easier on a computer. I have Mac and the download goes into my downloads folder. Will be similar on pc.
Rob
TX200 I guess in some cases it is down to the house wiring. In others, automation and sensors.
Yes, I do both. Car chargepoint is wired such that GE doesn't see it. Then I have additional software to track any bonus charging slots. Initially, I was happy to simply pause battery discharge while car was charging, but now that winter's here, I've changed to actively (try to) charge house battery when the car is charging.
Unfortunately, at least a couple of times, there was a charging session planned, but I got an alert from Octopus claiming they had been unable to control the device, and even though the car was charging, the slot got charged at day rate. It's only about 50p, so I'm trying to decide whether to bother complaining about it. Have to keep an eye on it...
Daveb01 so Axle that happens once a month? Great idea on Solaredge, they just folded their Res business as well 👍
DD almost sounds like you are acknowledging there is a problem but want to hide it there.... Great idea advertising it on the manufacturers forums 👍
Luxo I’m struggling to work out if you actually work for Giv and are genuinely concerned about the longevity of their products or you just have a deep seated dislike of Trefor because he developed something you were incapable of doing. Either way he seems to be living rent free in your head. Until the last couple of days (coincidentally) I've not really seen much negativity on this forum, only people willing to offer advice or support. The bottom line is, if people want to carry on with Predbat (I for one do) then that is 100% down to the individual. If Giv want to put caveats in their warranty based upon hard evidence of multiple failures caused by automations ( and that will also include giving remote access to any of the intelligent tariffs etc) then that is their perogative but they would be on sticky ground as they actually support this kind of approach. The mention of Predbat in Oli’s video was literally for clicks and he admitted as much. His balancing automation (apparently originally designed by someone who now works for Giv) is the biggest contributor to high write counts and he has identified from this that automations such as Predbat could have a similar effect. Strange that he used Predbat in the title though. Maybe he would have risked a potential lawsuit if he had used a paid automation service as an example. At least Trefor acknowledges a potential problem and is taking steps to mitigate it even though it seems to be still causing you even more distress. Nobody gets software or firmware right first time (just ask anyone who has got a Giv product) but by constantly adapting to new information it just gets better. There are more important things in life than worrying about whether a potential future warranty claim will be rejected.
Goshiki2 Until the last couple of days (coincidentally) I've not really seen much negativity on this forum, only people willing to offer advice or support.
I agree. I would just ignore these posts which I think are by the same person with two new accounts (one which he renamed) opened in the last 24 hours.
Before you add another message about Trefor and Predbat, do have a look at the balancing automation software that Oli’s recent video describes, its still available at https://www.speaktothegeek.co.uk/2023/11/using-a-givenergy-all-in-one-and-ac-coupled-inverter-together/
And Oli has helpfully made it available as a blueprint so you can easily install it on your system. Though don’t forget to click on the buy-me-a-coffee button to help support the work he’s done
The article was written in November 2023 so Oli must have been running it for a year or so now. Strangely though this month he has added a new warning message
Oli is kind enough to acknowledge that the balancing automation isn’t all his own work though, it was based on an automation from Paul from GivEnergy who has the same inverter setup. Oli describes Paul as a “credit to the company”
Let us know how you get on with it
😉
geoffreycoan Oli posted on FB that he stopped using it about 9 months ago and went to a "gentle" method as he called it.
The balancing works the same way as what was it now... Oh yeah, the predbat balancer. You know the one which is touted so frequently by people as the best way to balance dual systems. Curious that.
Goshiki2 so you acknowledge there that there's issues with predbat, maybe a good thing it was called out then 👍
Luxo I’d argue there are potentially more problems with Giv equipment than Predbat actually.
We need to move forwards on this whole issue. This is how I see the current situation. Feel free to add to this or correct anything.
Hopefully we will have a resolution soon to this problem. It is pointless dwelling on the past – what is done is done.
Until the last few days, these threads have been constructive and we have all learnt so much from each other.
I hope they can rapidly be returned to this aim.
Rob
No screenshots from me tonight. in last 24 hours, my inverter has mostly alternated between Demand and Freeze discharging, with charging during 'lower' rate slots at night when my batteries were being charged. I have had 21 register writes from Predbat records in the last 24 hours. I had one run of 18 hours with no status changes or register writes at all.
Another useful source is on the Givenergy portal.
On the inverter page, select Remote Control and scroll down so that you can see 'Remore Control History.
On mine, the last column has been populated with 'External change detected', reflecting my predbat use.
The table shows the register than is being changed (I think).
Looking at my data, when the status changes between 'Demand (Eco) to Freeze discharging and back, it appears that change has been made by the pause register toggling on and off. This looks like 1 interaction with the register to me.
When charging starts, it looks as if Start time is set together with End time. For subsequent charges, the end time is changed but the start time doesn't change. This would obviously reduce the number of possible flash interactions.
If you are interested, have a look. The remote control history may give some idea of what is happening inside a GE inverter. Mine is an old AC3.0 inverter.
Rob
IOG here. Dual Gen3 5.0 hybrid inverters, 4x 9.5 batteries.
(Can’t post the logs, as it timed out downloading them.)
For me it’s 140 writes in the last 24 hours. The vast majority of those are “pause battery” and “un-pause battery”. Sent by GE API to balance my inverters and stop them cross charging using their “balancer beta software”.
I am not using HA or any 3rd party software, as it would conflict with the above. Home batteries are preset to charge to 100% from 23:30 to 05:30 and to 100% every night. And also run a discharge every evening to finish at 23:29 at as close to 4% as I can manage. I (fairly regularly) change the start time at this time of year based on what I’ve got left in them; in the winter only (otherwise I keep it at 7pm—>23:29 rest of the year).
I’ve got a fair few writes going on with this balancer running. Can’t wait to get an EMS fitted, so that if anything happens to GE I can run in stand alone mode, otherwise I’m screwed the inverters cross charge each other like crazy !
Does this flash write limitation apply to the Gen 3 hybrids or only earlier inverters?
If its a case of 3 it may not be enough to gain the info but a failure mode (for future reference) would be nice to know for diagnosis.
Does it always fault the same way, does the inverter go into a safe state, does it just get stuck doing whatever its last instruction was?
The whole master/ slave chip setup would suggest its capable of going into a safe state if the master falls over and the fault list suggests it can identify an EEPROM fault so does it flag that too?
Pete UK Thanks for this info. It is a useful control with no input from predbat but use of IOG for control. I presume that you had two batteries daisy-chained to each inverter. I don't know the GE "balancer beta software".
Does this flash write limitation apply to the Gen 3 hybrids or only earlier inverters?
I don't know! The problems seem to refer to 'older' inverters although DD identified that there could be a lot of writes using inverters with 10 charging time slots.
Can you post a screenshot of your data (I presume it was from GE Inverter/Remote control)?
Compare it with my remote control history running Predbat with Agile below (one 2022 AC3.0 inverter connected to two 8.2 kWh batteries). Use of pause and end time to change status.
The chart is Predbat's register writes and bar is predbat's status. Yellow is 'Freeze Discharge' and pale freeze exporting. From 6 pm yesterday to 6 am today, I have had 31 register writes (predbat) and 35 entries in GE remote control.
I had same issue with attempting to download the remote control history: Timeout. I don't think it works.
Rob
I have the chart above as well and the Rabbit has managed to get the entity into my Predbat Card under Status 😀🎄
I had a look and I have gone back to every entry and they are all external, I could not see one for the GW balancing my AIO. (Will keep an eye out)
I did a read to see if I got a You in the second column (which I did)
Thank you for this info
I think it's more than 3.
I think it's three known to be predbat.
Before that they probably had a number of faults and didn't have enough data to correlate.
Now they have the external change detected flags, I guess they'll know the person is using API access but won't know what they're using - unless they ask them and they answer the question.
Daveb01 Nice having register write count here but remember that this is cumulative. It would be nice to have a running 24 hour count.
Rob
Rbor you can always define a utility meter entity in HA that resets daily
Weasel I was going to say exactly that. Thanks !
I will let everyone know when it gets to 1M (it maybe a telegram from heaven if they still do them)
I like the idea of seeing it go up as I can get the info daily, weekly, monthly etc from the chart
Rbor Can you post a screenshot of your data (I presume it was from GE Inverter/Remote control)?
Yes, two 9.5 batteries on each inverter.
It’s still timing out downloading and I’m on a work trip right now but it’s just pages and pages of this….
Weasel geoffreycoan Thanks but I how could utility meter help to zero register count at end of each day?
This is where my limited HA skills let me down.
Rob
Rbor You create a helper entity of type utility meter. Call it (say) predbat_inverter_writes_today
In the utility meter configuration you say the source sensor is predbat.inverter_writes (or whatever it is called), say you want a periodic reset and the reset is daily.
This will create a new sensor that increments as the predbat.inverter_writes sensor increments, but at midnight it resets itself automatically to zero.
You can create multiple such helper utility meters eg fro a monthly or weekly count
geoffreycoan Thanks for the walk through.
But I have a problem.
The register write entity is one of these:
I have found the entity in Developer Tools/STATES with some yaml attribute code:
Been on this for an hour and I am now giving up.
Stumped!
Rob
Rbor Hmm that is a pain. Trefor has been progressively putting the predbat sensors in the predbat domain to clearly separate them, but the utility meter seems to validate that the input sensor is in the sensor domain.
It doesn’t mention this limitation in the documentation https://www.home-assistant.io/integrations/utility_meter/
So either Predbat has to change all the sensor names to match HA standards (which it possibly isn’t), or this be raised as a HA bug.
One alternative idea, you could try configuring the utility meter in the old way via configuration.yaml, instructions in the link above. This may get round the UI validation we’re seeing
geoffreycoan
I'm not sure it counts as a bug if Trefor has chosen not to adhere to standards put in place by the HA devs.
I guess Rbor could also try converting the predbat entity to a sensor type using a template ( https://www.home-assistant.io/integrations/template/#state-based-template-binary-sensors-buttons-images-numbers-selects-and-sensors ).
PianSom Its not clear how ‘hard coded’ these sensor domains are. I get the benefit of being able to select just a sensor from the dropdown list in the utility meter, but not being able to overwrite it is a limitation/feature/call it what you will.
https://www.home-assistant.io/docs/configuration/entities_domains/
I am erring on the side that Trefor has gone against the HA domain convention, but renaming all the predbat. sensors will break a lot of dashboards and the Apex charts so I’m sure he’d be reluctant to do that.
Looking at my HA it appears that all the Predbat output data has a predbat domain, apart from the Solar forecast data which is correctly in the sensor domain.
A template sensor would work as well, bit messy and adds yet another un-needed sensor to HA. Pain
geoffreycoan PianSom
Thanks for your replies. At least it isn't just me!
I would like to be able to see a 24 hour period, perhaps from another entity. The utility meter options would allow many set periods including a cumulative total.
As Daveb01 stated:
I will let everyone know when it gets to 1M
I have also found the same niggle in Trevor's Total Cost Saving chart with uses two 'cumulative entities':
predbat.savings_total_predbat
predbat.savings_total_pvbat
I will look at template route but I need to first learn templates. I would never have dreamed of using a 'utility meter' helper to get daily totals.
A HA basic question:
In the entities and helper pages, the first column has an icon. I can't find anywhere that explain what the icon means. I couldn't find anything in HA help which is very text based. Am I am supposed to just 'know this'. I have worked out the meaning of some of icons and some feature when selecting helpers and automation types.
The register count entity has this icon:
What on earth does this mean? It is the only entity that has this icon.
I will disappear back into my HA rabbit hole where I expect to meet my fellow rabbit @Daveb01 .
Thanks.
Rob
I am using in the Netherlands a third party company who is managing the loading and unloading for my battery.
I did monitor the data and I could see that they are sending in 24h more then 2.500 requests to my inverter. On some days they we're sending 8.000 requests with the inverter error was up to 6.000 requests.
So when I am seeing people talking about 140 writes ....
ChrisNL Can you upload screenshots of givTCP logs and GE inverter/remote control history?
Also what is your inverter and battery set up?
Thanks
Rob
Rbor
That's an icon that would have been chosen by Trefor. His code, his choice. eg
As Geoffrey say, templating is a bit of a pain, and is yet another thing to maintain. But it's not that bad. Put a line in your configuration.yaml saying template: !include templates.yaml then put any entities you want define in there. Mine, for example, includes stuff like
- binary_sensor:
- name: Grid Status
unique_id: grid_status
state: "{{ states('sensor.givtcp_XXXXXXXX_grid_frequency')|int < 49 }}"which is a binary sensor which detects if the grid has gone down.
You'll want to create a sensor which has the same value as the predbat.WHATEVER entity.
Top tip - use the Developer tools/Template page to see if the code you are using is actually producing the result you expect it to.
Worst thing about it is that you often need to restart HA to see if templates.yaml is working properly.
Rbor That is the default Utility Meter Icon.
Rbor Go to Devices and Services, Create Helper, Template a Sensor.
Copy
{{states('predbat.inverter_register_writes') | int }}
In to the State Template* line
Give the sensor a name and that will mirror the Predbat sensor.
Then create another helper and select Utility Meter using your newly created sensor as the source. You can then chose how often you want it to reset.
Someone might have a better way as I’m new to Home Assistant but give it a try.
PianSom As Geoffrey say, templating is a bit of a pain, and is yet another thing to maintain. But it's not that bad. Put a line in your configuration.yaml saying template: !include templates.yaml then put any entities you want define in there. Mine, for example, includes stuff like
Ugh, that’s not generally the best way to define templates. Yes you can do it that way but in many cases you can build helper entities (including template entities) using the HA UI. Same way as you tried to create the utility meter.
The template code you would need to get the current value of the inverter writes is simply:
{{ states('predbat.total_inverter_writes') | int }}
Make sure you include the single quotes around the entity name, and enclose everything in double curly brackets.
Smart Home Junkie has a good YT series on writing Jinja
Creating sensors in configuration.yaml has the advantage that there is more configurability than via the UI. e.g. I have a couple of climate controls to manage my inverter fans, not all the config options are available in the UI so I have to do it via configuration.yaml. But progressively HA are adding the ability to build more and more entity types via the UI. Template sensors were added a while ago as was Climate controls.
PianSom Worst thing about it is that you often need to restart HA to see if templates.yaml is working properly.
I found that this isn’t the case, you have to restart HA the first time you add a new template, but after that if you change the template you can just go to Developer tools and select ‘reload template entities’ near the bottom of the screen. You can reload most different types of configuration from the list, if unsure you can always just reload all the YAML.
Rbor BTW you can change the icon for most entities in HA. Unfortunately not for the Predbat created ones for the same reason discussed before, they don’t have a unique id in HA
Oops, I am obviously old fashioned. Times and software change.
PianSom geoffreycoan
Thanks both. Off to see what Smart Home Junkies has to say about Templates.
Rob
Here an example. I am having a 3phase inverter 10kW, battery 20kW
ChrisNL Oh wow, they (Powerselect?) are changing settings in 30sec intervals (sometimes multiple settings in that interval - similar to what I would expect to see a commercial BESS be instructed to do, not pummelling a consumer product) - that is a lot of writes to accumulate as you optimiser looks to be following the grid in near real-time.
I have no idea what warranty terms you have in NL - it seems the Givenergy API has no problem with writing so much however?
"Due to the large imbalance on our energy network, this is also very profitable, and the energy supplier will reward you considerably." - of small comfort if your system is no longer functional from doing so down the line and you have to replace it earlier than expected!
Yes Powerselect is my energy supplier api. So there is much traffic possible ;-)
Then I even showing the error rate I had, this is now down to a minimum it seems.
hoggy I bought the Battery from the company Accuselect this is a reseller of GivEnergy. The company has co-developed with the Energy supplier this service. I didn’t receive any information that by using the service this is having an impact on my guarantee-warranty of the inverter/battery.
ChrisNL Don’t worry, GivEnergy developed it, and you’re not running Predbat so it must be OK 😉
Seriously though I would contact Accuselect and tell them you have noticed the large number of inverter writes that are being done by their software, and get it in writing that this is OK and it won’t have any issue with your warranty.
I would imagine the 3 phase inverter has less risk and less potential exposure to this issue than the older inverters, but still worth getting it in writing
PianSom Goshiki2 geoffreycoan
Thanks for your collective advice on tweaking Trevor's register count entity to produce a daily tally.
I have succeeded 😃, having ventured into HA's hidden world of Developer tools, States, Templates, Helpers, and Utility meters. What a rigmarole!
Still I now know something about templates and how to create a sensor entity. I am half-way through watching Smart Home Junkie's videos on templates using yaml and Jinja.
I started my daily register count entity late last night and will wait for a whole day of data to proudly show you what I have achieved (provided it works!). The count did drop back to zero at midnight which bodes well.
I upgraded last night to Trefor's v8.8.2. I have had more register writes than before but, with current weather conditions, I have experienced more status changes.
Rob
geoffreycoan Yes I already contacted them, since my notification it seems they took action.
I had a big problem with the EPS (backup) for months of automatic restarting of the inverter. I was afraid this was due too the number of failures. After long pushing GivEnergy found the defect with monitoring firmware, what it was they don’t want to share, it is fixed with firmware update for my inverter.
What I don’t understand is why GE isn’t adding a maximum rate per minute or hour and ensuring that the commits via HA or any source are validated (openapi) if wrong it is not accepted, if they say the inverter may get problems or warranty issues.
geoffreycoan I don’t understand the difference using Predbat or a third party (if these are so precise). Looking into investments Predbat is doing GE must be taking steps forward to adapt it. In my view it is very logical owners want’s to be able to use automations via HA or other automations.
Last night was very busy. Looks like tonight maybe the same. Read/writes are up. I will see how it is after a week and times it by 52 to get an average per year. I can not see the GW doing any balancing so will have to add a bit to come to a rough average. Se how accurate it is after a month then a year.
Daveb01 Last night was very busy. Looks like tonight maybe the same.
Likewise. I don’t have the newer software that counts the inverter writes but I was at -60p earlier this morning after Predbat had charged and discharged a few kWh in the night. Makes a change to see export higher than import, purely from Predbat, as there’s no sun to speak of.
I can not see the GW doing any balancing
I don’t think you’ll see a lot of obvious activity from the gateway as all the commands are being sent downstream of the gateway direct to the AIO’s. Only way I think you would see it would be from inferred activity - look at the individual AIO SoC’s and maybe their individual charge/discharge rates and pause status. If you see the two AIO SoCs diverging and then coming back together you may be able to see the pause status or rates on the AIO’s being changed by the gateway.
Daveb01 Yes very busy with predbat analysing whether to charge, export, pause, etc.:
From Dec 2nd to Dec 8th inclusive, I have had 373 'Trefor register writes', an average of 62 per day.
These range from 20 to 120 register writes in a day.
We don't know how many actual register interactions correspond to one 'write'. A GE knowledge base article on this would be informative, especially as GE's own data in 'Inverter/Remote control history' refers to what is happening to different types of register. I note that 'start time' and 'end time' are often set together with just 'end time' then being changed with subsequent changes (a saving).
My predbat plan has a common repeated sequence of 'Freeze discharge to 'Discharging'.
Looking at the GE remote history and givTCP logs, I suspect that each change is a 'GE' Pause (on or off) and that Pause is a single interaction. (Caveat: this is a 'Rob suggestion/guess'.)
From weather forecasts for this week, we are heading for more benign days where there will be fewer register writes with few low Agile rates.
Looking at Agile over the last week, we have had both high rates and low rates.
Over the last 7 days,
That is certainly better than it has felt, especially for the 1st week of December. If continued (it won't!), my Dec bill would be £56 + SC). And all this with a HP, no gas and a low mileage EV.
Last December, on 2 slot Cosy with no Predbat, my Dec bill was £140 + SC with an average import rate of 18.13p/kWh.
Predbat and Agile are playing a good innings for me (although I can't help but wonder about 3 slot Cosy)
Agile's low rate days nicely pull down the average.
Since mid January 2024 when I moved to Agile import, my average import rate has been 9.88p/kWh.
Rob
I went for the easier option, rather than creating new sensors/helpers etc
Markdown card, just need to set the date and time the update was installed, e.g. the date and time it showed zero.
{{ (as_timestamp(now()) - as_timestamp("2024-12-02 07:33: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 07:33:00")) | timestamp_custom("%j")| int)) | int }} avg per day
I'm averaging 40 per day on agile incoming and outgoing.
TX200 Now that is really neat. I have just copied your code into a new markdown card and here is the result:
Less than a minute to do.
Now I need to investigate how it works by studying HA Date and time help files .........
Thanks a lot.
Rob
I wanted to set a variable ideally (so you only do the calculation for the date difference once)
Small steps!
And an improvement... variables !
{% 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 for this. It's great.
My stats on agile incoming and fixed outgoing:
7 days
590 total writes
84 avg per day
Can I also make the counter for the GIVTCP integration HA?
ChrisNL Can I also make the counter for the GIVTCP integration HA?
Not directly and easily no. Predbat has been changed so that every time it changes GivTCP (either via a REST command or changing a GivTCP HA control) it increments its own counter.
GivTCP doesn’t have such a feature built in. You could request it as a feature request for GivTCP and Mark may well include it given all the recent “discussion” about inverter writes, and the advantage of it being included in GivTCP is that it would be more accurate as GivTCP knows precisely what registers are being changed, when.
The only other practical way would be to write a shell script that counts the number of ‘write OK’ messages in the GivTCP log each day. It won’t be as accurate but would give you a good idea
geoffreycoan Not directly and easily no.
Well, not with that attitude! 🙂
Might be worth exploring a counter for MQTT posts to the GivEnergey/SERIAL/Control topic? See, for example, here. You'd have to do a dive into GivTCP control messages and make some guesses as to how they interact with register writes ...
So actually quite some work. Like Geoffrey said.
geoffreycoan I’ve added this as a Feature Request https://github.com/britkat1980/ha-addons/issues/37
Feel free to add your own experience/thoughts to the FR
geoffreycoan And Mark has replied to say he’s just put this feature into Dev release 3.0.47
Be interesting to see how it compares to the Predbat calculated values
Of course the Predbat values will still be useful for non-GivEnergy inverters
As might be expected, the amount of activity makes a big difference to number of register writes.
When Darragh came through, I noticed a lot of activity, sometimes charging to exporting to charging ...... exploiting the level of the rates.
In 24 hours, I had 120 writes.
But in the last 24 hours, weather has been much more benign and I had 30 writes.
After 8 days, I am now averaging 58 writes per day.
Rob
I just count the log pages I had for the last 8 hours 20 pages * 15 writes = 300 writes : :🫣 then 58 per day is peanuts
ChrisNL 58 per day is peanuts,
Very much so. Our setups are so different with mine being residential, single Gen 1 AC3.0 inverter running on Agile with a max write rate of every 5 min, but most of the time with no writes.
Yours uses a 3 phase inverter with writes every 30 seconds.
Your setup seems to be a question of 'Is your inverter up to the task of writing at this continual rate'?
As geoffreycoan suggested, is it time to contact Accuselect?
Rob
Might need to change the title, for those of us not thrashing the inverter 🤣
Mines down to an average of 37 writes a day now.
Think there was a bit more optimisation in a recent patch.
For all those raging against predbat: don’t use it and if you think you can do better then go for it.
At the end of the day, even without predbat you could end up in the same situation, in reality you could end up with as many writes manually controlling your inverter from the GivEnergy app.
Predbat, is just trying to help you. If you have concerns then don’t use it. Simple. Don’t start raging against a guy trying to do something good for people, based on some idiot from YouTube that was deflecting his own stupidity. “Oh I wrote a script that balances my inverters every 30 seconds…..but predbat” - get out.
JasonF have you tried predbats balancing as a comparison?
gregstewart have you tried predbats balancing as a comparison?
I have used Prebat’s balancing and it’s not great TBH. It runs every minute (this is configurable) and if it sees the inverter batteries are out of balance it changes the charge and discharge rate on one inverter so the other one catches up.
But I found it wasn’t very effective and it of course sends loads of rate change writes to the inverter so I stopped using it. Did log it and its in Trefor’s enhancement list. Part of my proposal was to set PauseCharge on all inverters when the sun is not shining and the battery is not planning to do a grid charge. This would for me stop most of the cross charging which tends to occur overnight when the house is running off batteries.
What I found was more effective was my own automation which sets Pause Charge on the inverter that is charging when the other is discharging. Of course at the next 5 minute Predbat run, Predbat will revert this, but it stops it running away
alias: Detect and stop cross charging G to H
description: ""
triggers:
- entity_id:
- sensor.g_sd2237g182_battery_power
for:
minutes: 1
above: 0.6
trigger: numeric_state
conditions:
- condition: numeric_state
entity_id: sensor.h_sd2237g395_battery_power
below: -0.3
actions:
- action: select.select_option
metadata: {}
data:
option: PauseCharge
target:
entity_id: select.h_sd2237g395_battery_pause_mode
- action: script.notify_all_devices
metadata: {}
data:
critical: "N"
url: ""
title: “Cross charging detected"
message: >-
G battery power {{ states('sensor.g_sd2237g182_battery_power') }}kW, H
battery power {{ states('sensor.h_sd2237g395_battery_power') }}kW
enabled: false
mode: singlegregstewart I don’t need to, I have parallel AIO so the gateway handles balancing between them.
JasonF certainly sounds like predbat can run exactly the same way as the balancing script then.....
After 40 days and 40 nights? 😄
40 days
1612 total writes
40 avg per day
Not too bad given I'm on agile.
TX200 I'm averaging a bit more than you are:
Days: 39
Total inverter writes: 2958
Average inverter writes per day: 75
Also on Agile:
19 days, total 2425 inverter writes (across two inverters)
Average 63 writes per inverter per day
We’re all in the same ballpark
And I am much the same, also on Agile:
This is right from the start when Trefor introduced his register write entity at start of December.
Rob
Predbat daily inverter writes per day this year: can clearly see the drop in inverter writes from when I moved from Octopus Agile to Octopus Cosy:
And this is with 3 charges in the Cosy periods a day.
Figures are for my two Gen 1 hybrid inverters, so halve for each inverter.
I think the spike 2 days ago is due to the power being off a few times that day and Predbat having to restart and re-instruct the inverter each time.
Anyway, I don’t see anything being particularly excessive in these figures.
geoffreycoan
Interesting. Here's mine for this month.
Guess when I switched from Agile to Cosy.
My typical daily register writes are 9.
This is my average since this all started:
Rob
This is mine, Predbat is in read only mode currently as my gas, elec and comms meters have died as of 5th Dec.
Replaced twice now by Octopus since then....
So this is just Givenergy's smart beta 3 charge slot updates for COSY.
I'm also on the latest firmware which has virtual writes, so that number is probably ficticious for real emmc writes.
This mine from the first day of Predbat
78 days
4593 total writes
58 avg per day
Over in GivTCP-dev land the Real Time Control (RTC) register has made an appearance.
Useless unless you have the as yet unreleased firmware to go with it, but interesting that it can be turned on & off as opposed to what I had assumed was more baked in approach.
[unknown] Not everyone will want the safe registers in RAM.
Else if you change them and the inverter looses power, the content is gone back to what was in flash before.
Hence its switchable. Grid services (Which is what this is designed for) will turn it on, do what they need at their speeds, then when finished turn it back off again
TheDragon (GivEnergy) is there any information about what registers are held in RAM so we can better understand what we’re losing if there’s a power loss, and is there any kind of periodic sync from RAM to registers that happens in the background - I think that was suggested as being part of the solution?
If as an example, its the ‘control registers’ that are held in RAM (e.g. charge start/stop times, mode, eco on/off, battery pause state, charge/discharge rate, etc) and all the ‘data counts’ were always held in registers (e.g. battery charge/discharge/PV generation/import/export/load today/total) then personally I could live with that as (for me) Predbat sets the inverter to what mode it needs when it runs, so if I lost the previous operational state then it wouldn’t be a material loss.
I suspect for most people they don’t change their inverter controls all that often (so is a question of whether the RAM registers are really needed or not), but if there was say a 4 or 6 hourly sync of all RAM to registers then other than for the dynamic operators the current operating state and charge/discharge schedules would be preserved.
Couple this with the low risk of a power cut
geoffreycoan i was gonna do a new thread for this once released. But here are the registers that are in RAM
Mick was going to do a thread on this and how to use them.
These are designed for Grid services, but CAN be used by jo popolus, aka predbat users
Number Description
Enable AC Charge Upper Limit (Winter Mode) - Global AC Charge to value
Enable Eco Mode (Battery Power Mode)
Inverter Active Power Rate
Battery Discharge 1 Start Time
Battery Discharge 1 End Time
Battery Discharge Enable Switch
AC Charge 1 Start Time
AC Charge 1 End Time
AC Charge Enable Switch
Battery Reserve % Limit
Battery Charge Power
Battery Discharge Power
Winter Mode Cut SOC - Global AC Charge to value
Battery Pause
Battery Pause Start (Unavailable in AC3)
Battery Pause Stop (Unavailable in AC3
Enabling RTCL will store these only in RAM, so NO shadow copy to flash
Disable RTCL, all RAM is written to Flash in one page write.
Write any register not in the list, the page get written, which will include these too.
So if you wish to do a perodic write back, just turn off RTCL, wait 5s and turn on again.
Or write any other register.
this list was for Grid services, so may not have all your favourites in it. Maybe we will expand it, if it is uwell used and liked.
TheDragon (GivEnergy) Thanks for the preview list and explanation of how they could be used, and please do publish a separate thread when formally released as I’m sure there will be a lot of discussion and interest in this feature.
TBH this looks pretty much like the whole set of controls that would be manipulated regularly by Predbat/IOF/WonderWatt, etc, so is pretty comprehensive.
Look forward to seeing it come to fruition
Has the logic behind predbat changed?
Had free or very low agile rates from 9:30 this morning to 16:00 this afternoon. predbat has charged the batts to 100% but is hold/chrg them at that. It used to discharge/charge them to make the most money it could.
Is it a setting I've changed or missed or has the logic been changed.
[unknown] Has the logic behind predbat changed?
Had free or very low agile rates from 9:30 this morning to 16:00 this afternoon. predbat has charged the batts to 100% but is hold/chrg them at that. It used to discharge/charge them to make the most money it could.
Is it a setting I've changed or missed or has the logic been changed.
The logic changes in each release of predbat! Sometimes the tweaks are less obvious as to what they do….
But it may simply be that there was no financial benefit to discharging/charging the battery during the day.
Here’s a sample of my plan from this afternoon:
As you can see the battery is pretty much full and its being held full through the cheap period.
The reason for this (for me) is that my 2 Gen 1 hybrids can together charge 2.6kWh in a 30 minute slot, but the solar prediction is above this for every slot, so if solar is anything like as predicted then I’ll be generating more than I can charge the batteries with and will be exporting anyway.
In fact when I looked, at one point in the free electricity period I was exporting 8kWh!
Tonight is cheap periods as well and Predbat is doing what I would expect, repeatedly charging and discharging the batteries through the night
geoffreycoan Thanks Geoffrey,
Just seems odd.
Here's my plan for today. I know it could/probably will change
Just hope it decides to change and charge during the Free periods and hopefully the cheap slots from 11.30 onwards.
@"Wavy Davy"#p83859 that is a bit strange, your solar prediction in the morning is very low, would have expected that Predbat would export or at least freeze export and then charge during the cheap period.
Do you have switch.predbat_set_freeze_export and _freeze_charge turned on? Assume select.predbat_mode is set to charge & discharge. Is metric_min_improvement_export and _charge set to particularly high values?
Was any clipping predicted?
My own plan for today expects to use the cheap period. I have manually added some freeze exports to tweak the plan and keep the soc low. Whether it actually does import, remains to be seen
[unknown]
Thanks for reply Geoff, sorry been out all day so only just got in.
Export freeze was OFF but charge freeze was on, so have turned it off.
Mode is set to charge & Discharge.
metric_min_improvement_export is 0.1, charge is 0.
Not sure if clipping was predicted as I don't normally look at that, but there's none predicted now for the duration of the chart. (wed 15:00).
Havent got any cheap rates on the horizon, but will keep an eye on it and see if the charge switch being changed makes a difference.
[unknown] Export freeze was OFF but charge freeze was on, so have turned it off.
I suggest you want export freeze AND charge freeze both setting to ON. Turning these on enables Predbat to set a charge freeze or an export freeze on your inverter.
Export freeze is useful during a sunny day when rates are dropping, an export freeze will hold the SoC at the current level and export any solar. So when rates are dropping this can hold the current SoC level so that there is space in the battery to charge later on.
Charge freeze is useful overnight when the rates are around the same as your export rate. It will again freeze the SoC level but this time it allows charging so if there's no solar (e.g. overnight) then it has the effect of running the home off grid import rather than cycling it though the battery and incurring conversion losses
geoffreycoan
Hi Geoff, Don't know if its better or not, but this is what my plan looks like now.
The import rates are around the same as my export rates so maybe its ok, but never seen it look like this before.
Wavy Davy Hi Geoff, Don't know if its better or not, but this is what my plan looks like now.
The import rates are around the same as my export rates so maybe its ok, but never seen it look like this before.
I’ve got the same, batteries are at 42% and predbat is planning freeze export all day.
If I look in detail, I think this is the right plan:
I’ve got enough stored battery power to see me through the evening load and any spikes during the day, so all solar is being exported. Then charging later tonight when rates are low.
All good for me
Has predbat's charge/discharge regime been changed?
mine doesn't seem to export even when I have full batteries and there are er 3 hours of free or negative agile rates.
It used to discharge then charge to minimise costs.
Haven't changed anything that I remember.
Mine is going like the clappers on standard settings
Wavy Davy On standard settings mine is exporting/importing frequently
Mine still isn't doing much exporting.
Have had lots of free slots the last couple of days and hardly any export.
Most of last night was free but only exported .4kW.
Ive put most of my settings back to default. Exceptions are
expert Mode =on,
best_soc_keep = 0.2,
calculate_plan_every 5 mins,
combine_export_slots = true,
predbat_forecast_plan_hours = 48 hours.
None of which i think should affect discharge.
The only other things different are select.predbat_manual_api and select.predbat_update neither of which I've changed myself but are showing pink.
This is what predbat did last night/morning.
Definitely could be better.
Looking at it again, it seems as though its favouring keeping the Batteries at 100% all the time and ignoring if there's cheap rates coming up when it could recharge.
With the help of WonderWatt I exported 25kWh yesterday from imports and made just under £4. Best day ever. Predbat should have had similar results. There must be something set incorrectly.
Windy Miller With the help of WonderWatt I exported 25kWh yesterday
WOW that's some schedule, I use Wonder Watt too though I am no longer on Agile. WW really is a great service with super support, well worth the subscription to me for time saving alone. After a few months tuning it, I am running pretty much hands off now 24/7, apart from the Octo free saving sessions when they appear. I didn't buy a battery system to be a full time plant manager, or to Geek out on HA etc , I've got plenty of hobbies already without adding another fulltime one.
Wavy Davy comparing your settings to mine:
I don’t set best_soc_keep, its set to 0 (same as best soc max & min)
combine_export_slots is off
worth checking your metric battery cycle cost (mine is 0), set discharge during charge (off), your inverter and battery losses (mine are 0.04, 0.055 and 0.05 respectively)
predbat for me has been keeping the batteries busy, even getting to grid clipping I’m exporting so much during the day. I exported 46kWh yesterday for £6.75 profit . Charging and discharging through the day and night
geoffreycoan Thanks Geoff, I have put the values to those you suggest and will see what happens.
Just looking at the table it looks a bit more promising. Strange I hadn't recently changed anything, but anyway will see how it performs now.
Wavy Davy that looks very much like my own predbat plan for tonight
it could well have been the best_soc_keep that was causing predbat to not do much. Maybe worth some experimentation and if necessary bug on github
I think it was on this thread we first discussed creating a dashboard display of how many inverter writes predbat was creating each day and as a predbat rolling average.
e.g.
(Once GivTCP also started counting inverter writes I added this to the dashboard. The predbat and givtcp numbers are pretty similar, not 100% identical, but always very close)
Anyway, I noticed the other day that the predbat daily average was reported as 800 writes per day !
Turns out the Jinja used to calculate number of days to average over was wrong. The calculation subtracted the date I started counting predbat writes (i.e. date I upgraded to a predbat version with inverter write counting functionality), then subtracted that from today’s date, and convert to days. It was the last bit that was wrong and was converting to days this year so once it went over the 1 year anniversary it went wrong.
Corrected YAML (for a dashboard markdown card) is:
{% set datediff = ((as_timestamp(now()) - 1734888000) / 86400)| int %} {% set totalwrites = (states('predbat.inverter_register_writes') | int) %}
{{ (states('sensor.predbat_daily_inverter_writes')|int(0)/2)|int }} writes per inverter today
Average {{ (totalwrites / datediff / 2) | int }} writes per inverter per day
GivTCP writes: G {{states('sensor.g_xxxx_write_count')|int}} / safe {{states('sensor.g_xxx_safe_write_count')|int}} / today {{states('sensor.g_daily_inverter_writes')|int}} | H {{states('sensor.h_yyyy_write_count')|int}} / safe {{states('sensor.h_yyyy_safe_write_count')|int}} / today {{states('sensor.h_daily_inverter_writes')|int}}The 1734888000 value is the unix date time for when I started using the predbat write counting functionality, 86400 is the number of seconds in a year.
The zzzz_daily_inverter_writes are utility meters wrapping around the underlying predbat and givtcp sensors.
geoffreycoan Given the state of Agile these days I suspect flash writes are not an issue 😉
Vestas agreed
what is curious is how the daily number of inverter writes does change though. I’ve been on Cosy all winter for import and Agile outgoing for export (but so far I’ve only had a very very small number of exports), and since my battery capacity exceeds my home+heat pump consumption, you’d think the number of writes (i.e. set to charge in the Cosy cheap periods, demand outside them) would be constant-ish. But its not:
This is for two inverters, so halve it and you get an average of around 40 per inverter per day, but there’s a huge variation 🤷
The proceeding 3 months from August to October when I was on Agile until early October I think, much more variation and what looks like a windy period at the beginning of October
On Agile there was less writes because the Agile rates were so poor most of the time that I was on Demand most of the time, charge during the day on solar, use that overnight to run the house.
On IOG, my daily status goes charging to demand to changing.
Virtually no PV during the day and no change in status.
My register writes in the last 24 hours has been 6.
Rob
Average of 46 writes a day for me
On agile, since 1st Oct.
The writes was at zero before I joined agile, maybe because PredBat wasn't in use (monitor mode /read only).
geoffreycoan The 1734888000 value is the unix date time for when I started using the predbat write counting functionality, 86400 is the number of seconds in a year.
No wonder time appears to be flashing by so quickly as I get older.......