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

[Feature request] Max mains power based charging #215

Closed
MathiasVDA opened this issue Nov 19, 2023 · 18 comments
Closed

[Feature request] Max mains power based charging #215

MathiasVDA opened this issue Nov 19, 2023 · 18 comments

Comments

@MathiasVDA
Copy link

MathiasVDA commented Nov 19, 2023

Hello, in Belgium, part of the electricity bill will depend on an "monthly maximum 15min power consumption". I, and I think many other Belgian users, want to limit this electricity bill by not drawing to much power in a short period of time.

Initially, I thought this was already possible with the smartevse, but I think this is only the case for a 1 phase mains connection.

What the smartevse now allows me to set, relevant for the SMART mode is:

  • MIN: all time minimum charging current
  • MAX: all time maximum charging current
  • CIRCUIT: maximum charging circuit current, only applicable when multiple EV's are charged on the same circuit
  • MAINS: maximum MAINS current for 1 phase

I charge on 1 phase. But my other consumers in my house are distributed on the other phases. Let's say my smartevse is on Fase1, then this could be a steady SMART mode charging state :
Fase1: 15A charging, 5A other consumption
Fase2: 10A consumption
Fase3: 5A consumption

=> Total consumption = 35A. Lets say that I would target a capacity tarif of 20A. In this example, I need the smartevse to stop charging the EV completely.

Is it possible to add an additional variable to set the maximum TOTAL MAINS current and adapt the SMART mode charging to take this variable also into account?

Naturally, being able to edit this variable with the API and/or MQTT would be ideal. Then advanced users can let their home automation system keep track of the "monthly maximum 15min power consumption" and adapt the smartevse parameter in function of other accidential consumention.

Thanks

@dingo35
Copy link

dingo35 commented Nov 19, 2023

Very interesting, I understand this will/might be implemented in every EU country:
https://community.home-assistant.io/t/energy-management-calculation-every-15-minutes/335359/5

There is already a variable Isum that represents the sum of all Mainsphases, it should not be a big problem to limit this variable.

I am struggling with a name that would make clear the meaning and difference with MaxMains; something like "Limit Total Mains Current" , or something that refers to the EU regulation?

If someone would want to "get the most" out of their mains connection, shouldnt we have to keep track of the average total current in the current settlement period, and decide in the last 5 minutes to increase / decrease charging current?

Also shouldnt the settlement period be a variable, since some countries use 1 hour?

Then, how does this settlement period work? Is it the average current on fixed window (so from 4:00 to 4:15), or the maximum of a sliding window?

I think I need more documentation/information on this, not like the legal stuff but from a technical standpoint.
Any idea where to find this?

@HA-TB303
Copy link

@dingo35
Copy link

dingo35 commented Nov 19, 2023

Ok even in NL om spraakverwarring tegen te gaan:

  1. is ergens gedefinieerd hoe het kwartiervermogen wordt berekend? Hoeveel samples worden er genomen, begint de sampling op het hele uur (zit er een klok in de kWh meter?), of start het kwartier willekeurig?
  2. Is de berekening van het jaargemiddelde, door de maandgemiddeldes opnieuw te middelen, specifiek voor Fluvius of is dit algemeen? Start deze berekening op 1 januari opnieuw of vindt de berekening plaats over de factureringsperiode (bijv. 1 aug - 31 juli)?

@MathiasVDA
Copy link
Author

Well it's great to hear that what Belgium/Flanders now has, will be more common in the EU. That way, more solutions will come to market to simplify the life of a common consumer.

1. More information

I see that @HA-TB303 already mentioned some links in Dutch. I also have assisted with an extension of dsmr-reader in this github issue: dsmrreader/dsmr-reader#1084

I'll give some more information from what I know according to the VREG (I've checked this by email with them).

  • the settlement period is always a fixed 15minute window. So always 4:00->4:15 and the next is 4:15-4:30. Never a rolling window.
  • power consumption is based on sum of all phases. So if one phase has 5kW solar production and another phase has 5kW consumption, than the net power is 0 kW
  • you can calculate the average power consumption using several methods. Easiest is to look at the kWh at 4:15 and substract the kWh at 4:00 and do x4. That's the average power consumption
  • the 15min peak power consumption value is also published in the dsmr telegrams: Piekvermogen uit telegram halen dsmrreader/dsmr-reader#1764 I have attached a screenshot that I think documents the telegram text. All three values (current, monthly and yearly) are available.
  • capacity tarif is only applicable to users with a "smart meter". In general I suspect that most users of smartevse with this tarif ristriction will have a smart meter, thus DSMR output connected to a sensorbox.

image

If on january the 2nd 4:00-4:15, your power consumption during that 15min was 10kW average, then the monthly value is set to 10kW. If on any other 15min window during that month, you don't exceed that 10kW, then the value for january is 10kW.

The price you have to pay is calculated on a yearly basis. To get the yearly value, you average the monthly values.

From what I understood, a yearly value up to 2.5kW doesn't increase the cost. Every kW above that is ~100€ on your bill.

Now, how to best implement this in smartevse.

2. The easy & simple solution

Since smartevse uses currents instead of power (I don't like that very much but it's the current situation :)), it's only logical to continue with setting currents in parameters.

Introduce a new current parameter and edit the SMART mode according to the post in the topic starter.

For naming, I would suggest to use "TOTAL MAINS". In order to clarify the distinction with the other MAINS, I would rename the current parameter to "PHASE MAINS".

This will allow a user to set a fixed target and will probably be sufficient for 90% of the users.

3. More complete solution

You are right to say that smartevse could also make TOTAL MAINS dynamic depending on previously measured values. In that case, you will want to let the user set a "STARTING TOTAL MAINS" parameter. At the beginning of the month, this value is used for the SMART MODE. When the monthly value increases, smartevse can then take into account this increased value.

I would implement this solution using the data supplied by the telegram messages as shown in the screenshot above. Then you will not be responsible to calculate the 15min average values and the settlement period should also be available in those messages.

@MathiasVDA
Copy link
Author

Ok even in NL om spraakverwarring tegen te gaan:

1. is ergens gedefinieerd hoe het kwartiervermogen wordt berekend? Hoeveel samples worden er genomen, begint de sampling op het hele uur (zit er een klok in de kWh meter?), of start het kwartier willekeurig?

Ik heb dit nog nergens neergeschreven gezien, buiten in een email antwoord van de VREG aan mij persoonlijk. Hier heb ik dit bericht gedeeld: dsmrreader/dsmr-reader#1084 (comment)

Dus vaste kwartieren.

2. Is de berekening van het jaargemiddelde, door de maandgemiddeldes opnieuw te middelen, specifiek voor Fluvius of is dit algemeen? 

Voor zover ik weet is de actiezone van de VREG (dus voornamelijk Fluvius) de enige die capaciteitstarief heeft geïmplementeerd. Ik weet dus niet of andere beheerders, andere facturatiemethoden moeten toepassen.

Start deze berekening op 1 januari opnieuw of vindt de berekening plaats over de factureringsperiode (bijv. 1 aug - 31 juli)?

Dat weet ik niet maar ik vermoed dat het over de facturatieperiode gaat gaan. Ik denk wel niet dat dit een impact heeft op de implementatie in smartevse.

@dingo35
Copy link

dingo35 commented Nov 19, 2023

Als SmartEVSE zelf bijhoudt wat het hoogst geregistreerde kwartiervermogen is, dan kan hij automatisch bepalen wat de maximale laadsnelheid is, zonder dit kwartiervermogen te overschrijden.
Dat gebeurt dan dynamisch; dus als morgen het kwartiervermogen door je warmtepomp verhoogd wordt van 2,5kW naar 3,5kW, dan heeft het geen nut meer om SmartEVSE zichzelf tot 2,5kW te laten beperken.
Ik denk dat het enige dat dan nodig is, is een "reset kwartiervermogen" knop/veld, om aan het begin van de facturatieperiode te resetten naar de standaard (2,5kW in het geval van Vlaanderen).

@MathiasVDA
Copy link
Author

Als SmartEVSE zelf bijhoudt wat het hoogst geregistreerde kwartiervermogen is, dan kan hij automatisch bepalen wat de maximale laadsnelheid is, zonder dit kwartiervermogen te overschrijden.

Klopt, maar nogmaals, dat is ook beschikbaar in de dsmr telegrammen. Als je het door smartevse zou laten bijhouden, moet je eens nadenken over hoe het moet verlopen bij een herstart of als de smartevse een tijdlang zonder stroom zat.

Ik denk dat het enige dat dan nodig is, is een "reset kwartiervermogen" knop/veld, om aan het begin van de facturatieperiode te resetten naar de standaard (2,5kW in het geval van Vlaanderen).

Het zou voor mij alvast handig zijn als ik die standaard kan instellen. Ik weet sowieso dat ik telkens aan 4kW kwartiervermogen kom door de kookactiviteiten. Het is dan zonde om de eerste paar dagen van de maand daartoe beperkt te zijn. Daarnaast kan ik mij ook wel inbeelden dat er mensen zijn die de SMART mode willen gebruiken maar bereid zijn om een bepaald vermogen
te betalen

@dingo35
Copy link

dingo35 commented Dec 11, 2023

Ok guys, here is an alpha version, please test thoroughly because I can currently hardly do any testing myself.
You will find a parameter SUMMAIN at the end of the LCD menu, default 600A so not to bother anyone else, which will limit the SmartEVSE charging current so that the sum of the Mains phases will not exceed this value.

The parameter is valid from 30 - 600A and can be changed through the REST API (current_max_sum_mains) and MQTT (/Set/CurrentMaxSumMains), and should be set in Ampères.

Please let me know your results.

@MathiasVDA
Copy link
Author

MathiasVDA commented Dec 14, 2023

I can test the alpha version this evening.

The parameter is valid from 30 - 600A

A valid range starting from 30 (~6kW) is very high. Can we not start the range from 10A?

@dingo35
Copy link

dingo35 commented Dec 14, 2023

Sure that is possible, but you realise 30A is only 10A per phase?

I will lower it to 10A.

EDIT: working on some improvements, hope to upload alpha2 at the end of the afternoon.

@dingo35
Copy link

dingo35 commented Dec 14, 2023

maxsummains_alpha2.zip

Limit lowered to 10A, please test thoroughly!

@MathiasVDA
Copy link
Author

So I tested:

  1. Setting the parameter using the menu on the SmartEVSE, using MQTT and using the REST API. All work flawlessly
  2. Setting the parameter & using Smart mode, connecting the car, charging is limited as designed to the max total main current - consumption of other appliances
  3. Turning on the oven, SmartEVSE lowers the charge current

So it all seems to work perfectly for me. Many thanks!!
Can I buy you a coffee?

@dingo35
Copy link

dingo35 commented Dec 15, 2023

Appreciate the gesture, but really not necessary.

This feature has been implemented now via 135abc9 and is part of release v1.8.0.

@dingo35 dingo35 closed this as completed Dec 15, 2023
@devdems
Copy link

devdems commented Mar 25, 2024

@dingo35 here we are just limiting the total power based on the MaxSumMains variable correct?

In the code, I don't see that we would be storing 15-minute intervals of the usage from the mains meter and checking that the average consumption in that interval stays below MaxSumMains correct? I guess this part was never built and would need to be done by an external script that would update MaxSumMains via MQTT.

@dingo35
Copy link

dingo35 commented Mar 25, 2024

Correct; that is because the 15min average should be calculated l and transmitted by your meter in the dsmr telegrams, see posts above in this thread.

@devdems
Copy link

devdems commented Mar 25, 2024

Correct; that is because the 15min average should be calculated l and transmitted by your meter in the dsmr telegrams, see posts above in this thread.

I see. One problem I can see here is if something happens with external output and it is not updated in 5, 10, 15 seconds or whichever interval we have, the variable MaxSumMains could be stuck at a number that is too high. Is there any fallback mode to a low number?

@dingo35
Copy link

dingo35 commented Mar 25, 2024

No if you're not able to provide the data reliably you cannot expect a lot of "woulda coulda shoulda" behaviour. It would clog up the code.

In technology, work on the root causes of problems, not on the symptoms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants