Using Nord Pool API is a grey area. Technically it's public and appears to work so far without any tokens, but Nord Pool API documentation states If you are a Nord Pool customer, using our trading APIs is for free. All others must become a customer to use our APIs. which apparently means that almost nobody should be using it.

Also https://github.com/custom-components/nordpool seems somewhat unmaintained and https://github.com/custom-components/nordpool/issues/125 remains unfixed and is hitting at least me regularly.

ENTSO-E would be the correct place to fetch the prices from, and now (10/2022) there's also a HASS integration for that: https://github.com/JaccoR/hass-entso-e

Add support. Then maybe we also need to consider "nordpool_diff" name. Should that be entsoe_diff?

2022-10-31 14:48:39.622 ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.nordpool_diff_rank_10_normalize_max_min fails Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 515, in async_update_ha_state await self.async_device_update() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 710, in async_device_update raise exc File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run result = self.fn(*self.args, **self.kwargs) File "/config/custom_components/nordpool_diff/sensor.py", line 139, in update prices = self._get_next_n_hours(self._filter_length + 1) # +1 to calculate next hour File "/config/custom_components/nordpool_diff/sensor.py", line 148, in _get_next_n_hours prices = _get_next_n_hours_from_entsoe(n, e) File "/config/custom_components/nordpool_diff/sensor.py", line 83, in _get_next_n_hours_from_entsoe if p := e.attributes["prices"]: KeyError: 'prices'

DST is probably not handled correctly right now. We just read "today" and "tomorrow" attributes (which are typically 24-element lists) from nordpool, and assume that there are 24 hours in day and thus dt.now().hour gives index to current hour in "today" list. Too many assumptions there. Possibly there will be 25 elements in the list when moving from summer to winter, and 23 elements in the opposite case.

If EU gets rid of DST then this issue goes away without changing anything. Need to see to prioritize.

Normalization made in https://github.com/jpulakka/nordpool_diff/issues/15 makes the result "totally scale-free", meaning that (when normalize: max_min is used) the output varies similarly no matter if the input varies between 1-2 cnt/kWh or 100-200 cnt/kWh.

This works as planned - making the the output magnitude independent of current overall electricity price (variation). But this also doesn't feel quite right. When prices are very cheap, there's no need to optimize targets as heavily as when the prices are very expensive. Real-world nonlinearities (heat pump efficiency, heat leak) could turn unnecessary variation into an anti-optimization.

Maybe "somewhat scale-free" normalization would be in place. So, the output wouldn't be linearly dependent of input scale, but it would still be somewhat dependent, so that 100-200 cnt/kWh variation would give bigger input than 1-2 cnt/kWh variation, but just not 100x bigger. Something to think about. Logarithmic dependency?

Are no good message function in GitHub so writing this as a ticket for now, feel free to close it at any time.

I was looking for how to find a way to plan electricity usage in the future by nordpool_diff but failed in the HA templates and scripts. But thought it would be easier to do it in native python inside the integration with all the raw data available. Started by forking your repo but soon realized it became an integration of it's own.

Hope you don't mind me making a rather new integration from your work, I did put a disclaimer in the readme.md top to your integration but let me know if you disapprove.

It's still seem to be some bugs in the code to resolve but it do seem to work (sometimes) If you like to, have a look at it https://github.com/dala318/nordpool_planner and if you find it useful feel free to include in nordpool_diff (or contribute in mine).

This makes the use of your plugin easier, especially keeping track of latest versions. Might get you started for #7 If you have other thoughts, don't feel sorry to decline. It's an awesome plugin!

If i set it to 20 and there is only 15 ahead prices... What happens then? btw this seems good although i hardly understand it. btw2 i did not know where to wright this

Problem

I have set up my water heater to only turn on if nordpool_diff_rectangle_10 > .66. However, on days with low price variation, this never occurs, so the water heater will never turn on.

Solution

If I additionally turn on the water heater if the prices is among the 2 lowest of the next 10 hours, it will also turn on when the (absolute) price variation is small.

There is still a corner case left; when the price is slowly decreasing, so I think I will also have to turn it on if it has stayed off for more than 16 hours (say).

Even though this new filter type is strictly not a FIR differentiator, the framework of retrieving prices was very handy to reuse for this filter, so I hope it is a welcome addition.

Currntly we don't override should_poll property with False, and by default HA is polling us continuously. The good thing is that this works robustly, but maybe this isn't quite as beautiful as this could be. We should listen to nordpool state updates, and fire update only when needed, as described in https://developers.home-assistant.io/docs/core/entity/

Just like nordpool offers upcoming data as "today"/"tomorrow" attributes, nordpool_diff could offer not only current hour "principal value", but also upcoming hour value(s).

At least the next hour could be interesting when we're close to hour boundary and making decisions about turning something on; if it's xx:59, and next hour filter value is below some threshold, and we would like to avoid short "on" cycles, then we shouldn't turn the thing on at xx:59 if we would turn it off only after 1 minute. This can be avoided by taking the upcoming hour value into account.

Currently the filter is "block-shaped", e.g.

[-1, 1]
or
[-1, 0.5, 0.5]

It's good default, very easy to understand ("price for the current hour is subtracted from the average price for the next few hours").

Optionally, a triangular filter might be cool, something like

[-1, 0.67, 0.33]
or
[-1, 0.5, 0.33, 0.17]

Either right triangle (which corresponds to average of _diff_2..._diff_N, doesn't it?), or exponentially decaying, or...

Maybe with this kind of filter we would combine virtues of short and long filters?

(Could also be arbitrary, user-definable?)

Currently if filter is longer than available data (e.g. filter length 15 and at 14:00 only 10 hours are available), data is padded using the last available element (typically 23-24 price). It might be better to pad using today after midnight data. Or the average between that and 23-24. Make this adjustable.