A reliable way of triggering automations only when Nordpool price period changes about nordpool HOT 9 CLOSED

I use pyscript custom component. I have a numeric sensor which controls amount of hours I want to heat the house. The triggered function runs every 10 minutes. It calculates lowest x prices and checks if current hour is included in this lowest x prices array. Depending on that it turns on/off climate sensor that controls if heating should be turned on or off.

from nordpool.

Just use the state change.

The integration uses self._attr_force_update = True

meaning if will force a state change regardless if the value is identical

from nordpool.

Thanks for clarifying that the integration updates its status even when the value is identical. This is very great!

However, there is still an issue that the integration state changes for other reasons as well. I need only trigger for price period changes and I have no way of filtering these other state changes away.

In the attached picture the price is right at midnight. The switch is turned on and the price is removed from the "right prices list". Then the switch is turned immediately off again at midnight, because there is another state change and trigger and the price is not anymore in the "right price list" because it is assumed to be used.

My guess would be that the other state change is related to housekeeping where tomorrow data is copied to today and other stuff.

Another case is when new tomorrow data becomes available. The integration creates a state change trigger which is not related to price period change.

from nordpool.

I use pyscript custom component. I have a numeric sensor which controls amount of hours I want to heat the house. The triggered function runs every 10 minutes. It calculates lowest x prices and checks if current hour is included in this lowest x prices array. Depending on that it turns on/off climate sensor that controls if heating should be turned on or off.

This works almost all times. There are edge cases, though. If heating is wanted for 2 cheapest hours and the price array is like [10, 10,10,0], then the heater is on for all four hours with this simple approach... I intend to use this to charge EV, so practically in this scenario batttery would become full almost certainly from the first three most expensive allowed hours and the cheapest one in the end would have little use.

Not the most common scenario, sure, but it would be nice to take this situation into account as well.

from nordpool.

No, it works correctly all the time =). Otherwise, that would be a bug in algorithm.

Here is the code:

import datetime
import zoneinfo

def n_lowest(n, candidates: dict):
    candidates_clean = filter(lambda x: x["value"] is not None, candidates)
    return sorted(candidates_clean, key=lambda x: x["value"])[:n]

def find_price(dt, candidates):
    for x in candidates:
        if x["start"] <= dt < x["end"]:
            return x

def filter_today(candidates):
    return filter(lambda x: x["start"].day == datetime.date.today().day, candidates)


@service
def update_heating(entity_id):
    current_hour = datetime.datetime.now(tz=zoneinfo.ZoneInfo(key='Europe/Tallinn'))

    candidates = sensor.nordpool_kwh_ee_eur_3_095_02.raw_today + sensor.nordpool_kwh_ee_eur_3_095_02.raw_tomorrow
    hours_to_heat = int(float(input_number.hours_to_heat))
    today_candidates = filter_today(candidates)

    cheap_hours = n_lowest(hours_to_heat, today_candidates)
    should_heat = find_price(current_hour, cheap_hours) is not None
    if should_heat:
        climate.turn_on(entity_id=entity_id)
    else:
        climate.turn_off(entity_id=entity_id)

from nordpool.

I have reread your message, and you are correct. The last hour of charging consumes much less power as well.

from nordpool.

Split hours into more slots. Per 5/10 minutes. If you know exactly how long you need to charge, then you can calculate how many slots you need.

from nordpool.

Split hours into more slots. Per 5/10 minutes. If you know exactly how long you need to charge, then you can calculate how many slots you need.

I'm afraid I don't quite get what are you aiming at by "splitting hours". For me, it is quite enough to tell something "charge 2 cheapest hours"

My original problem is, that when the cheap price is marked as "used", an extra trigger from Nordpool integration in this period will stop charge as the price is marked as "used" when starting the period. This kind of situation will happen if the price is cheap at midnight or the moment when new day data is fetched.

Prices need to be marked as used. Another scenario when this would be needed is, if the prices are all the same. Like 0,0,0,0,0,0. Now the two cheapest hours are both 0. All zero prices are charged, which I propably do not wan't. This too is not quite common situation, I agree, but robust system should take this kind of situations also into account.

from nordpool.

Please reopen this. I made a test case, where I made a test template sensor which is set to trigger when nordpool changes and then log the trigger time. Last night there were two consecutive identical prices and the second one did not create trigger for my automation, so no indication that the price period had changed.

I use this as my trigger. If I remove "from: null", it also fires on housekeeping updates like when new data becomes available.

• trigger:
  • platform: state
    id: "interval_change"
    entity_id:
    • sensor.nordpool_kwh_fi_eur_3_10_024
      from: null

from nordpool.