Hi openEMSies,
first of all thank you a lot for the great work, on which we are building our business.
We are working on a full deployment of the framework in an energy management context.
Presently, we have some installations, where some containerized edges are reading different sets of meters.
We are working on the development of some drivers to be used for managing some OCPP EVCS.
We modified one of the original drivers (ABL) and made it working with the column we are testing (a custom one, built on white labelled electronics).
The work is supposed to evolve according the following points:
- connect to the station via OCPP, getting the station id, receiving the start/stop requests from it, starting and stopping the vehicle recharge, and reading some important values (mainly the Active energy) in a given moment;
- write the above into an influx db;
- associate the above to an rfid/userId tag;
- activate an id management system in order to identify the rfid owner, understand if she has the right to charge, bill him, etc.;
At the moment we were able to solve just the first two points, then, we had some problems in implementing the user identification inside OpenEMS Core.
We were not able to identify a proper system in order to implement the missing feature without modifying the generic parts (OCPP Core Event Handler or OCPP Server).
Our impression is that the code is something still in an early stage of development, but, to tell the truth, we have very little prior experiences on OCPP related implementations, so… it could be that we did not find the way, but it was there.
Someone is developing some in this way?
I can provide more details if needed.
Please let us know.
Many thanks in advance.
Gioacchino
Hi Gioacchino,
welcome to the OpenEMS Community and thanks for getting in touch. I personally do not have too much knowledge of OCPP myself, but I know that Sebastian Asen (core OpenEMS developer at the FENECON team) once prepared an early state of a architecture for such a functionality within OpenEMS.
@sebastian.asen: Could you share what you have, so that we can discuss on it and evolve it?
The ABL implementation is not the most mature. We dropped professional support for it, because we were not able to get the power data in high resolution, as would be required for our applications. Whenever possible, we usually try to avoid OCPP and use other available protocols (like Modbus/TCP or KEBAs proprietary UDP protocol).
Regards,
Stefan
Hi @stefan.feilmeier,
many thanks for your quick reply and for involving @sebastian.asen on the tread.
We have used the ABL implementation as a track to develop a generic driver on the OCPP standard and today we are able to interact with the custom hardware we are testing.
The EVCS statuses are correct and we can manage EVCS main events and get the power data.
Actually we are checking the stability of the system between OCPP Server and EVCS.
The system we are building in YouPower may have to interact with different types of EVCS, in addition to the one we are going to produce in house, so we have opted for the use of the OCPP protocol, instead of Modbus/TCP (we use it for meters).
We await a kind reply from Sebastian Asen because if he further implemented this in OpenEMS it would be useful for us and we could participate in the development and share it as opensource.
I take this opportunity to add @chicco, lead member of our development team to the tread.
Regards,
Gioacchino
Hello Gioacchino,
thank you very much for sharing your experience.
As you mentioned, the OCPP part is in an early stage where the focus was to be able to read and write data from/to the charger (the reason is also that we don’t have the best knowledge in OCPP as we come from a different area like storage, PV, meters, etc.).
To avoid the billing process implemented in OpenEMS, we have separate partners involved in our projects for now and focus on load management.
I know @p.wimmer from consolinno has made some attempts to forward the authorization and energy parts to another backend as a proxy.
I welcome further improvements in this area.
Regards,
Sebastian
Hello Sebastian,
thank you for getting in touch.
Actually we are working on external authorization system where the OCPP Server will receive idTag status (Accepted, Blocked, etc.) after request for Authorization, Start and Stop transactions.
Meantime we are evaluating if is suitable using the OpenEMS Backend for this.
Any suggestions from @p.wimmer are welcome.
Regards,
Gioacchino
Sry for late response,
didn’t get the mention part 
.
Yes we choose a different approach for ocpp. Because we didn’t want to stear/regulate the chargers over ocpp. We use ocpp for what it is more or less ment to be, for the billing part of transactions. Sadly some chargers don’t allow limitaions over modbus, as ABL for example. here we build in a ‘workaround’, so that openems talks to the ocpp backend, gets data from the charger there and send limitations.
That is more or less because you cant have two ocpp-server set up in one chargestation.
the mobility house make’s a proxy on the “Hardware”, so he uses the ocpp connection and makes itself a ocpp connection to the backend. all the controlling fields get blocked by the proxy. (also a nice method to get rid of the problem).
and ocpp for java was not quite far developped so we decided to switch to python for ocpp, so that we dont need to implement all the new features by our own.
best regards
Pauli