Venus (CCGX) for the Raspberry Pi!

[___]

Hi all,

It's with some trepidation and lots of excitement that I'm releasing -- with the blessings of big blue -- the first version of Venus for the Raspberry Pi.

What this means is that you can now run the same software that runs on the Victron CCGX on a raspberry pi. You need at least a Raspberry Pi 2, though it should also work on the Pi 3.

The instructions for making this work is available here.

And no, I will not port this to windows.

[Weasel]

Hey @plonkster, Really Flipping awesome man. i got it working easily. now i just need to get some devices on it. i'm waiting for some cables  

[___]

I have an idea for supporting the vebus devices. The thing is, the mk2 is on the way out, and there is no intent of supporting the mk2 in this setting. Updating the firmware on the mk2 is REALLY problematic. However, the mk3 is still going to be a usb/serial device, and I half suspect it's going to look like an ftdi device to the OS anyway, which means that whatever I do to make the mk2 work will also make the mk3 work later. I will probably do something about that soon, but it is low on the list of priorities.

All that is really needed is to make serial-starter ignore the mk2 and not attempt to try all sorts of protocols on it. Then the rest can be a manual "do it at your own risk" sort of thing.

[Guest]

3 hours ago, plonkster said:

And no, I will not port this to windows.

Ja kyk, it is not worth the time nor the effort to port it to Windows. I mean, why on earth would anyone do such a stupid thing!!! Who uses Windows, gmpf, best they get a Pi and be done say I. 

 

FWIW, if you say the MK2 is on its way out ... let me put it like this. If Victron does not keep on supporting MK2 protocol on older devices, devices one bought at the time as new, in order to keep using the device till it fails 10-20 years later, I see storm clouds forming just below the horizon. Ja, you can pass this onto Victron for then their is just no ways it is viable to buy something that last that long, yet, the software improvements leaves it behind forcing a new purchase ... aint gonna happen.

But then I also see opportunity. 

[___]

1 minute ago, The Terrible Triplett said:

not keep on supporting MK2 protocol on older devices

The protocol is staying. The little USB dongle thingie is being replaced. The mk2 will still be supported on the existing platforms, they are just not adding mk2 support to new platforms. So no mk2 support on the BBB or the Rpi. When I say "no support", what I mean is you can still do it yourself, you just cannot call HQ for help if it breaks.

3 minutes ago, The Terrible Triplett said:

then I also see opportunity

Rumour has it that the new generation of inverters will ditch the RS485 vebus for a CAN bus, so the opportunity is definitely coming :-)

[SilverNodashi]

7 hours ago, plonkster said:

Hi all,

It's with some trepidation and lots of excitement that I'm releasing -- with the blessings of big blue -- the first version of Venus for the Raspberry Pi.

What this means is that you can now run the same software that runs on the Victron CCGX on a raspberry pi. You need at least a Raspberry Pi 2, though it should also work on the Pi 3.

The instructions for making this work is available here.

And no, I will not port this to windows.

Well done! I might just, just, just, decide to get a Victron after all. With this, at least, I'll be able to monitor it while it's keeping the door open

[___]

Hi Guys,

Just made another interim release. It's not a final release yet as it still lacks swupdate support (image-based online updates) but it is getting there. In this version:

0. All software updated to their latest versions, on par with 1.80~19. It's a test release. It comes with a stinking new version of mk2-dbus that will likely not work with existing mk2-usb dongles due to firmware issues. You really want an mk3.

1. It uses u-boot to boot, in preparation for future software update support. Basically the bootloader that comes with the Pi isn't sophisticated enough.

2. There was a bug in an earlier version where the ethernet address (and serial number of the board) got lost and the driver made up a random ethernet address on each boot. As the ethernet address is also used as the VRM ID, that was a disaster. It turns out the bootloader of the Pi passes this information as parameters to the kernel. Placing u-boot into the chain broke this automatic parameter passing and I had to explicitly pass those values on. To fix it.

3. The new image contains two copies of the system, one is a backup for the other. Once swupdate support is in place, it will always update one of the copies and leave the other unchanged so you can fall back to it.

4. Data is stored on a separate partition so that you can do updates of the individual rootfs without losing settings.

5. The kernel was updated from 4.1 to 4.4.

6. I added support for the Realtek 8188EU wireless USB network device because it seems to be popular -- and I own one.

As usual it can be downloaded here: http://45.55.253.39/venus/raspberrypi2/

[___]

Hi again,

 

Yet another testing release.

 

In this release:

 

1. Latest versions of the various bits corresponding to version 2.0.0~2.

 

2. New version of u-boot. The motivation behind this was to get device tree overlay support, but I ended up going in a different direction. There is some good news though: The u-boot prompt is now accessible from a normal usb keyboard and monitor, you no longer need a serial connection for that.

 

3. Device tree overlay support. The start.elf loader that comes with the Pi already has device tree support, whereas DT support in u-boot is rather new and not enabled by default. It turns out to be much simpler to load the relevant device tree using the conventional config.txt method. The trick is to tell start.elf to load the tree at a specific location, and then to tell u-boot to use the same location. This is to facilitate the addition of extension boards in future.

 

4. Kernel updated to version 4.4.28.

 

5. A small bug in the network configuration, inherited from the parent distribution, caused an additional dhcp client to start on the ethernet interface. This dhcp client and connman would end up fighting with each other later.

 

As usual the image can be found here:

 

http://45.55.253.39/venus/raspberrypi2/venus-image-raspberrypi2.rpi-sdimg.bz2

 

regards,

Izak