something like this,
In the Hack, selling to the grid from battery is disabled.
Youâre right that it could be a nice feature but then youâre not really running Green mode anymore.
What you could do is run Green mode in the winter months with limited solar and switch to Trade mode in summer months with high solar yield.
At the moment the Hack canât yet detect which mode youâre running, but if/when it can it could disable itself if it detects youâre running in Trade mode.
One possible way to achieve this would be to periodically pull the DESS config from VRM with NodeRed, parse the isGreenModeOn value and write that to a dbus register (for instance: /DynamicEss/DESS_userMode) for @dognose 's hack to act on.
Code could look something like this (I am not a Python coder so this might be totally wrong, but you get the gist):
if !(self._dbusservice['/DynamicEss/DESS_userMode'])
DESS_userMode = GREEN;
else
DESS_userMode = self._dbusservice['/DynamicEss/DESS_userMode';
fi
So far Iâve succeeded in writing custom values to dbus settings from Node Red, but I havenât been able to create the above dbus register from Node Red.
First of all, I am not a code expert, for me it was already a task to copy and paste this code into the cerbo :-).
thatâs why i am grateful that this code is shared by dognose, so thank you.
I donât want to use the trade mode, for me the green mode works well with 2 important points:
- maximize self-consumption (try to get through the day and night with solar and battery).
- only sell excess solar (at the expensive price).
if I donât empty my battery before the morning in the summer, the battery will still be 50-60% Soc.
on a sunny day it will be 100% at 11-12 oâclock and then start delivering back to the grid with low prices.
the hack does most of its work during the day when there is solar+
So I thought this would be a nice solution.
for now I should disable the hack for the summer and take my loss that the green mode sometimes maintains the tagetSoc a bit too well.
especially if there is more solar than planned.
I did some further digging.
The limitation to not feed into the grid from the battery is a limitation from Green Mode in general, not just from The Hack. Dognose did optimize this code because in some cases it didnât work as it should.
If you want to inject power from the battery into the grid with DESS, it is mandatory to run in Trade Mode.
An alternative you can try when you know you will have more solar yield than you can consume is to disable DESS, run regular ESS and set a negative Grid setpoint when the (evening) injection price is high.
Conclusion:
If you want it all automated and inject from battery to grid when prices are high, you need to run in Trade mode.
Thatâs just how itâs all designed, sorry.
Thatâs your opinion
The first line in the photo:
Only sell surplus solar back to the grid after consumption and battery charging.
and thatâs what green does.
donât say sorry it was just a question.
yes and that works very well.
There is a major difference. In Germany, it largely doesnât matter WHEN I sell the electricity to the grid, because the price is usually always the same. In other countries, this is sometimes different due to fluctuating remuneration. It makes sense to put the electricity into the grid at the most expensive time, even if the home storage is not yet filled to meet demand. One of the biggest problems for development is the different market designs.
1 Like
Third line in the photo: âEnergy in battery is reserved for consumptionâ.
As in: it will not be used to feed back into the grid.
Itâs in the DESS Manual as well.
open disclosure DESS (Green mode) settings checklist
- requires @dognose DESS HACK
- all numbers are examples and have to be adapted to your system
- this document ist best effort and subject to change, comments welcome
calculate system efficiency
example:
from victron VRM installation overview page: Downloads: production report
Battery: discharge kWh / charge kWh = roundtrip efficiency
roundtrip efficiency: 0.591
sqrt(0.591) =>
system efficiency: 0.769 => /Settings/DynamicEss/SystemEfficiency 76.9
1/0.769 =>
energy needed for 1kWh in the battery: 1.3kWh
=>
dognose HACK: dynamicess.py: line 528: chargerate = round(1.3 * (percentage * self.capacity * 36000) / abs((end - now).total_seconds()))
reinstall modified dognose HACK dynamicess.py at this point and reboot CerboGX.
calculate your personal best price
example:
costs: PV â battery â house/grid
16.8/0.769/0.769=28.409
so it is cheaper to use grid if price is below 28.409
DESS calculations are based on sell price,
so we have to calculate backwards (keeping effiency in mind):
28.409/1.3=21.853
calculated sell price setting:
Sell price type: fixed
Sell price: 21.853
battery settings
example:
Take a look at VRM: advanced: Gateway: System Battery Power widget
and estimate your systems sustained battery charge power.
sustained battery charge power: 3.3kW
use this number for your DESS Maximum charge power setting and let battery price be NULL until everything is working as expected:
Maximum charge power: 3.3kW
battery price: 0
Modify your battery usage scenario: (for example via dbus-spy on cerbogx)
/Settings/CGwacs/BatteryLife/MinimumSocLimit 0 (use 100% of available battery)
/Settings/DynamicEss/MaxTargetSocForIdle 66 (if calculated, use grid up to this SOC for consumption and keep battery idle) (2/3 of available capacity) (defaults to 100% and is used for Adhoc charge also)
Summary
This all leads to the following system state:
DESS green mode with @dognose DESS HACK improvements
DESS should use 100% battery capacity (MinimumSocLimit 0)
DESS should use grid if price is below 21.853 and SOC is below or equal 66% (MaxTargetSocForIdle 66)
DESS use a maximum charge rate of 3.3kW per hour for forcasted SOC calculation
DESS calculations are made for a specific average per system effiency rate
5 Likes
Not 100%. Green Mode can also Feedin from battery to grid under certain (rare) circumstances. Never going to happen with regular fixed feedin prices or if bat2grid restriction is enabled.
For any other system, it may happen, if early feedin-prices are so high, that it would offer a financial advantage. (But, at the end we are talking about some ct here, after deducting battery costs and efficency losses)
Or say: There would be a theoretical use case where DESS is attempting this on purpose even if in green mode. (I have no Idea, if such an optimization is considered when the schedule is created)
For me (fixed feed in prices, that NEVER exceed purchase prices plus actually a bat2grid restriction in germany) the only bat2grid ever happened was due to error, so I just dumped that out completly.
There are things to come, but iâm not promising anything now 
1 Like
feature request
situation
There is a very low price (windy) periode coming, followed by several days of rainy weather. EVs are already empty, no PV surplus in sight.
feature request
Wouldnât it be nice if we could use the period of low price for maintaining SOC while charging the EVs or power the heatpump?
We could achieve this with only a few lines of code:
pseudo code
while energy price is low
read SOC from com.victronenergy.system /Dc/Battery/Soc
set SOC to com.victronenergy.settings /Settings/CGwacs/BatteryLife/MinimumSocLimit
result
At this point we could maintain SOC, consume cheap energy for EVs, heatpump, whatever, while also be able to use @dognose adhoc charge feature.
For visualization this was done manually. Why not let the computer do this automatically via DESS?
what is the purpose, what exactly do you want to achieve with it?
I have a small Node-RED script running, which executes the following daily at 02:00, as the period from 02:00 to 05:00 is almost always the time of the cheapest prices in winter. This means that if the min. SOC is increased during this time, recharging usually takes place at the most favorable time:
-
if the moving average of the SOC over the last 7 days was greater than 50%, reduce SOCmin by 5%, but at least to 10%.
-
if the moving average of the SOC over the last 7 days was less than 35%, or the maximum SOC reached in the last 24 hours was less than 80%, increase SOCmin by 5%, but to a maximum of 35%.
In this way, the minSOC is transferred from summer to winter mode and vice versa in maximum 5% steps per day.
If the battery is regularly charged from grid, the system automatically keeps the min. SOC in the lower range.
Works perfectly and independently of the dognose hack.
1 Like
This situation happened here last night: electricity price dropped from ~28c/kWh to ~15c/kWh between 21:00 and 7:00 and I manually set a bunch of parameters to take as much advantage as possible.
Automating this would require a truckload of parameters and variables so Iâm not sure if automating would actually simplify things.
Scheduling however would allow me to plan a charge scenario ahead and go to bed early
Variables to take into account:
- Whatâs the minimum price drop (and thus timeframe) I want to benefit from ?
- Whatâs the maximum grid pull (and thus charge speed) I want to use ?
Since we have quarter hour peak tariff here in BE: do I want to remain below my preferred peak value or does the lower electricity price compensate for a higher quarter hour peak value ? - Where do I want to push the cheaper electricity to ? EV, battery, heat pump, ⌠?
- If a combination: how much of the cheaper kWh to each ?
- Calculation: whatâs the ÎSoC % for each target ?
With all that decided, I set to charge ~50/50 to my electric motorcycle (to which I can set a charge rate and Target SoC) and my home battery for ~8.5 hours at max power that remains below minimum peak rate.
Woke up this morning to see that charging ended 2 hours too early, so I had set my ÎSoC %'s too low 
The motorbike doesnât like it when power is suddenly cut while itâs charging (Iâm using a granny charger, not an EVCS) so I prefer it to just complete itâs scheduled charge cycle. I need a minimum SoC to get to work and back anyways
So my biggest miss was the ÎSoC % calculation for my home battery.
What I plan to do for the future is to set a charge rate and target SoC on the motorbike and schedule a relay to start charging it when low price kicks in.
For my home battery, instead of setting a target SoC, I plan to schedule an Adhoc Charge Rate at start and end (0W) of the cheaper timeframe.
All the required components for this case (relay and Adhoc Chargerate) are available from within Node Red so thatâs how Iâll probably implement it.
Integrating it in dognoseâs Hack would be nice but I have a feeling that this would go beyond the purpose of the hack. And bloating that would only complexify further development to itâs core functions.
YMMV.
How I understood it from reading docs, feedin from battery to grid in Green mode was more a bug than a feature that Victron intended, and your hack countered that bug
But maybe itâs not that simple.
Feeding in from battery to grid at high feed in prices when thereâs no solar excess (typically at night) can be a nice feature when a) feed in price at least offsets battery cost and b) you are certain that the next day there will be so much solar excess that a depleted battery in the morning will be fully charged again by the evening.
Not sure if this would fit in the Green Mode concept or should be part of Trade Mode however.
In Belgium, with a Dynamic contract, feed in prices are variable per hour just like buy prices.
Both can also be negative !
Negative feed in prices happen frequently (even at night) but negative buy prices are very, very rare.
Excited to see what you are further developing !
If I may throw in a small feature request: can you include in the next iteration of your hack the creation of a /Settings/DynamicEss/DESS_Mode dbus path and disable your Hack features if the value is anything else than blank (path exists but nothing ever written to it) or Green ?
I donât want to have additional Node-RED scripts nor do I want additional shell scripts. We all together are currently trying to find settings for which DESS functions as expected.
For tomorrow Iâam almost there:
The system maintains SOC for 21 out of 24 hours, while it should do this for the whole day based on the prices.
As you can see: For the majority of DESS users in this forum, DESS does not work as they expect, since documentation lacks details or is inaccurate or DESS is worthy of improvements. Iâam just trying to be part of the game.
2 Likes
Good evening. I switched from ESS to DESS (Green Mode / Tibber) three days ago. (Multigrid 48/3000, VenusGX, 6xPylontec US3000C, five AC coupled PV inverter)
Reading about the Bat2Grid issue, I did install the DESS HACK right away. Thanks a lot @dognose for this work btw. Checked the install was successful accd. to instruction. As far as I can judge things worked quite well 'till todayâŚ
The forecast for today looked very good
but it turned out to be very different, with three to four times more batt to grid than batt to consumption
For sure in total its a few kWhrs and it doesnât break my bank account, but something Iâll continue to pay attention to.
That is very strange behavior.
If the Hack is installed and running correctly, battery to grid export should be completely disabled.
I suggest you re-check all your (DESS) settings.
I canât find the mistake
For the cycle cost I entered â0â as I donât mind to maximise usage.
Grid Setpoint 10W
Better to set a realistic battery cost, like âŹ0.1/kWh.
Can 't explain why (way too late for thinking) but my mind tells me the system will assume free energy otherwise, and inject that to the grid.
Or something like that.
@BartChampagne txs for the hint, Iâll try âŹ0.01 /kWh
Be careful when using an artificially low battery cost.
Iâll admit itâs tempting, even if itâs just to see the battery actually doing some work instead of your system just pulling power from the grid.
But sometimes it is cheaper to just pull from the grid and not use the battery.
A too low battery cycle cost will cause excessive wear and an early battery replacement cost, potentially ending up more expensive than pulling power from the grid.
The entire system is built to save you money, but depends on honest costs to calculate with.
Otherwise you might lose money instead of saving.
And that kind of breaks the concept.
I donât know what brand of battery you got but âŹ3884 for 20kWh seems cheap.
A realistic cycle cost would be âŹ0.035 to âŹ0.065 per kWh, calculated for 6000 and more realistic 3000 cycles.