Today I have noticed a very strange behaviour that did not occure before. I wonder what can be the reason for it.
I have a 3 phase ESS system with 2x 4kWp connected via MPPT and ac coupled 4kWp solaredge on grid side. Entire setup works in ongrid mode, having Load output not connected and all loads on grid side. I use Shelly 3EM as grid meter (i know, slow, but does it thing).
Because there is a lot ov PV in my neighborhood, when feeding full 12kW grid voltage exceeds limit and inverters shut down. To prevent this I have written a small NodeRed flow, that checks forecast and if it is more than free capacity in the battery starts dumping by setting setpoint to -5kW.
When there is less than 10% SoC or less pv forecast that would fit into battery (roughly speaking, there is also a hysteresis built in), it switches setpoint to -50W to prevent taking energy from grid. This flow has EXACT those 2 possible setpoints - “-5000” and “-50” and looks more or less like this:
Todays night, exactly between 4am and 6am from graphs I see that MP stopped following setpoint and switched off production. I do not see any error messages on GX console nor even VE.Bus state change on the advanced graphs in VRM:
what is even more interesting - at exact 6am it resumed normal operation just by itself. No other automation that this NodeRed flow is running, and that one just sets the setpoint, does nothing else.
I wonder what could have been the reason for this glitch. Would there be an undervoltage situation I would expect to see some alerts remembered in VRM or remote console, but there is simply nothing there.
Anyone has some ideas/hints what shoult I check to explain this behaviour?
Just to add - System is running in “Optimized mode without Battery Life” and has Minimum SoC set to 0% (as there are no loads on inverter output connected)
Today it happened again - at exact 4am my multiplus stopped feeding into grid to compensate gridmeyer to set setpoint. And then at exact 6am it resumed normal operation. No alarms, vebus state is consistent bulk over entire period just mp power drops to 0w and it goes not keep defined setpoint. Is there a minimal freq at which the setpoint has to be updated and if not it resets somehow? But would it even reset to 0w multiplus would have to generate power. That is really weird and I have no clue what might I check more to bail down the reason…
Have you tried disabling your flow in NodeRed? Maybe could be a bug in it. You can also chart your ESS setpoint, and other ESS parameters in VRM. I believe you would need to create a custom widget:
As you noted, not a recommended meter for your use case. There could be some bug cause by this (it’s a WiFi meter too right? That adds another level of complication for debugging).
Well, my flow in nodered can control only the setpoint. To get such response the setpoint would have to be set exactly to the value of my loads, and the flow can produce either -50 or -5000. None of those values should produce outcome as on the charts.
regarding Shelly as grid meter - the attached advanced graph plots values reported by this meter. It is also being used to calculate the load as everything is on the grid side of multiplus. I confirmed via a separate readout from utility meter that Shelly works correctly. Also home assistant graphs are identical to load graphs from VRM so there is no chance that grid meter is faulty. But still somehow my multiplus decides NOT to follow set setpoint. I will activate logging for the setpoint read out via nodered but do not expect to find there anything. It behaves as if the battery would be low and stops maintaining defined setpoint. I do not use battery life setting as this could be the most obvious case. I use optimized without battery life with minimum SoC setting of 0%. Also multiplus minimum battery voltage is set lower than any voltages reached. Besides - would any low battery alarm kick in other than ESS low battery this would switch to sustain and leave an alarm in Cerbo. Nothing like this happened.
So I’m still puzzled. See all the graphs I attached, they just do not make sense with minimum SoC of 0%. Maybe something changes this parameter? I will log it in addition, maybe this is what happens…
VRM should already be logging both of these parameters for you, you just have to show the graphs using a custom widget. So once you add those widgets, the historical data will already be populated.
In VRM setpoint is not available also under advanced graphs. Grid monitor however is. After 6am it shows either -50w or -5000w as configured in the flow, but 5-6 am it is just the real load, without a single watt from inverters:
Here ac input power is free multiplus perspective - positive pulls power from ac coupled inverter and negative pushes power to grid side to compensate loads. Around 5-6 inverter was idle for no apparent reason.
Sorry, I gave you the wrong parameter to see the setpoint (I have a two phase system, but you can add all 3 phases in yours.
Do you use Dynamic ESS or is that disabled?
Do you have communicating BMS with DVCC enabled? It’s possible your BMS could be showing a discharge current limit of “0” at that time, forcing the units to pull from grid. You can plot this out too.
The advanced “Hub4 power setpoint” charts (including phase 1, 2, 3) should tell us if your system is actually set to 0 watts setpoint during those hours (the prior graphs show the actual power flows). If its not set to zero, then there might be a configuration issue somewhere.
If you plot “BMS Charge and Discharge Limits” when selecting “Battery Monitor” as the device, that will show you what the BMS is reporting.
I am sorry, but the reason that I found was really stupid. I simply forgot that I had a schedule set at 4am to 6an to get soc to 20%. I was pretty sure it was disabled, but as this phenomen showed up at exactly 4am and vanished at 6 and only on lower SoC got me to rethink that again. It had somehow to be time related. Since vebus was already in bulk mode it did not change state either. Sorry to bother you all - victron worked just the way it was set to. Disabling this schedule got things as I expected them to be.
