Energy Supplier tariff abstraction

[Blueboater2]

Many energy suppliers offer variable tariffs that alter by time of day or by the spot price of the energy that they supply. Typical of this in the UK is Economy 7 which offered 7 hours of cheaper electricity over night and was used to run electrical storage heaters. It would be fairly simple to add an automation to use this to drive additional systems that could make use of this cheap electricity.

The issue is that every supplier offers different tariffs at different times of day with different costs and uses different naming conventions. Using this data in automations requires the creation of custom template sensors, and every HA user will create their own set of names for the tariffs. It’s horribly implementational.

What would be useful would be a generic entity called power mode that everyone could use and defined a set of standard charging rates e.g. Peak rate, Standard Rate, Low Cost Rate, Free rate (negatively priced) etc. This entity would allow standard energy management integrations to be made or easily added into existing systems. Changing suppliers would be a simple case of attaching the source of these integrations to the suppliers add on, everything else would be unchanged.

[hahuzar]

How often does your tariff change?

IMHO, it is not needed to give names, what I do is store the prices. My current supplier has a regular low+normal tariff, but I might switch to a supplier with dynamic prices that change at hourly rate (at the full hour), so I started a Node-RED flow that creates a prices series, x eurocents every hour in influxDB. Then can sort of vector multiply that by the hourly average kWh of various real and virtual counters. That virtual counters is to see what-if a scenario would cost me or save me. It is not HA based as it is way to proprietary and on old data and I know my way in influxQL fairly well but new on HA.

[Blueboater2]

It’s not the change in tariffs that I’m interested in, it’s the ability to link behaviour to something that is standardised. I can then exchange blueprints/automations with other installations knowing that they won’t need to be re-written due to someone using different language to describe a common object. As dynamic pricing becomes more common and people start to manage their energy more closely the ability to exchange blueprints that have energy management behaviours would become more common, and a common abstraction and a standardised API would assist in that.

[hahuzar]

What is the scope of when you say ‘standardised’? Is it within HA or should that also include other homeautomation software? Like Domoticz for example. And what about suppliers that sponsor you via a battery lease and provide you with a smartphone app and cloud account?

[Blueboater2]

I’m thinking just inside HA, not wider. (I’ve played the international standards alignment game at work and it’s not fun!)
Once HA has a standard definition then it’s up to others whether they want to align with the convention or not.

[hahuzar]

OK, I also assumed within HA. But I currently don’t know where to start. My background is mobile telecoms, so all about communications so more or less forced to create a standard. For the numbering scheme and accounting, w.r.t. 2G and 3G, it is probably the best the world can have. The companies behind it have operations in many countries, so part of that is why it is like it is. With 4G voice, there is no standard, there is only IP packet data, so 4G voice is quite a mess.

I compare this how electricity companies operate. You might know that Linux Torwalds couldn’t work on the linux kernel repos some months ago because he had no electricity. I at the moment found some raw JSON file I downloaded from my supplier 20 months ago, parsed it with Node-RED and see that the company had estimated my TV and washingmachine usage. I actually don’t have a TV. Because I allowed them to read-out my smartmeter (or forgot to dis-allow them).

So this is all about money and local/regional companies trying to play monopolist, use your data to estimate how much they can let you pay. So that is why I think energy should come with a pricetag. Like power=voltage*current, energy per timeunit shall have a pricetag. In NL there is a website where you can download per hour kWh rates for more than ten companies as JSON array. So I consider granularity of 1 hour, also because it is ‘kiloWatt per hour’. Looking at my solar invertors, there is enormous variation in 1 hour timeframe.

I have no battery, so let’s say at 12:15 I want to cook rice but then a lot of clouds, so I need most power from the grid. But at 12:30, all clouds gone, so 2kW power for 15 minutes at least, so I cook my rice on pure solar energy.

Because in NL there is a rule/law to equalize used energy with delivered energy on a yearly basis, there is currently no real financial issue. But it will come, as the grid is overloaded on sunny timeframes.

As sort of test, I made a SCR based 2kW dimmer for my waterboiler of 120Liters. It ‘follows the power of the sun’, it only uses excess solar energy. I wish the boiler was a battery, but currently financially not interesting enough to buy one.

[bartkummel]

I think we actually have two different problems here, that are related:

• We have tariffs that change per hour (or possibly other interval) and are published a day in advance (or possibly on longer or shorter notice).
• We want to make decisions based on the tariff, in a more or less abstract way. So we don’t want have logic like “if price is below € 0,20”, but rather “if energy is cheap”

So I’d say, HA needs:

• A uniform way to store tariffs, both historical and for the (near) future.
  • The interval by which the tariff changes can be different per energy company
  • The notice period of new tariffs can differ per energy company
• A uniform way to categorized tariffs, like “cheap”, “average”, “expensive”.

[Blueboater2]

That’s exactly it.

As an example:-
I’ve got an electrically heated towel rail in the bathroom. Pressing the button kicks off a script that runs it for 30 minutes. If electricity is “peak rate” it doesn’t turn on. If its “free rate” it’s turned on irrespective of any button presses.

What “peak rate” and “free rate” means is different to each user. For some “free rate” could be negatively priced energy from their suppliers. For others it could be that their solar is producing a surplus of power and they’d rather use it than send it to the supplier.

The abstraction allows common automations and blueprints but lets users trigger the power modes according to their own requirements.