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
Does it need Shoulder tariff/period knowledge? #17
Comments
Personally, I have no shoulder periods - just off-peak and peak... |
I've likely over complicated this by combining 2 different elements:
..and makes recommendations, or even automates, when to charge/discharge accordingly. |
@AnthonyBe I'm coding this now. My preference - only charge during Off Peak (easiest logic). Can you see a need to charge from shoulder? If so, when? Only if shoulder rate / round trip efficiency < peak rate, and peak load expected to exceed remaining capacity? I wouldn't have thought this was a high priority, and it makes the charge logic MUCH harder. |
Great to hear! :) I understand the complexity, but in sitting down and thinking about it, charging from Shoulder would definitely reduce costs in the scenario you've outlined... hmm.. OK in thinking about it more, I've just realised that I need to stop considering the way that the current Tesla TBC is working for me (inefficiently) and consider this more holistically.. (I’ve re-written this response 3 times over a day 😊) So, the question is would we need to charge from grid during Shoulder. The answer is Yes (sorry!). I initially was thinking "Yes" because in my current situation using Tesla TBC it will discharge during Shoulder and if there is increased 'abnormal' power consumption and/or lower than expected solar production, the battery could find itself with insufficient power to cover the Peak period fully. In this scenario, having the battery recognise this and performing a last minute battery top-up from the grid near the end of the Shoulder period would definitely be advantageous. At this stage, Both the Tesla Cost-Saving and Balanced TBC modes will discharge during Shoulder. This is bad for anyone using a retailer with a ToU rate plan where price diff between Off-peak and Shoulder is less than ~15%, e.g. Powershop. For us folks, during Shoulder, we’d rather pull from Grid than discharge battery. And as mentioned above, we’d rather pull from grid to top-up the battery near the end of the Shoulder period if we think we are going to be short in covering the upcoming Peak period. For people with a bigger difference between their Off-peak and Shoulder rates, then it becomes more nuanced.. discharge during shoulder (this is the difference to above scenario).. but not so much that there isn’t sufficient battery charge to get through the next period if that period is a Peak period. Reason I say that is that for many plans, the weekends and public holidays might have a Shoulder instead of Peak, and thus Shoulder would transition to Off-peak in the evening and thus there would be no reason to retain charge in the battery during the Shoulder. So, rules logic.. IF tariffrate=SHOULDER IF tariffrate=SHOULDER |
I've been avoiding characterising tariffs in my design as PK, SH, and OP because as soon as you introduce a fourth tariff such as mid peak, you end up having to try to work that out. But as you describe it, then with a slight tweak, it becomes: IF cheapest consumption rate / round trip efficiency < MIN(current consumption rates, any other consumption rate > cheapest rate that will occur before the next instance of cheapest consumption rate) AND forecast load of non-cheapest rates before next period of cheapest rates < remaining capacity THEN DISCHARGE IF current consumption rate / round trip efficiency < MAX(current consumption rates, any other consumption rate > current rate that will occur before the next instance of cheapest consumption rate) AND forecast load of non-cheapest rates before next period of cheapest rates < remaining capacity THEN CHARGE I think my current approach of building an hour by hour tariff map from a simple tariff definition just needs a small tweak to support this. The trick will be also being able to switch to standby mode (rather than charge or discharge, but PRESERVE CHARGE). |
I just got notified by my electricity retailer (Powershop) about new rates AND Seasonal Time of Use tariffs!! You can read the detail here: https://help.powershop.com.au/pricing-rates/information-on-my-tariff-nsw-qld/ Do you feel like defining multiple tariff maps wrapped in IF DATE statements? :) |
That's easier than VIC (which, in some cases, are defined based on the
commencement of DST). I think including months in the tariff definitions
should work (and be near enough for VIC, too).
…On Tue, 26 Jun 2018 at 15:50, Anthony ***@***.***> wrote:
I just got notified by my electricity retailer (Powershop) about new rates
AND Seasonal Time of Use tariffs!!
Yep, different time periods for each tariff period for each season!
You can read the detail here:
https://help.powershop.com.au/pricing-rates/information-on-my-tariff-nsw-qld/
Do you feel like defining multiple tariff maps wrapped in IF DATE
statements? :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#17 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AkO8I1WXTnm9MeylDq_lUF4jYtkun0JZks5uAcuygaJpZM4TWWam>
.
|
Peak and Off-peak tariffs and Peak windows (weekday and weekend) are currently handled, but does it also need to understand Shoulder tariff and windows?
By factoring in round-trip inefficiency, for some people they may still want discharge in Shoulder, while others do not, depending in their relative rates. Equally, as per the Tesla app, some might want absolute short-term money-saving (possibly as long-term expense of wear and tear on battery) while other might want a more conservative mode if there is minimal (again definable somehow?) saving in discharging in Shoulder.
The text was updated successfully, but these errors were encountered: