[Bug]: Feed-in despite feed-in being deactivated

[mrstackit]

Contact Details

No response

VRM portal ID

c0619ab2c843

Country / region

Germany (de)

B max

2.2

TB max

1.2

FB max

1.2

TG max

0

FG max

10

Battery costs

0.04

Buy price

(p+0.02+0.13)*1.19

Sell price

0

feed-in possible

no

feed-in possible

yes

Version

0.1.6

What happened?

After I updated Venus to 3.10 today and started Dynamic ESS Node Red and another test, I discovered that after a certain amount of time the battery is no longer being charged with the maximum possible power, but is being fed into the network. However, I deactivated feeding into the power grid in Node Red. The error is only fixed again when I set mode 0 and then mode 4 again.

Relevant log output

No response

Screenshots

![DESCRIPTION](LINK.png)

[dirkjanfaber]

Can you also set feed_in_control_on to false? Not sure if it has to do with it, but it makes not a lot of sense to have this one enabled and the feed_in disabled.

[mrstackit]

So far I have understood that feed in possible and feed-in control have different uses. The first is for feed in to grid and the second is because the battery discharge can be planned and if the prices are negative the battery is not used. Is it false?

Now i have feed-in control disabeld. I'll get back to you tomorrow at the latest to see if it's of any use

I'll get back to you tomorrow at the latest to see if it's of any use.

[mrstackit]

What I noticed now that I changed it and the PV no longer produces enough is that the Dynamic ESS somehow limits the power from the battery. Watch in the picture here:

Although in the Dynamic ESS dashboard it looks as if he is not planning to make any purchases:

To me it looks like the same behavior that I had when charging the battery, only now when discharging

Addendum September 22nd: Noticed strange behavior again today. The battery is charged with around 200W even though the PV production is only 200W and the electricity is also expensive.

I have now deactivated Dynamic ESS again in Mode 0. The way it currently works, it costs more than it is supposed to save.

Once the error has been found, I'll be happy to test it again.

Addendum September 23nd: This error also occurs with the new Dynamic ESS function directly via the VRM portal.

[kyros32]

Hello, yes, I can confirm this issue via beta VRM portal. I think it is related to ESS mode being stuck.

I also think, that this problem is much wider in its philosophy and such issues are complicated to solve and debug with native tools (VRM, console, HW reboot, ...).

I will elaborate further...

Some Modbus settings change console settings (let's call them internal regulation variables - which should NEVER be allowed to change by BMS persistently).

External control should always only substitute persistent setting variables (user defined via console) and should be valid and effective ONLY when communication works OK.

However, when communication with BMS is lost, then reverting to default (fallback) internal settings should happen immediately (does not happen NOW - now last communicated values are pernament).

Therefore, in such cases we see weird behaviour, because simply turning off Modbus, rebooting, reconfiguring does not work - ie. ESS mode can not be set via console - so BMS (3rd party company) can effectively break our installation.

I suggest implementing a heart-beat variable for Modbus. All settings made by BMS (or higher level apps and functions) should not be persistent and after comms are lost then heart-beat variable does not change it's value (ie every 30s) and then Cerbo should fallback to internal (default user defined) values and drop everything that was substituted via BMS.

Unless this is solved, I think implementing more complex d.bus and Modbus apps will be very problematic and not transparent.

[Martijnth]

I'm noticing the same problem when enabled DynESS. This morning it started buying power at a way more expensive rate then it did sell an hour before. The battery was 50% so it could've used the battery but it did not.

The energy prices differ a lot between buy/sell because I ignore the 'saldering'

So even if i have a 50% charged battery it is going to buy expensive power

[dirkjanfaber]

@Martijnth what is your vrm id?

[Martijnth]

@dirkjanfaber 48e7da870ed3

[kyros32]

@dirkjanfaber Mr. Hoor, if you would be kind enough, I am trying to make my ESS work again - disabling DynESS does not help, I even tried changing stuck ESS mode via Modbus TCP Client - I changed it successfully, but it did not help either :-(

Any support is appreciated at this time. Otherwise, I will have to reconfigure everything from scratch and cross my fingers :-)

This site has been OK until 500 -> 506 upgrade and then enabling DynESS (I wanted to test with fresh FW...).

Thank you. Regards, Robert

ID: c0619ab1eb6e

[dirkjanfaber]

@Martijnth : We took a look at your system and the reasoning of the system around that time.

The consumption forecast was low and the actual consumption was much higher than anticipated, and Dynamic ESS keeps the planned battery usage stable while punishing the forecast inaccuracies on the grid (selling the excess to grid, buy the additional need from the grid). This is indeed less ideal, but it is an issue of the forecasts being inaccurate, nothing that the Dynamic ESS decided.

If you wonder why we keep the battery stable and not the grid: in our internal testing keeping the battery usage stable (basically the same as the plan) has been a lot more cost-effective than otherwise, because of the battery costs that pile up.

We are working on a way of adding scheduled loads to the system (to make the forecasting more accurate). But that takes time to implement well.

[dirkjanfaber]

@kyros32 :As far as I can see, your issue is not Dynamic ESS related. I suggest posting it on the community forum instead in a new post.

[khostri]

@kyros32 :As far as I can see, your issue is not Dynamic ESS related. I suggest posting it on the community forum instead in a new post.

Hi @dirkjanfaber . I want to add to this as I think it is somehow DynESS related. I have tested previous version and disabling it was ok - like deploying disabled flow and then work normally as before DynESS test. I have current version (working with SOC) and I fear that its different story. Tried like 3 days ago to disable it. Deployed disabled DynESS flow and changed ESS mode to charging. And nothing happened - setting was totally ignored. Then I have tried to turn off nodeRED and still no charging. So now I am stuck. DynESS work otherwise ok I think although there are still some questionable timeframes. But I don't know what internal values was changed which are not reverted back after disabling dynESS So I think that behavior kyros32 described when system is ignoring standard setup after DynESS was installed is valid. There is maybe some bug or there are some specific steps to disable it in case it would be needed. I hope there are still previous configured values stored somewhere.

[dirkjanfaber]

You can check the mode the system is operating in. If it is in mode 0, (zero) than it is off.

Checking the mode your system is in can be done by using the following piece of flow:

[{"id":"2fd11441aaae5df8","type":"debug","z":"15669bac1d63a856","name":"dynamic ess mode","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":710,"y":1020,"wires":[]},{"id":"df9c15a37ea63581","type":"victron-input-custom","z":"15669bac1d63a856","service":"com.victronenergy.settings","path":"/Settings/DynamicEss/Mode","serviceObj":{"service":"com.victronenergy.settings","name":"com.victronenergy.settings"},"pathObj":{"path":"/Settings/DynamicEss/Mode","name":"/Settings/DynamicEss/Mode","type":"number"},"name":"","onlyChanges":false,"x":370,"y":1020,"wires":[["2fd11441aaae5df8"]]}]

[kyros32]

@dirkjanfaber @khostri Hello, as for my problem, only resolution is sticking to this manual: https://www.victronenergy.com/media/pg/Cerbo-S_GX/en/reset-to-factory-defaults-procedure.html

1) Do Cerbo GX reset described above. 2) Set everything up again 3) Works like a charm - no need to reconfigure inverters over VE.Bus

So I really believe this should be looked into before going into production. Definitely some left-over persistent settings that blocks ESS. I have uploaded the backlog here. Maybe it helps. vrmlogger-backlog.sqlite3.zip

[kyros32]

@dirkjanfaber @khostri update:

now, when I set DynESS to Auto, it behaves the wrong way like before. However, when I set to Off then ESS starts working again normally. Definitely worth investigating.

-Regards,Robert

[mrstackit]

Yesterday I updated to beta firmware v3.20~7 since then it seems to be working better. What surprises me a little is that the battery charge is limited and feed into the grid. As a result, the battery is not full. Why is that? I have a Pylontech US2200C, what should the battery capacity be set to 2.2 or 2.4 kWh? Maybe that has something to do with it?

Edit 03.10.2023:

Unfortunately, the behavior has not completely disappeared. As soon as DESS is on, the charging power of the battery is still limited if there is enough PV power and fed into the grid. Last night I noticed the same thing happened when unloading. With a kWh price of over €0.40, the discharge power was limited to 100-200W and the rest was obtained from the grid.

Why is that?

[khostri]

@dirkjanfaber Thanks for flow - its ok for check. I will try to test if mode=0 works. But regarding bug feeding when should not is there in my instalation also:

disabling feedin manually (or through flow) does not help:

manually injecting 0 here seems to help (at least for current hour):

[dirkjanfaber]

Looking back at the data of the original post of this issue (as there is quite a lot of noise in this issue).

The system calculates every few minutes how quickly it should (dis)charge to reach the target SOC at the end of the hour. If it falls behind (because your load is higher), it will speed up a bit, if it gets there too fast, it will slow down. If the battery capacity is overestimated, it will typically slow down towards the end. If the battery capacity is underestimated, it will typically speed up towards the end.

Battery capacity is never exact. And speeding up- or slowing down a bit near the end of the hour is a result of that, and in general not a problem.

If you really want to prevent this, try tweaking the battery capacity a bit in the DESS Node-RED flow settings or if you use VRM, then the VRM Settings.

If you stop and start the dynamic ess, it forces a re-calculation.