Open Daandamhuis opened 1 year ago
Yep, good suggestions. Updating the battery configuration is also a request in another issue. Lets get the current pull request through first then we can work on some of these.
What is the use case for charge and discharge limits? Thanks
I have a use case for adding a limiting sensor as well: In order to further extend my simulations I wish to be able to vary the (dis)charge rate depending on other factors than only excess solar power, for example (grid) pricing. For example, depending on the energy contract we have other strategies can be more profitable: with a dynamic contract prices can vary highly during the day. It can be profitable to charge not only from solar but also from the grid when the price is low, then discharge the battery into the grid when the price is high.
I think the simulation can be used for other purposes as well if we get some way of influencing the zero point used in calculating the existing simulated (dis)charge rate. A possible implementation could be we get to give the simulation a power sensor which value would be added to the zero point. If the sensor's value is exactly zero (or no sensor was specified or the sensor has no valid value), the existing usual (dis)charge regime is active. If the sensor's value is positive the battery charges from the grid at the rate of the power sensor's value, in addition to any excess solar power. If the sensor's value is negative, the battery discharges into the grid at the rate of the power sensor's value. All rates are of course still limited to the battery's specified max (dis) charge rates.
Potentially an additional limiting can be added as well: the maximum rate going into or from the grid. Simulating the rating of the home's main fuse.
Another use case could be to simulate 'peak-shaving': lowering the peak use of grid power for the whole-house usage. Under some contracts the energy tariff depends on the peak power usage over some period, say a month. It can in this situation be profitable to put in a battery that has a large enough discharge rate to deliver the peak whole-house usage, but only charge it -from the grid- at a low rate over a long(er) period. In this situation there doesn't even need to be any (excess) solar power in the simulation. Making the change I described above I think would enable this simulation as well.
The tariff itself doesn't even need to be dependent on the peak-usage for peak-shaving to be profitable. Using a battery to cover the peak-usage can help being able to lower the grid dependence. For example in the Netherlands, you pay quite a lot more for a 3x35A connection than for 3x25A or even 1x35A. By lowering the grid connection one can significantly lower their home's monthly fixed costs, and at the same time reduce net-congestion.
Thanks for the feedback - always good to have new ideas. The good news is many of these features are available already.
Your suggestions about adding Max and main charge limits are already requested and will hopefully be implemented in the next release. For the time being you could use an automation for this. Removing entities is also seems like good practice I will need to look into.
If you set the battery up using the config_flow (i.e. the user interface as described in the readme, not the yaml) you can add as many import and export sensors as you like and each one can have its own tariff.
The battery percentage is available as an attribute of the battery sensor. You could make a custom sensor if you want this as a separate attribute. I'm happy to break out the battery percentage as a separate sensor in a future update.
To set charging or discharging at different times or tariff levels you need to make an automation to change the batteries mode depending on the circumstances you want. It is better to use home assistants automations for this as then it can be completely custom. Modes include force charging which charges from the grid.
At the moment you can't set a power limit for charge or discharge that is true, but why would you want to limit the battery in that way? If energy is expensive surely you'd want to use as much from the battery as possible? Even if you are charging from the grid at a cheap time why would you want to charge slowly? In real life you might have to if you only have a limited supply or to reduce strain on the battery, but as this is a simulation that isn't really an issue. Give me a use case and I will consider implementing it.
Thanks again
On Sun, 2 Jun 2024, 10:50 rrozema, @.***> wrote:
Another use case could be to simulate 'peak-shaving': lowering the peak use of grid power for the whole-house usage. Under some contracts the energy tariff depends on the peak power usage over some period, say a month. It can in this situation be profitable to put in a battery that has a large enough discharge rate to deliver the peak whole-house usage, but only charge it -from the grid- at a low rate over a long(er) period. In this situation there could even be no excess (solar) power in the simulation. Making the change I described above I think would enable this simulation as well.
— Reply to this email directly, view it on GitHub https://github.com/hif2k1/battery_sim/issues/89#issuecomment-2143759361, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFAIZGM24IN4RLXSQTMDL7DZFLMGZAVCNFSM6AAAAAA3ZMJ5VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBTG42TSMZWGE . You are receiving this because you commented.Message ID: @.***>
To be clear: I am not the original poster of this incident. I was only responding to it as the incident described a topic I wanted to address too and didn't want to start a duplicate discussion. The topic starter did not respond to your request for a use case, so I gave you 2 for being able to control the battery's charging rate dynamically. I will try describe them more clearly:
Use case 1: AC-coupled battery needs to limit it's charge speed to not overload the mains fuse. My home has a 1x35A grid connection (roughly 8400W). I run several appliances in my home which, if they all run at the same time, together use more than 8400W. So if I would add a battery, I would have to make sure the battery charges only at a rate determined as the difference between my main fuse's rating plus the solar production, minus what's already used by other appliances. You're right that the simulated battery will not blow my main fuse, but my simulation is not correct as long as I can't make the simulation follow this real life limitation.
Use case 2: AC-coupled battery used for peak-shaving. There are at least two scenarios in which it can be beneficial to limit the charge speed of the battery. 2a: the running costs for a large net connection can be substantially higher than those for a less powerfull connection (f.e. where I live 35, 49 euro/month vs. 58,21 euro/month). Instead of upgrading the net connection when installing for example a new heat pump, we could also try to install a battery that we charge at a low(er) rate and run the appliances' peak use off the battery. Thus avoiding the added running (monthly) costs of the larger net connection. 2b: in Belgium many energy providers try to fight net congestion by basing each month's tariff on the peak power used during that month. If you run on one day for 15 minutes all your appliances at the same time (dish washer + washing machine + dryer + Quooker + oven + furnace, etc) your tariff for all electricity used that entire month wil be based on the peak use during those single 15 minutes. Such peaks and thus the extra costs can be avoided by charging a battery at a low rate, then running the appliances of the battery power. As long as your battery can handle it, you can run all the appliances at the same time and still pay only the lowest tariff.
Op zo 2 jun. 2024 19:34 schreef hif2k1 @.***>:
Thanks for the feedback - always good to have new ideas. The good news is many of these features are available already.
Your suggestions about adding Max and main charge limits are already requested and will hopefully be implemented in the next release. For the time being you could use an automation for this. Removing entities is also seems like good practice I will need to look into.
If you set the battery up using the config_flow (i.e. the user interface as described in the readme, not the yaml) you can add as many import and export sensors as you like and each one can have its own tariff.
The battery percentage is available as an attribute of the battery sensor. You could make a custom sensor if you want this as a separate attribute. I'm happy to break out the battery percentage as a separate sensor in a future update.
To set charging or discharging at different times or tariff levels you need to make an automation to change the batteries mode depending on the circumstances you want. It is better to use home assistants automations for this as then it can be completely custom. Modes include force charging which charges from the grid.
At the moment you can't set a power limit for charge or discharge that is true, but why would you want to limit the battery in that way? If energy is expensive surely you'd want to use as much from the battery as possible? Even if you are charging from the grid at a cheap time why would you want to charge slowly? In real life you might have to if you only have a limited supply or to reduce strain on the battery, but as this is a simulation that isn't really an issue. Give me a use case and I will consider implementing it.
Thanks again
On Sun, 2 Jun 2024, 10:50 rrozema, @.***> wrote:
Another use case could be to simulate 'peak-shaving': lowering the peak use of grid power for the whole-house usage. Under some contracts the energy tariff depends on the peak power usage over some period, say a month. It can in this situation be profitable to put in a battery that has a large enough discharge rate to deliver the peak whole-house usage, but only charge it -from the grid- at a low rate over a long(er) period. In this situation there could even be no excess (solar) power in the simulation. Making the change I described above I think would enable this simulation as well.
— Reply to this email directly, view it on GitHub https://github.com/hif2k1/battery_sim/issues/89#issuecomment-2143759361,
or unsubscribe < https://github.com/notifications/unsubscribe-auth/AFAIZGM24IN4RLXSQTMDL7DZFLMGZAVCNFSM6AAAAAA3ZMJ5VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBTG42TSMZWGE>
. You are receiving this because you commented.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/hif2k1/battery_sim/issues/89#issuecomment-2143959766, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANKYDR2ZM4YPVG62P4AMHDZFNJSDAVCNFSM6AAAAAA3ZMJ5VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBTHE2TSNZWGY . You are receiving this because you commented. Message ID: @.***>
Some Ideas I have in terms of the Battery Sim, I will continue to add more to it if I find or think of something in the future.
Fixes
New features