Feature request: Additional costs

[stigvi]

In Norway, and probably other countries as well, we dont pay for the energy alone. We also have to pay a local company for grid connection. Some of this additional costs are fixed monthly costs, but some are also energy costs added to the price entso-e are providing. And these additional costs are variable based on weekday and time of day.

The Nordpool integration, https://github.com/custom-components/nordpool , handles this quite elegantly by overriding the now() function. Look at the documentation and also on line 265 in https://github.com/custom-components/nordpool/blob/master/custom_components/nordpool/sensor.py on how this is implemented. Also note that all prices the Nordpool integration provides, has these additional costs added, also the list of future prices.
My own configuration is like this:

`
additional_costs: >-

 {% set s = {

    "hourly_fixed_cost": 0.0,

    "night": 0.5426,

    "day": 0.6676,

    "cert": 0.01

    }

  %}

    {% if now().isoweekday() >= 1 and now().isoweekday() <= 5 %}

      {% if now().hour >=6 and now().hour <22 %}

        {{(s.day+s.hourly_fixed_cost+s.cert)|float(0)}}

      {% else %}

        {{(s.night+s.hourly_fixed_cost+s.cert)|float(0)}}

      {% endif %}

    {% else %}

      {{(s.night+s.hourly_fixed_cost+s.cert)|float(0)}}

    {% endif %}`

[blowk]

This would be challenging because every country handles this differently.

In some countries the dynamic price is calculated with Entsoe energy price + fix energy price + additional cost.

A couple of years ago I setup as a sensor in HA that calculates this.

[stigvi]

This would be challenging because every country handles this differently.

In some countries the dynamic price is calculated with Entsoe energy price + fix energy price + additional cost.

A couple of years ago I setup as a sensor in HA that calculates this.

This flexibility is what this feature request have. You can configure almost whatever you want with a template.

[JaccoR]

Getting additional costs per kWh in there is done pretty quickly, however variable costs in summer/winter, day/night or week/weekends is much more work. Especially to get this user friendly. The templating that the Nordpool integration uses is pretty nice, but I think it can be done more user friendly in the initial configuration.

A solution can be using the config flow to set up their template by selecting night/day split, week/weekend split etc. and asking the user for additional costs of these splits.

Come to think of it: A nice solution would be maintaining a list of energy providers and its templates. Then in the initial setup configuration, the user can select their energy provider based on the country they selected and the integration automatically uses the template that comes with that provider. I am not sure if this idea is feasible though.

We can start by implementing a template, like the Nordpool integration does, and work our way up to the list solution. What do you think?

[SVH-Powel]

The Nordpool way of doing this is not very user friendly, I agree on that :-) But not sure a list is feasible. For Norway alone, this list must have 160 different companies/areas. They change their prices each year and sometimes twice a year. It will be a huge job maintaining this list.

[JaccoR]

You're right. That's hopeless work, however it only makes sense to do this for energy providers with hourly tariffs. In the Netherlands there's only 4 energy providers who have this. How is that in Norway?

It could be possible to have a list of known templates and if your provider is not in the list you can select the option to make your own template. We can open a discussion where people can upload their templates to keep the list updated and make use of the power of the community :).

Anyway, I will start a new branch to get the templating into this integration. Any help is welcome!

[jpulakka]

Just want to 👍 I'm also https://github.com/custom-components/nordpool user and its "additional_costs" is absolutely genius feature and it would be great to have it in hass-entso-e. Currently I'm using it to cover

• Transfer price (depending on date / time, can change whenever the local company decides so)
• Taxes (can change whenever the government decides so, e.g. in Finland VAT applied on top electricity tax (!) changes from 24 % to 10 % between 12/2022 ... 4/2023 and probably back to 24 % after that, goot luck keeping templates up to date :)
• Marginal (depending on contract)

It could also be used to handle

• Units (Entsoe uses €/MWh but some of us might prefer snt/kWh)
• Currency conversions Feature request: Multiple currency support #9

[JaccoR]

Alright, additional cost support has been added in the additional cost branch . You can now add your template in the config flow.
Before I merge I will test it out myself. If you have the time, please consider testing it out as well and let me know if you have any issues.

Example template:

{% set s = {
    "hourly_fixed_cost": 0.5352,
    "winter_night": 0.265,
    "winter_day": 0.465,
    "summer_day": 0.284,
    "summer_night": 0.246,
    "cert": 0.01
}
%}
{% if now().month >= 5 and now().month <11 %}
    {% if now().hour >=6 and now().hour <23 %}
        {{s.summer_day+s.hourly_fixed_cost+s.cert|float}}
    {% else %}
        {{s.summer_night+s.hourly_fixed_cost+s.cert|float}}
    {% endif %}
{% else %}
    {% if now().hour >=6 and now().hour <23 %}
        {{s.winter_day+s.hourly_fixed_cost+s.cert|float}}
    {%else%}
        {{s.winter_night+s.hourly_fixed_cost+s.cert|float}}
    {% endif %}
{% endif %}

[JaccoR]

I merged it in the new commit, let me know if you have any issues with it.

[Damazinho]

So how do I interpret this? I live in NL and all we have is additional costs per kWh (Inkoopkosten, Energiekosten, ODE) and additional costs per hour (Netbeheerkosten & Vaste Leveringskosten).

Is it possible to add both types of costs in the template?

[jpulakka]

I merged it in the new commit, let me know if you have any issues with it.

You're so quick @JaccoR :) A few comments:

I got

Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 365, in async_setup
result = await component.async_setup_entry(hass, self)
File "/config/custom_components/entsoe/init.py", line 22, in async_setup_entry
additional_cost = entry.options[CONF_ADDITIONAL]
KeyError: 'additional_cost'`

after the first (re)start after updating (but not yet configuring) the component. Also, after restart, the whole configuration was initially empty, API key etc. had to be re-entered. However after that it worked.

The one-line input textfield isn't exactly optimal for holding a 30+ line template. I wonder what's the HASS philosophy for stuff like this. In the nordpool plugin I used to put everything in configuration.yaml, which is convenient to store in version control and it's clear where the data is, but if "config flow" is used, does a copy of the template need to be stored separately somewhere or how should it be versioned?

Now I also realized one thing. The additional_costs, at least as supported by nordpool plugin, allows adding (possibly time-dependent) fixed (per kWh) costs. But it doesn't know the spot price, so it's not possible to calculate price-dependent relative costs such as VAT, or is it? Yes it is, was added very recently, custom-components/nordpool#165

Created separate issue about VAT: #17

@Damazinho

So how do I interpret this? I live in NL and all we have is additional costs per kWh (Inkoopkosten, Energiekosten, ODE) and additional costs per hour (Netbeheerkosten & Vaste Leveringskosten).

The template, as in the example above, adds additional costs per kWh. Could you please clarify with an example what is additional cost per hour? So if it's really X €/h depending on hour (but not on kWh), then I'm afraid that's not possible to express that as part of hourly electricity price which is in €/kWh.

[Damazinho]

We pay a monthly fee to use the network for our electricity. For me this is €20,10 network management per month and €5,40 delivery fee per month.

[JaccoR]

@jpulakka Thanks for the remarks!

The one-line input textfield isn't exactly optimal for holding a 30+ line template. I wonder what's the HASS philosophy for stuff like this. In the nordpool plugin I used to put everything in configuration.yaml, which is convenient to store in version control and it's clear where the data is, but if "config flow" is used, does a copy of the template need to be stored separately somewhere or how should it be versioned?

I am aware of this. Ideally both the .yaml version and config flow should be possible. I tried a function setting up the platform using yaml, however I could not get it to work (yet). #18
Updating the integration usually does not break the integration and a reinstall is not necessary (now it did, basically a small mistake on my part). Without a reinstall home assistant should keep the same config after updating, even if you used config flow.

The additional_costs, at least as supported by nordpool plugin, allows adding (possibly time-dependent) fixed (per kWh) costs. But it doesn't know the spot price, so it's not possible to calculate price-dependent relative costs such as VAT, or is it? Yes it is, was added very recently, custom-components/nordpool#165

Good one! I quickly looked at nordpools code and I think it should be fairly easy to add current price into the template. I'll look into this. In the nordpool integration, the VAT can be added by a checkbox, but I already saw that the VAT of the Netherlands is outdated. Updating this for all countries could be a bit tiring. Any ideas on how this could be done nicely?

@Damazinho

We pay a monthly fee to use the network for our electricity. For me this is €20,10 network management per month and €5,40 delivery fee per month.

Prices of the integration are in EUR/kWh. Monthly fees are not and the integration does not know how many kWh you consume. Therefore these costs can not be expressed in EUR/kWh. The template is meant for additional costs per kWh.

[Damazinho]

@jpulakka Thanks for the remarks!

The one-line input textfield isn't exactly optimal for holding a 30+ line template. I wonder what's the HASS philosophy for stuff like this. In the nordpool plugin I used to put everything in configuration.yaml, which is convenient to store in version control and it's clear where the data is, but if "config flow" is used, does a copy of the template need to be stored separately somewhere or how should it be versioned?

I am aware of this. Ideally both the .yaml version and config flow should be possible. I tried a function setting up the platform using yaml, however I could not get it to work (yet). Updating the integration usually does not break the integration and a reinstall is not necessary (now it did, basically a small mistake on my part). Without a reinstall home assistant should keep the same config after updating, even if you used config flow.

The additional_costs, at least as supported by nordpool plugin, allows adding (possibly time-dependent) fixed (per kWh) costs. But it doesn't know the spot price, so it's not possible to calculate price-dependent relative costs such as VAT, or is it? Yes it is, was added very recently, custom-components/nordpool#165

Good one! I quickly looked at nordpools code and I think it should be fairly easy to add current price into the template. I'll look into this. In the nordpool integration, the VAT can be added by a checkbox, but I already saw that the VAT of the Netherlands is outdated. Updating this for all countries could be a bit tiring. Any ideas on how this could be done nicely?

@Damazinho

We pay a monthly fee to use the network for our electricity. For me this is €20,10 network management per month and €5,40 delivery fee per month.

Prices of the integration are in EUR/kWh. Monthly fees are not and the integration does not know how many kWh you consume. Therefore these costs can not be expressed in EUR/kWh. The template is meant for additional costs per kWh.

So what exactly is the "hourly_fixed_cost": 0.0, ?

[jpulakka]

@JaccoR

Thanks for creating #18 ! I may be in the minority preferring configuration.yaml over config flow but I'm not the only one :)

Also, it's excellent to get current price available in additional costs. With that (and (fake) time, which it already has) it should be possible to handle anything imaginable in the template.

In the nordpool integration, the VAT can be added by a checkbox, but I already saw that the VAT of the Netherlands is outdated. Updating this for all countries could be a bit tiring. Any ideas on how this could be done nicely?

As discussed in #17 it's probably best to just let it be a percentage number, to be edited by the user. Very little extra inconvenience for the user, very much relief for the maintainer = excellent trade-off.

[SVH-Powel]

So what exactly is the "hourly_fixed_cost": 0.0, ?

hourly fixed cost is whatever you want it to be. It could be the base price. If you dont need it, simply remove it and create a template for your own needs. It could be

additional_costs: "{{0.05|float}}"

if the additional costs are not dependent on time of day and €0.05

[JaccoR]

I was working on getting price dependent additional costs in when i stumbled on a discussion point. In the Netherlands VAT is added as a percentage of the day-ahead-price + extra cost as a whole. So intuitively I set the template as:

{{(price + extra_cost)*(1 + VAT) | float}}

This is not right as I should have set the added cost instead of altering the price. It should have been:

{{extra_cost + (price + extra_cost) * VAT | float}}

I had to think twice to realize the added cost template is not altering the price but is something that is added to the price.

What do you think: Should the template alter the price as shown in the first example or should it only represent the added cost as in the second example?

[jpulakka]

@JaccoR Yep, there are two ways in which it could work.

I don't have strong opinions about which way it should be, but I have an opinion that the functionality should be reflected by the name.

Nordpool's additional_costs are additional, as the name says. It made perfect sense originally, when it could only be used to add (time-dependent) constants to the price. But when current_price was provided to the template, then it became maybe just a bit more confusing intuitively, even though it still does exactly what it says.

If we would modify the price directly in the template, rather than provide something to be added to the price, then it should be called something like "price_modifier" rather than "additional_costs", to make it clearer what exactly it does from the name.

[SVH-Powel]

With modified prices we are able to do currency conversion in the template. But perhaps not that interesting as most of europe is using euro anyway..........

[JaccoR]

I think the price modifyer is more intuitive. I will go with that one and call it Price Modifyer Template,

[SVH-Powel]

I did a test with this template:

{% if now().isoweekday() >= 1 and now().isoweekday() <= 5 %}
{% if now().hour >= 22 and now().hour < 6 %}
{{3}}
{% else %}
{{2}}
{% endif %}
{% else %}
{{1}}
{% endif %}

and I got these prices:

prices:

• time: '2022-10-14 00:00:00+02:00'
  price: 2

• time: '2022-10-14 01:00:00+02:00'
  price: 2

• time: '2022-10-14 02:00:00+02:00'
  price: 2

• time: '2022-10-14 03:00:00+02:00'
  price: 2

• time: '2022-10-14 04:00:00+02:00'
  price: 2

• time: '2022-10-14 05:00:00+02:00'
  price: 2

• time: '2022-10-14 06:00:00+02:00'
  price: 2

• time: '2022-10-14 07:00:00+02:00'
  price: 2

• time: '2022-10-14 08:00:00+02:00'
  price: 2

• time: '2022-10-14 09:00:00+02:00'
  price: 2

• time: '2022-10-14 10:00:00+02:00'
  price: 2

• time: '2022-10-14 11:00:00+02:00'
  price: 2

• time: '2022-10-14 12:00:00+02:00'
  price: 2

• time: '2022-10-14 13:00:00+02:00'
  price: 2

• time: '2022-10-14 14:00:00+02:00'
  price: 2

• time: '2022-10-14 15:00:00+02:00'
  price: 2

• time: '2022-10-14 16:00:00+02:00'
  price: 2

• time: '2022-10-14 17:00:00+02:00'
  price: 2

• time: '2022-10-14 18:00:00+02:00'
  price: 2

• time: '2022-10-14 19:00:00+02:00'
  price: 2

• time: '2022-10-14 20:00:00+02:00'
  price: 2

• time: '2022-10-14 21:00:00+02:00'
  price: 2

• time: '2022-10-14 22:00:00+02:00'
  price: 2

• time: '2022-10-14 23:00:00+02:00'
  price: 2

  I would expect the price to change between 2 and 3 and not be 2 all day

[jpulakka]

@SVH-Powel

This doesn't look right

{% if now().hour >= 22 and now().hour < 6 %}

You probably want to have or there.

[SVH-Powel]

@SVH-Powel

This doesn't look right

{% if now().hour >= 22 and now().hour < 6 %}

You probably want to have or there.

Of course. It is one of those days, today .........

So forget my previous post. Everything is OK, except me which needs one more cup of coffee

[ikke-zelf]

For the NL I use this template:
Sorry, I have no idea how to indent this in git to show a nice yaml formatted piece of code.

{% set s = {
    "extra_cost": 0.018,
    "voorschot_cvo": 0.0001,
    "energie_belasting": 0.04,
    "ode_belasting": 0.03,
    "VAT": 1.21,
    "VAT_discount": 1.09
}
%}
{% if now().year <= 2022 %}
    {{(current_price + s.extra_cost + s.voorschot_cvo + s.energie_belasting + s.ode_belasting) * s.VAT_discount | float}}
{% else %}
    {{(current_price + s.extra_cost + s.voorschot_cvo + s.energie_belasting + s.ode_belasting) * s.VAT | float}}
{% endif %}

[Damazinho]

For the NL I use this template: Sorry, I have no idea how to indent this in git to show a nice yaml formatted piece of code.

{% set s = { "extra_cost": 0.018, "voorschot_cvo": 0.0001, "energie_belasting": 0.04, "ode_belasting": 0.03, "VAT": 1.21, "VAT_discount": 1.09 } %} {% if now().year <= 2022 %} {{(current_price + s.extra_cost + s.voorschot_cvo + s.energie_belasting + s.ode_belasting) * s.VAT_discount | float}} {% else %} {{(current_price + s.extra_cost + s.voorschot_cvo + s.energie_belasting + s.ode_belasting) * s.VAT | float}} {% endif %}

This one gives: Invalid Template, Check https://github.com/JaccoR/hass-entso-e when trying to add?

[Hellowlol]

Hi! Nice to see that somebody created a entso-e sensor! This was my backup plan when nordpool shutdown the api.

Just a couple to tips to reduce the amount of in unneeded issues. (And save yourself some headache) consider raising an exception if current_price is missing from the template.

allow the user to set the currency in the settings. It’s possible to use the template to convert the price to a different currency, but the sensors currency will still be wrong.

Nice work! 👏

[ikke-zelf]

For the NL I use this template: Sorry, I have no idea how to indent this in git to show a nice yaml formatted piece of code.
{% set s = { "extra_cost": 0.018, "voorschot_cvo": 0.0001, "energie_belasting": 0.04, "ode_belasting": 0.03, "VAT": 1.21, "VAT_discount": 1.09 } %} {% if now().year <= 2022 %} {{(current_price + s.extra_cost + s.voorschot_cvo + s.energie_belasting + s.ode_belasting) * s.VAT_discount | float}} {% else %} {{(current_price + s.extra_cost + s.voorschot_cvo + s.energie_belasting + s.ode_belasting) * s.VAT | float}} {% endif %}

This one gives: Invalid Template, Check https://github.com/JaccoR/hass-entso-e when trying to add?

updated the post

[JaccoR]

I opened a discussion category where you can find and share templates!

If you share, please mention the country and the energy provider, so people can copy it.

[JaccoR]

@Hellowlol

Hi! Nice to see that somebody created a entso-e sensor! This was my backup plan when nordpool shutdown the api.

Thanks!

Just a couple to tips to reduce the amount of in unneeded issues. (And save yourself some headache) consider raising an exception if current_price is missing from the template.

Good thinking! I will add it to my todo list.

allow the user to set the currency in the settings. It’s possible to use the template to convert the price to a different currency, but the sensors currency will still be wrong.

Yes I was already thinking about it. The ENSTO-e API only gives price in EUR. As exchange rates change over time this means you have to keep updating the template when using the template for this. When an exchange rate is provided by the integration it means this exchange rate needs come from an API or something. See #9.
I could build something where you can choose the currency unit of the sensor, but this would not solve the above problems. I am not sure how to handle this yet.

[Hellowlol]

@JaccoR imo you don’t need to solve the currency. The user should provide a sensor that has the convertion rate and do the calculation in the template. If they cant be bothered they can always use the nordpool integration as their api support multiple currency

[SVH-Powel]

Is it possible to support a syntax like this?

{{(current_price * states("sensor.currency")) | float}}

I dont know the system for evaluating template values in an integration like this, but if other sensor values could be evaluated, then this is an easy solution for currency conversion.

[ThorAlex87]

@Hellowlol I think in many cases it's not "can't be bothered" but more "have no idea how to". I'm in that last category, i can spend hours making some copy-pasta and half the time somehow make it work, but I would certainly appreciate an easy solution.

[JaccoR]

@SVH-Powel tbh i have no idea if that would work. Would probably work though!

[Hellowlol]

@JaccoR @SVH-Powel thats the idea. It should work out of the box. You can easily test this in the template page in ha. You have to substitute current_price with some random value ofc

[SVH-Powel]

@JaccoR @SVH-Powel thats the idea. It should work out of the box. You can easily test this in the template page in ha. You have to substitute current_price with some random value ofc

Yes, it works and is a perfect solution for me

{% set s = {
"day": 0.6676,
"night": 0.5426,
"cert": 0.01,
"vat": 1.25,
"eur": float(states('sensor.kurs_eur'), 10)
}
%}
{% if now().isoweekday() >= 1 and now().isoweekday() <= 5 %}
{% if now().hour >= 6 and now().hour < 22 %}
{{(current_price * s.eur * s.vat + s.day + s.cert) | float}}
{% else %}
{{(current_price * s.eur * s.vat + s.night + s.cert) | float}}
{% endif %}
{% else %}
{{(current_price * s.eur * s.vat + s.night + s.cert) | float}}
{% endif %}

[JaccoR]

I'll close this issue for now.