question

Despite a large following for this post I received no suggestions so I started investigating using the D-bus further as an alternative to using a Victron node. What follows is directed at obtaining the Solar Charger Load Current but can be used for getting and setting a wide range of other information which is available on the D-bus.

In very simple terms the D-Bus is an inter-process communication mechanism; a medium for local communication between processes running on the same host. D-Bus is meant to be fast and lightweight. It is message based and instead of programs needing to interact with multiple other programs all communication is routed through the central D-Bus. The messages are handled by a daemon that runs the actual bus, a kind of "street" that messages are transported over, and to which any number of processes may be connected at any given time.

There are at least two ways to access the D-bus under the Venus OS from the Command Line or from scripts. The 'standard' low level way common to most machines is via dbus-send which actually Sets and Gets values. The other more focused solution is dbus which I understand is implemented using Python and is very slow. The invocation using dbus is however much shorter and easier to understand. dbus-spy is a useful Victron utility which enable one to inspect the D-bus configuration and current values.

First I logged in using SSH over the local network and used the dbus-spy command. This has a simple interface which you can navigate with the up, down, left, right keys to explore the system bus destinations at the first level and then the paths complete with the real time value returned by the GetValue method at the second level. These match the inputs we need for the dbus command. I found the destination for solar charger was com.victronenergy.solarcharger.ttyUSB3 and at the second level I was delighted to finally find Load/I So the dbus call one needs is:

dbus -y com.victronenergy.solarcharger.ttyUSB3 /Load/I GetValue

The -y option is to specify we are using the system bus (there can also be other buses).

This will go in an Exec Node and the message we get is actually a string "value = x.yyyyyyy" so this needs to be fed into a Function Node to convert it to a number and round it to a sensible number of decimal:

text = msg.payload;
text = text.substring(8, text.length - 1);
num = Math.round(text * 100) / 100;
msg.payload = num;
return msg

The only obscure point is that a text string containing a number it is automatically cast to a number in a Maths expression in JavaScript.

So the result is:

This is not an exact replacement as I have slowed it to once every 30 seconds which saves some nodes in my flows but more importantly, the dbus call is very slow, the call takes 0.85 second on my Raspberry Pi 3B+ so I want to reduce the processing load. In the longer term I may replace the dbus call by the faster dbus-send.

Hello @pcurtis, that’s impressive - dbus-send is much faster:

@splash suggest some code for dbus-send here:

https://community.victronenergy.com/questions/37257/venus-gx-command-relay.html

~# time dbus-send --print-reply --system --dest=com.victronenergy.solarcharger.ttyUSB3 /Load/I com.victronenergy.BusItem.GetValue | awk -F'double ' '{printf "%s",$2}END{print '\n'}'
0

real    0m0.018s
user    0m0.009s
sys    0m0.009s

~# time dbus -y com.victronenergy.solarcharger.ttyUSB3 /Load/I GetValue
value = 0.0

real    0m0.952s
user    0m0.717s
sys    0m0.077s

[ System: Pi3+ | VenusOS v3.00~4 ]

My solution above can be improved, in particular because the USB ports assigned to VE-Direct interfaces can change after a firmware update or sometimes even after a restart so it is best to obtain the interface after every restart. My solution is to:

Use dbus -y piped into grep to obtain the interface of the solar charger. I only have a single examples of the device so it is easy.

An Exec Node has the option to append the input msg.payload to the Command so now 'build' the parameter string using the interface obtained from dbus -y in a Function Node and then stores it in Context using a Change Node. This flow is run only once after every restart so it does not matter if it is slow.

Next one Injects the message payload containing the parameter string from Context into an Exec node and append it to a dbus-send Command. This is fast.

Some of the extraction of the value can be done in the Exec node but it is finally tidied up and rounded to 2 decimal places in a Function Node

So the end result is significantly more complex but is now much faster and should survive upgrades.

Most of the heavy lifting is done in the Function Node which builds the parameter string which is stored and then passed to the Exec node. Note it is two lines only so be careful copying.

msg.payload = " --system --print-reply --dest=" + msg.payload.trim() + " /Load/I com.victronenergy.BusItem.GetValue | grep variant | grep -Eo '[[:digit:]]+([.][[:digit:]]+)?'";
return msg 

These solution above can be adapted to almost any parameter on a VE-Direct (USB) interface but check every stage with Debug Nodes. In particular check the output of dbus-send which can be quite complex. The only 'clever' bit is the second grep -Eo '[[:digit:]]+([.][[:digit:]]+)?' which extracts decimal numbers from a text string. Those aficionados of awk will be able to formulate many alternative solutions!