OCPP support also adds support for other chargers that support OCPP, like alfen and zaptec. You get both. Unless you block other chargers.
as long as we have our own charging station, we will focus on that one. Our business is not charging stations integrator.
If you have OCPP support, you do not have to focus on any charging station. That is the whole point of OCPP.
We are not going to do the server side of OCPP. It will be the client side, that normaly is supported by the charging stations, runing on the VRM platform.
We have to stop this discussion, sorry if we are not doing what youâre expecting, but these are the plans now.
1 Like
Ok thanks for clearing that up, disappointing to read.
Unless youâre starting your own charge processing company and invoicing people when they charge at a station connected to your OCPP server, you donât need an OCPP server.
And if you are, you should write your own OCPP server, pick one thatâs available on the internet or just buy one.
Bugging a company -thatâs already providing you with a truckload of free services and has no interest of providing an OCPP server- for not giving you one for free is not how any of this works.
If you want to integrate a third party charging station in your Victron ecosystem, there are other ways besides running an OCPP server.
OCPP is just like any other EVCS protocol, that also happens to be very convenient for charge processing. Plenty of consumers use OCPP. For example, I use it to connect my Alfen charger to Home Assistant. Because it supports OCPP, this is very convenient.
Free services? I paid good money for my Victron system. It is not an unreasonable request to ask for OCPP support either. It would enable support for dozens of chargers, from a single driver.
Very nice!
Some practical questions:
- most OCPP service providers require an MID certified energy counter for proper billing.
If iâm not mistaken, the Victron EVCS is not MID certified. Option to work with an external MID certified meter? - third party users charging at an OCPP enabled EVCS typically identify with a Smartcard and/or Vehicle Identification (ISO15118) - the latter requiring support from the EVCS itself.
Are there plans to support Smartcard identification or, even better, ISO15118?
And of course the mandatory question: will this be a paying service? 
In your case, HomeAssistant is your OCPP Server.
You can already make HA talk to the Victron ecosystem in multiple ways.
When Victron implements the OCPP Client on their side, it will integrate nicely with your HA OCPP server.
But if Iâm not mistaken, you can integrate a Victron EVCS in HA even without OCPP.
Since you already have an OCPP server, why would you need another one on Victron side?
Iâm still new in the EVCS stuff but afaik an EVCS can only connect to one OCPP server.
Yes, integrating a third party EVCS in the Victron ecosystem would be nice for the user but looking at it from the Victron side, I see little incentive to make that happen.
Pretty much the only real use case I see (outside of the nerd factor):
- an EVCS connected over OCPP to a charge processor, so other people can use my EVCS and I get paid for that
- that EVCS be integrated in the Victron ecosystem so that max charge power is controlled by the Victron GX
Possible ways to do that (making this up as I go, at 4AM, so donât judge me harshly):
- Some kind of OCPP Proxy on the GX device that relays authentication and consumption information upstream while instructing the EVCS on max charge power
- OCPP authentication and billing between EVCS (via GX and VRM) and the upstream OCPP provider, while the GX instructs the EVCS on max charge power using another protocol (typically Modbus)
For case 1. I donât see the business benefit why Victron should put real effort in it.
Case 2. has a direct benefit for Victron as it would enable their EVCS to be used by external billing partners (caveat: see my previous post).
For non-Victron EVCSâs connected to an external OCPP server (for billing): Iâm looking for ways to control them (over Modbus) in regards to max charge power.
With the Node Red OCPP solution, a lot can be done by the user.
If the Victron solution doesnât fit your needs, you can always build your own interface - thatâs how an open system works.
So you paid âgood moneyâ for your Victron system and now you feel entitled to services outside of what youâre already getting?
Try talking to Alfen and convince them they should work really hard to allow you to integrate their EVCS into the Victron ecosystem instead.
Since your Alfen EVCS very likely was a lot more expensive than a Victron EVCS, you obviously have a lot more argumentational weight to throw in and theyâll start cracking at it right away.
Yes, Iâm being sarcastic now.
Please give my reasoning some thought before replying.
Good night.
Hi Bart. The EVCS version we are selling now does not have a proper meter inside. Unfortunately, it cannot be MID certified.
On V2, which we are working on releasing, we will probably be able to certify it. But that process has not started yet.
ISO15118 involves expensive hardware inside the unit. We are still targeting residential users; most of them are not using this kind of feature. Paying for that and not using it does not sound like a good commercial idea.
But I have an Alfen charger. As noted by victron above, OCPP server will not be supported. So this will not help me.
Well my main goal is to get my EV charger into DESS for smart charging. That will only work if victron recognizes it as an EVCS, for example using something like GitHub - vikt0rm/dbus-goecharger: Integrate go-eCharger into Victron Energies Venus OS as a acload ¡ GitHub
So just monitoring the load is not enough, you need proper charger control.
I agree that supporting a billing system with OCPP is not something victron has to support. There are no upstream or external OCPP servers for the usecase I am focussing on here. My usecase is limited to OCPP as a communication layer between the EV charger and GX. And this will be true for almost all consumers that have a victron system and a third party EV charger.
Yes, but not this. There is no virtual EV charger node and in another thread I read that victron has no interest in adding that either. Yes itâs great that itâs open enough I can build my own solution around it, Iâm not dismissing that. But in my opinion, that should only be required for exotic things. And not something as basic as EV charger support.
Absolutely, I feel entitled to get basic EV charger support in my energy management system. In fact, I want go even further and say that I expect any energy management system to support open protocols for any DER where they are available. That includes EV chargers, but also solar PV, heat pumps. The big 4, basically. Iâm afraid this will only happen if the EU demands better interoperability through laws.
Normally OCPP is only used for authentication, metering and -ultimately- billing, not so much for load control.
Because to do load control, you have to integrate data from not just the EVCS itself but also from a grid meter - a device thatâs typically not talking to the OCPP server upstream. But in general it is talking Modbus.
My best advice for you is to dig in the Alfen documentation and search for load control using Modbus (or another API) and do the integration (as a virtual load) that way, keeping the OCPP part separated.
Thatâs the path Iâm exploring.
Creating a Virtual EVCS in NodeRed might not be possible but if you create a virtual AC load that you can send throttling commands to, thatâs just as good.
Maybe, but OCPP can do many things. As an example, the Home Assistant integration is quite comprehensive: Table of Contents â home-assistant-ocpp documentation
All I need is for victron to recognize the charger as being an evcs (`com.victronenergy.evcharger`). Victron can handle everything else, ideally always through DESS but that is coming later this year.
Iâm going the OCPP route so others with different chargers can benefit as well. Going the modbus route means I have much less flexibility.
Hey Lucian, thanks for the reply.
For the current EVCS, an external MID meter and NFC reader might be an option but as I stated a year ago this would indeed require a lot of âglue logicâ to make it all work.
An MID certified EVCS with NFC integrated and OCPP (via whatever means) would be the best package for the consumer market.
I just checked and ISO15118, as part of OCPP 2.0, indeed requires the PLC hardware as used in CCS chargers, it doesnât run over the old fashioned PWM signal.
Thatâs a big bummer since now I agree that this extra hardware cost might not be in scope for Victron.
Yes, we have an NFC reader inside V2. For MID, I hope it can be done.
Yes, that PLC changes the cost a lot. What we are doing is making the V2 model prepared to add PLC communication. So, it will be prepared with some connectors. However, this is just long-term planning. We are not sure what will be in the end. It depends on so many things.
1 Like
Thatâs a fair point, not disagreeing on that.
But using OCPP for that actually complicates the solution, a lot.
Let me explain:
- you need to integrate not only the EVCS into the OCPP data flow but also the grid meter
- this shifts the problem from the EVCS to the grid meter
- since the OCPP processing is typically done âin the cloudâ it would make the grid throttling internet depending
The way most EVCS manufacturers, including Alfen, fix this is by using a separate local loop.
Either by connecting to the P1 port on the main grid meter, or by using a grid meter connected via Modbus.
Ultimately I guess it depends on what you want to achieve.
I can see the use case for running a local OCPP server, but it seems like an uncommon scenario.
Most people will use an OCPP provider in the cloud.
Integrating a local grid meter in the OCPP data flow would require an intermediate OCPP gateway between the EVCS and the OCPP provider in the cloud - and that is not part of the OCPP design.
Going the Modbus route will likely be the easiest solution.
But why? My current OCPP setup home assistant doesnât need that either.
My OCPP server will run locally on the GX.
Iâm still going through the spec, but the way I understand it is that the OCPP server can control the charging loop of the client through âOCPP smart charging messagesâ. Meaning all responsibility shifts to the server, rather than the client. Alfen also has an internal load balancing option, I think this is what you mean? Iâm not planning on using that.
Interoperability! I want victron to treat my charger as if it was a victron EVCS fresh out of the box.
As I stated earlier: OCPP is a protocol developed to enable communication between EV charging stations and Charge Point Operatorâs (CPO) backend systems.
Itâs cute that you can integrate your Alfen EVCS in HA, but thatâs not where the protocol is designed for.
Youâre running a specific and personal implementation.
If thereâs a vendor that will support this, kudos to them but I see no obligation for them to do that.
Again: it would be cute if Victron -or any vendor for that part- would seemlessly integrate other vendorâs systems into their own ecosystem, but I donât see the business case.
Most vendors have their own ecosystem and as long as you stay within that ecosystem everything (usually) integrates very well.
Start mixing stuff and pray it works.
You could just as well demand that Alfen integrates your Multiplus in their ecosystem - thatâs not going to happen either.
OCPP serves to integrate EVCSâs into CPO systems.
Victron is not running a CPO system so they have zero reasons to implement an OCPP server.
At least the Victron ecosystem is about as open as can be (very few vendors are this open) so if you want to integrate a third party system, youâre free to do so yourself - if that other vendor supports it.
But Victron has no obligation to do it for you.
It would be very nice if every system integrates with every other system out of the box, but except in Star Trek thatâs not how things work.
Says who?
No Iâm not. I am using a standard OCPP server connected to a vendor OCPP 1.6 client. Nothing personal about it.
Happy customers is a great businesscase. Victronâs policy effictively turns my perfectly fine charger into e-waste. Either I buy into the ecosystem, or else screw you. You really donât see the problem with that?
There is nothing stopping it from being this way, other than vendors refusing to implement open protocols.
Youâre still missing the point.
Yes, OCPP is an Open protocol. So is Modbus.
There is no obligation for any vendor to support either of them.
Most CPOâs use OCPP for convenience, but thatâs where the business case stops.
Youâre ranting at Victron for not implementing an OCPP server for your convenience, while they have no business case to do so but they offer you an equally open alternative - that youâre refusing.
Are you ranting at the Alfen forum just as hard because theyâre not implementing Victronâs EVCS protocol (hint: itâs Modbus) ?
Turning your charger into e-waste?
Thatâs just BS.
Thereâs the Node Red OCPP implementation and both Victron and Alfen support the open Modbus protocol so nothing and nobody is stopping you from integrating them.
This inter-vendor integration might not be as simple as youâd like it to be but thatâs your problem and not theirs.
If you want to keep flogging the dead horse thatâs your choice but I wonât be repeating myself any more.
The solution to your problem is Modbus.
Take it or leave it, but donât complain that there is none.