Intelligent Octopus - Control - Stop Battery Drain

Since I got the email from Octopus about not taking advantage of the smart charging, I've looked at how to do this properly.
In the past, I've just disabled the smart charging and used Zappi boosts between 23:30 and 05:30.
This has always worked perfectly.

In order to try and use the smart charging, I was always worried about getting a slot outwith the above hours, as it would drain my GivEnergy batteries.

My approach to this, is using HomeAssistant to detect when the Intelligent Dispatching sensor changes.

Thoughts being as follows:
-Only check the Intelligent Dispatching sensor outwith 23:30-05:30 as I have the Gen2 configured to charge at these times
-Rather than pause the battery, take advantage of the cheap rate, so charge the inverter too.

So I have created 3 automations.

IO SLOT START - What this does is check for the Intelligent Dispatching sensor, only outwith 23:30-05:30, and if its On, Force Charge the inverter
There doesn't appear a way to tell the inverter using GivTcp to just Force Charge permanently, so I choose the maximum option 180 - 3 hours

**alias: IO SLOT START
description: ""
trigger:

• platform: state
  entity_id:
  • binary_sensor.octopus_energy_a_xxxxxxxx_intelligent_dispatching
    to: "on"
    condition:
• condition: not
  conditions:
  • condition: time
    after: "23:28:00"
    before: "05:30:00"
    action:
• action: select.select_option
  metadata: {}
  data:
  option: "180"
  target:
  entity_id: select.givtcp_edxxxxxxxx_force_charge
  mode: single**

IO SLOT STOP - This checks for Intelligent Dispatching for Off. This will trigger at any time

**alias: IO SLOT STOP
description: ""
trigger:

• platform: state
  entity_id:
  • binary_sensor.octopus_energy_a_xxxxxxxx_intelligent_dispatching
    to: "off"
    condition: []
    action:
• action: select.select_option
  metadata: {}
  data:
  option: Cancel
  target:
  entity_id: select.givtcp_edxxxxxxxx_force_charge
  mode: single**

I did this third automation to run at 23:28, because what I found is the following:
If you do not send a Cancel command to the force charge, so it runs its course, if the slot starts at say 10PM, its end time would be 1AM.
What I found was at 1AM, the inverter would stop charging, even though its internal charge range is 23:30-05:30.
If you Cancel the force charge before the scheduled charge, it seems to be fine.

IO STOP - Pre 23:30

**alias: IO STOP - Pre 23:30
description: ""
trigger:

• platform: time
  at: "23:28:00"
  condition: []
  action:
• action: select.select_option
  metadata: {}
  data:
  option: Cancel
  target:
  entity_id: select.givtcp_edxxxxxxxx_force_charge
  mode: single**

All of the above seems a bit of a janky workaround, so was wondering if we could have a conversation on how others have achieved this.

Thanks for reading....

ProximusAl In the past, I've just disabled the smart charging and used Zappi boosts between 23:30 and 05:30.
This has always worked perfectly.

AFAIK, simply asking for the car to be ready by 05:30 should guarantee no extra morning slots.

Rather than pause the battery, take advantage of the cheap rate, so charge the inverter too.

My pattern is that I've already fully charged the battery in the standard 6 hours, and am typically exporting back to the grid in the morning, so my focus is just about inhibiting this export during the bonus charging slots.

(I don't use HA, just run a script in the morning using the Octopus and GE APIs to decide what's to be done each day.)

DD I do ask for the car to be ready at 05:30. Its the extra slots I get before 23:30...

So this is making sure the drain doesnt happen before the 23:30 slot, not after it

Just to clarify, sometimes I get IO slots from 20:00-22:00, so I dont want the battery to drain into the car, so by charging the inverter, both the batteries and car get cheap rate electrons....

ProximusAl ah, okay, then you can discharge battery back to grid before recharging at 2330

There is another way to avoid getting early slots... I generally leave my zappi in stop mode, only changing to eco+ mode when I actually want to charge. It's not until this happens that Octopus actually prepares the schedule. So a timed script that does this mode switch after 11pm would prevent evening charging.

I don't think I've ever had an early slot - perhaps I need to plug in earlier to see what happens. Evening slot is probably more useful than morning slot.

Is there a reason you are not using Predbat? This integrates with your battery, Zappi charger and Octopus IOG and handles this complex requirement very gracefully.

If you get additional slots, outside of the 23:30-05:30 standard window, Predbat will control your battery so that it charges the battery during these slots.

DD That's not something I can feasibly do. I have 2 cars, one a PHEV and one a Tesla.
The majority of the time, its the PHEV that gets plugged in.
So for example, yesterday, my wife went out in the PHEV, and when she got back, knowing she wont use it again in the day, she plugged it in at 10:30am.
IO gave her a slot from 11:30-12:00, so a quick half hour during the day.
Next slot was from 11PM, so 30 mins before the normal cheap slot.

My only option is to make sure during the IO slots, the inverter charges, so a. Its cheap, and B. It doesnt drain.

The whole reason for my post is that generally...on the whole...it works, but this morning I woke up to the battery at 100% but not providing the house, and I cant find any logs as to why its happened. I had to reset the inverter to defaults to get it to start discharging. (ECO mode was on, Wasnt charging etc...everything checked)

SamM I've certainly heard of Predbat, but I thought that I would be able to do this myself. Perhaps I'll have a look at PredBat, but I've certainly seen some posts of people having a hard time with it.

ProximusAl
Honestly, given that you are comfortable with HA and automations and so are reasonably technical, I think it would be worth you spending some time looking at Predbat. (The developer has two EVs too, so it can support that.)

It can be a little daunting at first, but you can set it all up and watch it without letting it take control, just to make sure you are happy with it. Personally, I would now find it hard to manage my system without it.

I tried to do something similar to you, then I started using predbat which just takes care of it now.

PianSom Just looking at PredBat. I run HA in a Docker, so I dont have the addon store, and it seems the HACS method of installing it doesnt seem to be the way forward?

Can I run PredBat as a docker container?

ProximusAl
Yes.

I am a HA Core user, with HA in a Docker container. I have just moved to Predbat in its own container. Here is my docker-compose:

  predbat:
    container_name: predbat
    image: nipar44/predbat_addon:latest
    restart: unless-stopped
    environment:
      - TZ=${TZ}
    volumes:
      - [YOUR_PATH_HERE]/predbat/config:/config
      - /etc/localtime:/etc/localtime:ro
    ports:
      - 5052:5052

But note that this method has an undocumented bug in it at the moment. When you edit your apps.yaml to make it go live you need to delete (and not just comment) the "Template: true" (or something like that!) line

PS this method is new, so has not made the main docs yet. But see here

PianSom OK, up and running.....I guess...

Where should I be looking to configure things (Already had Solcast, GivTcp etc), I mean configure as in how to deal with IO slots, Power Ups etc, or is it really that clever it does it all?

Only warnings in the log are:

27 2024-09-05 12:20:26.028871: Warn: Regular expression argument: carbon_intensity unable to match re🙁sensor.carbon_intensity_uk), now will disable
17 2024-09-05 12:20:26.025801: Warn: Regular expression argument: geserial2 unable to match re:sensor.givtcp2(.+)soc_kwh, now will disable
14 2024-09-05 12:20:26.006868: Warn: unable to find /config/appdaemon.yaml skipping checks as Predbat maybe running outside of AppDaemon
5 2024-09-05 12:20:26.004811: Warn: Failed to decode response from http://192.168.76.2:8123/addons/self/info

ProximusAl
Looks like you are about there.

Have a look at the Config page, make sure there is nothing unexpected in red. Have a look at the apps.yaml page, and make sure that all your feeds are working ok (you should be able to see values next to pretty much everything.

The warnings are nothing to worry about

• 1 I'm guessing you don't have carbon intensity set up
• 2 I'm guessing you only have one inverter, so you can comment out the regex for inverter in apps.yaml
• 3 you are running outside of appdaemon, so that's fine
• 4 as you are running in HA Core you don't have adding, so that's fine

But basically you are there. As it says here, you are ready to light the touch paper. The next step is

Good luck! Have fun.

Oh, it should handle IO slots automatically.

Power-ups need some manual intervention. You need to add to apps.yaml once accepted something like this -

# Power-up input
  rates_import_override:
    - start : "12:00:00"
      end : "16:00:00"
      rate : 0
      date : "2023-12-23"
    - start : "12:00:00"
      end : "16:00:00"
      rate : 0
      date : "2023-12-24"

PianSom Thank You.

So do I need to take off the scheduled charge on the inverter and let PredBat handle that, or will it do it itself?

Only things in red are:

ProximusAl
If I were you I would leave your system in the state it is in for now - it's where you know and understand it.

If you are feeling very brave and just want to go for it then turn off Predbat read-only mode and - yes - turn off the scheduled charge. Most folks seem to be happier watching the plan for a bit though. I know I was!

Does the plan look ok to you now you have enabled "Control charge and discharge"?

PianSom I suppose I better go and read what the plan means before I answer that.

One other question if I may.

The majority of the time, the PHEV is plugged in, which can only charge at 3.7kW.
OI is set up to control my Zappi, but the car I put in is my Tesla, which charges at 7.4.
As the PHEV is mainly plugged in, I set OI to 30% every night which gives me just over 3 hours, enough to charge the PHEV from empty. I mainly charge the Tesla at work, so rarely charge it at home.

Should I change PredBat car_charging_rate to 3.7 due to mainly the PHEV being on every night, or leave it at 7.4?

ProximusAl
I think the answer is 3.7. Because Predbat will only use this value for planning purposes, it won't change the Zappi output in any way.

But you could try asking over on the "First night live on Predbat" thread - https://community.givenergy.cloud/d/3696-first-night-live-on-predbat/1908 - may well be someone there with first hand experience

PianSom Thank You....

I've turned on PredBat, lets see what it can do.
I've added the Carbon Intensity, so that no longer shows in the log.

The only thing left, and I'm not sure if I need be worried or not is this:

ProximusAl
Hmm, on my (AIO) system it seems to pick it up ok from GivTCP:

But the Predbat docs say:

so I suspect that whatever inverter you have doesn't have a Pause mode. In which case you can just comment it out from apps.yaml to prevent the redness I guess.

PianSom I have a Gen2 HY5. Pretty sure I used to have those sensors. Don’t now though. I seem to have a GivTCP Temp Pause Charge instead as a dropdown.

ProximusAl I have a vague recollection that givtcp has an "old firmware" button - perhaps need to clear that to allow the newer features ?

DD I think that was a fair few months ago. I recall GivTCP defaulting to new firmware, and you could switch it to old firmware if you haven’t upgraded the inverter firmware. My inverter is on the latest and greatest firmware for Gen2.

ProximusAl
Are you East of England? Signed up for and told Predbat about tomorrow's Power-up? 🙂

PianSom unfortunately not. Bristol.

I use Home Assistant and have an automation to just tell it to stop the battery discharging when the Zappi is charging (the main trigger) at home (the additional condition). And then a second automation to re-enable discharging when the Zappi stops charging. I might use some grid unnecessarily, but it leaves more energy in the battery which will likely mean more export later, at a higher rate than the grid import.

I'm in a similar situation with IOG & draining batteries outside of paused battery discharge time slots. However, integrating & using HA, Prebat or any other 3rd party automation is above my pay grade. I certainly do not want to incur extra cost to have my system re-wired or replace my Zappi with a GE charger (not available when I had mine installed). The solution I currently use works but, apparently, does not meet the requirements of the IOG tariff.

It's so annoying that a solution to what seems to be a very common problem cannot be found or provided within the std GE Software which, in itself, has taken me the best part of 18months to get to grips with & parts of which are still a mystery to me. Very clunky to use & understand.

This seems to be a common issue with most high tech companies who assume that all their customers are tech savvy, can integrate any number of 3rd party programs to get the results they need & code a space rocket to the moon & back.
Very frustrating.

My two pence worth.

If you are thoroughly enjoying yourself @ProximusAl that's great. If not WonderWatt have taken all that pain/work away with their IOG solution (there is an Agile one too). Once set up you choose if you want the battery to hold(ie charge) whatever time of day Octopus allocate you those pesky 'out of hours' slots. You can also set up all you 'buys' and 'sells' in schedules too.