Thanks for uploading this

[Javert1969]

Many thanks for uploading this - as mentioned on FB I am looking to set this up myself and this will be an invaluable example to follow. I will post any findings here. For reference my inverter is a Smile-G3-S8 and I am currently running a slightly older version of Axel Koegler's integration downloaded in March 2026. I have tweaked the code of this integration to allow for my export limit being lower than my inverter size here in the UK - I hard coded my export limit into the Excess Export automation code.

[PlainSeer]

Thanks, and it is useful to know that someone else is working with the same inverter.

I am also using a Smile-G3-S8. I was using Axel Koegler’s AlphaESS Modbus code before it was converted into the newer Home Assistant integration/device-based format, so my setup has evolved alongside those changes.

PredBat has been working very well with it. It is successfully planning and controlling battery charging and export, including variable charge/export power, target SoC, and the charge/export freeze modes documented in this repository.

For tariffs, I was originally using Intelligent Octopus Go for import with Outgoing Fixed for export. I have now moved to Octopus Agile Outgoing export. The live tariff information comes into Home Assistant through the BottlecapDave Octopus Energy integration, and PredBat is handling the changing half-hourly Agile export prices well. It moves deliberate battery export towards the more valuable periods while taking account of expected household load, solar generation, battery reserve and future import costs.

So far I have been impressed with how well PredBat optimises the AlphaESS system. The combination is considerably more flexible than relying on the inverter’s native schedules alone.

[Javert1969]

OK - just to check my understanding so far - "home_assistant_predbat_alphaess_package.example.yaml" contains everything that is in "home_assistant_house_load_example" and "home_assistant_alphaess_bridge_example" together in one file that can be added to my packages, so it's an either/or thing?
To put it another way - installing this (after fixing it to the correct data of course) replaces steps 1 to 4 below it in the documentation?

Also - I'm not totally clear why I need a customised daily load so far sensor as I already appear to have a sensor called "Today's house load" as part of the older integration and I have also created 2 versions of this - one with and one without EV charging included. I think this should be sufficient probably?

Also again - conceptuatlly just so I understand Predbat a bit better - does the predbat plan create a "charge freeze" event or "discharge freeze" that goes with a 30 minute slot? then the "charge_freeze" service gets called in that apps.yaml file so that section of code gets executed? Is that how it sort of works?

In the docs it also refers to "export freeze" in the plan, but is that somehow using the same freeze services in configuration?

Finally - you mention that it is successfully using variable charge/export power, from what I can see that is what is controlled in the example package or the bridge package?

What I will probably want to do eventually is that for the "charge_freeze" service, I will want to use the "Excess Export" function in Axel's original integration, in conjunction with the "support_feedin_first" flag - if that flag even works as I cannot find it being used in any of the supported inverter examples even though it is covered in the automation.

I guess my first objective is just to get Predbat to make a plan based on my inverter sizes etc and then see what is happening and see what I need to do from there.

Finally - have you told the guys at Predbat that you have loaded this Github template as they might want to eventually include it in their list of examples?

[PlainSeer]

Yes, that’s basically right.

The home_assistant_predbat_alphaess_package.example.yaml is just the all-in-one version of the Home Assistant side of it. It combines the house-load sensors, rate helpers/bridges, export target script and automation into one package. So you would use either that, or create the various bits separately – not both.

On the house load sensor, if you already have a reliable “Today’s house load” sensor which resets at midnight and steadily increases in kWh through the day, then there is probably no reason to recreate mine. I only made the Modbus-derived one because the existing daily load sensors on my setup weren’t usable at the time. PredBat basically just needs a good cumulative load_today sensor, it doesn’t care whether it came from my example or directly from your integration.

And yes, your understanding of the freeze services is pretty much how I understand it as well. PredBat makes the plan and, when it reaches one of those states, calls the appropriate service defined in apps.yaml.

The slightly confusing bit is the terminology. In the PredBat plan you’ll see Freeze Charge and Freeze Export, whereas in the custom inverter configuration those correspond to:

• Freeze Charge → charge_freeze_service
• Freeze Export → discharge_freeze_service

On mine I then translate those into the appropriate AlphaESS Dispatch modes.

The variable charge/export power is done by the two helper/bridge automations in the package. PredBat requests a power level in watts, the helper holds that value, and the automation converts it to kW and sends it to the AlphaESS charge/export power control. That means PredBat can decide to charge/export at, say, 3 kW rather than everything always being full inverter power.

Your idea about eventually using Excess Export for charge_freeze is interesting. I haven’t tried that combination though, particularly with support_feedin_first, so I wouldn’t want to say it will definitely behave correctly without testing it. I’d probably get the basic PredBat setup working first and leave it in Monitor mode initially, make sure the plan/sensors all look sensible, and then introduce the inverter control pieces one at a time. That’s more or less how I ended up building mine.

Also worth saying that the example is very much based on what works on my particular G3-S8, rather than me claiming it’s the “correct” AlphaESS configuration. Having another G3-S8 setup to compare against will actually be really useful.

I haven’t specifically asked the PredBat guys to include it as an official example yet. I wanted to get it documented properly and have it used/tested a bit first. If it proves useful to a few people then I’ll probably mention it to them.

[Javert1969]

Yes will I had a bit of a breakthrough in understanding this morning - yesterday I was scratching my head a lot about “freeze charge” and “freeze discharge”. After seeing a comment in your code that freeze discharge is the same as freeze export, this made me even more confused.

I think my confusion was that generically I was thinking that “Freeze discharge” means that discharging is blocked, so you cannot discharge. It actually means the opposite - charging is frozen but you can still discharge. I’m not sure that’s the terminology I would have chosen but at least now I sort of get it.

I think that when Axel’s original integration that I am still using was developed, there was no mode 19 available, but it will accept mode 19 now. Excess export goes beyond mode 19 because I guess mode 19 will clip your solar if you are generating more solar than your export limit or inverter capacity - this might not be relevant for your situation if you don’t have an export limit that’s less than your inverter size. In Excess export this clipping will only happen if your battery is already full, otherwise the excess that your export limit or hybrid inverter can’t handle will go to the battery.

I also noted that your code is based on the HACS version of the integration as you previously mentioned, and a lot of the entity names have been changed by either adding or partially replacing the word “inverter”. I will need to decide whether to first do a project to flip over to the new system but there was a reason why I didn’t do that up to now. I will check this out further also. Otherwise I will just alter all the references to the old Axel’s terminology.

[PlainSeer]

Yes, I think you’ve got the distinction now. The terminology confused me initially as well — PredBat calls the plan state “Freeze Export”, while the custom inverter interface calls the corresponding service discharge_freeze_service.

And yes, the entity names in my example are from the newer HACS integration, so you’ll either need to translate them to the older names or decide whether moving to the newer integration makes sense for your setup. I’d definitely check why you stayed on the older version before changing it, though.