JaccoR / hass-entso-e

Integration for Home Assistant to fetch day ahead energy prices from European countries via ENTSO-e Transparency Platform
Apache License 2.0
181 stars 30 forks source link

Improvements on price analysis (calculation) modes #194

Closed Pluimvee closed 4 days ago

Pluimvee commented 6 days ago

There are currently three calculation methods for the min(), max(), avg() and percentage methods.

Publish the publish method is performing calculations on the 72hrs of data fetched daily around 13:00. The data requested is from yesterday 0:00 till the next day 23:00. It therefore contains the prices from approx 36hrs before and approx 36hrs in the future of fetching time. While moving in time the historical data gets bigger and the future price data gets smaller. The current code contains some strange logic to filter the dataset when its larger then 48hrs,

Rotation (better named daily) this method does the math on the dataset of today. As such the results change at 0:00

Sliding This method uses the dataset of the current hour (now) till the end of the dataset. As such the window used for the math is not fixed but reduces while moving in time. Also when new data is fetched the dataset is suddenly enlarged, and all results change suddenly

In my opinion these methods do not make the sensors very useful.

Proposal:

  1. publish should use the dataset as fetched. Suggest to add Fetched which uses the original dataset. After some time we can deprecate the publish
  2. Rotation -> rename to daily, or today as this is what it does (make it an alias)
  3. Sliding -> sliding should calculate the current price based on its surroundings. Meaning the min/max/avg should indicate how the current price relates to the previous x hours and following x hours. I suggest to have a a. Sliding24 which calculates using 12hrs before and after b. Sliding12 which calculates using 6hrs before and after

The latter method is useful to enable, disable equipment as it tells something about the current price level within the 24/12hrs surrounding hours. As such its not limited to cheap hours, but also indicates acceptable and expensive hours. (the latter I use to discharge my battery ;))

Pluimvee commented 4 days ago

A visualisation of my proposal

image

Pluimvee commented 4 days ago

Why I suggest to have 12-hour analysis-window? image

and on a 24 hour period the analysis is not conclusive to detect a low-price period twice a day. Especially when you want to turn-on equipment below 20% and shut-off above 80%. (Yellow is a 24-hour analysis window, blue a 12-hrs) image

Roeland54 commented 4 days ago

You convinced me that this would be a good improvement.

Pluimvee commented 4 days ago

Personally I have the integration running twice:

  1. with market prices and running analysis in sliding-12 mode
  2. with Tibber prices and running analysis in daily mode

The first I use to detect optimum price periods and switch on/off ev-charges etc. The second I use for dashboards.

I also use the two to differentiate between delivery and consumption prices. On net delivery the price of my energy consumption is market price (when salderen subsidie in NL ends). image

Pluimvee commented 4 days ago

Code changes for this in Pull request #197