question

I think the perceived need for X11 for dbus is a red herring. Test dbus with

dbus -y

that works even on 2018-11 Raspian Lite. See the end of https://github.com/victronenergy/venus/wiki/raspberrypi-install-venus-packages for installing dbus-cli support.

For me on a Pi 3 B+ sometimes vedirect-dbus would segfault, sometimes it would run.

When it failed

 ps -ef | grep vedirect  

would show the vedirect-dbus process as <defunct>

running it manually and very verbose such as

/opt/victronenergy/vedirect-interface/vedirect-dbus -v -v -v -v -v -v --log-before 25 --log-after 25 -t30 --banner -s /dev/ttyUSB0

would show

failed to determine an unique number, see --dbus-instance

when it was failing.

(Or launch it with gdb --args (the previous command) then type run. Control-c and quit to exit.)

Manually adding a unique dbus instance to the command that launches vedirect-dbus seemed to solve it. For example edit /data/service/vedirect00/run to to call it as

/opt/victronenergy/vedirect-interface/vedirect-dbus -v --log-before 25 --log-after 25 -t30 --banner -s /dev/ttyUSB0 --dbus-instance 0

That dbus instance is what shows up in the VRM Portal as the Device Instance on the Device List page. When I don't have to set it it ends up 288 or 289 for a BMV-712 on a Victron USB to VE.Direct cable. When you manually set it it seems you can pick any unique ID for that device, from 0 to 65535.

I have not tried the --dbus-instance switch on a Pi Zero yet...

Hint for the Pi Zero W - try to use the environment variable VRM_IFACE to set an interface, such as wlan0, if you don't have an eth0 to get a MAC address from for your VRM Portal ID.

See /opt/victronenergy/vrmlogger/ext/velib_python/ve_utils.py

# Fall back to getting our id using a syscall. Assume we are on linux.
# Allow the user to override what interface is used using an environment
# variable.
import fcntl, socket, struct, os

iface = os.environ.get('VRM_IFACE', 'wlan0')
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
info = fcntl.ioctl(s.fileno(), 0x8927,  struct.pack('256s', iface[:15]))
__vrm_portal_id = ''.join(['%02x' % ord(char) for char in info[18:24]])
return __vrm_portal_id

Edit for clarity - I am using 2018-11 Raspian Stretch Lite. I consistently have gotten the SegFault on a Pi Zero and Zero WH. I have not tested on the Zero [WH] since discovering the --dbus-instance switch.

I have a Pi 3 B+ that sometimes would send data to VRM, and sometimes would SegFault, but since adding --dbus-instance 0 it has worked consistently.

I will try on different Pi versions and report back.

My hunch is vedirect-dbus is compiled for the ARMv7 of a Raspberry Pi 2/3, not the ARMv6 of a Zero or (1).

I created one microSD card and moved it between four Raspberry Pi models. Each had internet access via Ethernet. (The Zero using an SPI to Microchip ENC28J60 module.) I used Raspian 2018-11 Lite, and followed https://github.com/victronenergy/venus/wiki/raspberrypi-install-venus-packages to install the Venus package. On all systems dbus -y worked.

On the 3 B+ and 2 B it worked correctly, data from a BMV to the VRM Portal.

On the Zero and (1) B+ it did not work, ps -ef | grep vedirect showed vedirect-dbus to be <defunct>, and after stopping the vedirect00 service I gathered data with gdb and ldd, see below. vedirect-dbus reports itself as version 3.24.

Hardware details:

Pi 3 B+
Hardware : BCM2835
Revision : a020d3
model name : ARMv7 Processor rev 4 (v7l)

Pi 2 B
Hardware : BCM2835
Revision : a21041
model name : ARMv7 Processor rev 5 (v7l)

Pi (1) B+
Hardware : BCM2835
Revision : 0010
model name : ARMv6-compatible processor rev 7 (v6l)

Pi Zero
Hardware : BCM2835
Revision : 900093
model name : ARMv6-compatible processor rev 7 (v6l)

debugging info from Pi Zero

root@raspberrypi:~# ps -ef |grep vedirect
root       228   220  0 21:14 ?        00:00:01 supervise vedirect00
root       242   229  0 21:14 ?        00:00:00 multilog t s25000 n4 /var/log/vedirect00
root      1587   228  0 21:23 ?        00:00:00 [vedirect-dbus] <defunct>
root      1591   450  0 21:23 ttyAMA0  00:00:00 grep vedirect

root@raspberrypi:~# svc -d /etc/service/vedirect00
root@raspberrypi:~# cd /opt/victronenergy/vedirect-interface/

root@raspberrypi:/opt/victronenergy/vedirect-interface# ldd vedirect-dbus
        /usr/lib/arm-linux-gnueabihf/libarmmem.so (0xb6f4b000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6f22000)
        libdbus-1.so.3 => /lib/arm-linux-gnueabihf/libdbus-1.so.3 (0xb6ecf000)
        libevent-2.0.so.5 => /usr/lib/arm-linux-gnueabihf/libevent-2.0.so.5 (0xb6e81000)
        libevent_pthreads-2.0.so.5 => /usr/lib/arm-linux-gnueabihf/libevent_pthreads-2.0.so.5 (0xb6e6f000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d30000)
        /lib/ld-linux-armhf.so.3 (0xb6f61000)
        libsystemd.so.0 => /lib/arm-linux-gnueabihf/libsystemd.so.0 (0xb6cb6000)
        libevent_core-2.0.so.5 => /usr/lib/arm-linux-gnueabihf/libevent_core-2.0.so.5 (0xb6c80000)
        libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0xb6c4d000)
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6c36000)
        liblzma.so.5 => /lib/arm-linux-gnueabihf/liblzma.so.5 (0xb6c05000)
        liblz4.so.1 => /usr/lib/arm-linux-gnueabihf/liblz4.so.1 (0xb6be4000)
        libgcrypt.so.20 => /lib/arm-linux-gnueabihf/libgcrypt.so.20 (0xb6b13000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6ae6000)
        libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb6a6d000)
        libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6a5a000)
        libgpg-error.so.0 => /lib/arm-linux-gnueabihf/libgpg-error.so.0 (0xb6a3a000)

root@raspberrypi:/opt/victronenergy/vedirect-interface# gdb --args /opt/victronenergy/vedirect-interface/vedirect-dbus -v --log-before 25 --log-after 25 -t30 --banner -s /dev/ttyUSB0
GNU gdb (Raspbian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/victronenergy/vedirect-interface/vedirect-dbus...(no debugging symbols found)...done.
(gdb) run
Starting program: /opt/victronenergy/vedirect-interface/vedirect-dbus -v --log-before 25 --log-after 25 -t30 --banner -s /dev/ttyUSB0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00061f6e in ?? ()
(gdb) bt
#0  0x00061f6e in ?? ()
#1  0x00012dba in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) quit
A debugging session is active.

        Inferior 1 [process 1759] will be killed.

Quit anyway? (y or n) y

debugging info from Pi (1) B+

root@raspberrypi:~# ps -ef |grep vedirect
root       262   253  0 21:30 ?        00:00:00 supervise vedirect00
root       275   263  0 21:30 ?        00:00:00 multilog t s25000 n4 /var/log/vedirect00
root       495   262  2 21:30 ?        00:00:00 [vedirect-dbus] <defunct>
root       497   481  0 21:30 ttyAMA0  00:00:00 grep vedirect

root@raspberrypi:~# svc -d /etc/service/vedirect00
root@raspberrypi:~# cd /opt/victronenergy/vedirect-interface/

root@raspberrypi:/opt/victronenergy/vedirect-interface# ldd vedirect-dbus
        /usr/lib/arm-linux-gnueabihf/libarmmem.so (0xb6f49000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6f20000)
        libdbus-1.so.3 => /lib/arm-linux-gnueabihf/libdbus-1.so.3 (0xb6ecd000)
        libevent-2.0.so.5 => /usr/lib/arm-linux-gnueabihf/libevent-2.0.so.5 (0xb6e7f000)
        libevent_pthreads-2.0.so.5 => /usr/lib/arm-linux-gnueabihf/libevent_pthreads-2.0.so.5 (0xb6e6d000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d2e000)
        /lib/ld-linux-armhf.so.3 (0xb6f5f000)
        libsystemd.so.0 => /lib/arm-linux-gnueabihf/libsystemd.so.0 (0xb6cb4000)
        libevent_core-2.0.so.5 => /usr/lib/arm-linux-gnueabihf/libevent_core-2.0.so.5 (0xb6c7e000)
        libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0xb6c4b000)
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6c34000)
        liblzma.so.5 => /lib/arm-linux-gnueabihf/liblzma.so.5 (0xb6c03000)
        liblz4.so.1 => /usr/lib/arm-linux-gnueabihf/liblz4.so.1 (0xb6be2000)
        libgcrypt.so.20 => /lib/arm-linux-gnueabihf/libgcrypt.so.20 (0xb6b11000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6ae4000)
        libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb6a6b000)
        libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6a58000)
        libgpg-error.so.0 => /lib/arm-linux-gnueabihf/libgpg-error.so.0 (0xb6a38000)

root@raspberrypi:/opt/victronenergy/vedirect-interface# gdb --args /opt/victronenergy/vedirect-interface/vedirect-dbus -v --log-before 25 --log-after 25 -t30 --banner -s /dev/ttyUSB0
GNU gdb (Raspbian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/victronenergy/vedirect-interface/vedirect-dbus...(no debugging symbols found)...done.
(gdb) run
Starting program: /opt/victronenergy/vedirect-interface/vedirect-dbus -v --log-before 25 --log-after 25 -t30 --banner -s /dev/ttyUSB0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00061f6e in ?? ()
(gdb) bt
#0  0x00061f6e in ?? ()
#1  0x00012dba in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) quit
A debugging session is active.

        Inferior 1 [process 527] will be killed.

Quit anyway? (y or n) y

Discussion of compiling for armv6 vs armv7: https://stackoverflow.com/questions/39002372/cross-compiling-for-raspi-executing-the-programm-ends-in-segmentation-fault

List of different Pi Hardware: https://elinux.org/RPi_HardwareHistory

Here is how the packages are built:

The venus repo uses the conf called `raspbian`; which means there is only one machine, called `raspberrypi` [1].

Via the metas.whitelist file it doesn't use the machine configs we have in meta-victronenergy; so instead it uses the ones from meta-bin-deb.

Which means it will be using this one:

https://github.com/jhofstee/meta-bin-deb/blob/master/conf/machine/raspberrypi.conf

And there it says that the packages are being built with;

DEFAULTTUNE ?= "arm1176jzfshf"

For reference, this repo is from someone who really has his things in order normally:

https://github.com/agherzan/meta-raspberrypi/tree/master/conf/machine

And for the zero wifi he uses:

DEFAULTTUNE ?= "arm1176jzfshf"

require conf/machine/include/tune-arm1176jzf-s.inc

include conf/machine/include/rpi-base.inc

Which is the same (I didnt compare those include files.

I hope this helps you!

[1] https://github.com/victronenergy/venus/blob/master/configs/raspbian/machines

I'm very close, but on a Pi Zero and Pi (1) B+ it does not automatically send data to VRM after a reboot.

The Pi (1) B+ should have less issues than a Pi Zero, since the Pi Zero does not have an Ethernet port, and the Microchip ENC28J60 changes its MAC address on each boot, which could have been tripping me up.

I installed and configured the Venus Package per https://github.com/victronenergy/venus/wiki/raspberrypi-install-venus-packages on a 2014 Pi (1) B+ with Rapian 2018-11 Lite, copied a working ARMv6 compiled vedirect-dbus binary, and it can send data from a BMV Battery Monitor to the VRM Portal... but it stops sending the data to VRM after a reboot.

After the reboot the system gets the data from the BMV and stores it in the local database /data/db/vrmlogger-backlog.sqlite3 , but when checking the VRM portal it does not show the Venus as having connected since the reboot.

In /var/log/vrmlogger/current I get the error

MainThread-vrmlogger: get_announce() => exception while opening /tmp/last_boot_type: [Errno 2] No such file or directory: '/tmp/last_boot_type'.

I can get it to send the data cached in the local database, and then send live data, if I create the file /tmp/last_boot_type

svc -d /etc/service/vrmlogger
touch /tmp/last_boot_type
svc -u /etc/service/vrmlogger

But on reboot the issue happens again. (I tried to work around the issue with crontab @reboot and /etc/rc.local, but so far nothing but manually running those three commands makes it connect to VRM.

The code to deal with last_boot_type is in /etc/service/vrmlogger/vrmlogger.py

        try:
                with open('/tmp/last_boot_type', 'r+') as fileObject:
                        line = fileObject.readline()
                        boot_type = line.rstrip('\n')
                        if boot_type != '-3':
                                fileObject.seek(0,0)
                                fileObject.truncate()
                                fileObject.write('-3\n')  # Write to the file that we have already read it.
        except Exception, ex:
                logger.error('get_announce() => exception while opening /tmp/last_boot_type: %s.' % ex)
                boot_type = '-2'

On Raspian(Debian) there is a mechanism to create a file on boot:

create the file /etc/tmpfiles.d/vrmlogger.conf

# see https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html

# Type Path               Mode User Group Age Argument(file contents)
  F    /tmp/last_boot_type 755 root root  -   0

@400000005ca176773161edfc MainThread-dbusmonitor: Found: com.victronenergy.battery.ttyUSB0, scanning and storing items
@400000005ca1767731f87cf4 MainThread-dbusmonitor:        com.victronenergy.battery.ttyUSB0 has device instance 288
@400000005ca1767805c2059c MainThread-dbusmonitor: ===== Search on dbus for services that we will monitor finished =====
@400000005ca176781574ce34 MainThread-kwhdeltas: no suitable battery service found
@400000005ca1767818d6b9fc MainThread-kwhdeltas: no suitable battery service found
@400000005ca176782a044384 MainThread-vrmlogger: Starting to log, logmode == LogToVRM, url == https://ccgxlogging.victronenergy.com/log/log.php
@400000005ca176782d9e5264 MainThread-http_endpoint: Internal backlog buffer initialised. Count = 23
@400000005ca176782dbf24bc MainThread-http_endpoint: Found '' as remembered external path
@400000005ca176782ddf956c MainThread-http_endpoint: Checking '' for suitability for external storage
@400000005ca176782dff0c1c MainThread-http_endpoint: Mount point to check was empty.
@400000005ca176782e1cae0c MainThread-http_endpoint: Because we haven't found a suitable remembered external storage path, we're scanning for one to use.
@400000005ca176782e588e2c MainThread-http_endpoint: No mountpoint candidates found.
@400000005ca176782e770ec4 MainThread-http_endpoint: No suitable external storage path found
@400000005ca176782f331394 MainThread-http_endpoint: Starting sender thread
@400000005ca1767830458d34 MainThread-http_endpoint: Started sender thread
@400000005ca17678306a8ddc MainThread-http_endpoint: HttpEndpoint initialised, http worker thread running
@400000005ca176783a877f64 MainThread-vrmlogger: Starting mainloop, responding on only events
@400000005ca1768613dfe9dc HTTPThread-vrmhttp: Using existing VRM auth code

@400000005ca179d80d1ebde4 MainThread-http_endpoint: HttpEndpoint stopping, http worker thread stopped
@400000005ca179d80d4312ac MainThread-vrmlogger: logger stopped

@400000005ca17a2a2c3abf0c MainThread-dbusmonitor: ===== Search on dbus for services that we will monitor finished =====
@400000005ca17a2a3b2ee6dc MainThread-kwhdeltas: no suitable battery service found
@400000005ca17a2b030a30cc MainThread-kwhdeltas: no suitable battery service found
@400000005ca17a2b143c88cc MainThread-vrmlogger: Starting to log, logmode == LogToVRM, url == https://ccgxlogging.victronenergy.com/log/log.php
@400000005ca17a2b15c927f4 MainThread-http_endpoint: Internal backlog buffer initialised. Count = 41
@400000005ca17a2b15e9eaac MainThread-http_endpoint: Found '' as remembered external path
@400000005ca17a2b16083c64 MainThread-http_endpoint: Checking '' for suitability for external storage
@400000005ca17a2b16252aa4 MainThread-http_endpoint: Mount point to check was empty.
@400000005ca17a2b16461854 MainThread-http_endpoint: Because we haven't found a suitable remembered external storage path, we're scanning for one to use.
@400000005ca17a2b16820bfc MainThread-http_endpoint: No mountpoint candidates found.
@400000005ca17a2b169f8eac MainThread-http_endpoint: No suitable external storage path found
@400000005ca17a2b175c7ddc MainThread-http_endpoint: Starting sender thread
@400000005ca17a2b18b58214 MainThread-http_endpoint: Started sender thread
@400000005ca17a2b18d37224 MainThread-http_endpoint: HttpEndpoint initialised, http worker thread running
@400000005ca17a2b2279a154 MainThread-vrmlogger: Starting mainloop, responding on only events
@400000005ca17a2e1962e4cc HTTPThread-vrmhttp: Using existing VRM auth code
@400000005ca17a370db116bc MainThread-nonvolatilequeue: Vacuuming /data/db/vrmlogger-backlog.sqlite3, because the db is empty

So... I'm looking to use pi zero w with Venus image because, I've a grid off system, and need to economize any milliwatt, specially during winter when the sun do not direct recharge my battery ( because it's down) ....anyway now Venus still works on pi zero w?! ... Which are the right step I do to try?! ... I'm not a nerd coder, but I can follow the right steps

thx all people that's work on it...

Other were if there are no choice I'll buy a rpi model 3