being able to set an hard upper limit for dynamic tariffs

[cruschke]

Is your feature request related to a problem? Please describe. Recently there was this issue at EPEX causing dynamic tariffs to skyrocket, like 1kW/h for 2,33 Euro.

This is for example relevant for minimum charge planning upon arrival or Min+Solar. Let's assume you have configured 30% minimum charge and you would need to charge 20kW, this add up to 46,60€ 🙀.

Describe the solution you'd like This feature request is to be able to set an hard upper limit to avoid being ripped off. It is up to the user balancing the risk of a rip-off and having a car surprisingly not charged.

E.g. a reasonable upper limit could be set to 0,50€, if the price is above that level, charging is suspended until it drops.

Describe alternatives you've considered paying attention to alarming emails from your dynamic tariff supplier, disconnect the car, etc

Additional context Add any other context or screenshots about the feature request here.

[andig]

Interesting. Who would win if the tariff errors? Minsoc? The good thing here is that minsoc charging would still start, but at a later time. Bad news: new behavior that needs be visualised.

/cc @naltatis

[cruschke]

That's why I was phrasing it as hard upper limit to make the limit always win, like "under no circumstances I am willing to pay more than 0,50€/kWh". For the UI it does not have to be much sophisticated as it hopefully does not happen too often, like making the charging bar red and where the "price limit is set" add some ‼.

[andig]

That's why I was phrasing it as hard upper limit to make the limit always win, like "under no circumstances I am willing to pay more than 0,50€/kWh".

Wrong answer ;)

Who would win if the tariff errors?

In that case you don't know. Do you chose empty car (for no good purpose) or spending 2€?

Bonus question: given we have smart cost limits per loadpoint- would we need absolute limit per loadpoint, too or globally?

[cruschke]

Potentially a mock makes it more clear. If I have a strong need to have the car charged to 30%, I would likely set the price limit to something higher than if it's just a nice-to-have the car is charged 30%. Potentially this might be a per loadpoint configuration (e.g. having a car that is more relevant than the other).

Who would win if the tariff errors?

I would consider this as AND if currentSoc < 30% AND currentPrice < 0,50€ ; then charge()

Another related use case would be avoiding the minSoc charging at peak-times of dynamic tariffs (like 6am-8am and 8pm-10pm).

[andig]

Vielleicht einfacher auf Deutsch. Ich beantworte die Frage selbst: Wenn wir den aktuellen Tarif (aufgrund eines Fehlers) nicht kennen bleiben wir beim aktuellen generellen Verhalten von evcc. Im Zweifel hat „geladenes Auto“ Priorität vor „gespartem Euro“. Im Rahmen von minSoc.

[cruschke]

Wenn wir den aktuellen Tarif (aufgrund eines Fehlers) nicht kennen bleiben wir beim aktuellen generellen Verhalten von evcc.

Aber wir kennen den Tarif zu jedem Zeitpunkt. Der Fehler ist doch ein ganz anderer: aufgrund irgendwelcher Probleme bei der Strombörse hat der Stromhandel nicht funktioniert und so sind die Strompreise zeitweise durch die Decke gegangen. Das hat mit der Tibber API Verfügbarkeit nichts zu tun, die hat zu jedem Zeitpunkt funktioniert und einfach diese astronomischen Preise reported und als Kunde muss ich die auch bezahlen. Ich habe gerade nochmal nachgekuckt, an dem Tag waren das zwischen 18-22 Uhr 3€ pro kWh. Stell Dir vor Deine andere Hälfte kommt nach zu dem Zeitpunkt nach Hause, Du hast minSoc auf 30% eingestellt und das Auto lädt 20kW nach. Da wäre halt so eine Art "Notbremse" ganz praktisch.

[andig]

Aber wir kennen den Tarif zu jedem Zeitpunkt

Das ist genau der Punkt. Nein- jeder Service kann mal ausfallen.

[cruschke]

Ja das stimmt natürlich. Ich kenne den Code nicht, der die Tibber/Awatar/whatever APIs abfragt, aber typischerweise sind die Forecasts doch für die nächsten 24h (zumindest bei Tibber). Wenn man die Werte entsprechend cached dann ist das doch total egal, wenn die Tibber API mal 5h down sein sollte.

Das Problem müsste doch aber auch beim günstigen Netzladen bestehen, nur wäre der "Schaden" hier dass ich gegebenenfalls eine Chance verpassen würde, mein Auto günstig zu laden falls ich stundenlang keine Preisdaten bekommen würde und es kein Caching gäbe.

[jeffborg]

We have this issue in Australia with Amber as well. The tariff can potentially skyrocket up to about $20 a kwh, Currently I have an automation in home assistant to simply turn off evcc if above a certain price.

[andig]

Yes, we should definitely implement this. The limit should apply to solar mode and minsoc charging. Correction: the limit should apply to minsoc and planner charging. In min+solar, user wants min, this doesn't seem doable to override.

/cc @naltatis

[naltatis]

I think having an optional upper limit for dynamic prices is a good idea. But UI-wise I would see this as a global limit. Not something tied to a vehicle specific minsoc configuration (as in the screenshot above).

Another case where I'd like to have this limit:

In winter I configure my thresholds so that higher grid-use is allowed to better use small available surplus. This usually leads to longer charging in the evening. Similar case if I use the battery buffer feature. Here I think the upper-price limit should also kick in and prevent pulling energy from the grid.

My suggestion would be to not tie the cost limit feature to specific functions like minsoc, planner, threshold but instead implement it as a general charging disable feature in pv (and min+pv) mode.

This is easy to implement and understand for new users.

Drawback: There might be situations where my PV can charge the car completely, without the risk of pulling from grid (large pv, no clouds). In these situations, the car wouldn't charge, and we'd feed-in to the grid. But I think this is an acceptable tradeoff and skyrocket prices usually don't happen at solar-peak hours.

[andig]

Seems we're not clear how to do this:

• must be a global limit
• must affect minsoc mode
• must not affect fast mode
• must not affect planner (but we should display expensive periods when planning)

It's unclear what handling we want for PV mode:

• should it interfere with residualpower (@naltatis thresholds are switching behaviour, these should be irrelevant). It is unclear when and how.
• should it interfere with min+solar. Seems similar to case above. Imho that's unexpected since min+solar is similar to fast in that respect.

This is easy to implement

Generally: we can't use the load management (set to 0W) to implement this feature since different modes need to behave differently.

This would make it hard to implement, especially for PV mode.

[naltatis]

must not affect planner

I don't agree. I would also disable charging when the planner picks slots that are above the upper limit.

This would make it hard to implement, especially for PV mode.

@andig you know the implementation better than I do. So it may be more complicated than I thought. But from a users' perspective, the behavior I'd suggest is:

"If you are in (Min+)PV mode and grid-price exceeds the upper limit, stop all charging."

[andig]

Re planner: if I create a plan to charge as cheap as possible then thats what I want. I dont want evcc to tell me „yeah, you can make a plan but I‘m not gonna support you“. That might lead to not reaching the plan goal, i.e. vehcile not fit for purpose. If the plan shows expensive slots I can still reduce the plan goal accordingly. Imho a plan is a plan and must be executed.

[andig]

„ If you are in (Min+)PV mode and grid-price exceeds the upper limit, stop all charging."

I disagree for same reason as fast mode. Should that be stopped too, because too expensive? If not, whats the difference to the min in solar mode?

The real problem however is to allow PV but disallow grid and do that on top of residualpower. I don‘t see how that should work.

[naltatis]

The real problem however is to allow PV but disallow grid and do that on top of residualpower. I don‘t see how that should work.

My suggestion is to start with a KISS solution. Implement a hard limit that guarantees not grid usage in (Min+)PV mode. We can still optimize from there. But I don't think these situations happen very frequently. Especially here in Germany.

The goal of this feature request (as I understand it) is to not grid-charge due to automatic behavior of evcc (which happens only in (min+)pv mode).

Fast mode should stay as it is. No magic, just fast charge.

[andig]

My suggestion is to start with a KISS solution. Implement a hard limit that guarantees not grid usage in (Min+)PV mode

How do we determine grid usage here- we cannot just switch of if we have enough PV. Grid power above threshold? Site power above residual power?

Fast mode should stay as it is. No magic, just fast charge.

Same argument for min+solar? Min shouldn‘t have any magic. It should particularly not unexpectedly switch off.

[naltatis]

How do we determine grid usage here- we cannot just switch of if we have enough PV.

Don't see why we can't do that. Technical reason?

[andig]

We can, but we shouldn't. I don't want to switch off 5kW PV charging just because grid would be expensive if used. Hence we need to determine grid usage.

[jeffborg]

I would want to switch off due to feedin price being high. On Amber in Australia so the feedin tariff price is linked to the grid tariff price.

[andig]

@jeffborg sorry, but you'll need to refer to the different cases. Just switching off if you really need to charge the car ist not acceptable. I don‘t think feedin price is being discussed here at all either?

[jeffborg]

@andig I think its perfectly acceptable to shut off totally when the price can be up to $18/kwh not 18c/kwh. Yeah I know Australian wholesale power prices sometimes can be crazy cheap or crazy expensive. This may need different thresholds for different modes.

[andig]

Looks like we don't agree on how this could be done. Close?

[naltatis]

Looks like we don't agree on how this could be done. Close?

Yes, at least for now. Workaround via external automations (mode "off" when price > x) is possible today. Maybe we come do a good solution down the road and reopen this topic.