Detecting grid outages

Hi,
I am happily using HA and predbat with my AIO and gateway and am considering moving my two non-protected circuits back onto the main consumer unit.

When the system was installed, I deliberately separated my cooker and my wife's studio from the rest of the house. The rationale was that in the unlikely event of a power cut, these two circuits alone could exceed the 6kW capability of my AIO.

Now that I have HA, I realise that I could move these circuits by having smart RCBs that could be controlled by HA. They would be programmed to trip only if total load exceeded 6kW AND there was no grid supply.

I can easily use GivTCP to determine the battery load, but how best do i determine whether the system is attached to the grid?

Weasel I can easily use GivTCP to determine the battery load, but how best do i determine whether the system is attached to the grid?

Not heard of smart RCBs that you can control by HA. Clever stuff.

The way most of us detect whether the grid is connected is to look at the givtcp grid frequency sensor. If less than 49Hz then grid power is lost, if greater than 49 then grid power is restored.

I have the following automation notification copied from someone else on this forum:

alias: Grid Status Notifications
description: Notifies loss / resumption of grid status to home battery system
mode: single
triggers:
  - entity_id:
      - sensor.givtcp_xxxx_grid_frequency
    for:
      seconds: 10
    below: 49
    id: grid_lost
    trigger: numeric_state
  - entity_id:
      - sensor.givtcp_xxxx_grid_frequency
    for:
      seconds: 10
    above: 49
    id: grid_resumed
    trigger: numeric_state
conditions:
  - alias: Uptime is more than 1 min
    condition: template
    value_template: "{{ as_timestamp(now()) - as_timestamp(states('sensor.uptime')) >= 60 }}"
actions:
  - if:
      - condition: trigger
        id:
          - grid_lost
    then:
      - data:
          title: Power Cut
          message: >
            Connection to the grid lost - house is on battery. Current load is
            {{ states('sensor.givtcp_xxxx_load_power')|int }}kW. Current SoC is
            {{ states('sensor.givtcp_xxxx_soc')|int }}%. Battery will last
            approximately {{              
            ((states('sensor.givtcp_xxxx_discharge_time_remaining')|int)/60)|int              
            }} hours.
          critical: "Y"
        action: script.notify_all_devices
  - if:
      - condition: trigger
        id:
          - grid_resumed
    then:
      - data:
          title: Grid Power Restored
          message: >
            Connection to the grid resumed. Current load is {{
            states('sensor.givtcp_xxxx_load_power')|int }}kW. Current SoC is {{
            states('sensor.givtcp_xxxx_soc')|int }}%.
        action: script.notify_all_devices

The check on uptime (you have to enable this sensor) is to detect whether HA has been running as otherwise you get a false alert when you first start HA up. If however I reboot HA I still get a false alert, so its not perfect yet

geoffreycoan Thank you sir, that is a most ingenious solution.
I will dig out the details on the RCB and post later. I bought the RCB originally to monitor the load on the circuit and the ability to connect it to TuyaSmart was a bonus. I think it might even support Zigbee as well as Wi-Fi

Thanks also for the idea on startup and avoiding false positives.

isn't there a problem that you have poll rather frequently in order to discover grid outage in a timely fashion - quickly enough to turn off high-powered circuits. I think I'd be quite nervous of relying on some active software to detect and respond. What if a brownout crashes the computer you're relying on?

Can it be done with something passive. Like a contactor just unconditionally switched by a mains feed. So if the grid fails, the contactor opens. Is there an output from the gateway which is not powered when the grid goes off.

Hmm... that doesn't really fulfil requirements. Maybe use a CT clamp in a passive circuit to detect when load exceeds 6kW so that the contactor only opens then.

DD Your point is well made DD and I suppose I am just trying to squeeze every last saving from my battery. In addition to my AIO, I have 4x APC UPSs to provide protection for mine and my wife's computers, the internet router and main switch - plus the TV, main Virgin Media box, streaming boxes and sound bar. my HA Green is connected to the latter so is unlikely to suffer from a brownout, but your point on polling intervals has made me think.

The main downside to having the cooker and studio circuits unprotected is that I cannot use the battery energy so must pay the prevailing rate for their use.

• The studio is relatively simple because I can control when the heat pump comes on and so far I only have it running during Cozy periods and this is sufficient. During other periods, the usage is relatively light, so I just bite the bullet and accept the the 2kW hot-water heater might run for a few minutes for a top-up. The other gadgetry draws a constant 40-50w total, so won't break the bank. So far, the heat-pump initially spikes at around 2kW and once up to temperature drops to an intermittent 400w. Obviously this might increase in colder weather.
• The cooker is a double-oven of which one is rarely used, so I could consider using my combination microwave if I really want to minimise any peak-period consumption

All of the above is really stretching the law of diminishing returns, so I may well leave things as-is

What about a manual changeover switch with those circuits moved to a separate consumer unit - so normally they are on the grid, but you can make a decision to switch them to backup power if need be?

Weasel The main downside to having the cooker and studio circuits unprotected is that I cannot use the battery energy

Does that necessarily follow? Is the problem that the CT clamp doesn't catch their usage? Eg if you were forcibly exporting from the battery while the cooker was on, it would consume the power.

DD Good point. I may well be catching some benefit if I am forcibly exporting. Either way, I am fiddling around the edges at this point.

I will have a look at when predbat does it's force discharge and this may correspond with my oven usage

To your earlier point DD, the CT clamp is placed near my gateway which is a couple of metres away from the main consumer unit, and the two high-load circuits are split off immediately after the smart meter into their own separate consumer unit. Therefore their usage is not measured by the GivEnergy system - although one of the circuits has its own power monitoring RCB, so I can see how much the studio is using

A quick scan of the latest predbat predictions for the next few days puts my usual cooking window squarely in a forced export period from the battery - therefore I will generally be running my oven from the battery output anyway. The export figures recorded by my AIO will obviously diverge from those of Octopus, but overall, I will benefit because I will not be paying peak-rate prices, but rather sacrificing my 15p export rate

Weasel I will have a look at when predbat does it's force discharge and this may correspond with my oven usage

In principle, an external agent could monitor consumption of oven and force battery discharge to cover ithe ysage.

DD I suppose you are right, but now I realize that predbat has a forced discharge pretty much where I would be using the oven anyway, I am not sure I can be bothered at the moment 🙂