Venus OS v3.60~46 Spontaneous Start Charging at night - No DESS Activated

Beta testing Venus OS beta testing
,
1

No DESS activated.
No automated Node-RED flows.

This morning, I noticed that the Android display showed no connection.
Checking VRM, I found that no live connection was possible, with the last update occurring six hours ago (around 7 AM).

I then checked the P1 meter in HomeWizard and saw that the system had started charging at around 1 AM. The charging increased in steps, as shown in the HomeWizard screenshot, until the battery reached full charge this morning. I have manually discharged the batteries to make room for surplus solar power, and reverted to V3.54.

IMG_1927
IMG_19272796×1290 150 KB

2

Ok. But what does the vrm stats show?

What are your system components and setup?

3

You mean the stats under ‘Advanced’ or Installation data:

Scherm­afbeelding 2025-03-20 om 17.07.21
Scherm­afbeelding 2025-03-20 om 17.07.211318×626 41.8 KB

It did not register any consumption.

The Setup is as follows:
Cerbo GX
3x Multiplus 2 48/8000
30kWh Batterybank
SMA Energy Meter (GitHub - Waldmensch1/venus.dbus-sma-smartmeter: A service for Venus OS, reading smart meter data from a SMA system (SMA-EM Speedwire Broadcast) and making the values available on dbus.)
SMA Tripower x 15-50

With Beta V3.60~25 seen no such behaviour.

4

Yes under ac input voltage and current, unless you have another widget you like to use.

With mods though, there can be issues with beta.
What would need to be established is also if the GX lost comms with the meter during this time.

5

Good observation.

Scherm­afbeelding 2025-03-20 om 17.48.15
Scherm­afbeelding 2025-03-20 om 17.48.15536×458 29.5 KB

Communication presumably was lost, but that is why Cerbo started to charge the batterie?

The external Android tablet display was hung to and i could not open Remote console within VRM.
It looked and felt like things hung up.

And yes, the Beta could have issues with the Python Script for the SMA Energy Meter.

I think i just wait for the official newer version, playing around with Beta is just fun when it works:)

6

It is just a theory, strange things happen when comms are lost with grid meters.

So may be related.

It will be interesting to see if it is “one of those things” or possibly a finger pointing at an actual issue.

agreed.

7

As a follow up…

So for those with mods it can have changes.
But also for those with mods or those providing, they need to be the ones to sort out integration issues.

8

Blame on me…. Thanks for your input LX.
Well today again some weird behavior, and that with v3.54.

I looked for the cause and after a while I found that my network had changed IP addresses. I did not set fixed IP addresses, I am a fool.

I believe that this caused a change in IP for the Cerbo so the SMA energy meter could not transmit the data to the Cerbo anymore and indeed this caused some strange behavior.

Android Display not connecting and loss of the metering device.

But after all it is okay to have a post about this I think.

I changed the devices to fixed IP and it connected again, though it took some reboots and time.

I also think that if an important device like a metering device has lost connection to the Cerbo that the Cerbo should not go into any mode, not loading not discharging or what so ever.
Or let the user set a mode that fits purpose for the installation in case a metering device has lost connection.

For me this is unpredictable behavior that should be set by the user or system installer, even remotely changeable.

9

By default, with ESS, the system goes into passthrough as it has lost its connection to an EM.
Behaviour is built around supported and tested devices, so strange behaviour from mods will not be tested or considered, which often use different mechanisms to provide data to the system.

10

As understand from your explanation Nick, the python scrypt is not handling the lost connection and therefore steers the system the wrong way.

This would mean for me, debug the python scrypt or use a tested Energy Meter to avoid this kind behavior, correct?

11

Effectively yes.
With a tested EM, that is part of QA and will be widely installed, so the probability of running into an issue is reduced, and if you do find one, it will be fixed far faster.

12

This is a great lesson to learn and often pointed out. I know, inexperienced users can be a pain in the a..

But the patience is great from the Victron team, thanks for that.

13

We have all been there. It is a continuous learning curve, technology doesn’t stand still :slight_smile:

14

I still need to implement a function in the python script for setting the ‘dbusservice[‘/Connected’] = 0’ if no data from the multicast stream is received, this way the Cerbo will set itself in passthrough mode? I will check the documentation on that one.

The whole day was filled with disconnects and strange behavior, even with official V3.54
Finally after a lot of hours searching and debugging got It up running again on V3.60~48
It is now working for hours without interruption, lets see how it behaves the coming days.

I was debugging the Python script from the GitHub project and starting the test script on my MacBook caused the SMA Energy Meter data stream on the Cerbo GX to immediately start as well. This had to be a multicast routing issue.

The stream stopped after some time, so i think the connected switches in between halted the Multicast data because of misconfiguration, but strangely it had worked for some days before.

For now it works after tweaking some network settings and change some details in the Python script.

Unifi gear from time to time has some strange behavior, depending on device updates.
Technology sometimes makes you want to pul out all hair… Mix it in the cocktail with inexperience and the taste will definitely not be great;)

Happy Sunday.