New picing module for Spanish PVPC model

[juanjoqg]

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

[ngardiner]

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]

It's not an actual provider, is some official price that several companies offer, it is call "regulated price for the small consumer". Yes, I have this contract with my provider. I have added a new schedule charging model, where the current start and end charging times are actually a wider period within which you can choose the number of hours you need to charge. The feature selects the start hour in order to get the cheapest cost. For example: I just need to charge for 4 hours and don't need to check the prices to select the cheapest one. I just have to select: Start 22:00 end 07:00 Flex cheaper 4 hours. The actual start hour will be selected according to the price El sáb, 20 feb 2021 a las 2:01, Nathan Gardiner (<notifications@github.com>) escribió:

…

Very cool - is this your power provider @juanjoqg <https://github.com/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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#237 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANNQWXBZEJFRNJTKOEOJBKLS74CWRANCNFSM4X5I3RNA> .

[ngardiner]

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.

[ngardiner]

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

[ngardiner]

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.

[juanjoqg]

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.