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

Does it need Shoulder tariff/period knowledge? #17

Open
AnthonyBe opened this issue Apr 16, 2018 · 7 comments
Open

Does it need Shoulder tariff/period knowledge? #17

AnthonyBe opened this issue Apr 16, 2018 · 7 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@AnthonyBe
Copy link

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.

@spoonwzd
Copy link

Personally, I have no shoulder periods - just off-peak and peak...

@BJReplay BJReplay added enhancement New feature or request help wanted Extra attention is needed labels Apr 16, 2018
@AnthonyBe
Copy link
Author

I've likely over complicated this by combining 2 different elements:

  1. Short-term - Build in support for Shoulder period as it is quite common in ToU tariffs. This should encompass both Shoulder tariff and Shoulder time periods (periods can differ weekends to weekdays). This would be purely to recognise the 3 distinct tariff periods when it comes to declaring when to charge and discharge the battery.

  2. Longer-term - Build in 'smarts' that looks at:

  • Peak, Shoulder, Off-peak, and Feed-in tariffs
  • Power lost on PW2 round-trip inefficiency
  • Overall 'cost' of cycles on battery

..and makes recommendations, or even automates, when to charge/discharge accordingly.

@BJReplay BJReplay added this to To do in Add Tariff Based Decision Mode via automation May 5, 2018
@BJReplay BJReplay moved this from To do to In progress in Add Tariff Based Decision Mode May 5, 2018
@BJReplay
Copy link
Owner

@AnthonyBe I'm coding this now. My preference - only charge during Off Peak (easiest logic).
Then, potentially, discharge during off shoulder if offpeak rate / round trip efficiency < shoulder rate, and the forecast total of shoulder and peak before the next off peak period < remaining capacity.

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.

@AnthonyBe
Copy link
Author

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 Off-peak rate / round trip efficiency < Shoulder rate AND forecast total of Shoulder + Peak before the next off peak period < remaining capacity
THEN DISCHARGE

IF tariffrate=SHOULDER
IF Shoulder rate / round trip efficiency < Peak rate AND peak load expected to exceed remaining capacity
THEN CHARGE

@BJReplay
Copy link
Owner

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).

@AnthonyBe
Copy link
Author

AnthonyBe commented Jun 26, 2018

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! Starting 1st July, i.e. this coming Sunday.

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? :)

@BJReplay
Copy link
Owner

BJReplay commented Jun 26, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
Development

No branches or pull requests

3 participants