Czech energy cost rate sensor

If you’re using an energy provider that sells energy based on the energy market price (, like - you can use this integration to get the current energy cost:

The integration currently supports fetching the cost in euro per megawatt hour, but I’ve provided instructions how to convert it to CZK/kWh if you want to automatically calculate your energy costs in the energy dashboard.

You can easily install it by adding a custom repository in HACS.

I’ll be adding more features to it, like automatic rate conversion, and conversion between multiple units of measure - for now - it is what it is. I hope you’ll find it useful.

that’s awesome! That’s exactly what I’m looking for and I’m trying to parse OTE directly, but I can’t do it at all!
I have only a few questions / comments.
1.) Is it possible to view the whole day, not just the current price?
2.) I have a feeling that you have the value shifted by an hour. It’s 3pm now, but you still get the price from 2pm.
3.) What is most important to me, can you also display prices for the next day? I would like to run electricity on the grid accordingly, start the device and charge the batteries.

Anyway, it’s an amazing job and thank you for it!

1 Like

Hey, thanks for the feedback. My answers will be in the same order as your questions:

  1. I wasn’t able to figure out a good way of doing it, using HA sensors. Not sure how exactly to present it. Having a text variable isn’t going to do it. It should be something consumable by automations. Any idea on how the data would be presented?
  2. The value is not shifted - the way they represent it on the website is not intuitive. They start the day from first hour, and finish it with 24th. Meaning that line 8 in their table means 7:00 to 7:59, and 24 is 23:00 to 23:59.
  3. That’s same as #1 i can retrieve the values, but no idea what kind of sensor to use. I’d be able to return a true value for cheapest hour of the day so you could use it in automations like if cheapest hour is true - start dishwasher, problem is that various programs are longer than 1 hour and you risk to start charging your car during cheapest, but then continue charging it during the most expensive 4-5 hours… I’m thinking about passing time periods to the automation - like charge periods. 1 hour, 3 hours, 7 hours - and the integration would return if the condition is met (from now next N hours are going to be the cheapest). But that has another problem - you may have different tariff that is not accounted for - so I need to introduce factoring in the cost of transport into the calculation. Making it slightly more complex. It’s not impossible to do, just not trivial and I didn’t have much time to work on it. Have it on my to-do list though. But most importantly, the counters used by PRE, and other companies in CR do not send realtime data. The company selling you energy has no idea if you consumed the electricity at 5pm or 7 pm at night. They only know how much was total consumption in a given period during specific tarif (HD0). The energy companies are using some kind of models to estimate when an usual household uses how much energy based on some statistical data, so the information provided by this integration is mostly informational - so you’d have an idea of how much your household consumes.

Hi, thank you for the quick reply.
1.) Unfortunately, I am not a developer in python, but it should be solvable using attributes such as rate exchange. The entity shows a single state, but when you look at the attributes, you will see all the available currencies for you to reach with a template. On this basis, you can then create your own sensors. Just get a table with data into HASS, automation on this basis can be solved by everyone.
2.) That would be solved by the first point, it would be up to everyone to understand it. :slight_smile:
3.) As in the previous case, it will not be necessary to do any special automation, if the values ​​for the first day are loaded into the attributes, everyone can write their own automation. The next day they are updated sometime around 1 pm and you can see what the prices will be the next day.
As you mentioned “Bezdodavatele”, if you have a photovoltaic power plant, the distributor must replace the electricity meter with a 4-quadrant meter that sends the meter status every 15 minutes. This data is taken over by the Bezdodavatele and charged by the hour. If you consume 3kWh at 10 am today, you will pay 0.2447 * 3 Euro. Your application has really huge potential, there are several people in the FCB group on PV that use HASS and deal with spot prices.

Like this

    def extra_state_attributes(self):
        """Return other attributes of the sensor."""
        attr =

        return attr

That’s a good idea. Will add it and let you know.

1 Like

There you go:
Should be available for update via HACS

1 Like

WOW, you’re awesome! Thank you very much, it is more than useful, I have already shared it with others.
Do you plan to do that information for the next day? That information is not there yet, but it will be in a few hours, it would also be very useful. :slight_smile: You just need to add the date and update at the right time, for example today + 1 day and update every day, for example at 4 p.m.

Well, since I have you here, the conversion to kWh and CZK does not work for me. I also added open exchange rates, used your code, but it shows me zero.

EDIT: In the manual you have sensor.exchange_rate, but the sensor is actually called sensor.exchange_rate_sensor.

I just fixed a small bug introduced by the previous release:

For the next day - yes, I’ll do that - however not using the attributes. It needs to be a configurable window that will be set to true or false, depending on the total cost of charging/using appliances in that window (including transport cost).

For the exchange rate - if your value is zero - it means one of the variables is zero, either CURRENT_PRICE or EUR_CZK. You need to have both sensor.current_ote_energy_cost and sensor.echange_rate sensors in a non-zero state. I hope it works.

This is amazing work, the exchange rate was a problem of the sensor name from your manual, see edit above. :slight_smile: Now it works as it should.

Great, that’ll be another great thing. I just wonder if it would not be possible to choose the date from which I would like to read the amounts. So in the sensor template I will set yesterday or even tomorrow and it will throw away the values. Again, this could be at the discretion of the user he wants to read.

EDIT: I think you’re still wrong in that current hour. My impression is that Hour = 1 means 00: 00-01: 00, Hour 13 means 12: 00-13: 00, Hour 24 means 23: 00-23: 59: 59. It’s maybe like the first hour, the thirteenth hour, the twenty-fourth hour, etc. But those are really details, I can change them via the template. :slight_smile:

EDIT2: Actually, your original explanation was correct, it just didn’t show up correctly. Currently at 13:06 (ie 13:00-13:59) it shows the price of 199.42, which is at “12 hodina” (11: 00-11: 59). I think it shows a shift of 2 hours.

EDIT3: I have a problem reading attributes. Cannot read with: {{state_attr ('sensor.current_ote_energy_cost', '11')}}
Do you think there could be a problem with quotes? It’s not in quotes in any other entity or sensor.


sensor.czk_price_per_kwh does not display the price calculated from EUR, but from USD.
I edited code to

state_attr('sensor.exchange_rate_sensor', 'USD')/state_attr('sensor.exchange_rate_sensor', 'EUR')*state_attr('sensor.exchange_rate_sensor', 'CZK')

Hello, any news? With attribute and tomorrow prices? :slight_smile:

Oh, I will not have time for that any time soon. Especially for the reasons I’ve explained earlier: only a small number of people in CZ have smart meters that report back to the energy company in realtime. For anyone else the time of energy consumption doesn’t matter beyond HD0.

Hi Vadim,

could you please add PEAK and OFFPEAK sensors ?

btw you can read peak/offpeak via shelly 1 pm.

Many thanks
Karel Peran

There are already integrations providing HD0 information for PRE and CEZ:

Yep but those integration are not exact. There are differences sometimes in ± 20 mins.

The right way of solving it - is reporting those issues to the maintainers, instead of re-implementing the functionality elsewhere.

Looks like you haven’t deep dive to this topic. In general time on web is just expected switch not real switch between peak and offpeak. Exact time is ordered by the current situation in distribution network. Solution with shelly is for exact switch :slight_smile:

Anyway this is offtopic. I was asking if you could add support for offpeak and peak price from ote webpages.

Thank you