TeslaMateAgile
TeslaMateAgile copied to clipboard
MattJeanes
Weekend and Summer/Winter pricing
Hi @MattJeanes, thank you for the great project!
My provider has the following rates:
Summer pricing (between March and October):
- 00:00 - 07:00 (monday to friday) = 0,0895€ [cheap]
- 07:00 - 23:59 (monday to friday) = 0,1795€ [expensive]
- 00:00 - 09:30 (saturday) = 0,0895€ [cheap]
- 09:31 - 13:00 (saturday) = 0,1795€ [expensive]
- 13:01 - 18:30 (saturday) = 0,0895€ [cheap]
- 18:31 - 22:00 (saturday) = 0,1795€ [expensive]
- 22:01 - 23:59 (saturday) = 0,0895€ [cheap]
- 00:00 - 23:59 (sunday) = 0,0895€ [cheap]
Then there's the winter pricing, with slightly different hours.
Any thoughts on having the fixed rates system fit these needs?
Hm this could be added yes but this seems like a very atypical use case. Do you know if your energy provider provides some kind of endpoint or API to retrieve this data?
In my case it’s actually the same for all energy providers in Portugal. It’s what they call the “weekly dual-schedule tariff”. If I were to change energy providers, the hours would stay the same.
Since it’s not provider specific, there very well may be an API somewhere. I’ll look into it and report back if I find one.
Okay cool let me know, I think this is a relatively unusual scenario but it may be worth adding if they don't have some kind of API for this.
In Poland a tariff that one would use for EV charging can be also somewhat like @nunofgs shows (would be named G12w) or a simplified scenario G12 would be as follows:
Winter (1.10. – 31.03.): 22-6 - offpeak (half the price of regular G11 which is a single fixed price for all times) 6-13 - regular (slightly more expensive than G11) 13-15 - offpeak 15-22 - regular
Summer (1.04. – 30.09.): 22-6 - offpeak 6-15 - regular 15-17 - offpeak 17-22 - regular
As you might have guessed I'm on such a tariff and I'm preparing for having EV so if we can add optional conditions apart from hours to also check dates and days of the week would be great. I might be able to provide you with some sort of PoC if you point me to code lines that do the schedule check.
Cheers!
I'd also be interested in this. In my area (Kitchener-Waterloo in Ontario, Canada) we have three tiers of time of use rates plus a separate off-peak rate that is applied all weekend.
Thanks for your feedback, it seems clear this would be useful to lots of people!
In the Netherlands you also have weekend/evening rates and working day peak rates.
Two (standard) types in NL:
- Peak rate from 7:00 - 21:00 on weekdays -> all the rest is off-peak, so from 21:00 - 7:00 on weekdays and from friday 21:00 till monday 7:00.
- Peak rate from 7:00 - 23:00 on weekdays -> all the rest is off-peak, so from 23:00 - 7:00 on weekdays and from friday 23:00 till monday 7:00.
As another example, Denver also now has this structure: https://co.my.xcelenergy.com/s/billing-payment/residential-rates/time-of-use-pricing
Times (weekdays, non-holidays):
On-Peak is 3 p.m. -7 p.m. Mid-Peak is 1 p.m.-3 p.m. Off-Peak is 7 p.m.- 1 p.m.
Winter Prices:
On-Peak = 17 cents per kWh Mid-Peak = 14 cents per kWh Off-Peak = 10 cents per kWh
Summer Prices:
On-Peak = 28 cents per kWh Mid-Peak = 19 cents per kWh Off-Peak = 10 cents per kWh
Thank you for the info everyone, this is gonna take some effort to do but it seems clear that it's worth doing 😄
In California we have rate plans with separate weekend + summer/winter pricing as well
https://www.sce.com/sites/default/files/inline-files/TOU-D-PRIME_Fact_Sheet_0320_WCAG.pdf
Wisconsin also has different rates on the weekend and specific holidays if you opt into Three-Tier Time-of-Use, and the timings for the various rates vary with between summer and winter. Sadly, they don't seem to provide an API.
Also in Spain, most electricity providers have the following billing structure:
Mo-Fri: 00:00-08:00: Price3 08:00-10:00: Price2 10:00-14:00: Price1 14:00-18:00: Price2 18:00-22:00: Price1 22:00-24:00: Price2 Sat-Sun (and national holidays): 00:00-24:00: Price3 (For the sake of simplicity I would exclude the case of national holidays in the implementation)
Where Price1 < Price2 < Price3
Thus, also here, it would be very useful to have the possibility to specify different prices for different weekdays.
Hm this could be added yes but this seems like a very atypical use case. Do you know if your energy provider provides some kind of endpoint or API to retrieve this data?
No in fact is very common and usual at least for national holidays and weekend prices, we also have it in Belgium
Would also be great to have a start or end date of the rate in case you move the provider for example
Also adding my vote to this request. I'm in California. Time of Use (ToU) rates differ between weekdays/weekends, as well as Summer/Winter. As an example, here are the various ToU rates for Southern California Edison: https://www.sce.com/residential/rates/Time-Of-Use-Residential-Rate-Plans
Hello. I don't know if it will be simpler or more complicated. But I would like to suggest the idea that the price could be read from a MQTT topic. I don't know what you think. Thank you very much for this project. Best regards
I think the main issue with real-time feeds is that the charge is ultimately not calculated in real-time and needs access to historical data, so I'm not too sure MQTT would be the right approach for this.
This is on my radar by the way, but I don't have a lot of free time unfortunately these days. I'm always open to contributors if someone wants to give it a crack before I get to it!
Hey, so I've had an idea which I've written down in another issue that could solve this, at least, if you have Home Assistant or are willing to set it up
Let me know what you think: https://github.com/MattJeanes/TeslaMateAgile/issues/35#issuecomment-1628000669
v1.12.0 has now been released with support for Home Assistant, configurable lookback days and more which will allow you to create your own pricing as advanced as you like using Home Assistant. This is the currently recommended approach for advanced scenarios that the FixedPrice provider cannot handle.
I may re-visit this at some point and provide native support for this so you don't need Home Assistant, but I do not see that happening soon (without someone else submitting a PR anyway😉) so I am going to close this issue.