We have at least four systems having troubles here in the USA overnight. Three are customer systems - with three different types of communicating batteries - and one is one of my systems. Two of the four have Victron smart LFP batteries with Lynx Smart BMS, one has 3rd party batteries made by Trophy, one has Pytes batteries. I have lots of other systems with all of these battery types and not having any issues.
So far the common thread is Venus 3.50 and the time change from daylight savings time back to standard time over night. Some customers have VenusOS auto updates turned off and are doing fine, some have auto updates enabled and are running 3.50 and doing fine.
So far I haven’t been able to put my finger on what’s going on. I’m starting this thread to see if anyone else is seeing weird issues starting overnight?
The VE.Bus inverters are complaining about low battery voltage and turning on and off, even though the battery voltages and SOC are just fine. One of the systems no longer sees the Pytes BMS CAN device anymore no matter what we’ve done. We’ve reverted back to VenusOS 3.42 but still can’t see the batteries. We’re in the process of doing a factory reset on the Cerbo in case there is a config file still hanging around causing the problem.
On the Pytes system, we tried establishing BMS.CAN communication with other batteries in the stack but nothing.
If I figure out how to get these systems up and running again I’ll write back. For the moment, is anyone else seeing missing BMS’s or other weird battery issues in the last 24 hours on systems with communicating batteries running VenusOS 3.50?
Replying to my own thread…
In an effort to get down systems running again quickly, I had my customers do the following:
Remove GuiMods and turn off auto updates for the package manager
Turn of auto updates for VenusOS firmware and revert back to VenusOS 3.42
Then reboot the CerboGX (all have Cerbos for GX devices).
All customers reported their systems start having issues right around 11pm EDT last night. We are 5 hours behind UTC and our clocks changed at 2:00am EDT, which is 7:00am UTC. The problems started happening at 11:00pm EDT, or 4am UTC. It seems related somehow to the time change, but the hours don’t line up as I expected.
I’m not sure if this is a VenusOS issue, GuiMods, or both. I wanted to get everyone up and running again so I didn’t try just one change at a time to get to root cause.
I also have other systems running VenusOS 3.50 and not having any issues.
With the new GUI on VenusOS 3.5x I don’t feel like GuiMods is necessary and will leave it off. I’m also going to let 3.50 mature a bit before I try using it on these four systems. I don’t know where the exact problem lies. Maybe I’ll figure that out in the coming days.
3 x Hoymiles HM-1500, 1 x Hoymiles HM-800 + OpenDTU
Software:
VenusOS 3.40 / 3.50
Setup Helper 8.22
GuiMods 10.72
dbus-opendtu
Problem description:
Two days ago I did the update to VenusOS 3.50. At first everything was normal.
Last night (04:13 GMT+1) I experienced similar problems as described here, because my monitoring, which retrieves data via Modbus (TCP), was experiencing dropouts. At first I suspected a network fault.
When I tried to look at the system on site via the console on the CerboGX, the display switched back and forth between correct values and 0 / “Off” at irregular intervals (2-10 seconds). Overall, the system was very unstable and could no longer be reached sporadically via Modbus (TCP).
Then I wanted to check the Can connection to the Pylontechs. I noticed that the battery monitor was apparently constantly scanning the bus in “automatic” mode and displayed the battery every 2-10 seconds, only to lose it again shortly afterwards. So at first I thought it was a problem with the Canbus. I then restarted the system and checked the logs. There were no errors.
I then booted back to 3.40 and the system has been running again ever since. I will also wait until I make the next attempt.
Thank you for data. I re-installed VenusOS 3.50 on one of my systems to see if the issue comes back. I will leave GuiMods off. It doesn’t add much value if using the new GUI anyway.
Hi guys.
I have a very similar configuration to sfreund and also the same problems as him.
I upgraded 3.42 to 3.50 yesterday and immediately noticed the problems. Then booted back to 3.42 and almost everything worked again. However, I only realised today that MQTT over LAN was deactivated and the password protection for the console. That’s why my external (node red) evaluation and control software wasn’t working.
The time zone remained set correctly.
After the long development time and many betas, the result disappoints me somewhat. Hopefully the errors will be found soon and Victron can make improvements.
Greetings from Leipzig
Hi everyone, especiall @OGPS who has 4 affected sites.
Can you please check the Device List on VRM (or the Device List on the GX will also work) to see if the battery itself is still detected. If you’re getting error 67 while the battery is connected, vs getting it while the battery is not shown, gives a pretty good idea of where to start looking.
For example, here’s a site that lost the battery a day ago:
