Tariff Automation behaviour inconsistent

8 comments started 2023-01-01 last 2023-01-02
Home AutomationGivEnergy ProductsBatteryHome Assistant
L
#1 LordHippos

I've been using a setup to achieve two charging windows, my issue is that the behaviour of this seems inconsistent. More details below:

Charging window 1 - Octopus Go Tariff Automation
Charging window 2 - 17:00 - 19:00 target SOC 45%

Charging window 1 is done simply by enabling the Octopus Go tariff automation option.
Charging Window 2 is set by using Home Assistant to control AC Charge time and target SOC %.

In theory I could do both windows by updating the value with Home Assistant for AC charge but I wanted a fail safe in case the dongle lost connection (not that uncommon) or Home Assistant stopped operating. Charging Window 1 is the most important one, so I figure I'll let the inverter control that and charge up even if I've changed the values in the day manually or via HA.

On the night of 28/12 00:30 - 04:30 the tariff automation didn't fire at all, and my battery failed to charge until I noticed it and manually charged it half way through the window.

On that same day, the alternate charging window of 17:00 - 19:00 with a target SOC of 45% charged the battery to 57% so overshot the expected value. I think it only stopped because it reached the time rather than SOC target.

Today, 01/01/2023 00:30 - 04:30, the battery charged as it should but instead of using grid to power the home, once the charge completed at 04:10 it started consuming the battery. This is not the same sort of behaviour I've seen historically, looking back at my stats I can see back in October/Early November it would generally put all house load onto the grid for the entire duration of the AC charge window.

See the screenshot below (right click open in new tab for larger size), the charge ended at 04:10 and the power consumption for the next 20 minutes is from battery instead of grid:

Image

I've raised the missing tariff automation firing on 28/12 with GE support but they've not been able to provide any insight as to why it was missed or what could potentially have caused it to be missed, I was hoping that some detail into how it works might have been mentioned, because if the inverter is f.ex reliant on an external API to trigger, then that being offline could have caused the issue.

Has anyone got any info on how this works they can share, or had any similar experiences where the behaviour of the tariff automation is not seeming that reliable?

C
#2 cluelesscris

LordHippos I believe the second charging window is not working at the moment. Everyone that needs one uses their own automations to achieve it.

S
#3 stevelewis

LordHippos Disable automations and use a single solution to set both. If you already have HA set up, use it... to quote a proverb, a dog cannot have two masters.

L
#4 LordHippos

stevelewis

I thought that might be the answer, but anything you set externally is always going to be less than 100% reliable, even using HA I am a) hoping HA is up and running and b) that at the exact moment in time it executes the dongle isn't disconnected from the wifi, which it sometimes seems to lose connection to.

To work around b) I'm asking HA to set it a few times instead of just once, as if the wifi is offline it should catch it on attempt #2 or #3 later on. Speaking of, I believe the memory on the inverter isn't limitless, in an ideal world I would issue the desired state once an hour and hope for the best, but I think I'd eventually eat up all of the writable events doing this?

The best solution is two charge windows being available to be configured, hopefully one day, then I can just leave the overnight one at 100% at this time of year. In the spring/summer I may want to scale the charge back based on solcast predictions for the next day (another challenge for later).

S
#5 stevelewis

LordHippos presimably HA writes the configuration settings to the GE server using the API and receives an acknowledgment, rather than writing directly to the inverter registers? At least that's how I'm doing it with my Python code, so any short-term WiFi drop outs are less of an issue.

You're welcome to have a play with my code as it already has both the Solcast integration and a second charging period up and running. 😁

L
#6 LordHippos

stevelewis

It's using local updating with this repo via Home Assistant/HACS:

https://github.com/cdpuk/givenergy-local

This also handles the pvoutput stuff, so whilst I could change to using something else entirely, it's possibly better to stick with this for now and work out how to add Solcast stuff here.

S
#7 stevelewis

LordHippos I'm also uploading to PVOuput.org every 5 minutes... have been doing this since 2013.

BTW, I'm saving 10 parameters to pvoutput vs the 3 which appear in the GIVTCP code example.

    "v1"  : ge.pv_energy,
    "v2"  : ge.pv_power,
    "v3"  : ge.grid_energy,
    "v4"  : load_pwr,
    "v5"  : env_obj.temp_deg_c,
    "v6"  : ge.line_voltage,
    "v7"  : "",
    "v8"  : batt_power_out,
    "v9"  : env_obj.co2_intensity,
    "v10" : CO2_USAGE_VAR,
    "v11" : batt_power_in,
    "v12" : ge.soc
L
#8 LordHippos

stevelewis

Thanks, I am going to try setting this with HA instead of the tariff automation then, see how it goes.

I'd like to be able to read the current values and just skip setting them if they're already set, but it doesn't seem quite that simple in HA, a job for another time maybe.

The additional values look interesting but I'm pretty happy with the basics just tracking the generation and peak values I think!