[Feature request] Max mains power based charging

[MathiasVDA]

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]

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]

https://www.vreg.be/nl/wat-zijn-de-nieuwe-nettarieven-en-hoe-worden-ze-berekend

[HA-TB303]

https://eneco.be/nl/capaciteitstarief-nieuwe-nettarieven/capaciteitstarief-berekenen

[dingo35]

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]

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: https://github.com/dsmrreader/dsmr-reader/issues/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: https://github.com/dsmrreader/dsmr-reader/issues/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.

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]

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: https://github.com/dsmrreader/dsmr-reader/issues/1084#issuecomment-683350492

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]

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]

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]

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]

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]

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]

maxsummains_alpha2.zip

Limit lowered to 10A, please test thoroughly!

[MathiasVDA]

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]

Appreciate the gesture, but really not necessary.

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

[devdems]

@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]

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]

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]

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.