RS device is Inverter RS, Multi RS Solar, Inverter RS Solar, etc. High frequency devices.
Below, from the first link you find dbus services. From the second link you get the Modbus register list and there, on the first column of the Field list sheet you match the dbus service.
1 Like
Good morning Alex @alexpescaru !
Iâ trying to understand the Venus code a little betterâŚ
In those two lines (commenting out rescues me) 1225/1226 of dvcc.py the charge_voltage finally sent to the solar chargers is self._multi.hub_voltage which gets drived by (dbusmonitor).get_value(self.service, '/Hub/ChargeVoltage') - so far so clear.
But where the hell â/Hub/ChargeVoltageâ on the dbus ever gets set?
I searched the whole code for â/Hub/ChargeVoltageâ, but all I find is some constant values in some xy_test.py or in vebus.csv (I think one of these constant values I saw with ESS mode unequal 3 - I wondered where this value came from because it was not equal to any setting in my system).
There is one occurance that might point to this:
class HubTypeSelect(SystemCalcDelegate):
def get_input(self):
return [
('com.victronenergy.vebus', ['/Hub/ChargeVoltage', '/Hub4/AssistantId'])]
in hubtype.py, but I canât find this class ever get instantiated?!?
thank you!
ok, seems to be some delegate
self._modules = [
delegates.Multi(),
delegates.HubTypeSelect(),
delegates.VebusSocWriter(),
...
and then it seems to be initialized by some default
for m in self._modules:
for service, paths in m.get_input():
s = dbus_tree.setdefault(service, {})
for path in paths:
s[path] = dummy
and then there also seem to be some set mechanism
for m in self._modules:
m.set_sources(self._dbusmonitor, self._settings, self._dbusservice)
but I am totally lost :-/
can you give advice?!
(deleted)
Since the HubTypeSelect is querying that things from a service of type vebus, I would assume that this value is set by an external device on the vebus, and a generic Property Setter injects it on dbus, so you wonât find the fixed string /Hub/ChargeVoltage to be set in a python script.
something like (abstract):
foreach KeyValuePair kvp in message from vebusdevice:
dbusService[vebusdevice.servicename][kvp.key] = kvp.value
This also matches your observation that this value is set to 0, as soon as you connect the multi,
so maybe the multi sends the 0 value through the VE-Bus?
Beside that: The dbusservice is a generic linux-thing, accessible in various ways. Not only through python-scripts. there could also be ssh scripts, or deep burried (compiled) C-Code updating values there.
hi dognose! 
thank you! so you have any idea how to find out who/what sets it to 0 (or which way it never gets set)?
you could use dbus-monitor --system and monitor every change on the bus.
But thatâll be a lot to read. Probably log that to a file for 10 minutes, and then See if you can find out who or what sets it, example:
method call time=1726741666.031927 sender=:1.35 -> destination=com.victronenergy.vebus.ttyS4 serial=74236 path=/BatteryOperationalLimits/MaxChargeCurrent; interface=com.victronenergy.BusItem; member=SetValue
variant int32 101
method call time=1726741666.032884 sender=:1.35 -> destination=com.victronenergy.vebus.ttyS4 serial=74237 path=/BatteryOperationalLimits/MaxDischargeCurrent; interface=com.victronenergy.BusItem; member=SetValue
variant double 296
method call time=1726741666.033078 sender=:1.35 -> destination=com.victronenergy.vebus.ttyS4 serial=74238 path=/BatteryOperationalLimits/BatteryLowVoltage; interface=com.victronenergy.BusItem; member=SetValue
variant double 45
method return time=1726741666.033978 sender=:1.68 -> destination=:1.35 serial=14239 reply_serial=74231
int32 0
method return time=1726741666.034696 sender=:1.73 -> destination=:1.35 serial=14247 reply_serial=74232
signal time=1726741666.110682 sender=:1.57 -> destination=(null destination) serial=47968 path=/; interface=com.victronenergy.BusItem; member=ItemsChanged
array [
dict entry(
string "/Ac/Out/P"
array [
dict entry(
string "Value"
variant int32 -895
)
dict entry(
string "Text"
variant string "-895W"
)
]
)
dict entry(
string "/Ac/Out/S"
array [
dict entry(
string "Value"
variant int32 -1546
)
dict entry(
string "Text"
variant string "-1546VA"
)
]
)
Maybe already usefull like that to find the âsenderâ:
root@einstein:~# dbus-monitor --system | grep "ChargeVoltage"
method call time=1726742095.403798 sender=:1.35 -> destination=com.victronenergy.vecan.can0 serial=77195 path=/Link/ChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742095.403854 sender=:1.35 -> destination=com.victronenergy.vebus.ttyS4 serial=77196 path=/BatteryOperationalLimits/MaxChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742098.404367 sender=:1.35 -> destination=com.victronenergy.vecan.can0 serial=77217 path=/Link/ChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742098.406494 sender=:1.35 -> destination=com.victronenergy.vebus.ttyS4 serial=77218 path=/BatteryOperationalLimits/MaxChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742101.414539 sender=:1.35 -> destination=com.victronenergy.vecan.can0 serial=77235 path=/Link/ChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742101.415421 sender=:1.35 -> destination=com.victronenergy.vebus.ttyS4 serial=77236 path=/BatteryOperationalLimits/MaxChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742104.410438 sender=:1.35 -> destination=com.victronenergy.vecan.can0 serial=77258 path=/Link/ChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742104.413889 sender=:1.35 -> destination=com.victronenergy.vebus.ttyS4 serial=77259 path=/BatteryOperationalLimits/MaxChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742107.415452 sender=:1.35 -> destination=com.victronenergy.vecan.can0 serial=77276 path=/Link/ChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742107.416500 sender=:1.35 -> destination=com.victronenergy.vebus.ttyS4 serial=77277 path=/BatteryOperationalLimits/MaxChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
(didnât see changes for Hub/ChargeVoltage in the past 60 seconds, not sure if that value is frequently updated)
Iâm afraid it only gets initialized (with 0.0), never get set afterwards?!? so logging after boot might not helpâŚ
I found something in systemstate.py that might point to this âguessâ:
# VEBUS is available. First check that we are not externally
# controlled.
assistant_id = self._dbusmonitor.get_value(vebus, '/Hub4/AssistantId')
if assistant_id is not None and self._dbusmonitor.get_value(
'com.victronenergy.settings', '/Settings/CGwacs/Hub4Mode') == 3:
return (SystemState.UNKNOWN, flags)
can I do dbus-monitor --system >> /home/dbuslog.txt ?
who the hell is 1.35?
with my setup it looks a little different (accordingly?!):
method call time=1726742843.481152 sender=:1.30 -> destination=com.victronenergy.vebus.ttyUSB0 serial=1989738 path=/BatteryOperationalLimits/MaxChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742846.478590 sender=:1.30 -> destination=com.victronenergy.solarcharger.ttyUSB4 serial=1989759 path=/Link/ChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742846.479365 sender=:1.30 -> destination=com.victronenergy.solarcharger.ttyUSB5 serial=1989760 path=/Link/ChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742846.479911 sender=:1.30 -> destination=com.victronenergy.solarcharger.ttyUSB6 serial=1989761 path=/Link/ChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742846.480560 sender=:1.30 -> destination=com.victronenergy.solarcharger.ttyUSB7 serial=1989762 path=/Link/ChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742846.481128 sender=:1.30 -> destination=com.victronenergy.solarcharger.ttyUSB8 serial=1989763 path=/Link/ChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
method call time=1726742846.486712 sender=:1.30 -> destination=com.victronenergy.vebus.ttyUSB0 serial=1989769 path=/BatteryOperationalLimits/MaxChargeVoltage; interface=com.victronenergy.BusItem; member=SetValue
/Hub/ChargeVoltage never gets set âŚ
for any unknown reason in the meanwhile the /vebus/Hub/ChargeVoltage decided to get 57.6 Volt - donât ask me when or why this happened!?!?
nowhere in no setting I set 57.6 Volts and even in the complete source code â57.6â canât get foundâŚ
but at least it is not 0 anymore⌠
All Solarchargers are reporting as ttyUSBX - so guess, you are using a RPI as GX-Device with usb to ve direct adapters?
There are known issues with the usb driver of the rpi randomly assigning usb ports at startup (or say, in order of response) which may cause each device to end up on another port than earlier.
I donât know if this might be related, but as far as I know, one charger is considered the master. And if his id may change, but old stuff is cached somewhere, the system may reject ChargeVoltage Updates from what it believes to be a slave. (Just a guess)
Here, Link/NetworkStatus denotes if it is a master or slave.
canât tell which is what, since I only have 2 - but with 6 chargers you should be able to identify.
Eventually sometimes your system also just ends up with all devices considering them self slaves, and no one steps up to send a ChargeVoltage update? (Due to the usb issues)
Good Morning dognose @dognose ! 
I think this NetworkStatus applies only if the Chargers working in SmartNetwork (Bluetooth). All of them are 0 currently.
Also the chargers were not the problem but the /vebus/Hub/CharegVoltage.
BUT I realized two vebus entries in the config, one pointing ttyUSB0 and one ttyUSB8. USB8 was wrong, that applied to one of the chargers. I deleted all entries related to vebus<->USB8 (one /data/conf/settings.xml, perhaps another, donât remember).
Immediately after reboot the 0.0V ChargeVoltage issue remained, but obviously some time later it disappeared. Not sure if related to the wrong/double USB link.
I wonder if now I might uncomment the two lines 1225/1226 again (never touch a running system?). What makes me thinking is the high value. Shouldnât it reflect the 55.2V coming from the BMS?
HAA! unbelievable!
writing about it and having another look, the issue returnedâŚ
I will keep lines 1225/1226 commented outâŚ
Mine are VE.can, and one is the master.
That is even (namingly) visible in the gx under solarcharger â details â networked operation
Not sure if this applies for VE.Direct, tho - but hard to imagine that there is a different thing implemented for that.
So, maybe the situation, where all your devices are âNetworkStatus = 0â (Slave?) Causes no one to send a charge voltage to the /hub value in order to have it distributed to the other slaves? 
hi @dognose ,
the networked op pages look like this (all of them)
>> all your devices are âNetworkStatus = 0â (Slave?) Causes no one to send a charge voltage to the /hub value in order to have it distributed to the other slaves?
it works the other way arround: the /Hub/ChargeVoltage gets populated to the (all) chargers. You can verify by frequently overwriting /Hub/ChargeVoltage and see the value getting applied to the chargers, as also described in the ESS Manual:
The charge curve in VEConfigure is (should beâŚ) the master, not a solar charger.
Yes, that is clear - but for this value to be populated, someone is responsible. And since we can not find this value to be set through any python script, it is most likely under external control, set through generic forwarders of vecan, vebus, vedirect,âŚ
Therefore most likely the master-charger publishing voltage updates there in order to have them distributed to all slaves.
But the interesting part is that the control state for you (due to ESS Mode 3?) says âExternal Control & BMSâ.
So, this could mean that your âexternal control loopâ is responsible to maintain that value, just like it needs to maintain the grid-setpoint, and the BMS override only kicks in, if you choose values higher than what the BMS is currently allowing.
Hence, each controller is running as slave, because your control-loop has to take over the master-role
I think to clearify all this, another Topic would make sence. Basically the question âWhich values need to be manually taken care of in ESS Mode 3 as part of the external control requirementâ.
I tried. I wrote /Hub/ChargeVoltage, but after about 1 sec it gets overwritten with 0 by âunknownââŚ
and see 19th - somehow some value nowhere to be found appeared (and disappearedâŚ)
I still think that this is simply a bug⌠The manual is clearâŚ