Hello community,
First of all - wow, there is a pile of information out there and a pile of really helpful and knowledgeable people who are willing to share that knowledge, thank-you!
I have a small solar setup that acts as an “Internet relay” between two pieces of my property. A BlueSolar MPPT 75/15 charging a couple of retired batteries from a cell-tower back-up system which then run a pair of Ubiquiti antennas which bounce internet from one wired location to another on my farm. Coupled with the above I have a RaspberryPi running Venus OS and the Charge controller is connected to the Pi using a home made cable and things have been happily plugging along for a couple of years now.
My father recently made me a small wind generator and I’ve had no idea if it’s actually done much, it has its own charge controller and there is no interface at all for me to interact with it - so I figured I’d pony up and get myself one of the Smart Shunts I’ve been watching for so long.
I picked up SmartShunt 500A/50mV and plugged it in to the Pi using another home made cable and was very happy to see it was immediately picked up in the Venus remote console! - Only a few minutes later my Charge Controller went offline… I discovered that if I remotely rebooted the system (via the Remote Console) both devices would be online for a few moments (sending realtime data nicely) - but again the Charge Controller would go offline - Annoying.
I disconnected the Smart Shunt cable and the Charge Controller would stay online. If I disconnected the Charge Controller the Shunt would stay online…
Eventually in my troubleshooting I swapped the ports the Charge Controller and Shunt cables were plugged into, now the Charge Controller stays online but the Shunt goes offline after a few moments. This told me it was likely something communication related and possibly within the OS, so I started digging.
When looking at /var/log/ I was able to see that there was two vedirect.ttyUSBx devices showing up as expected. Quickly looking at the logs I was able to determine that vedirect.ttyUSB1 was the device that was going offline (which makes sense I guess as it’s the 2nd initialized device, regardless of how they’re plugged in)
Looking at the logs after a reboot shows the following:
@40000000672e8f5a001c5fac *** CCGX booted (0) ***
@40000000672e8f7301ac71a4 *** starting vedirect-interface ***
@40000000672e8f7315f2d3ec vedirect-dbus 3.83
@40000000672e91d73939a68c
@40000000672e91d73939bdfc -------- dumping backlog -------
@40000000672e91d73939c9b4 607.040 INF.VE.Text: H12=0
@40000000672e91d73939d184 607.040 INF.VE.Text: H15=0
@40000000672e91d73939dd3c 607.040 INF.VE.Text: H16=0
@40000000672e91d73939e50c 607.055 INF.VE.Text: H17=277
@40000000672e91d73939ecdc 607.055 INF.VE.Text: H18=109
@40000000672e91d73939f894 607.055 INF.VE.Direct: TEXT RegId=0308 Value=000045B4
@40000000672e91d7393a044c 607.055 INF.bmv: itemUpdate 0308 000045B4 1
@40000000672e91d7393a1004 607.055 INF.bmv: Found item History/TimeSinceLastFullCharge
@40000000672e91d7393c001c 607.505 INF.VE.Text: PID=0XA389
@40000000672e91d7393c0bd4 607.505 INF.VE.Text: V=12797
@40000000672e91d7393c178c 607.505 INF.VE.Text: I=-1157
@40000000672e91d7393c1f5c 607.505 INF.VE.Text: P=-15
@40000000672e91d7393c272c 607.505 INF.VE.Text: CE=-4935
@40000000672e91d7393c32e4 607.505 INF.VE.Text: SOC=986
@40000000672e91d7393c3ab4 607.536 INF.VE.Text: TTG=8634
@40000000672e91d7393c466c 607.536 INF.VE.Text: ALARM=OFF
@40000000672e91d7393cabfc 607.536 INF.VE.Text: AR=0
@40000000672e91d7393cb7b4 607.536 INF.VE.Text: BMV=SMARTSHUNT 500A/50MV
@40000000672e91d7393cc36c 607.536 INF.VE.Text: FW=0413
@40000000672e91d7393ccb3c 607.546 INF.VE.Text: MON=0
@40000000672e91d7393cd6f4 607.546 INF.VE.Direct: TEXT RegId=ED8F Value=0000FFF4
@40000000672e91d7393ce2ac 607.546 INF.bmv: itemUpdate ED8F 0000FFF4 1
@40000000672e91d7393cee64 607.546 INF.bmv: Found item Dc/0/Current
@40000000672e91d7393cfa1c 607.546 INF.items: Setting item Dc/0/Current to value -1.200000
@40000000672e91d7393e711c 612.591 INF.VE.Direct: Setting status to VdDisConnected
@40000000672e91d7393e80bc 612.592 ERR.service: connection lost
@40000000672e91d7393f440c 612.592 INF.task: done in 612.592
@40000000672e91e80eae8d74 *** starting vedirect-interface ***
@40000000672e91e81011b754 vedirect-dbus 3.83
@40000000672e91eb0fd58914
@40000000672e91eb0fd598b4 -------- dumping backlog -------
@40000000672e91eb0fd5a46c 000.092 INF.task: using ttyUSB1 as unique service part
@40000000672e91eb0fd5b40c 000.093 INF.VE.Direct: Setting status to VdUnknown
@40000000672e91eb0fd5bfc4 000.099 INF.settings: connected to settings on dbus (com.victronenergy.settings)
@40000000672e91eb0fd5e2ec 002.996 ERR.values: timeout connecting device
@40000000672e91eb0fd5fa5c 002.996 INF.task: done in 002.996
@40000000672e91f62ca9b934 *** starting vedirect-interface ***
@40000000672e91f62e0fadec vedirect-dbus 3.83
@40000000672e91f92ded1674
@40000000672e91f92ded29fc -------- dumping backlog -------
@40000000672e91f92ded3d84 000.092 INF.task: using ttyUSB1 as unique service part
@40000000672e91f92ded58dc 000.092 INF.VE.Direct: Setting status to VdUnknown
@40000000672e91f92ded7434 000.099 INF.settings: connected to settings on dbus (com.victronenergy.settings)
@40000000672e91f92ded975c 002.997 ERR.values: timeout connecting device
@40000000672e91f92dedaecc 002.998 INF.task: done in 002.998
--------repeating--------
RECORD SCRATCH
Ok so get this - just to make my life extra fun I’ve hit a snag as been composing this post. I’ve been at this for a couple of hours now: looking at log files, making notes of serial numbers to keep things straight, etc. After I started to capture log files and put things in order to make the post I, for some reason, stumbled across the ability to update the firmware on the devices remotely using the VRM Portal and looking at the device list. I had Venus updated and I had (I thought) applied updates via the Remote Console for each of the two devices connected via VE.Direct (but they must apply sequentially there vs skipping right to the latest?) I was surprised to see I was behind by SEVERAL versions on both devices - so I updated them.
I then set things up to tail a few log files again and started to actually draft this message - only it appears both devices have remained online…
Could I have simply been running bad firmware causing this issue? None of my searching and reading various threads/troubleshooting lead me to think this may have been the case, in fact some of the keywords I expected to find results for yielded virtually no help (let me add them again in the event this thread does nothing but help out someone else in the future - INF.VE.Direct: Setting status to VdUnknown, ERR.values: timeout connecting device, INF.VE.Direct: Setting status to VdDisConnected)
I debated just trashing this message, as it is, but I’m going to post it as I don’t find myself with a lot of time for this kind of stuff lately and my luck something will still go wrong and I’ll have to start from scratch again. I’ll chime in within a few days if this has resolved the issue for good or not - but for now I’ll just awkwardly see myself out…
Footnote:
Special thanks to these posts for providing a direction to go for looking at logs (You’ll need to enable SSH and set a password in order to be able to access them)