Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements on price analysis (calculation) modes #194

Closed
Pluimvee opened this issue Oct 6, 2024 · 5 comments
Closed

Improvements on price analysis (calculation) modes #194

Pluimvee opened this issue Oct 6, 2024 · 5 comments

Comments

@Pluimvee
Copy link
Contributor

Pluimvee commented Oct 6, 2024

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 Pluimvee changed the title Improvement on calculation methods Improvement on analysis (calculation) modes Oct 8, 2024
@Pluimvee Pluimvee changed the title Improvement on analysis (calculation) modes Improvements on price analysis (calculation) modes Oct 8, 2024
@Pluimvee
Copy link
Contributor Author

Pluimvee commented Oct 8, 2024

A visualisation of my proposal

image

@Pluimvee
Copy link
Contributor Author

Pluimvee commented Oct 8, 2024

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
Copy link
Collaborator

You convinced me that this would be a good improvement.

@Pluimvee
Copy link
Contributor Author

Pluimvee commented Oct 8, 2024

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
Copy link
Contributor Author

Pluimvee commented Oct 8, 2024

Code changes for this in Pull request #197

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants