Third party integration

Modifications
1

Hi,

is there a way to integrate a third party ev-charger (in my case a fronius wattpilot) to the victron system?
I am currently using the dynamic ees, but in combinatin with a thrid party ev-charger it is not working very good.

BR
Michael

2

Officially, the answer is no.

If you want to do some tinkering, there are 2 ways:

  1. Directly Venus→EVCS GitHub - vikt0rm/dbus-goecharger: Integrate go-eCharger into Victron Energies Venus OS as a acload (Wattpilot is just a rebranded go-e Charger)
  2. Indirectly via EVCC: GitHub - SamuelBrucksch/dbus-evcc: Integrate EVCC connected charger into Victron Ecosystem

I run EVCC everywhere, if you don’t know this brilliant piece of software, take a look at it.

BR,
Olli

3

But this does not support control of charging, only reading, if I understand correctly? So in my opinion, that does not make it very useful for victron.

I would like to have third party charger control in DESS, but victron does not seem interested in adding support for it.

4

Yes, you are absolutely right. None of the community scripts will enable PV charging control from the Victron side.
The simple reason for this is that there is no control mechanism for PV surplus within Venus OS. The Victron own EV charger product does all the calculations on the EV charger itself and it just pulls all the values via modbus from the Venus OS.

This is one of the reasons I recommend EVCC. It behaves just like the Victron EV Charger (pulling values from VenusOS) and then controls your third-party EV Charger. Sorry, but as long as Victron does not implement any of that logic themselves you will be stuck with external solutions.
In fact there used to an effort to run EVCC on the Cerbo itself, but it seems this project has been discontiued.

5

Yes, this can also be sub-optimal depending on how you define surplus.

If the battery is prioritized over the EV charger, then that can lead to extra charging and discharging. From solar to Victron and then from Victron to EVCS. While if the EV is available, you could have charged it directly.

In a recent video is saw some footage of the closed beta: EVCS and (D)ESS - summary of problems/improvement suggestions - #14 by langestefan

It seems that EV charging is coming to DESS this year.

That still leaves one more problem, namely third party charger support. The most promising way forward here to me seems support for OCPP in victron. Which Victron should add themselves, but they aren’t interested it seems.

Personally I am not a fan of EVCC because of their licensing, i do not want a subscription. On top of that it seems overkill to run with victron, when all we really need is OCPP support. (but yes, EVCC is awesome software nonetheless)

6

dbus-goecharger fork: PV-surplus Auto/Manual/Scheduled charging for the go-eCharger (no OCPP, no EVCC subscription)

Following up on this thread’s discussion about third-party EV chargers having no native PV-surplus mechanism in Venus OS (only the official Victron EVCS gets computed surplus data via Modbus) - I wanted to share a fork I’ve been working on that solves this specifically for the go-eCharger, in case it’s useful to others here.

Repo: GitHub - Gesiima/dbus-goecharger: Integrate go-eCharger into Victron Energies Venus OS as an EV charger, with optional PV-surplus Auto/Manual/Scheduled charge control · GitHub (fork of the original GitHub - vikt0rm/dbus-goecharger: Integrate go-eCharger into Victron Energies Venus OS as a acload · GitHub by vikt0rm, which handles the basic Venus OS/dbus integration - reading status, publishing to the GUI/VRM)

The problem this addresses

The original script integrates the go-eCharger into Venus OS as an evcharger device (shows up in the GUI, VRM, session data, etc.), but the “Auto” mode selector has no effect for third-party chargers - Venus OS doesn’t compute or pass through any surplus value for anything other than the official EVCS hardware. As pointed out earlier in this thread, that leaves third-party charger owners either running something like EVCC (subscription-based) or nothing at all.

What this fork adds

  • Reads grid/PV/battery power directly from Venus OS (com.victronenergy.system) and forwards it to the go-e’s own Eco mode API (pGrid/pPv/pAkku). The go-e’s own firmware does the actual current calculation and phase switching - this script doesn’t compute a charging current itself, it just feeds the go-e the same kind of surplus data its own app would.
  • Real Auto/Manual/Scheduled mode switching from the Venus OS “Charge mode” page (Scheduled maps to the go-e’s own “Daily Trip” mode).
  • Optional battery priority (EV only charges once the home battery reaches a configurable SOC) and battery-as-buffer (above a second, higher SOC, a configurable amount of battery power is allowed to help the EV too) - both with hysteresis to avoid flapping.
  • Grid target support (pgt), so you can keep a small reserve/export margin like the go-e app itself offers.
  • The Venus OS “Autostart” button (otherwise non-functional for third-party chargers) is repurposed as a manual 1-phase/3-phase override, since the go-e’s own anti-flapping lockout on phase switching (~10 min) can otherwise leave it stuck on 3-phase when surplus drops - configurable via AutoStartMode in case someone wants to map it differently.
  • A handful of fixes to the original (lifetime energy counter was swapped with session energy on newer hardware; session energy/time weren’t published at all).

Honest caveats

  • This is entirely based on empirical testing against one specific device (go-e V4, firmware 60.5) - go-e’s public API docs don’t cover several of the behaviours this relies on (e.g. amp being a ceiling rather than the live current, or the internal rolling averages that seem to actually drive the Eco algorithm’s decisions rather than the instantaneous values). Some of this may differ on other firmware/hardware versions.
  • It’s not OCPP, and it doesn’t try to be a general-purpose solution for other chargers - it’s specifically written against the go-e HTTP API v2.
  • No affiliation with Victron or go-e; this is a community script, use at your own risk, and I’d genuinely appreciate hearing from anyone who tries it on a different go-e model/firmware.

The README covers the reasoning and testing behind most of the above in a lot more detail (there’s a fairly long list of empirically-found quirks) for anyone who wants to dig in before deciding whether to try it.

Happy to answer questions or take feedback if anyone here gives it a shot.