question

novice avatar image
novice asked

Venus Packages on Raspbian Lite (Stretch)

Hello!


Has anyone been successful with this guide:

https://github.com/victronenergy/venus/wiki/raspberrypi-install-venus-packages on a raspberry pi using the latest Raspbian (lite) Stretch? I get a segmentation fault when trying to run /opt/victronenergy/vedirect-interface/vedirect-dbus directly


I can provide more info (core dump, etc)


Can anyone confirm what the latest actual venus PI images run on? I thought about trying to extract the vedirect-dbus binary from that image and trying.


Venus OSRaspberry Pi
4 comments
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

novice avatar image novice commented ·

I copied the binaries from the latest venus pi image and get an illegal instruction error now.

I'm using an original pi from my pile of boards (no pun intended?)


At this point I'll just install the last version of Jesse and move on with my life.


Unless someone from Victron ( @Izak (Victron Energy Staff) maybe?) cares to update the packages to support Stretch?

This could help other people that want to use unsupported boards. I have some arm boards that idle less than 250ma but have a few issues with Jesse. They would be great for monitoring remote sites!


Thank you.

0 Likes 0 ·
novice avatar image novice novice commented ·

Ok, just did a fresh install of the last version of Jesse and now I'm getting the same Segmentation fault!

0 Likes 0 ·
novice avatar image novice commented ·

Ok, getting somewhere now.....it appears I need to be running X11 for dbus to work. I've been running Raspbian lite....

0 Likes 0 ·
mvader (Victron Energy) avatar image mvader (Victron Energy) ♦♦ novice commented ·

@mreimer said that there is already a system dbus on Raspbian Lite before installing X11; so then the question is: what else does installing X11 do that makes this work? I can’t think of anything

0 Likes 0 ·
5 Answers
jr-marshall avatar image
jr-marshall answered ·

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.

17 comments
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

mvader (Victron Energy) avatar image mvader (Victron Energy) ♦♦ commented ·

Hi! Thats great results. So, to summarize: the vedirect-interface package works now on a RaspberryPi Zero W; running Raspbian Lite. Right?

So case closed; only last thing to do is update the wiki on our github wrt the instructions.

(And possibly looking into why its failing. Still interested in that?)


UPDATE: I’m asking; because I couldn’t 100% sure conclude if you were done with testing or not; and how much was tested on the zero and how much on raspbian lite


0 Likes 0 ·
mreimer avatar image mreimer mvader (Victron Energy) ♦♦ commented ·

Passing --dbus-instance 0 does not work for me:

# /opt/victronenergy/vedirect-interface/vedirect-dbus -v --log-before 25 --log-after 25 -t30 --banner -s /dev/serial/by-id/usb-VictronEnergy_BV_VE_Direct_cable_VE28E1FS-if00-port0 --dbus-instance 0
Segmentation fault

I'm ready and willing to debug this, with some guidance.

0 Likes 0 ·
mreimer avatar image mreimer mreimer commented ·

...on a Pi Zero W running the latest Raspbian, to be specific.

0 Likes 0 ·
jr-marshall avatar image jr-marshall mreimer commented ·

@mreimer - sorry for the non-starter with --dbus-instance. That had seemed to help me on a Pi 3 B+ that sometimes segfaulted, but the root cause of that issue now seems unrelated to the Pi Zero issue.

0 Likes 0 ·
mreimer avatar image mreimer mreimer commented ·

Recompiling on the Pi Zero W using the pre-installed Raspbian toolchain gets redirect-interface working. I'm happily reporting data from my SmartSolar 75/15 to VRM.

0 Likes 0 ·
jr-marshall avatar image jr-marshall mreimer commented ·

@mreimer - outstanding! Good job.

0 Likes 0 ·
novice avatar image novice mreimer commented ·

Awesome!


Would you be able to provide a brief synopsis of the process or point to the sources you used for us to figure out? Thank you!

0 Likes 0 ·
mreimer avatar image mreimer novice commented ·

Someone from Victron gave me access to the source to test this. All I had to do was to install libevent-dev and libdbus-1-dev, then follow the simple instructions to build the software. The source is not mine to give. The point was to prove that recompiling gets it working.

The next step is to figure out how to rebuild the publicly-available packages appropriately, but I don't have access to that. As I understand it, the ball is in Victron's court now. We're getting there.

0 Likes 0 ·
mvader (Victron Energy) avatar image mvader (Victron Energy) ♦♦ mreimer commented ·

Haha; actually I thought the ball was in your court @mreimer; so good to discuss that!

See this message from me in this thread; were I explain how it works.

I was hoping that could lead to some pointers of where the issue is.


@J.R. Marshall; since you were in a hurry due to an education program; are you all fine now for that in the mean time?



0 Likes 0 ·
jr-marshall avatar image jr-marshall mvader (Victron Energy) ♦♦ commented ·

@mvader (Victron Energy Staff) - I am great, thank you.

And thank you to @mreimer for documenting the two required packages to compile vedirect-interface and create a Pi Zero compatible vedirect-dbus binary.

I have a Pi Zero connected to a Microchip ENC28J60 SPI to Ethernet IC, sending BMV data to VRM!

I had to figure out a few more tricks - /etc/rc.local has to touch /tmp/last_boot_type , and I had to install the connman package. Also I have a script/service that sets a Raspberry-Pi style MAC address (Otherwise the ENC28J60 driver sets a different random MAC on each boot!)

0 Likes 0 ·
buzzlightyear avatar image buzzlightyear mvader (Victron Energy) ♦♦ commented ·

I'm really keen to have it working on Pi Zero W, what's the current status on this issue?

0 Likes 0 ·
buzzlightyear avatar image buzzlightyear mvader (Victron Energy) ♦♦ commented ·

@mreimer and @mvader (Victron Energy Staff) any chance of the necessary packages being updated so it can run on a pi zero? @mreimer are you able to share the compiled package for us to use on pi zero?

0 Likes 0 ·
mvader (Victron Energy) avatar image mvader (Victron Energy) ♦♦ buzzlightyear commented ·

Hi @buzzlightyear, its still waiting for someone (not us unfortunately) to look into why our build system is not producing them that way.


Compiling separately works; but thats (a) not really unexpected and (b) not whats necessary. And (c) nice ofcourse :-)

You’re welcome to look into it!

0 Likes 0 ·
buzzlightyear avatar image buzzlightyear mvader (Victron Energy) ♦♦ commented ·

@mvader (Victron Energy Staff) I'm happy to look into it, are you or @mreimer able to give my some pointers to start please?

0 Likes 0 ·
buzzlightyear avatar image buzzlightyear mreimer commented ·

Are you able to share the binary you compiled for vedirect-dbus so I can try on my zero please?

0 Likes 0 ·
novice avatar image novice buzzlightyear commented ·

I would also like binaries or build directions if someone could be so kind to share! I would be running this on a nano pi neo.

0 Likes 0 ·
gul-dukat avatar image gul-dukat novice commented ·
Just Bumping this thread. I have also been trying to grt vrmlogger to run on my pi zero. See fault as the binary from the jessie and buster repo are I believe compiled for armv7 not lower.
0 Likes 0 ·
jr-marshall avatar image
jr-marshall answered ·

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

7 comments
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

mreimer avatar image mreimer commented ·

That stackoverflow link probably describes this problem, in which case the solution is to compile with -mfpu=vfp, which is what the Pi Zero's Raspbian toolchain uses, as confirmed with "arm-linux-gnueabihf-gcc -Q --help=target".

gdb's "info file" says the entry point is 0x12da8, which is just a handful of instructions before stack frame 1 above:

$ objdump -a -x -D --disassembler-options=force-thumb /opt/victronenergy/vedirect-interface/vedirect-dbus

shows

   12da8:       f04f 0b00       mov.w   fp, #0
   12dac:       f04f 0e00       mov.w   lr, #0
   12db0:       bc02            pop     {r1}
   12db2:       466a            mov     r2, sp
   12db4:       b404            push    {r2}
   12db6:       b401            push    {r0}
   12db8:       f8df c010       ldr.w   ip, [pc, #16]   ; 12dcc <tcgetattr@plt+0x10c>

(I needed to pass "force-thumb" because otherwise the output didn't make sense.)

Interestingly, 0x00012dba appears to be in the middle of an instruction. It's quite probable I haven't instructed objdump the right way.


The second frame in the backtrace is 0x00061f6e, which doesn't correspond to an address in the link map shown above, but it is an address on the heap:

# cat /proc/12319/maps 
00010000-00026000 r-xp 00000000 b3:02 132716     /opt/victronenergy/vedirect-interface/vedirect-dbus
00035000-00036000 r--p 00015000 b3:02 132716     /opt/victronenergy/vedirect-interface/vedirect-dbus
00036000-00037000 rw-p 00016000 b3:02 132716     /opt/victronenergy/vedirect-interface/vedirect-dbus
00037000-0006f000 rw-p 00000000 00:00 0          [heap]
0 Likes 0 ·
buzzlightyear avatar image buzzlightyear jeroen ♦ commented ·

@Jeroen any suggestions how we can resolve the issue please?

0 Likes 0 ·
jeroen avatar image jeroen ♦ buzzlightyear commented ·

Well first of all to summarize the problem. The packages gets compiled with a standard Debian cross compiler configured that armhf is armv7-a. You are attempting to run that on an armv6 and that ain't going to work. It works fine for us since we only support raspberrypi 2 and above, so we simply dropped the armv6 tune so we don't need a special compiler.

I don't think it can be resolved without changing the compiler.

0 Likes 0 ·
jeroen avatar image jeroen ♦ buzzlightyear commented ·

perhaps a useful addition, you get "sorry, unimplemented: Thumb-1 hard-float VFP ABI" if you try to compile for armv6 with such a compiler.

0 Likes 0 ·
jr-marshall avatar image jr-marshall jeroen ♦ commented ·

FWIW, The Raspian FAQ
https://www.raspbian.org/RaspbianFAQ
says:

...the settings required for most GNU tools are as follows:
  • -march=armv6

  • -mfpu=vfp

  • -mfloat-abi=hard

0 Likes 0 ·
jeroen avatar image jeroen ♦ buzzlightyear commented ·

This community stuff is too chaotic for me, if you want to reach me send it to victron-dev-venus@googlegroups.com.

0 Likes 0 ·
mvader (Victron Energy) avatar image
mvader (Victron Energy) answered ·

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

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

jr-marshall avatar image
jr-marshall answered ·

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


However it still isn't getting the data to VRM after a reboot. I can now just stop and start vrmlogger, without manually creating the file.

I tried with tmpfiles.d creating an empty file, and putting 0, 1 and -3 in the file, same issue.


vrmlogger log after boot:

@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


svc -d /etc/service/vrmlogger

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


svc -u /etc/service/vrmlogger

@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


See also:

https://github.com/victronenergy/venus/wiki/watchdog victronenergy/venus/watchdog

https://github.com/victronenergy/venus/issues/10 boot type is always 0

1 comment
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

jeroen avatar image jeroen ♦ commented ·

This is incorrect, vrmlogger should start fine without /tmp/last_boot_type being present. It should log -2, no boot reason known, see the except. There should be no need to create the file during boot.

1 Like 1 ·
daniele-debernardi avatar image
daniele-debernardi answered ·

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

1 comment
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

mvader (Victron Energy) avatar image mvader (Victron Energy) ♦♦ commented ·
Hi, I'd recommend to make a new post for this, rather than adding something to an only slightly related other question.


Packages, the topic of this thread, is not the same as the Venus image.


And to answer your question: there is no venus image available for the pi zero w. And making one is not something very simple either I'm afraid.

0 Likes 0 ·