[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. |
|
Don't have a smart EVSE (yet). Thinking about it. But how do you deal with the current 15 minutes Average Demand, if you don't take in consideration what the rest of the house will be using in kWh in that quarter. The average demand is not based on kW's but on kWh, and will only be known at the end of the quarter. |
|
@johanvdk1 i use HA on which the calculation happens. I get the data of the house usage from some meter (in my case directly on P1 port on the mains meter). From there, I have the current consumption of the house and I know what max power I can draw from the grid at this time. Based on that I calculate the max current that SmartEVSE can use and push it through MQTT to SmartEVSE which sets the limit. We also have one feature request that would solve this issue without all this extra work but I don't think development has been started. SmartEVSE#69 And just to remind you this repo here is not maintained anymore. You need to use https://github.com/SmartEVSE/SmartEVSE-3 OR https://github.com/dingo35/SmartEVSE-3.5 |
|
@johanvdk1 SmartEVSE is reading the actual power consumption of your entire house if you have added the sensor on the right place. So using the feature that was implemented in this issue, you set the maximum immediate power output of your house and during the quarter hour the car will not draw more power than the left over from the house. if that appliances in your house draw even more power after smartevse stopped charging, then this is not something that smartevse could have foreseen. So you'll need to built your own logic around that. But than you have a capacity based issue with or without charging anyway and you need to implement logic if you want to avoid high costs. |
|
@MathiasVDA most of the users use SmartEVSE only to keep the cost down. In your case, you would need to buy sensorbox + current clamps or 3. Not to mention the hassle of pulling the wires from the main box to the sensorbox which is usually located in a completely different place. That is why the "wifi" solution is much more preferred which works fine now. It just takes some extra sw like HA. |
|
@devdems if you have a digital energy meter than you only need the sensorbox and a p1 cable. The cost of that is in my opinion neglectable compared to the savings from smartevse. Plus, you have both another meter to sense the P1 output. That could just as well have been the sensorbox. The bonus with using the sensorbox is the knowledge that you don't need any self fabricated home automation in order to get your car charged. |
|
@MathiasVDA, how are you going to connect sensorbox and SmatEVSE together? Here is where the most effort and cost will be. It is much easier to use HA, which is free and easy to use and also gives you a visualization of everything. |
This comment has been minimized.
This comment has been minimized.
1 similar comment
|
@devdems we are going a bit of topic here.. you connect the sensorbox and the smartevse using any kind of cable that you want. I've used a utp cable. Smartevse will read out the data and publishes it on your mqtt I have a running openhab instance and have worked with HA as well. I do not find it easier than plugging in 1 cable on two ends |
|
Ok thanks,
always thought 3.7.3 was later than 3.5. Confused.
What I mean is that actual power consumed is not a value that can be used in this calculation. This is Energy based, and you have to use the kWh figures from the meter.
* You have an actual Maximum Average demand (1-0:1.6.0) which is for example 5kWh
* You have a Current Average Demand. (1-0:1.4.0) That value increases with the amount of kWh used. It is reset every 15 minutes. You don't know the final value.
* Predict the final value (extrapolate, so assume that the consumption remains the same. If the value of Average demand is 1kWh after 600 seconds into the 15 minute window, then the predicted value is 1kWh/600 * 900 = 1.5kWh
* If you don't want to exceed the current Maximum Average Demand your budget for the remainder of the 15 minutes is 5kWh - 1.5 kWh = 3.5kWh. So that means you can push 3.5kWh into the EV without exceeding the maximum Average Demand. So it's safe to switch on with 15 A charge current.
So it's charging now.
- The wife puts the kettle on, the current Average demand value rises faster.
- the budget is recalculated every second, and shows that there's now only 3kWh available for the charger in the current quarter. (If the kettle would be on until the end of the 15 minute period).
- drop the charge current to 13A.
- The kettle is switched off after a few minutes. So the prediction was pessimistic, and budget becomes available again. It could become 3.2kWh now since the kettle used some Wh's.
- Since the budget is higher a new charge current could be calculated and used.
If at some point the budget is too low to maintain a charge current, the charger is switched off. To avoid toggling a time out is necessary. After that the charger can start again if sufficient budget is available.
I guess one could add some parameters here, like minimum and maximum charge current, and whether you like to have the last maximum Demand as a ceiling, or set your own ceiling.
|
|
@MathiasVDA this is exactly what i was mentioning in the beginning. You can not put a cable between those places when they are in completely different places. You can but it will very expensive or ugly. Wifi/MQTT solution solves the issue with price and the looks. |
|
@johanvdk1 No need to complicate. You just use the available power which you calculate with max power in the time block - house consuption. If you use this, there is no way that charging of EV will go over the limit. Yes, you will not be using absolutely everything that is available to you in those 15 minutes, but you are safe not to go over it. |
This comment has been minimized.
This comment has been minimized.
1 similar comment
|
@devdems so you are also charging your car wirelessly?😂 |
|
@MathiasVDA don't fall into douchebag territory. You are better than this. Just try to view things also from the wider perspective. |
|
@devdems true, if your total kW consumption always stays under the limit you cannot exceed the kWh limit. Fully agree I found my power consumption to be extremely spiky (up to 3kW spikes due a pump switching on and off and cooking plates peaking to 2kW, but actually consuming only 500W average) and rather than stopping the charger or averaging I choose to use what matters in the end, the kWh value. That way I'm sure I'm not missing any Wh that could increase my monthly maximum and I could use all Wh available. Is it perfect? Probably not. We'll see. Thanks very much for the feedback. |
|
@johanvdk1 that it's correct. |
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: