PVOutput - VenusOS 2.80 and later

Hi,

I used the script from @plonkster, but it stopped working when I updated to VenusOS 2.80. After a lot of head scratching, Google and assistance from the Victron community, I got it working again.

The updated script is available here:

1 Like

I curse the day I wrote that monstrosity… :slight_smile:

But I am also glad to see that others are maintaining it. Which is of course the point of Open Source. When a product is EOL’ed, because it is no use to me any longer… it does not leave everyone else up the stream without a means of propulsion…

2 Likes

Hi @isimobile

Getting this error on a CerboGX… - any advice?

root@einstein:~# /data/dbus-pvoutput.py:6: DeprecationWarning: Using or importing the ABCs from ‘collections’ instead of from ‘collections.abc’ is deprecated since Python 3.3, and in 3.10 it will stop working from collections import Mapping
Traceback (most recent call last):
File “/data/dbus-pvoutput.py”, line 10, in
import gobject
ModuleNotFoundError: No module named ‘gobject’

from gi.repository import GLib

Then find all places where gobject is used and replace with GLib.

Hi @isimobile

Any chance (a long shot) that this script can be converted to python 3.

I used to use it to upload to Emoncms from my Cerbo and it would be great to do so again.

Thanks
Mark

dbus-emoncms.zip (3.2 KB)

@mmaritz

This link will get you sorted: GitHub - isimobile/dbus-pvoutput: Victron Single Phase pvoutput

Credit to @isimobile

Thanks @Thaelian

I have the PVO Sorted but the Emoncms still needs the conversion :wink:

Apologies, missed the Emoncms portion.

I must have had my ‘man goggles’ on (as my wife calls it)

Most of the time, you only have to wrap the print statements with brackets like line 202:
print “Emondata sent:” + payload
to
print(“Emondata sent:” + payload)

Sometimes packages might also change, but first try the above (with all print statements).

There is a tool in python called 2-to-3 that is pretty good at finding the things that needs changing. Eg on the original version it suggests this:

--- dbus-pvoutput.py    (original)
+++ dbus-pvoutput.py    (refactored)
@@ -110,8 +110,8 @@

     # Periodic work
     def _upload():
-        energy_generated = sum(filter(None, generators.itervalues()))
-        energy_consumed = sum(filter(None, consumers.itervalues()))
+        energy_generated = sum([_f for _f in iter(generators.values()) if _f])
+        energy_consumed = sum([_f for _f in iter(consumers.values()) if _f])

         logger.info("EG: %.2f, EC: %.2f, PG: %.2f, PC: %.2f", energy_generated,
             energy_consumed, stats.pg, stats.pc)

And I can already tell you it’s going overkill here. In python 2.7, you had to call itervalues on a dict to get an iterable (rather than a list), but in python 3, values now works like itervalues did in the past and replaces it. Then it wraps it in iter() which is unnecessary (it is already iterable). And then it turns the filter statement (which in python 2.7 returned a list) into a list comprehension, which is also unnecessary, since sum() can handle iterables directly already.

So it helps… but you kinda still have to know a little python to do it properly.

The other option is you run it and see where it breaks, and then fix that part.

Just on the same topic: I am running the P3 version as suggested previously and saw the following error every now and then happening, maybe two or three times a day.

ERROR:dbus.connection:Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/dbus/connection.py", line 232, in maybe_handle_message
    self._handler(*args, **kwargs)
  File "./dbus-pvoutput-p3.py", line 104, in _on_dbus_items_changed
    set_state(state, target, value)
  File "./dbus-pvoutput-p3.py", line 98, in set_state
    value = unwrap_dbus_value(v["Value"])
KeyError: 'Value'
root@beaglebone:/opt/victronenergy/dbus-pvoutput#

Any ideas why it would give this error at random times?

The dictionary v does not have a “Value” key.

The easiest is to catch the exception and ignore it.

try:
    value = unwrap_dbus_value(v["Value"])
except KeyError:
    pass # Just ignore it
else:
    # do something with value

Also, I did not look at the code at all, but also keep this in mind:

You need to handle both PropertiesChanged, and ItemsChanged signals.

Ah, Ok. I confess to not have checked the P2 version for errors only the P3 version so this might have been there all along. I will add the exception handle to catch the null values and ignore them. The other suggestion is above my area of expertise.

Ok, I admit I need some help here. For the life of me I can’t see where the following error comes in or why it would ever do this.
Note: I’ve added an additional logger line to inspect the ‘generators’ which is where I see the strange behaviour.

INFO:main:Found solarchargers at com.victronenergy.solarcharger.ttyO2, com.victronenergy.solarcharger.ttyO4
INFO:main:Found grid meters at com.victronenergy.grid.cgwacs_ttyUSB0_mb1
INFO:main:Found vebus at com.victronenergy.vebus.ttyO5
INFO:main:generators: {‘com.victronenergy.solarcharger.ttyO2’: 994.5499877929688, ‘com.victronenergy.solarcharger.ttyO4’: 5763.85986328125}
INFO:main:EG: 6758.41, EC: 27572.67, PG: 4914.66, PC: 1625.70, VO: 237.01
INFO:main:generators: {‘com.victronenergy.solarcharger.ttyO2’: 5764.240234375, ‘com.victronenergy.solarcharger.ttyO4’: 5764.240234375}
INFO:main:EG: 11528.48, EC: 27573.03, PG: 4861.03, PC: 1615.30, VO: 236.17

To explain the above: I have two chargers, on initial startup it reads their ‘Yield User’ values correctly. On the next poll the first charger value is suddenly a duplicate of the second and it carries on like that until I kill the process.

Any ideas from the big snake experts?

Edit: Ok, I saw something that let’s me think it’s a timing thing when values change. Below it swapped to the two small chargers. I can only speculate that the ‘big’ charger changes a lot sooner than the smaller one and then somehow the indexing goes all wonky.

INFO:main:generators: {‘com.victronenergy.solarcharger.ttyO2’: 5764.990234375, ‘com.victronenergy.solarcharger.ttyO4’: 5764.990234375}
INFO:main:EG: 11529.98, EC: 27573.74, PG: 4783.81, PC: 3650.00, VO: 235.34
INFO:main:generators: {‘com.victronenergy.solarcharger.ttyO2’: 994.760009765625, ‘com.victronenergy.solarcharger.ttyO4’: 994.760009765625}
INFO:main:EG: 1989.52, EC: 27574.10, PG: 4236.68, PC: 3640.50, VO: 233.67