[Improvements] Battery Sim #89
Comments
|
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: 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
<#89 (comment)>,
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
> <#89 (comment)>,
> 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
<#89 (comment)>,
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
The text was updated successfully, but these errors were encountered: