PRE2023 1 Group1
Name | Student number | Major |
---|---|---|
Sven Bendermacher | 1726803 | BAP |
Marijn Bikker | 1378392 | BAP |
Jules van Gisteren | 1635530 | BAP |
Lin Wolter | 1726927 | BAP |
Problem statement
The problem that will be addressed in this project is the development of an algorithm that finds the moment the price for electricity is the lowest for electric devices, reducing the amount of money one loses to its yearly electricity bill. With the variable fee of the energy contract, the timing of the use of your electric device matters for the price one pays for the electricity. At moments when the energy generation exceeds the demand of electricity, the price will be low. An smart algorithm putting on the dish washer or washing machine at the moment the price is the best during the night could be profitable. Today, people can already take advantage of the hourly fluctuating prices by watching the costs of a kilowatt in an app, and then setting the time of an high electricity demanding device at an inexpensive moment. This is a practice for some people, but not everyone likes put in the effort to do this consistently. For those this algortihm combined with an app that does the work for you can come in handy, in particular if the algoritm can be connected to smart electric devices to operate them, making sure the system operates on its own without the need of human activity.
Project Requirements, Preferences, and Constraints
Creating RPC criteria
Setting requirements
It is necessary to work for the algorithm that it has access to the prices of the electricity per hour for the coming 24 hours. This way the algorithm can do its math and calculate the best moments for the electric devices. Therefore, the algorithm will need connection to Wi-Fi, to download the most up to date data. Algorithm should be reliable. Not too many bugs should occur, since this would decrease the user-experience drastically.
Setting preferences
The app would ideally be connected to the electric devices. This way a human would not have to interfere with the process and would not be bothered by manually planning the start of the dishwashing or washing machine. Furthermore an app that is easy to use ensures all people can profit from it, also elderly with less expertise regarding mobile phones.
Setting constraints
The app should not be too expensive. Since we are working with small ranges of profit, a too expensive app would not be worth the costs. Another constraint could be the reliance on an electric device being ready. If the dish washer is not ready for use yet, the app can not be used.
RPC-list
Requirements
- Implementable
- Relatively cheap
- No infrastructural changes in the electric circuit for a device that is able to turn on electric device
- Algorithm should be reliable
- Access to data regarding electricity prices
- connection to Wi-Fi
Preferences
- User feedback/interaction
- App should be easy to use
- App is looking good
- App tracking the total amount of saved money
- Connection to the electric devices
Constraints
- Environment (house)
- Not-smart electric devices
- Moment the electric devices are not ready to be used.
Users
The possible users for the algorithm for low energy pricing are quite vast, ranging from private homeowners to businesses. Private homeowners can use this app to lower their expenses on energy, which is especially important due to the surge in energy prices due to everything happening in geopolitics. Homeowners could thus use this to turn on their appliances at the right times leading to huge chances on saving large sums of money. Next to private homeowners even factories or businesses could look into using the algorithm, their sometimes-intensive use of energy could then also be better placed at more beneficial times. Energy intensive procedures needed to for example fabricate a certain product could then be done at better times lowering the costs of production leading to higher profits, which is in capitalism of course one of the main drivers in business. Thus, the users for the algorithm spread almost everyone, since almost no one lives without using electricity in this current era.
Private homeowners
As described above one of the most important users would be private homeowners, since the developed app/algorithm would enable them to save large sums of money. This users most important wish would encompass mostly a good working app which is easy to navigate as well as a trustable algorithm. The algorithm should be trustable since if the algorithm is wrong very often there would be no need to use the app, some errors can be accepted though since in no case would using the app cost more money than when using electricity on chosen times, only a perfect human being would be able to spread the electricity usage better than the algorithm.
Companies
The companies would similarly to the homeowners also want a good working app, with again a huge focus on the accuracy of the algorithm. Companies would also benefit from other built in functions such as overviews of electricty use as well as a method to make sure the responsible people are informed, which should thus need everyone to be connected to a single account. Companies would thus make profit from the use of the app/algorithm but would not need major alterations to the normal version for private homeowners.
Other institutions
Since the use of electricity is such a general thing in life, any group of people, company or institution having control over their electricity use could use the app to lower their electricty prices. An important question that then arises however is, in the case that many people start using the app, can the algorithm adapt to correctly spread the use of electricity. Since the increase in usage would also lead to an increase in electricity use on times that would otherwise be seen as off peak.
Other uses
Next to the intended uses done by users as desribed above it is important to mention that with a app based on a great algorithm other interests could also arise. If the algorithm is made to be very accurate with forecasts further into the future, as little as one day, people could start to make money using the app, since some platforms may enable users to trade electricity. This trading of electricity would increase prices and is in the scope of the perceived app not to be wished, since the proposed function of the app is to reduce costs and increase sustainability not to create profits for certain people.
Deliverables
The deliverables of this project will exist of an algorithm that is implanted in an app. This algorithm will be substantiated with documentation in which a literature review is embedded and the capabilities/results of the algorithm will be compared with other energy pricing options.
State-of-the-art
Papers on algorithms for optimal energy consumption.
- Dynamic energy scheduling and routing of a large fleet of electric vehicles using multi-agent reinforcement learning.[1]
- Residential demand response: Dynamic energy management and time-varying electricity pricing.[2]
- Implementation of a dynamic energy management system using real time pricing and local renewable energy generation forecasts.[3]
- Impact of dynamic energy pricing schemes on a novel multi-user home energy management system.[4]
A paper from 2021 analysing many papers on electricity price forcasting[5] sets out to find the state-of-the-art electricity price forecasting models, it describes problems that make comparing of different models hard and also state that there is no clear benchmark to check the performance of models to. The paper states that there are three main models, statistical models, machine learning models and hybrid models. The comparison of these 3 is very hard thus leading to the authors stating not one single state-of-the-art method but choosing multiple. For the statistical models the authors decide that the LEAR model is very accurate, while for the machine learning models the DNN model is most state-of-the-art. The hybrid models they state to be not compared enough to other models thus they decide to leave them out of consideration.
LEAR stands for Lasso Estimated Auto Regressive, where Lasso is a regression analysis method that performs both variable selection as well as regularization, which is useful to increase the quality of the dataset used for the model. Auto regressive just points to the type of model being based on time series analysis.
DNN stand for Deep Neural Network, which is a type of machine learning with the objective of trying to replicate the way a human brain thinks. The deep part stands for it being multiple levels of machine learning. These models can be better in analysis and prediction than the statistical models but do use much more computing power.
Appendix
Planning and logbook
Planning
Week | Day | Date | Occasion | Contents |
---|---|---|---|---|
1 | Monday | 04-09 | Instruction meeting | Group formation, Brainstorm about subject |
1 | Thursday | 07-09 | Group meeting | Decide on a subject, divide tasks among group members |
1 | Sunday | 10-09 | Deadline | Update the wiki on the first progress |
2 | Monday | 11-09 | Feedback meeting | Receive feedback on choice of the subject |
2 | Thursday* | 14-09 | Group meeting | Brainstorm about what involved parties to contact |
2 | Sunday | 17-09 | Deadline | Finish literature study, Write summaries of the literature study on the wiki |
3 | Monday | 18-09 | Feedback meeting | Receive feedback on literature study and choice of involved parties |
3 | Thursday* | 21-09 | Group meeting | Start working on the product, contact involved parties |
3 | Sunday | 24-09 | Deadline | Finish contacting involved parties, update the wiki on the first design/idea of the product |
4 | Monday | 25-09 | Feedback meeting | Receive feedback on contact with involved parties and product |
4 | Thursday* | 28-09 | Group meeting | Implement information of the involved parties, work on the product |
4 | Sunday | 01-10 | Deadline | Update the wiki on the progress |
5 | Monday | 02-10 | Feedback meeting | Recieve feedback about the implementation of the information of the involved parties and current version of the product |
5 | Thursday* | 05-10 | Group meeting | Implement the feedback, continue working on the product |
5 | Sunday | 08-10 | Deadline | Update the wiki on the progress |
6 | Monday | 09-10 | Feedback meeting | Receive feedaback on the progress |
6 | Thursday* | 12-10 | Group meeting | Work on the first draft of the final version of the wiki and the product |
6 | Sunday | 15-10 | Deadline | Finish the first draft of the final version of the wiki and product |
7 | Monday | 16-10 | Feedback meeting | Recive feedback on the drafts |
7 | Thursday* | 19-10 | Group meeting | Implement feedback, Check each others work, start working on the presentation |
7 | Sunday | 22-10 | Deadline | Finish the final version of the wiki and the product, finish the presentation |
8 | Monday | 23-10 | Presentation |
Logbook
Week | Name | Break-down of hours | Total hours spent |
---|---|---|---|
1 | Sven Bendermacher | Searing for ideas (2h), Meeting about subject (1h), Writing deliverables section and mail teachers (0.5h), finding/scanning some promising literature [1-4] (2.5h). | 6 |
Marijn Bikker | Introductory lecture, research into problems and possible technical solution, Meeting about subject, writing problem statement and RPC's. | 6 | |
Jules van Gisteren | Searching for ideas (1.5h), Preparing meeting (0.5h), Meeting about subject (1h), Creating the logbook and planning (2h) | 5 | |
Lin Wolter | Searching for ideas (2.5h), Looking into possible users (2h), Start of literature study with writing of State-of-the-art (3.5h) | 8 | |
2 | Sven Bendermacher | ||
Marijn Bikker | |||
Jules van Gisteren | |||
Lin Wolter | |||
3 | Sven Bendermacher | ||
Marijn Bikker | |||
Jules van Gisteren | |||
Lin Wolter | |||
4 | Sven Bendermacher | ||
Marijn Bikker | |||
Jules van Gisteren | |||
Lin Wolter | |||
5 | Sven Bendermacher | ||
Marijn Bikker | |||
Jules van Gisteren | |||
Lin Wolter | |||
6 | Sven Bendermacher | ||
Marijn Bikker | |||
Jules van Gisteren | |||
Lin Wolter | |||
7 | Sven Bendermacher | ||
Marijn Bikker | |||
Jules van Gisteren | |||
Lin Wolter | |||
8 | Sven Bendermacher | ||
Marijn Bikker | |||
Jules van Gisteren | |||
Lin Wolter |
Approach
- Literature study
- Contacting involved parties, interviews
Literature
- ↑ Alqahtani, M., Scott, M. J., & Hu, M. (2022). Dynamic energy scheduling and routing of a large fleet of electric vehicles using multi-agent reinforcement learning. Computers & Industrial Engineering, 169, 108180.
- ↑ Muratori, M., & Rizzoni, G. (2015). Residential demand response: Dynamic energy management and time-varying electricity pricing. IEEE Transactions on Power systems, 31(2), 1108-1117.
- ↑ Elma, O., Taşcıkaraoğlu, A., Ince, A. T., & Selamoğulları, U. S. (2017). Implementation of a dynamic energy management system using real time pricing and local renewable energy generation forecasts. Energy, 134, 206-220.
- ↑ Abushnaf, J., Rassau, A., & Górnisiewicz, W. (2015). Impact of dynamic energy pricing schemes on a novel multi-user home energy management system. Electric power systems research, 125, 124-132.
- ↑ Jesus Lago, Grzegorz Marcjasz, Bart De Schutter, Rafał Weron, Forecasting day-ahead electricity prices: A review of state-of-the-art algorithms, best practices and an open-access benchmark, Applied Energy, Volume 293, 2021, 116983, ISSN 0306-2619, https://doi.org/10.1016/j.apenergy.2021.116983. (https://www.sciencedirect.com/science/article/pii/S0306261921004529)