Hi,
I have a problem with current oscilations with my MultiPlus-II 48/5000/70-50 GX paired with a Shelly Pro 3EM-3CT63 as grid meter. As batteries I have two Pylontech US5000 in series rsulting in 10kWh capacity. Solar is ac coupled.
The Shelly Pro 3EM-3CT63 dumps its readings via Outbound websocket into the Multiplus which does work. The multiplus is configured as ESS and this works most usually.
However after big steps in energy consumption the ESS current sometimes starts to oscilate. This happened in the night with no solar power.
Is this caused by too slow readings of the Shelly energy meter?
I have to stop this, it’s burning energy, money and destroying my batteries.
The readings of the energy meter show correctly in the remote console (however they keep disappearing for a couple of days in the VRM Portal, but that’s another topic)
How does the Cerbo or Venus OS device know how to talk to the Shelly Pro 3EM over the web socket? Is this a modification you made to allow this, or is that a supported device now?
I would suspect that a delay is the culprit, what the the period of the oscillations in seconds?
That may tell you something.
Are the CTs oriented correctly?
Do you have ESS Multiphase Regulation setup for “Total of all Phases”?
No modifications, I just put the GX’s ip in the outbound websocket section in the Shelly settings.
The period time seems to be 10s. But it’s difficult to measure.
Yes, ESS works fine most of the time, when everything is steady. The battery gets charged when sun is shining and discharged in the night. Just sometimes those oscilations start.
Yes. As mentioned, when consumption or solar generation is within the limits of the Multiplus’ capabilities it manages to adjust the Total of all Phases to ~30W, which I defined as setpoint.
OK, can you watch the updates to the grid power on the console (as you did above) and guess at the update rate?
I’m seeing reports that the default for the Pro 3EM is a 15 second update rate, and the best it can do is a 2 second update rate. Even 2 seconds may not be fast enough for the ESS to track. Most energy meters give 1 Hz update. Some like the EM540/EM530 and Victron’s are up to 10 Hz.
Supporting this thesis is also this guy which is using his utility meter (limited to 1 Hz) and got rid of the oscillation changing parameters in his D-Bus script.
I do too for reasons of efficiency. We have net phase metering here.
When going from “external meter” to “inverter/charger” the problem is gone. Even better/faster when running off grid. But this does not work for us as one Fronius AC inverter is installed outside ESS due to 1:1 already being overstretched.
Did this solve your problem? I kind of hesitate to buy every component it’s corresponding meter though as Shelly, Fronius and SolarManager are already present here (we’re running the system for a shared neighborhood battery).
One more after some more research: Is it possible, that this phenomenon only occurs when
Victron VenusOS
Shelly 3EM Pro (reporting to Venus via outbound websocket)
JK BMS (reporting to Venus via CAN)
are coming together?
My guess is, that there is an unfortunate timing between the three of them:
Shelly reporting draw drom grid
Victron initiating discharche to correct accordingly
JK reporting with a slight delay
Shelly
Maybe I’m wrong and BMS is not important here (actually making the whole problem much more simple).
My next try will be to try to replace the websocket with this dbus script, being significantly faster than the outbound websocket. But I’m not very good at software things to be honest…
I am having similar oscillations with ABB B23 as external meter. With CT-sensor the ESS works just fine. Blaming the sensor speed will not resolve the issue it seems. To me it looks like an inherent issue in the internal working of the system when considerable latency of the measured value is present.
That’s an interesting thought. As all Victron sensors are rather quick, it might be that only 3rd party is affected by it?
What’s weird though is the fact that with Shelly 3EM Pro people are reporting, that the problem only occurs after firmware 1.2.2.
And now, after 17 E-Mails with shelly support, they told me just two days ago:
[…] from our developers […] downgrade [to 1.2.2] will not be possible […].
[…] firmware version 1.8.0 [now on 1.7.0] which will allow clearing reverse power / reverse energy handling. Since your setup appears to be sensitive to short bidirectional power changes, this option may help reduce or eliminate the oscillation behavior you are observing when large loads switch off.
At the moment, firmware 1.8 has not yet been officially released, so we are unable to provide it immediately. However, once it becomes available, we recommend updating the device and testing whether enabling this new option improves the interaction with your Victron ESS system.
I just installed 3.71 because there is great news regarding Victron & Shelly:
Venus OS now natively supports Shelly Gen2 (and newer) smart switches, energy meters and RGB light controllers. This brings better integration for the affordable and widely available range of Shelly smart home hardware to the Victron ecosystem. These are useful for controlling and monitoring AC loads such as water heaters, pool pumps, or lighting circuits.
Shelly devices on the same network are discovered automatically, though disabled by default. Once enabled in the Settings → Integrations menu, Shelly devices appear in the switch pane.
Supported device types include on/off switches, dimmable outputs with slider control, and energy meters. It’s also possible to set the RGB controller color in the UI using presets.
No more outbound websocket necessary anymore. It works out of the box and shows up nicely in the devices list.
I’m seeing noticeably faster update rates of the values provided by my 3EM Pro. So I’m hoping for the oscillations to be gone too now that there is native support from both companies.
There is one problem though; roles only include:
AC load
PV Inverter
Generator
Has anybody already tried to overcome this issue?
Or are they well aware of the oscillations and have failed to solve the issue so far?
This is “normal” behaviour for shelly EMs using their native connectivity:
The shelly websocket notifications are slow. The shelly will internally decide whether a change is huge enough to send an updated value or not.
So, when the shelly reports a 50W grid pull and then 10s nothing, the inverter will have adjusted it’s feedin power according to the meters claimed reporting interval multiple times, overshooting the target certainly.
Then the direction changes and the game repeats.
For this reason, official “shelly as grid meter” support has been dropped. Recomendation is to get a proper meter with measurement intervals that are suitable for a grid meter.
(Yes, they are still supported for ACload metering, where that issue is no big problem)
You can get them to work somewhat better by using a third party script that polls the shellies. Mind that will still be limited to 1 value per second or sth. But it is way more accurate than the shelly built-in event-based reporting that will mix in its own considerations on when a value change is worth beeing reportet.
Personal opinion: I use quite a bunch of shelly EMs as well, they are great and easy to use. But ultimately they are an IoT toy, not a meter for an ESS.
Thank you very much, @dognose for your elaborate answer to this issue. This really shines a light onto this specific issue and why it does only occur occasionally. It also explains why Victron is excluding the role of grid meter in its new native support for Shellys.
“Overshooting the target” is exactly what this is about. My guess is that large loads switching off in an otherwise steady environment is what causes the issue.
I am going to try the method of script you suggested (based on the dbus one by Fabian Lauer) making it report in a steady fashion. 1 Hz is fine for me. Question from a dummie: Can I install this on my Cerbo, or do 3rd party scripts only work on 3rd party hardware? (never done that before)
As an alternative I could also overstretch the 1:1 rule with my two Fronius and take the whole house to AC2 using inverter/charger as grid meter getting minimal reaction times in the process.
You can do that on any gx. Usually these scripts are designed in a way, that they install themself as a service after boot, so most the time able to survive a reboot and even firmware upgrade.
However it is recommended to have some experience with ssh / unix commands. There is usuallxy a copy/paste sequence of required commands provided, but if something does not work, you’ll otherwise have a hard time figuring out what went wrong and how to fix that then.
I’ve just had a quick look at that script, and in it’s current shape would not recommend it.
It uses an outdated way to register on dbus, which is known to cause a 60 second “stuck” for other services, while it starts up.
It will work after that, but if it - for whatever reason - restarts often, these stucks will mess with overall system responsiveness and reliability.
I’ll raise an issue in the repository, so the owner may take care of that. But last update is 3yo and 8 open issues, not sure if that script is maintained at all.
