I also enabled DESS yesterday (Green mode) and today got tthat battery 2 grid for 3 hours. I think it is because dess estimated that it will be more consumtion and therefore tried to get to that SOC.
I created a thread here for it.
And it seems when reading this thread the “hack” will not make it go away.
PS! I used tonight 02:00-06:00 gridsetpoint to charge my batteries because DESS was not planning to do it itself. I preffere to keep my batteries charged and not empty as DESS would do.
The current hack doesn’t “support” a discharge2grid at all. (That’s why it works good for green mode, where you usually wouldn’t expect a bat2grid to happen)
If DESS would generate a “discharge request” the hack would only discharge to cover loads, no grid feedin.
There are a few situations where bat2grid would make sence in green mode - they therefore don’t work as intendet, but vrm will quickly adapt it’s planing, if scheduled feedin doesn’t happen.
Yes, that is one of the reasons, there is “unexpected” bat2grid sometimes with the current productive implementation.
Ok, it will not export to grid from the battery. But what about the graph in VRM, does this still show these estimations?
And one more question, with hack system will still only charge when battery is low? I want to achieve that it would charge every night in the winter.
I have approx 75kwh of usable battery and my daily consumption is between 25kwh and 30kwh.
Yes I can live 2 days off battery, but if prices are below 10 cent in the night then why does dess not to charge the battery, why does it waits when I reach MIN SOC and then let me live some time on the grid and then charge battery.
PS! I do not see any charge schedule in my VRM when I enabled it, even in tomorrow there was none.
It doesn’t change anything on the schedule.
Because no matter how big your batterie is, direct consumption is cheaper in many situations.
To consume 1 kWh from battery, you usually need around 1.3 kWh beeing charged from grid at an earlier time.
That alone will make direct consumption upto 13 cent cheaper, when the lowest day price is 10 cent.
If you setup battery cycle costs of 2-3 cent, they are considered as well.
If you want to achieve a battery centric behaviour, then dess is not the feature you need. Dess will only buy as much energy as it thinks to be required until the next day to make sure most the capacity can be used for solar.
Today night there was 5h when my cost was 10cent/kWh and in the day there are 8 hours when buy cost is 26-27 sent/kWh. The difference is ~2,5 times.
When I buy 1,3kWh and consume 1kWh from that and 0,3kWh is heat (that is also used in my case in the winter) then that 1kWh from battery cost me 13 cents, but in that 8 hours directly from grid will cost 26 cents, so 2x cheaper is consume from battery. So consuming 20kWh from battery in that 8 hours I will save 2,6€ compared to consume directly from Grid.
I do not account battery cost because I have already spent that money 
And that battery will outlive me (I estimated 40 years, because in 2years i have only made 255 charge cycles)
(Un)fortunately, that’s not really how cost calculations work.
You could’ve put that money in an investment instead of a battery and get more return.
Unless you got your battery very, very cheap or simply cheat with the costs, a kWh cycled from a Lithium or LiFePo4 battery will cost you 5-10 cents/kWh, excluding the price to charge that kWh from the grid.
So unless the delta price between highest price and lowest price is at least those 5-10cents + cost of losses, there is no financial benefit to charge your battery from the grid and consume that energy later.
DESS takes this into account and many users are then disappointed because their battery doesn’t “work” as hard as they’d like.
Some go as far as to cheat heavily with the battery cycle cost so they use their battery much more, happily thinking they are saving money that way - while in reality it’s costing them more than just pulling energy from the grid.
Quite often the mind is deaf when the wallet speaks
If you still disagree and your battery has no cost anymore: can I have your battery (for free, because the money is already spent anyways) ?
The first you could script with NodeRed but that would go against the concept of DESS.
The second is because DESS is designed to work with Day Ahead prices and thus can only look (and schedule) 1 day ahead.
If that’s not the behavior you desire, then DESS is probably not what you want.
From the numbers, dess should have charged more there eventually.
Hard to tell, without seeing the schedule / estimates.
How long are you using the system by now? Forecast data requires some time to become accurate.
Just a small heads up: VenusOS v3.53 has been released today.
I’ve checked and there have been no changes to the dynamicess.py and PageSettingsDynamicEss.qml files compared to v3.52 so the Hack should work as-is on v3.53 but this is to be confirmed.
@dognose : If you like I can upgrade my VenusGX running your hack from 3.52 to 3.53 and test.
If you prefer to do some testing first I’ll postpone the update.
I will check this evening, but as far as I know, there shouldn’t be changes.
I’ve upgraded my VenusGX to 3.53, re-installed the Hack and everything is still running blissfully.
Again: major hat tip for your work !
It seems that Victron made a change in their version of dynamicess.py 2 days ago so I suspect that a next VenusOS release will require some work from you 
The PageSettingsDynamicEss.qml file from GUI-v1 I couldn’t find in the Victron GitHub repo (only for GUI-v2: link) but looking at the commit comment of the dynamicess file I suspect that stuff will be shifted around in the future.
I’ve just checked the code - there is already a prerequisite for future changes in this update, some new dbus-paths. Hence, I need to update the delegate a bit, so it matches the new “announced capabilities”, else the local system may run into issues with missing dbus keys.
Will do this during the weekend.
Seems like we noticed and posted the same changes in parallel.
GMTA ? 
@dognose Thank you very much for your work. Because of your work, DESS works 
One question: might it be possible to schedule the “adhoc charge”?
Yes then it would no longer be adhoc. But getting up at night at 0300 for initalizing adhoc charge is quite hard sometimes.
Why don’t you use the normal scheduled loading of the ESS for this? Should also work with active DESS?
Like grua said: you can use the normal schedule feature to do this.
Or you can do like I did and create something (quick & dirty) in Node Red
Thanks for the fast response. But because of this topic from Q&A section of the DESS-Manual:
Q: Can I use scheduled charging in combination with Dynamic ESS?
The short answer is no, as this will interfere with the calculations of the system. If you want to use scheduled charging, then either switch to normal ESS or get creative in Node-RED.
I simply did not try to use it…
Did somebody use it in that way?
Has scheduled charge from ESS higher priority than rules/schedule from DESS?
A scheduled charge has priority over the DESS scheduling yes.
And yes, by manually charging you will interfere with the algorithm calculations.
Then again, DESS typically can only look 1 day ahead (because it works with Day Ahead prices) and sometimes you just know that you’ll have an exceptional high consumption during peak tariff hours that DESS can’t anticipate.
For that purpose, a Scheduled Charge can be useful and I believe that’s why Dognose put AdHoc Charge in his Hack. The difference with a normal Scheduled Charge is that with the Hack’s AdHoc Charge, you can also put a charge rate.
What I did with Node Red was build a scheduler around the AdHoc Charge feature.
But unless you have expected loads that DESS can’t anticipate, you shouldn’t mess with the DESS algorithm by charging on your own schedule.
I also created something like you in HomeAssistant.
Edit, just recognized that 6000 kW ain’t possible… changed it to W…
Hi,
any news on the subject?
