This page belongs to the bbb user instructions

vebus_interface is essentially a wrapper around the mk2 code in the velib library. More info about the mk2 and its code is in a readme in velib. After checking out that submodule you'll find it in:

./firmware/etx/velib/doc/README_MK2.txt

There are a few build targets:

• PC: assumes USB-MK2: no reset control of mk2-ic)
• CCGX: assumes onboard mk2: control of MK2 through several IO lines
• Venus: any board supported by venus (besided the ccgx)
• mk2-vecan: embedded product (no OS) with vebus socket on one side, and canbus on the other. consists of two microprocessors: the mk2-ic and the micro running this code.

In case not already done, get the submodule:

./vebus_interface/ $ git submodule update --init

Then initialize velib. To see how, read /firmware/ext/velib/doc/README_make.txt, and especially the !!!!! NOTE. To simply build for a pc, run:

./vebus_interface/firmware $ ./ext/velib/mk/init_build.sh

Also install libevent and its headers:

sudo apt-get install libevent-dev

After that, on a linux PC, simply call make, and it builds. Note the default enabled options: dbus and target_pc.

First of all, read the manual:

$ ./obj/pc-linux-i686-unknown-release/mk2-dbus -h
./mk2-dbus

COMMON OPTIONS:

  --banner
   Print the version during startup.

  -h, --help
   Print this help.

  --log-before <count>
   When set to non zero <count> number of log lines, which are
   not enabled themselves, are nevertheless shown before an
   log which is enabled. For example an error message will be
   preceded by <count> warning and info messages which occurred
   before the error. Combined with -v also warning messages will
   be preceded by info messages

  --log-after <count>
   Like -log-before, but temporarily enables tracing of disabled messages
   after a warning or error occurred.

  -s, --serial
   The serial port to use (default /dev/ttyS0).

  -v --verbose
   Enable log messages. Specifying multiple times increases verbosity.

  -V --version
   Print the version number.

Then, to run it, simply do:

$ ./obj/pc-linux-i686-unknown-release/mk2-dbus -s /dev/ttyUSB0 -vv
000.000 INF.mk2: opening port /dev/ttyUSB0
000.042 INF.: restoring default
000.042 WRN.vebus_items: no device associated with item, refusing to update!
000.042 WRN.vebus_items: no device associated with item, refusing to update!
000.042 INF.dbus: connecting to dbus: session
000.050 INF.mk2: ---- get mk2 version ----
000.050 INF.: > 02 FF 'V A9 
000.077 INF.fh: new frame
000.109 INF.: < 07 FF 'V 97 3E 11 00 00 BE 
000.109 INF.mk2fh: rx msg queued
000.109 INF.mk2: reset?
000.109 INF.mk2: mk2 firmware version is 1130135
000.109 INF.mk2: ----  set mk2 state ---- (no state, 65535)
000.109 INF.: > 09 FF 'S 03 FF FF 01 D0 00 05 CE 
000.164 INF.fh: new frame
000.176 INF.: < 02 FF 'S AC 
000.176 INF.mk2fh: rx msg queued
000.176 INF.mk2: ---- mk2 state set done ----
000.176 INF.mk2: wait for mk2 init done (wait for L frame)
001.201 INF.mk2: ---- get leds / vebus error/config ----
001.201 INF.: > 02 FF 'L B3 

When running OK, you can reduce the number of v's, to reduce verbosity. Note that below FEPs are written with -vvv.

ERR.serial: could not open com-port

First make sure the comport actually exists. ls /dev/tty* will help. When sure that it exists, check that your user account has rights to open the comport. Typically you need to add your user to the dial-out group:

sudo usermod -a -G dialout $USER

Then logout and log back in. DON'T just prepend your command with sudo. It will fix this security issue, but will cause issues later on: the session variable DBUS_SESSION_BUS_ADDRESS won't be there, causing the default dbus to be system instead of session. And that will cause a dbus security error.

INF.: > 02 FF 'V A9
WRN.mk2_fh: mk2 no reply

The mk2 is not responding to messages sent to it. Solution: make sure that the mk2 is connected to a Multi or Quattro. Which in their turn need to be connected to a battery and/or powered on their AC-in connection. One way to check proper connection is to simply start VEConfigure3 (a windows application) and see if can connect and communicate to the VE.Bus device.

INF.mk2: reset?
INF.mk2: wrong version, starting update
ERR.mk2: needs updating but is not allowed

This means that the mk2 needs a different firmware version. But since connected via usb or some other way where there are IO pins connected to its reset line, your freshly built executable cannot take care of that for you automagically. To update, connect to a recent version of VEConfigure3.

Request Name Error (Connection ":1.82" is not allowed to own the service
  "com.victronenergy.vebus.ttyUSB0" due to security policies in the
  configuration file)

Most probably the process is trying to connect to the system dbus, while running it on a pc, rpi or bbb running Ubuntu, Debian or some other standard distro. Instead of the Venus distro running on the CCGX which has all dbus security stripped out. To start debugging, add a few lines to a file in velib to see which dbus is being used: diff --git a/src/types/ve_dbus_item.c b/src/types/ve_dbus_item.c index 69c0a3a..3b4ad62 100644 --- a/src/types/ve_dbus_item.c +++ b/src/types/ve_dbus_item.c @@ -1053,6 +1053,8 @@ VeDbus *veDbusConnectString(char const *address)

    dbus_error_init(&err);

+   logI("dbus", "connecting to dbus: %s", address);
+
    /* connect to the bus and check for errors */
    if (strcmp(address, "session") == 0) {
        dbus->conn = dbus_bus_get_private(DBUS_BUS_SESSION, &err);

The idea is that the program will automatically choose the right bus. It checks for presence of an env variable: DBUS_SESSION_BUS_ADDRESS. When present, it uses the session dbus. When not present, like on the Venus distro, it will use the system dbus.