[DESS HACK] Unexpected Bat2Grid and Solar-Feedin. (Green Mode)

Firmware Upgrades will “undo” my changes - but once i’ve updated my system, I will update the repository accordingly, based on the new original files to ensure there is nothing of the victron changes “missed”.

Hence after an upgrade, wait till I provide new setup-instructions for Version X.XX.

1 Like

You can also put the changes in the /data/rc.local file. Check Venus OS: Root Access [Victron Energy] for how to do that.

1 Like

For a service with it’s own fileset, the rc.local is fine, but modifying / overwriting existing system files, if the underlaying file base is changed - doubt that will run smooth all the time.

Might be issues with dbus service paths getting changed, etc. (And I noted, that just breaking the dess delegate also breaks the whole systemcalcs due to import errors :grin:)

1 Like

If the changes against the original file would remain relatively static, an option could be to import and apply a diff against the original file vs the modified file.
The Linux diff tool is relatively robust in applying a diff patch, even if the file to patch has mild changes made to it. And the tool is available on VenusOS.
On the other hand I’ll agree that on-startup patching of critical service files might be a little bit risky.

You can have the script only patch the file if the md5sum of the file on Venus hasn’t changed. But agreed that automatically changing files on the OS is risky.

1 Like

Tiny Round of “Acceptance-Testing” today :wink: :

  • Today is a rainy day, and the system scheduled to keep 34% soc throughout the day.

  • Having a solar-surplus during “targetSoc=34” triggers the “SELFCONSUME_ACCEPT_CHARGE” Strategy:

11_11

  • Having a “solar shortage”, while soc is > 34% triggers “SELFCONSUME_ACCEPT_DISCHARGE” because we are “ahead of plan”.

11_19

  • Falling down to “targetSoc” (34%) makes the system go into “IDLE_MAINTAIN_TARGET_SOC” in order to keep up with the VRM-Schedule:

image

  • Finally, if the solar shortage is resolved, the system will immediately switch into “SELFCONSUME_ACCEPT_CHARGE” again:

image

3 Likes

That’s indeed what my system is now doing (Trade mode).
I rather see it would charge the batteries, because the forecast is grid to consumption at 22.00 hr and thereafter.


yeah, so you are probably scheduled for targetsoc = 49%, causing the system to idle the battery and feed-in excess pv with the default implementation.

Spot on

1 Like

Well, for trade-mode, the “SELFCONSUME_ACCEPT_CHARGE” may not be suitable.

VRM may also have concluded, that it is better to keep the soc, selling excess energy NOW and therefore having a higher gain, than storing that solar to sell it later (and reduce the earnings by ~ 4ct battery-roundtrip-costs)

Hahahahaha, I set my battery costs to 0,00 and now the batteries are being charged instead of solar to grid.

1 Like

New prediction. Looks way much better.

Well, that’s just cheating ! :slight_smile:
It was a mental switch I had to make as well when turning on DESS.
Expected: charge batteries when there’s excess solar and grid prices are low, run from batteries when grid prices are high.

But when Cost(grid,high) is still lower than Cost(grid,low) + Cost(battery), it’s better to just consume from the grid.

1 Like

How do you put a formula on this ?.. :smile:
Or do you simply mean: when using battery, i.e. wearing out the battery ?

Yes, but if I already have the battery in the house and fully paid for anyway, why not use it as much as possible before it ages? After all, it costs nothing now. In this respect, I also see EUR 0.00 as battery costs as justified.

As per the DESS Settings page: Battery cost (per kWh) = Battery price / (battery cycle life * battery capacity)

So a €3000 battery of 10kWh capacity and an expected lifespan of 3000 cycles would cost “€3000 / (10kWh * 3000)” = €0.1/kWh

Well, the more you use it, the more it ages and the sooner you’ll have to replace it.
I assume you didn’t get it for free, so you’ll want to make sure that the cost of wearing out your battery isn’t higher than buying energy from the grid.
A Lithium or LiFePo4 battery typically gets ~3000 cycles of warranty, so that’s the cycle life you want to spread the cost over (amortization cost).

If at the end of those 3000 cycles the battery has saved you its purchase cost, you made a profit and any extra cycles you can get out of it is pure profit, so yes: then you could say battery price is 0.
If you cycled it 3000 times at a grid cost of €0.15/kWh instead of using the grid at (for example) €0.2 to €0.25/kWh, that battery energy costed you €0.25/kWh and you actually lost money.
(I took the €0.1/kWh battery cost from my previous post)

And in all those calculations, I didn’t even account for the price of the solar install.
Even solar energy isn’t completely free (panels and inverters etc cost money), but it tends to save you enough money on your energy bill anyway, so let’s just assume that charging from solar is “free”.

When really working out the numbers, a home battery rarely is a good investment.
For peak shaving: well… yeah.
For trading between low and high prices ? No.

Yeah, I know :exploding_head:

New thought. When solar is sold to the grid it is already AC. Instead charge the battery and at a later moment discharge it brings losses (AC to DC and later DC to AC).
So perhaps it is not so bad selling exces PV to the grid.

Good cells have a service life of up to 6000 cycles. Assuming you charge 300 times a year, that would be about 20 years that you would have to use the battery to reach its cycle life. With 3000 cycles still 10 years. The truth is probably somewhere in between, i.e. between 10 and 20 years to reach the maximum number of cycles.

However, this is already the period in which a battery has aged. In other words, for conventional single-family homes, ageing is probably limited more by the number of years and less by the number of cycles (a battery ages even without cycles).

From this point of view, it seems sensible to me to use a battery as much as possible until the end of its service life. The 3000 or 6000 cycles will probably never be reached. Therefore, enter the lowest possible battery costs.

But we ar OT :wink:

you can take efficency into account with node-red:


@dfaber said some time ago, this will be taken into account by DESS