Skip to content

commandline introduction

Jump to bottom Edit New page
Ivo Graber edited this page Mar 9, 2018 · 42 revisions

This page explains the software development oriented tools, tricks & tips.

There are also more operational commands, see here.

Working with D-Bus

Note that below examples use DbusCli (executable name: dbus). It is pre-installed on the CCGX, and can also be installed on your development computer. There are alternatives as well, see dbus-send.

Get a list of all dbus services

dbus -y

Get all paths of the com.victronenergy.settings service

dbus -y com.victronenergy.settings

Read a value

dbus -y com.victronenergy.settings /Settings/Logscript/Enabled GetValue

Read all values (works with most services, except some of the Python services including localsettings).

dbus -y com.victronenergy.solarcharger.ttyO2 / GetValue

Write a value

dbus -y com.victronenergy.settings /Settings/Logscript/Enabled SetValue %1

See the dbus interface

dbus -y com.victronenergy.settings /Settings/Logscript/Enabled

dbus-spy

dbus-spy is an ncurses tool, which shows a list of all com.victronenergy.* services on the D-Bus, and all paths and values within each service. The values are updated in real-time and can be changed.

The interface works somewhat like the CCGX gui:

  • up/down keys: move up and down in the menus
  • right/left: move in and out submenus
  • enter: enter a submenu or change a value.
  • 't': switch between values and texts.
  • ctrl-c or 'q': close the application

Besides above there is also the very cool Favorites function. See f and F in the Readme for details.

Caveat: by default dbus-spy will only show the values of D-Bus services which support a GetValue on '/', because finding all paths without this feature will take a long time, and a lot of D-Bus communication. If you want the content of the other services as well, start dbus-spy with the -i option and be patient.

dbus-send examples

dbus-send is a faster, but somewhat more complicated to use, alternative for dbus-cli as used in previous paragraph.

  dbus-send --system --dest=com.victronenergy.settings /Settings/System/RemoteSupportPort com.victronenergy.BusItem.SetValue variant:int32:67

  dbus-send --system --dest=com.victronenergy.settings /Settings/System/RemoteSupportPort com.victronenergy.BusItem.GetValue

  dbus-send --system --print-reply --dest=com.victronenergy.settings /Settings/System/LogLevel com.victronenergy.BusItem.SetValue variant:int32:0

  dbus-send --system --print-reply --dest=com.victronenergy.settings /Settings/System/LogLevel com.victronenergy.BusItem.SetValue variant:int32:0

  dbus-send --system --print-reply --dest=net.connman /net/connman/technology/wifi net.connman.Technology.SetProperty string:"Powered" variant:boolean:true

  dbus-send --system --print-reply --dest=net.connman /net/connman/ net.connman.Technology.SetProperty string:"Powered" variant:boolean:true

Connmand Manager
  dbus-send --system --type=method_call --print-reply --dest=net.connman  net.connman.Manager.GetProperties
  dbus-send --system --type=method_call --print-reply --dest=net.connman net.connman.Manager.GetTechnologies
  dbus-send --system --type=method_call --print-reply --dest=net.connman net.connman.Manager.GetServices

  dbus-send --system --type=method_call --print-reply --dest=net.connman  / net.connman.Technology.Scan

  dbus-send --system --type=method_call --print-reply --dest=com.victronenergy.qwacs /Manager com.victronenergy.manager.TestArray
  dbus-send --system --type=method_call --print-reply --dest=com.victronenergy.qwacs /Gateway com.victronenergy.gateway.GetUplink

**Connmand Service**
  dbus-send --system --type=method_call --print-reply --dest=net.connman net.connman.Service.GetProperties

**Connman NTP**
  dbus-send --system --type=method_call --print-reply --dest=net.connman  org.freedesktop.DBus.Introspectable.Introspect

  dbus-send --system --type=method_call --print-reply --dest=net.connman / net.connman.Clock.GetProperties

  dbus-send --system --type=method_call --print-reply --dest=net.connman / net.connman.Clock.SetProperty string:"Timezone" variant:string:"Europe/Amsterdam"

  dbus-send --system --type=method_call --print-reply --dest=net.connman / net.connman.Clock.SetProperty string:"Timerservers" array:string:"0.pool.ntp.org","1.pool.ntp.org"

**udev mount**
  dbus-send --system --type=signal / com.victronenergy.udev.mount string:$DEVNAME string:"/media/$name"

**udev umount**
  dbus-send --system --type=signal / com.victronenergy.udev.umount string:$DEVNAME string:"/media/$name"

Managing services

svstat /service/logscript
svstat /service/*
svc -d /service/logscript
svc -u /service/logscript

Reading log files

tail -F /log/logscript/current | tai64nlocal
more /log/mk2/current | tai64nlocal
tail /log/*/current | tai64nlocal
dmesg
cat /log/messages.2 /log/messages.1 /log/messages.0 /log/messages | tai64nlocal
logread
grep -h -i "ERROR" /log/*/current | tai64nlocal
for file in `ls /log/*/current`; do echo "cleared log at `date`" > $file; done

Opkg

See versions of all packages

Note that Venus updates are image based. See the swupdate issue.

The package manager, opkg, is still available. And can be used to install optional installs.

root@ccgx:~# opkg list-installed
base-files - 3.0.14-r76
base-passwd - 3.5.26-r0
bash - 4.2-r5
...
websockify-c - v0.8.0-r1
wget - 1.14-r16.2
wpa-supplicant - 2.2-r1
wpa-supplicant-cli - 2.2-r1
wpa-supplicant-passphrase - 2.2-r1
zip - 3.0-r1
/opt/colorcontrol/opkg-scripts/set-feed

Then update the package list

opkg update

Then install a package

opkg install [name of package here]

To find other packages, such as gdb, do: opkg list | grep gdb

Analyzing logfiles quickly

Configure the ipaddress:
  export CURRENTIP=192.168.4.108
  
First arrange auto-login by using ssh-copy-id to all ipnumbers you want to look at.
  ssh-copy-id root@$CURRENTIP  
  
Check that you have the right one
  ssh root@$CURRENTIP "ifconfig"
  
Then copy past below lines.
  ssh root@$CURRENTIP "cat /log/vrmlogger/* | tai64nlocal"
  ssh root@$CURRENTIP "cat /log/vrmpubnub/* | tai64nlocal"
  ssh root@$CURRENTIP "cat /log/mk2/* | tai64nlocal"
  ssh root@$CURRENTIP "cat /log/dbus-pvinverter-vebus/* | tai64nlocal"
  ssh root@$CURRENTIP "cat /log/dbus-systemcalc-py/* | tai64nlocal"
  ssh root@$CURRENTIP "cat /log/vecan/* | tai64nlocal"    (note, starting message is not in the logs)
  ssh root@$CURRENTIP "cat /log/messages.2 /log/messages.1 /log/messages.0 /log/messages | tai64nlocal"
  ssh root@$CURRENTIP "cat /log/messages.2 /log/messages.1 /log/messages.0 /log/messages | tai64nlocal | grep Aligment"

CPU speed

root@CCGX:/sys/devices/system/cpu/cpu0/cpufreq# cat ./scaling_available_governors conservative userspace powersave ondemand performance root@CCGX:/sys/devices/system/cpu/cpu0/cpufreq# echo performance > ./scaling_governor root@CCGX:/sys/devices/system/cpu/cpu0/cpufreq# cat ./scaling_governor performance root@CCGX:/sys/devices/system/cpu/cpu0/cpufreq# cat ./cpuinfo_cur_freq 600000

Serial port & serial-starter

The serial-starter service is doing the plug-and-play function for devices with a serial connection. The color-control and other Venus devices do not have a hardware serial port, so USB converter cables are used. Most serial communication protocols are very simple and do not provide any means of identifying connected devices. To work around this Victron provides USB converter cables which are preprogrammed with a special USB-Id (ID_MODEL). The serial-starter uses the id to identify the device it connects to. That means that the cables cannot be interchanged arbitrarily! In practice, the same USB-Id can be used for several different devices.

The serial-starter does the following:

  • detect all (new) USB devices (/dev/ttyUSBx)
  • for each device:
    • read its ID_MODEL using udevadm info
    • look up the device class in /etc/udev/rules.d/serial-starter.rules
    • look up the available drivers in /etc/venus/serial-starter.conf
    • run all available drivers one by one:
      • The drivers are implemented such that if they can't detect a device at the other end of the line that they support, they exit again. Serial-starter will then try the next one, and so forth. Restarting from scratch and forever continuing when none of the drivers sticks.

More details on the current serial-starter implementation are in these issues:

And of course also in the implementation itself, see /opt/victronenergy/serial-starter on your Venus device.

To see serial starter in action, run ps and grep for all services that were passed your serial port in the command line. Run it a few times to make sure you catch whats going on.

root@raspberrypi2:~# ps | grep ttyUSB0
 1300 root      1580 S    supervise vedirect-interface.ttyUSB0
 1308 root      1596 S    multilog t s99999 n8 /var/log/vedirect.ttyUSB0
 1390 root      1580 S    supervise gps-dbus.ttyUSB0
 1402 root      1596 S    multilog t s99999 n8 /var/log/gps-dbus.ttyUSB0
 5271 root      3048 S    {start-gps.sh} /bin/bash /opt/victronenergy/gps-dbus/start-gps.sh ttyUSB0
 5284 root      3144 S    /opt/victronenergy/gps-dbus/gps_dbus -v --banner --dbus system --timeout 2 -s /dev/ttyUSB0 -b 38400
 5286 root      2264 S    grep ttyUSB0
root@raspberrypi2:~# ps | grep ttyUSB0
 1300 root      1580 S    supervise vedirect-interface.ttyUSB0
 1308 root      1596 S    multilog t s99999 n8 /var/log/vedirect.ttyUSB0
 1390 root      1580 S    supervise gps-dbus.ttyUSB0
 1402 root      1596 S    multilog t s99999 n8 /var/log/gps-dbus.ttyUSB0
 5321 root      3048 S    {start-vedirect.} /bin/bash /opt/victronenergy/vedirect-interface/start-vedirect.sh ttyUSB0 PRODUCT=P1_Converter_Cable
 5323 root      2780 S    /opt/victronenergy/vedirect-interface/vedirect-dbus -v --log-before 25 --log-after 25 -t 3 --banner -s /dev/ttyUSB0
 5325 root      2264 S    grep ttyUSB0

In above example you see first see the gps daemon being started against our tty, at 38400 bps. And there-after the vedirect-interface driver.

Now, how to make serial-starter ignore your tty?

One way is if it has a somehow unique ID_MODEL-USB propery. Run this code to see the ID for your device: udevadm info --query=property --name=/dev/ttyUSB0 | sed -n s/^ID_MODEL=//p

Note that ftdi serial converters, and other brands as well I suppose, can programmed with a unique ID. See ft_prog for ftdi.

Then, in case its unique, and you simply want serial-starter to ignore the port, add the id to the ignore statement in serial-starter.sh, in the get-program() function, around line 73:

...
get_program() {
    product=$1

    case $product in  
        builtin-mkx|MK3-USB_Interface)
            echo mkx
            ;;   
        builtin-vedirect|VE_Direct_cable)
            echo vedirect
            ;;
        FT232R_USB_UART)
            echo cgwacs:gps:vedirect
            ;;
        USB-RS485_Cable)
            echo cgwacs:redflow
            ;; 
        USB-Serial_Controller_D)
            echo cgwacs:gps
            ;;
        ignore|P1_Converter_Cable)
            echo ignore
            ;;
        *)
            echo gps:vedirect
            ;;
    esac
}
...

In above example, I've added P1_Converter_Cable. Then restart the Venus device, and then run the ps | grep command a few times again to make sure the serial port is left alone:

root@raspberrypi2:~# ps | grep ttyUSB0
 8713 root      2264 S    grep ttyUSB0

Then, finally, set the baudrate and run cat to see data coming into the serial port:

root@raspberrypi2:~# stty -F /dev/ttyUSB0 115200
root@raspberrypi2:~# cat /dev/ttyUSB0 
/XMX5LGBBFG1009224834

1-3:0.2.8(42)
0-0:1.0.0(171227232200W)
0-0:96.1.1(4530303330303033313536383532323135)
...

Next level: make serial starter auto start this

  1. install (or at least symlink in case you have your code on the data partition) your software in /opt/victronenergy/ like all the drivers and also other executables.
  2. make sure there is a service directory below that: /opt/victronenergy/your-program/service. Look at another driver for an example. The TTY will need to be passed, see vedirect-interface/service for an example.
  3. note that also in the /log/run file there is a TTY placeholder.
  4. add your program to serial-starter.sh. At the top in the list, and also in the get-program() case statement.
  5. since USB devices trigger the serial-starter via udev, simply restarting the serial-starter is not enough. So, reboot the device, or replug your USB device to make the magic work.
  6. note (ofcourse) tail -F /log/serial-starter/current | tai64nlocal
Add a custom footer
Add a custom sidebar
Clone this wiki locally