question

Have you tried adding:

packagegroup-core-buildessential

with opkg? This fixes a lot of problems. I upgraded one pi to python3 for some tests that was interesting

I decided to take a closer look at the Python scripts included with the install.
It turns out that instead of

from gi.repository import GLib

they're using

from dbus.mainloop.glib import DBusGMainLoop
import gobject

. Then creating the main loop using

DBusGMainLoop(set_as_default=True)
mainloop = gobject.MainLoop()

So that begs the question, which is the correct way for the future, especially knowing Python 3 is in the wings? Please understand that Python is all new to me anyway!

Anyway, for now I have got the script working using the above changes, but will have a look at the mentioned opkg.

Sadly no joy doing

opkg install packagegroup-core-buildessential

It certainly dragged in a heap of packages and installed them, but it looks like mainly a gcc set of tools.

So for now I'll just use the method I described.

I've also loaded python3 on top of Venus 2.72, major issue here is that there is no pip3 in the repository, you have to install non standard packages (gpio) with setup tools - but that works fine as long as you can get the package source code.

Main loop becomes:

DBusGMainLoop(set_as_default=True)
mainloop = GLib.MainLoop()

as gobject is deprecated.

Build essentials did take some tries to install.

OK. So it seems we're in a state of flux ATM in regards the transition to Python 3.
Repo examples are up to date, but the Venus OS install is behind. I'm also on V2.72

Being the non expert in the ways of Python I may just let it ride until the experts release the promised Python 3 version.

For now I have fake values I desire available on the dbus , but many other aspects to deal with like the .qml behind the GUI pages to present what is now available on the dbus, and of course completing the connection to my custom hardware.

The half baked driver I have crafted does allow me to write to dbus via ModbusTCP, also making the required changes there to the attributes and unitid config files.

I developed a BMS system with an SPI interface, originally using the standard Raspian OS, with pymodbus, myql and Flask to provide the web server. This all works fine, and I configured some HTML pages to view the BMS data. Then I added in some service programs to handle the VE Direct/modbus and VE-Bus/modbus to interface to the MPPT and inverters. Then I translated the whole of the BMS software into python 2.7, and got it to run with Louis's d-bus serial battery software which saved a huge amount of development time. Then I added the python 3 to Venus 2.72, and found only 3 Victron scripts needed modifying - plus some of the d-bus battery code. I'm now trying to integrate the migration from mysql to sqlite-3, which is available with the Venus Os to record long term battery history on the sd card. I might spend some time looking into the .qml code as there are some features lacking in the battery display. You don't mention what you are trying to achieve?

I've replaced the OEM mains charger in my caravan with a Victron unit, but doing so I lose the nice self resetting "fuses" that unit provided.

They were using "ProFets" which are high side switching mosfets, which also include current monitoring.
So I've built a unit up that provides 16 Profet outputs to replace the old charger's handy feature.
But the enhancement I wish to do, and was not in the old unit, is to report the current heading out to each load. There has been times I've stood there and pondered "where is that 3A going" and all obvious loads are accounted for.

So it is all open to change at the moment how I actually get the info out of my box, it could be serial, Bluetooth or Wifi, undecided right now. For now I can just open a Bluetooth terminal and see the raw info.

But the nexus is getting custom states into Venus/dbus, and the python script gets that working.
There is also the Qt side to bring the info up on the touch screen, and yeah that's even more poorly documented detective work.
I have already removed the useless AC in / AC out and Inverter boxes from the touch screen - don't have any of that equipment, no need to take up 50% of screen real estate!

My project is not essential, but is something to do, and honestly I am surprised that Victron have NOTHING like this now!
Perhaps many more $ in selling inverters or basic Lynx boxes - smart DC loads seem like a dirty world from what I read here :-(

sounds interesting,developing a "wiki" on this type of modifications would be good, so the data is in one place. Haven't seen anything like that so far.

As far as an intelligent dc load center goes, I think the reason the big V doesn't do anything like that, is that every user is different. just monitoring the fuse state is pretty basic.Adding custom dbus services is not a problem. I've done that and seen the results in the dbus monitor. The trick is to get the data displayed - and so far I've had other fish to fry. Apparently d-bus can be used to exchange information between different processors - https://stackoverflow.com/questions/15174043/using-d-bus-for-multiple-machines-over-the-internet, so you could have your current measuring device use an Ethernet connection to your Venus device, (with my bms the bms is the Venus device) which would simplify the interface - so you could run a pi, with 2 x 8 ADC's in your current measuring center, and then use d-bus over Ethernet to directly get the data to the Venus display device. You then just have the problem of displaying it...

With a well timed beta release overnight (well it was for .au), I have installed Venus V2.80~11 on a spare RPi and the initial python code now runs fine using

from gi.repository import GLib

I may keep playing in that candidate system for now, and leave the caravan intact and stable for now :-D

I too just loaded 2.8, but it does not have the python modules I need for my code to run, and there is no way to install these yet...