Increase the max number of connectable (vedirect) devices

[mpvader]

Right now, the max number of VE.Direct devices that can be connected to a CCGX is around 5: 2 direct and 3 via USB. The exact number depends a bit: enabling MQTT reduces it. As does connecting energy meters, enabling ModbusTCP, etcetera.

The max for the Venus GX is 6: 2 direct ,and 4 via USB.

With below changes in place, the max for the Venus GX becomes ~20, and the CCGX possibly more.

@jhofstee investigated the cause for these limits, out of which came several required changes:

• Back port kernel patch, which (enormously) reduces the number of interrupts being created by ftdi usb connected serial ports.
• Fix the serial starter, see Improving the USB plug & play function (serial-starter) #129
• Fix the GUI: it will start very slowly, lots of D-Bus timeouts. Though -probably- once started, it might work ok. ( @jhofstee is working on this)
• Fix vrmlogger to better handle name-owner changes, and possible also other D-Bus signals: dbus nameowner changes cause high cpu load by vrmlogger #128.

And a few nice to haves:

• Change the ssh-tunnel script so it does not create so many dbus name-owner changes when unable to connect.
• Change the bbe hardware: right now the limit is 10 devices via USB, because of the max number of end-points in the TI driver/hardware. By connecting one of the two ports directly instead of via a hub, this can be increased to ~20. Note that the CCGX driver/hardware implementation does not have this limit.

Obviously it could be that more changes are needed. Fixing one unveils the next.

And, just because images are nice, the test rig:

[mpvader]

@izak do you also have this kernel patch in the rpi kernel(s)? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/serial/ftdi_sio.c?id=c6dce2626606ef16434802989466636bc28c1419

you should. And if you did, I can tick the first one on above task list.

[izak]

Nope, I don't have that! I had to actually check the source code, it's not there. Can add it, it looks like the patch will apply cleanly with no massaging.

[mpvader]

Pls do.

[izak]

It's done. We can merge it next time along with the u-boot fixes.

[mpvader]

thanks. I've closed the first task. Its in for all three machines now.

[mpvader]

The previous test setup didnt work. A photo of the new test setup under construction:

[mpvader]

gui v3.5.1 includes the fixes to allow more devices:

• let Qitems directly make dbus calls instead of allocating proxy objects (takes too long on bigger systems)
• bulk get initial values / text

It was added in v2.12~1. Next step is to actually test it on the test bench.

[mpvader]

a test with 14 MPPTs, one Quattro, running ESS and BOL (adds voltage sense) on a gridless octo results in 30~50% cpu idle.

v2.12~8

Sun was low, no actual charging going on. More tests later.

[mpvader]

14 active mppts, 1 x quattro, ESS, DVCC incl shared voltage sense, normal lead battery, charge current limit set to 50A.

First some tests to find the worst situation:

v2.15, Octo GX

• gui on some static page: ~20% idle
• gui on overview with moving balls: ~10% idle

these were visually taken from top. Below are taken with mpstat 2 120 (every 2 seconds, for 4 minutes).

v2.20~30 Octo GX

• gui-moving-balls, no AC in: 17.63% avg
• gui-moving-balls, AC in: 2.85% avg

[mpvader]

Closing this issue.

The maximum of VE.Direct devices is now documented for customers here.

most easy improvements have been done. Some more are right now being worked on (reduce the impact of having ESS or DVCC enabled). But out of scope of this issue.

Also, the coming GX hardware designs are all more powerful.