PRE2023 1 Group1: Difference between revisions
Line 114: | Line 114: | ||
|10-09 | |10-09 | ||
|Deadline | |Deadline | ||
|Update the wiki | |Update the wiki on the first progress | ||
|- | |- | ||
|2 | |2 | ||
Line 123: | Line 123: | ||
|- | |- | ||
|2 | |2 | ||
|Thursday | |Thursday* | ||
|14-09 | |14-09 | ||
|Group meeting | |Group meeting | ||
Line 138: | Line 138: | ||
|18-09 | |18-09 | ||
|Feedback meeting | |Feedback meeting | ||
|Receive feedback on literature study and involved parties | |Receive feedback on literature study and choice of involved parties | ||
|- | |- | ||
|3 | |3 | ||
|Thursday | |Thursday* | ||
|21-09 | |21-09 | ||
|Group meeting | |Group meeting | ||
Line 159: | Line 159: | ||
|- | |- | ||
|4 | |4 | ||
|Thursday | |Thursday* | ||
|28-09 | |28-09 | ||
|Group meeting | |Group meeting | ||
|Implement information of the involved parties | |Implement information of the involved parties, work on the product | ||
|- | |- | ||
|4 | |4 | ||
Line 168: | Line 168: | ||
|01-10 | |01-10 | ||
|Deadline | |Deadline | ||
| | |Update the wiki on the progress | ||
|- | |- | ||
|5 | |5 | ||
Line 174: | Line 174: | ||
|02-10 | |02-10 | ||
|Feedback meeting | |Feedback meeting | ||
| | |Recieve feedback about the implementation of the information of the involved parties and current version of the product | ||
|- | |- | ||
|5 | |5 | ||
|Thursday | |Thursday* | ||
|05-10 | |05-10 | ||
|Group meeting | |Group meeting | ||
| | |Implement the feedback, continue working on the product | ||
|- | |- | ||
|5 | |5 | ||
Line 186: | Line 186: | ||
|08-10 | |08-10 | ||
|Deadline | |Deadline | ||
| | |Update the wiki on the progress | ||
|- | |- | ||
|6 | |6 | ||
Line 192: | Line 192: | ||
|09-10 | |09-10 | ||
|Feedback meeting | |Feedback meeting | ||
| | |Receive feedaback on the progress | ||
|- | |- | ||
|6 | |6 | ||
|Thursday | |Thursday* | ||
|12-10 | |12-10 | ||
|Group meeting | |Group meeting | ||
| | |Work on the first draft of the final version of the wiki and the product | ||
|- | |- | ||
|6 | |6 | ||
Line 213: | Line 213: | ||
|- | |- | ||
|7 | |7 | ||
|Thursday | |Thursday* | ||
|19-10 | |19-10 | ||
|Group meeting | |Group meeting |
Revision as of 12:28, 10 September 2023
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
Setting preferences
Setting constraints
RPC-list
Requirements
- Safety
- User feedback/interaction
- App should be easy to use
- 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
Preferences
- App should be easy to use
- App is looking good
- App tracking the total amount of saved money
Constraints
- Environment (house)
- Not-smart electric devices
- Times when the electric devices cannot be turned on, a not ready dishwater for example.
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.
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]
Appendix
Milestones and logbook
Milestones
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 | |||
Jules van Gisteren | |||
Lin Wolter | |||
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 |
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.