question

pcurtis avatar image
pcurtis asked

SmartSolar MPPT 100/20 48V missing Load Current option in Node-RED in OS v2.92

I have just updated my 'operational' system from OS v2.80 to V2.92 and Load Current is no longer available in the list of available values in the Victron Node. It is however still present in the VRM displays and Victron Connect

screenshot-from-2022-11-10-09-11-14.pngscreenshot-from-2022-11-10-04-19-44.png
Has anybody else experienced this problem and are there any suggestions on how to get the Load Current data into Node-RED? So far I have checked with dbus-spy and it does not seem to be present on the dbus either.

MPPT ControllersVenus OSRaspberry PiNode-RED
2 |3000

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

3 Answers
pcurtis avatar image
pcurtis answered ·

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:

example-dbus-flow.png

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.


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.

pcurtis avatar image pcurtis commented ·

Seriously Off Topic, I notice I seem to have just been awarded "Expert" status. I am not sure if is justified in this arena but it is now over 55 years since I wrote my first program in Atlas Autocode on the Manchester/Ferranti Atlas where my vacation job was actually winding up paper tapes. The Manchester Atlas was one of the world's first supercomputers and it was initially claimed to be the most powerful computer in the world and was promoted by the saying that when it went offline, half of the United Kingdom's computer capacity was lost. - how things have changed!

1 Like 1 ·
olafd avatar image
olafd answered ·

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 ]

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.

pcurtis avatar image pcurtis commented ·
@OlafD @splash Thanks for the extra code, I had run out of space and could not face explaining dbus-send. dbus is so much easier first time. My own timings also used time and I got 0.857 on a Raspberry Pi 3B+ and 0.502 on a Pi 4B

The speed issue has already been raised at https://community.victronenergy.com/questions/34398/dbus-script-unbearably-slow.html and it seems to be the python implementation judging by @Jeroen 's comment, my tests did not show any significant differences in what you accessed.

0 Likes 0 ·
pcurtis avatar image
pcurtis answered ·

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.

smart-dbus-node.png

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!


smart-dbus-node.png (35.8 KiB)
2 |3000

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