Development on Raspberry Pi

[Ingo]

Is there an easy way to start fiddling with Venus OS on Raspberry Pi?

I've installed the pre-build VenusRPi images on my Pi2 and it works great. What I am after is to fiddle a bit. My initial goal is to try and add a third-party energy meter to the system, via ModbusTCP, to read energy consumption at point X.

Is this going to be difficult to impossible? Or do I have a chance to get this right with some guidance?

Thanks,

Ingo

[___]

On 2018/10/27 at 3:44 PM, Ingo said:

I've installed the pre-build VenusRPi images on my Pi2 and it works great. What I am after is to fiddle a bit. My initial goal is to try and add a third-party energy meter to the system, via ModbusTCP, to read energy consumption at point X.

Start here. Then you probably need to look at what a grid meter needs to publish, so look here, and then you can also look at the provided velib_python (not the most beautiful code but does the trick) for some examples on implementing your own services. Venus already includes pymodbus.

[Ingo]

Thanks for the pointers. I'll study all your references and see if I can get something simple like /Ac/L1/Voltage going. 

[___]

You can also take a look at my battery proxy script. It's a conglomeration of hackeries, combining code that watches value changes with code that pretends to be a battery. I wrote it so I can fake  BMS, so essentially it takes a BMV as a "slave" and adds on data to it. It's a good example as it shows you how to publish values (as well as watch others, which you probably don't need to do).

You can also just consult google on how dbus works. It's pretty much the defacto linux IPC bus.

[Ingo]

Excellent!! This will surely help.

[___]

Oh I forgot about this. This uses modbus rtu to talk to a wind turbine and publish to dbus. It's not the neatest code, in fact I hate it a tiny bit (just looking through there right now... really need to fix that to use new style classes and make it less java-ish), but it has almost all the bits you need.

[ghatikar]

I will be also watching the development with interest  Although don't have enough time and inclination to write it myself I do have a  Modbus energy meter which I would not mind monitoring to separate loads between AC out 1 and AC out 2 

[Ingo]

On 2018/10/29 at 9:51 AM, plonkster said:

Oh I forgot about this. This uses modbus rtu to talk to a wind turbine and publish to dbus. It's not the neatest code, in fact I hate it a tiny bit (just looking through there right now... really need to fix that to use new style classes and make it less java-ish), but it has almost all the bits you need.

Ok, I managed to use the wind turbine code to get my PM9C energy meter going via TCP and publish three values to dbus. I think however that the publishing is not working the way it should. I created my own section and when reading from this location it doesn't return anything except an error.

root@raspberrypi2:/opt/victronenergy/dbus-pm9c# dbus -y                                       
org.freedesktop.DBus
com.victronenergy.sensor.schneider_502
com.victronenergy.system
com.victronenergy.qwacs
com.victronenergy.logger
com.victronenergy.fronius
com.victronenergy.settings
net.connman
fi.epitest.hostap.WPASupplicant
fi.w1.wpa_supplicant1
root@raspberrypi2:/opt/victronenergy/dbus-pm9c# dbus -y com.victronenergy.sensor.schneider_502
ERROR:dbus.proxies:Introspect error on :1.606:/: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
/
root@raspberrypi2:/opt/victronenergy/dbus-pm9c#

Any ideas where I can look?

[___]

It looks like your introspection code isn't working. With dbus, you can query a service to find out how to call the methods.

What you need is to implement GetValue (returns a variant), SetValue (takes a variant as a parameter), and whenever the value changes you need to send a PropertiesChanged signal with the Value and Text of the changed item. This is normally handled for you if you use the VeDbusService class in the vedbus module in velib_python.

(Yes, I wish it was a bit neater, packaged as a proper python egg/package... but it is a bit hard, it is used on embedded devices as well, so the trick is pretty much to hack it into the PYTHONPATH and go from there).

[Ingo]

I  see that the directory referenced below is empty. I use dbusservice as per your original wind turbine example. Should I change it?

self.dbusservice.add_path('/AcOut2/Voltage', 0, writeable=True)

 

# importing dbus complements                                                                                                                       
sys.path.insert(1, os.path.join(os.path.dirname(__file__), './ext/velib_python'))                                                                  
from vedbus import VeDbusService #VeDbusItemImportObject paths that are mandatory for services representing products 

No worries on the code style, I can read it fine for a mostly HW guy 

[___]

12 minutes ago, Ingo said:

I  see that the directory referenced below is empty. I use dbusservice as per your original wind turbine example. Should I change it?

It's not a directory. It is a "dbus path", a way to arrange things in a hierarchical manner.

AcOut2 is not a standard path. The Guys who wrote that added some of their own stuff.

For a power meter the only things you need to publish is voltage (per phase), current (per phase), power (per phase), and forward and reverse energy counters (per phase), and then the overall power and energy counters across all phases. Most meters implement these and you only need to periodically fetch them using modbus and then republish them on dbus. See here.

Then you are also expected to put some things under /Mgmt and a few things directly in / (like /Connected, which is usually just always a 1). See here.

[Ingo]

Thanks. The Mgmt stuff is already done and I publish Voltage, Current and Power at the moment. The reason for the non-standard AcOut2 is so that I don't mess with the already connected CG grid meter stuff. The periodical publishing works, I update every two seconds as my poller runs through the loop. Let me move the data to a standard path and see what happens.

com.victronenergy.grid

/Ac/L1/Current         <- A AC
/Ac/L1/Energy/Forward  <- kWh  - bought
/Ac/L1/Power           <- W, real power
/Ac/L1/Voltage         <- V AC

 

[___]

Usually you'll call your service com.victronenergy.grid.some_kind_of_connection_detail, where you put something at the end indicating how it is connected. This allows you to have more than one grid meter (each one must have a unique /DeviceInstance).

The other processes, specifically hub4control, will pick up on it automatically and start using the values for ESS or whatever you want to use it for.

It is also typical to make the code such that it can also pretend to be a pvinverter service (rather than grid) or genset, so that you can also use the modbus meter to measure other things. But that is probably for later.

[Ingo]

It's called com.victronenergy.grid.PM9C at the moment but the symptoms are the same as the original code. Let me leave this for a while as I am stuck now and need to check a few other examples on what they do different to what I am doing.

Thanks for the guidance so far.

[Ingo]

@plonkster, can you perhaps verify that the Wind Charger example actually works. I took the original Wind Charger code and simulated the modbus RTU input data and it's running perfectly fine except for the fact that I can't do 'dbus -y com.victronenergy.windcharger.bornay_ttyUSB0' to display any of the available variables either.

Running other code like 'vedbusservice_example.py' does display all the variables and I can use dbus-send to read and write to these.

[___]

It's possible that the author of that code also skipped the introspection part. You don't need introspection to work, it's just a nice to have. 

[Ingo]

Ok, thanks. I'll toy around a bit more but want to move on to the next step soon. If I now have all the values from my PM9C meter (V/A/P). Is there a way to get the Venus homepage to display this in a separate 'block' similar to the 'AC Loads'?

[___]

8 hours ago, Ingo said:

Is there a way to get the Venus homepage to display this in a separate 'block' similar to the 'AC Loads'?

No, unless you're up for making your own overview page. Look in /opt/victronenergy/gui/qml, there are a few extra ones already (eg a boat/motorhome one).

[Samsed]

I got a question which Raspberry Pi will work, I see there is the following 1 available:

https://www.pishop.co.za/store/zero-kits/raspberry-pi-zero-essentials-kitwireless-with-header

[___]

Venus doesn't run on the pi zero. In theory it could, but it's a different cpu, so has to be specially compiled. 

[phil.g00]

@plonkster

I see you did most of the development on the Pi 2.

I saw on a Victron website that various pi's are supported with some caveats about bluetooth and wireless issues.

Is this still the case, or have the issues with the 3 and the 3+ been resolved since?

[___]

12 hours ago, phil.g00 said:

his still the case, or have the issues with the 3 and the 3+ been resolved since?

Some of it has been resolved but I really haven't had much time to spend on it recently. My colleague made some fixes to the  bootloader and to add dtbs for the 3b+. So it works pretty much for anything above the pi 2, which is not surprising: pretty much the same processor.

Onboard  Bluetooth is not supported. Probably never will be. It has two uarts. One fully featured, the other not so much. You can choose which one to connect to the bt chip. We use the good one for a serial debug console. If you want  Bluetooth you need to use a usb dongle. Not that it matters. No Bluetooth comms to smartsolar de ices is implemented either