PLEASE NOTE: If you had an account with the previous forum, it has been ported to the new Genetry website!
You will need to reset the password to access the new forum. Click Log In → Forgot Password → enter your username or forum email address → click Email Reset Link.
NotMario i am really interested in having a GS talk to cerbo. I have ran several victron systems and like cerbo and vrm. I really like victrons bms and mppt with the cerbo / vrm monitoring the ability a GS inverter work with cerbo would be great.
What do protocol should I get when ordering GS inverter, what else do i need?
NotMario i am really interested in having a GS talk to cerbo. I have ran several victron systems and like cerbo and vrm. I really like victrons bms and mppt with the cerbo / vrm monitoring the ability a GS inverter work with cerbo would be great.
@notmario built a software bridge via WiFi comms to the GS inverter; I don't have any Victron equipment, so I don't know what physical protocol a Victron system could utilize. Have to wait for an answer from @notmario 😉.
Nothing special is needed with a Cerbo. It will communicate to the GS over ethernet/wifi.
This system can be quicky installed using kwindrem's "SetupHelper" mod: https://github.com/kwindrem/SetupHelper
Need only add the "venus-gs" repo for user "iNotMario". Then you have to edit the "service/run" file to use the IP of your GS unit. (Or you can fork the "venus-gs" repo)
Be aware that your router should always give your GS the same IP address. (OR you can elect to use DNS when editing the service file described above)
At this point, i generally consider the module to be production functional - i've been running it continuously for many months now.
Here's the system running with GUIMods.
Also, the Node-Red system i've mentioned in another thread - keeps the battery ready for solar power.
Hey there, I just stumbled across this and had a raspberry Pi laying around so loaded up VenusOS and the setup helper successfully, even managed to install venus-gs onto the system via setup helper. Looks like everything is showing up but not connected. I was wondering if you could help me out with the "Then you have to edit the "service/run" file to use the IP of your GS unit." i'm really not all that savy with coding/terminal commands, but can follow instructions.
Looks like everything is showing up but not connected. I was wondering if you could help me out with the "Then you have to edit the "service/run" file to use the IP of your GS unit." i'm really not all that savy with coding/terminal commands, but can follow instructions.
What you need to do is edit the file: /data/venus-gs/service/run
You'll see something like ` http://1.5.5.2 3' in the command. You'll need to change it to the IP of your GS, and that IP address will need to be statically defined in your router.
Once you've made that change, you'll need to "uninstall" using SetupHelper, then "Install" again to commit the change to the active filesystem. Once you reboot your GX, it should begin gathering the data from your GS.
Hey @notmario, one question...
Nothing special is needed with a Cerbo. It will communicate to the GS over ethernet/wifi.
I took a look at your repo / gsdevice.py. In there it looks like you're taking the GS API payloads and then mapping them for ve-dbus. Is there an API or specification devices can implement to offer these telemetry points in a "victron native" way and maybe not even need a translaton layer?
Hey @notmario, one question...
I took a look at your repo / gsdevice.py. In there it looks like you're taking the GS API payloads and then mapping them for ve-dbus. Is there an API or specification devices can implement to offer these telemetry points in a "victron native" way and maybe not even need a translaton layer?
What you're calling a "translation layer" is what they [at least internally] refer to as a "service".
It doesn't look as though Victron had the foresight to produce a generalized network-based API. Instead their architecture seems to require the creation of services that translate a protocol to ve-dbus.
The obvious solution to this would be to exploit dbus' network functionality - and just run a dbus node on each device - but victron neglects to make dbus available on the network.
Outside of the obviously "most correct solution" of just using dbus-tcp, the closest generalized system i've seen is a community maintained service for MQTT. I believe you can have a device send MQTT messages to the victron and it will, based on mqtt paths, convert it into ve-dbus paths.
Frankly, Victron's ve-dbus system is impressively klunky as it's not extensible at all. Basically, each device has a type, and each type has a list of usable attributes. There's no nesting of devices (think of how HTML has child tags). With nesting of devices, you could easily, just by virtue of data, describe an inverter (for example like a GS) which has 4 temperature probes, and 2 fans (probes and fans, themselves, being devices), and supply applicable data that can then easily be abstractly rendered onto the HMI, and properly associated with it's parent device.
If not for the fact that the ve-dbus API is so limited, i'd create a generalized system myself - but it's difficult (er... pointless) to do when all you can do is map type-specific attributes to individual devices. (AKA, the generalized API would just map a bunch of attributes from one API to the ve-dbus API - but you're just moving the burden to the end device at that point anyway)
Unfortunately, victron is somewhat of a "only guy in town" type of situation, and i don't see them making much in the way of real architectural improvements. Only the occasionally added support for specific devices. The vast amount of real tangible utility comes from community maintained solutions, and like i said, only one of those seemed to be at least partially generalized - mapping mqtt paths to ve-dbus paths.
The TLDR;
I never found any generalized way to add devices to the victron. If i had, my solution would have been different:
1) Pass the buck to Sid and have him implement the generalized API. Or, failing that...
2) Make a proxy that runs on a Linux machine that translates the generalized API to GS API Calls, thus at minimum avoiding the need to modify the victron itself.
But alas... turns out you have to add a service that makes the appropriate dbus calls...