-
Notifications
You must be signed in to change notification settings - Fork 26
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
Comments
Very interesting, I understand this will/might be implemented in every EU country: 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. |
Ok even in NL om spraakverwarring tegen te gaan:
|
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 informationI 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).
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 solutionSince 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 solutionYou 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. |
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.
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.
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. |
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.
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 |
Ok guys, here is an alpha version, please test thoroughly because I can currently hardly do any testing myself. 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. |
I can test the alpha version this evening.
A valid range starting from 30 (~6kW) is very high. Can we not start the range from 10A? |
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. |
Limit lowered to 10A, please test thoroughly! |
So I tested:
So it all seems to work perfectly for me. Many thanks!! |
Appreciate the gesture, but really not necessary. This feature has been implemented now via 135abc9 and is part of release v1.8.0. |
@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. |
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? |
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. |
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:
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
The text was updated successfully, but these errors were encountered: