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

New picing module for Spanish PVPC model #237

Open
wants to merge 20 commits into
base: pricing_modules
Choose a base branch
from

Conversation

juanjoqg
Copy link

additionally It adds a new schedule charging scheme base on forecast cost

ngardiner and others added 16 commits January 21, 2021 23:30
update screenshot
…iables used with requests, update the login flow to allow branching based on specific errors or MFA code requests (not yet implemented), and handle locked Tesla accounts without crashing
@ngardiner
Copy link
Owner

Very cool - is this your power provider @juanjoqg? Let's sync this in with the development of the pricing platform, something I'll get moving on.

How do you envisage future power prices being used? One thing that comes to mind is that we could visualise them on the charging schedule table.

@juanjoqg
Copy link
Author

juanjoqg commented Feb 20, 2021 via email

@ngardiner
Copy link
Owner

There's a lot going on in this PR, seems to be related to the merge of commits from the 1.2.1 branch, which is okay, I think we can break this down into managable pieces and merge them into the branch that I'm working on for introducing pricing modules.

In order to do this, I'm going to pull relevant pieces out of this PR and merge them into the pricing module branch, and converge it all together. First step will be the new module that you have committed for PVPC, and then I'll take a look at the extensions that you have made to the Web UI.

It won't be an immediate merge of everything but bare with me and I'll get something together, and aim to get it committed to the main branch soon, as I'd like to get moving with charge pricing support. We just need to do it in a coordinated fashion given it is an entirely new branch of functionality.

cheapestStartHour = ini
for module in self.getModulesByType("Pricing"):
cheapestStartHour = module["ref"].getCheapestStartHour(numHours,ini,end)

Copy link
Owner

@ngardiner ngardiner Feb 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few thoughts about this:

  • It's always possible that we could have more than one Pricing module running. The reason might be different data being provided by different modules. It doesn't matter too much but my thoughts are that the logic should be:
        for module in self.getModulesByType("Pricing"):
             moduleCheapestHour = module["ref"].getCheapestStartHour(numHours,ini,end)
             if moduleCheapestHour > cheapestStartHour:
                 cheapestStartHour = moduleCheapestHour
  • This will also require checking the ability for advance pricing per module. We could always just put a dummy function which returns ini if it doesn't support advanced pricing, but it's better to just check and not query if not imho, it saves having to add useless functions

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, just thinking out loud about the scheduled charging logic here:

  • I assume this is really only useful when not using green energy, though. Even the cheapest energy of the day might be more expensive when drawn from the grid rather than green energy.
  • I think there's somewhat of a hole in the scheduled charging logic, in that we basically look for the cheapest start hour to start a charge for a given duration, but it then may carry over a more expensive period after that, and we don't really protect against charging through a more expensive period overall, we just pick a cheap hour. I worry that people might think they are better off but end up worse off, eg it might trigger a charge to start at 1PM which is peak for renewables but then continue through to 7PM which is peak for grid pricing.
  • It would almost be better to say - how many hours during a 24 hour period do you want to charge your vehicle for, and then we choose the x cheapest hours over that day and start/stop per hour. The fault in that logic is that it assumes a vehicle is connected 24/7, and if it isn't, advanced pricing is not of much use to us as we have no dynamic data to respond to.

I'd be interested in feedback from those with power pricing APIs to hear how they'd want to use the functionality.

ngardiner added a commit that referenced this pull request Feb 27, 2021
@juanjoqg
Copy link
Author

juanjoqg commented Feb 27, 2021

Hi
Yes, this option does not make any sense with the greenCharge, it is more apropiate to schedule charging over night.
This function getCheapestStartHour(numHours,ini,end) is suposed to give you the cheapest period "numHours" between "ini" and "end".
As I use it, I schedule the "valley" hours i.e. 22h to 7h, I know I need to charge just for 5h in this period, so with the "Flex Cheaper" option added to the schedule, the program will select the start hour to ensure the cheapest 5h period is used.

Select hours and stop/start is and option, but I do not see it that better for the complex it takes, usually the hour price do not change that much, except bettween periods and when it changes drastically it goes for some hours. I.e. here in Spain there are just two big changes on the price, at noon and night, within those periods the price fultuates but not that much (30%), bettween periods the changes could be 400%.

Aditionally, with the new schedule model, if you select both "Flex Charge" and "Flex Cheaper" the period of time will be establish to charge the car to the limit established as it does with the Flex charge, but the start hour will be selected to get the cheapest period.

This functionalities can be merge with the limit_amps_from_the_grid in order to, base on the last week consumption on the same period, calculate the actual energy available and change the period acordilly.
The changes on the IU are:

  • Show the hour week price on the week calendar, future prices are showed in blue color
  • Show the hour consumption (charging not included) on the week calendar. This is base on the Loggin module (SQL)

By the way, a use a new table green_energy_wh to acumulate by hour the historical information.
+-------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| time | datetime | NO | PRI | NULL | |
| genWh | decimal(9,3) | YES | | NULL | |
| conWh | decimal(9,3) | YES | | NULL | |
| chgWh | decimal(9,3) | YES | | NULL | |
+-------+--------------+------+-----+---------+-------+
This table will have a register by hour with the acumulated consumption in wh.

I added this new parameters to the mySQL module:
"whenToAcumulate": "hours", (every numberToAcumulate hours it acumulates by hour and insert in the new table). There is a "days" option.
"numberToAcumulate": 1,
"purgeAcumulated": false, (true will delete from the green_energy table the hours acumulated on the green_energy_wh)

Sorry for the mess, but I'm trying to put in place all the useful functionality I have in mind.

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

Successfully merging this pull request may close these issues.

3 participants