Chargy is a transparency software library for the validation of secure and transparent e-mobility charging processes, as defined by the German Calibration Law ("Eichrecht") in combination with the Alternative Fuels Infrastructure Regulation (AFIR) and the new Measuring instruments (MID-11) of the European Commission and the European Digital Quality Infrastructure. The software allows you to verify the cryptographic signatures of energy measurements within charge detail records and comes with a couple of useful extentions to simplify the entire process for endusers and operators.
You can test the Chargy WebApp at: https://chargy.charging.cloud
- Chargy comes with meta data. True charging transparency is more than just signed smart meter values. Chargy allows you to group multiple signed smart meter values to entire charging sessions and to add additional meta data like EVSE information, geo coordinates, tariffs, ... within your backend in order to improve the user experience for the ev drivers.
- Chargy is secure. Chargy implements a public key infrastructure for managing certificates of smart meters, EVSEs, charging stations, charging station operators and e-mobility providers. By this the ev driver will always retrieve the correct public key to verify a charging process automatically and without complicated manual lookups in external databases.
- Chargy is Open Source. In contrast to other vendors in e-mobility, we belief that true transparency is only trustworthy if the entire process and the required software is open and reusable under a fair copyleft license (AGPL).
- Chargy is open for your contributions. We currently support adapters for the protocols of different charging station vendors like chargeIT mobility, ABL (OCMF), chargepoint. The certification at the Physikalisch-Technische Bundesanstalt (PTB) is provided by chargeIT mobility. If you want to add your protocol or a protocol adapter feel free to read the contributor license agreement and to send us a pull request.
- Chargy is white label. If you are a supporter of the Chargy project you can even use the entire software project under the free Apache 2.0 license. This allows you to create proprietary forks implementing your own corporate design or to include Chargy as a library within your existing application (This limitation was introduced to avoid discussions with too many black sheeps in the e-mobility market. We are sorry...).
- Chargy is accessible. For public sector bodies Chargy fully supports the EU directive 2016/2102 on the accessibility of websites and mobile applications and provides a context-sensitive feedback-mechanism and methods for dispute resolution.
- Alfen
- Bauer energy meters
- EMH energy meters
- Mennekes XML
- OCMF v1.1 - v1.4
- Porsche
- chargeIT (2 versions)
- chargepoint
Version 1.2.x of the Chargy Transparency Software (Desktop) was reviewed and certified by Verband der Elektrotechnik Elektronik Informationstechnik e.V. (VDE). If you are a charge point vendor and want to use this software to verify the compliance with the German Eichrecht you can talk to our partner ChargePoint and obtain the required legal documents.
Version 1.0.x of the Chargy Transparency Software (Desktop) was reviewed and certified by Physikalisch-Technische Bundesanstalt (PTB). If you are a charge point vendor and want to use this software to verify the compliance with the German Eichrecht you can talk to our partner chargeIT mobility and obtain the required legal documents.
If you need help with the Chargy Transparency Software or want to include your smarty energy meter or transparency data format, talk to us.
This software is also available as DesktopApp.
Assuming you have a current Node.js (~v21.7) installation you can just clone this git repository, install all the JavaScript dependencies, compile it and run the webpack development server...
git clone https://github.com/OpenChargingCloud/ChargyWebApp.git
cd ChargyWebApp
npm install
npm run build
npm start
Your prefered web browser should automagically open http://localhost:1608
For Linux production deployments, build the static web application and serve the generated build/ directory with a web server such as nginx. See Chargy WebApp on Linux.
The hosted WebApp supports deep links for CPOs and backend systems that want to send customers directly to a verification result.
Small charge transparency records can be embedded directly in the URL via the verify query parameter:
https://chargy.charging.cloud?verify=<base64-or-base64url-encoded-data>
The payload is decoded by the browser and then processed like data received via drag and drop or clipboard paste. Both standard Base64 and Base64URL are accepted. Base64URL without padding is recommended for links.
This variant should only be used for small text payloads such as compact JSON, XML or OCMF data. Large payloads are not recommended because URL size limits vary between browsers, proxies, mail clients and QR-code workflows. As a practical rule of thumb, keep the full URL below a few kilobytes whenever possible.
Larger payloads can be referenced via verifyURL:
https://chargy.charging.cloud?verifyURL=https%3A%2F%2Fapi.example.org%2Fctrs%2F12345.json
The verifyURL must reference a concrete charge transparency payload resource, not a directory or collection URL.
An optional temporary access token can be provided with the token query parameter:
https://chargy.charging.cloud?verifyURL=https%3A%2F%2Fapi.example.org%2Fctrs%2F12345.json&token=<temporary-token>
The WebApp appends this token to the downloaded URL as its own token query parameter. If the target URL already contains a query string, the token is merged into it:
https://api.example.org/ctrs/12345.json?format=chargy
becomes:
https://api.example.org/ctrs/12345.json?format=chargy&token=<temporary-token>
Alternatively, or in addition, a bearer token can be provided with the bearerToken query parameter:
https://chargy.charging.cloud?verifyURL=https%3A%2F%2Fapi.example.org%2Fctrs%2F12345.json%3Fformat%3Dchargy&bearerToken=<temporary-token>
This token is sent as an HTTP authorization header when downloading the payload:
Authorization: Bearer <temporary-token>
The token and bearerToken parameters may be used at the same time, even if that is redundant.
The WebApp will only download external payloads from URL prefixes explicitly allowed by a local externalURLs.conf file served next to index.html.
The file format is one rule per line:
# <URL-prefix> <max-payload-size-in-kbytes>
https://api.example.org/ctrs/ 100
Blank lines and lines starting with # are ignored. The requested verifyURL must start with one of the configured URL prefixes. Redirects are only accepted when the final URL still starts with the same allowed prefix.
The size limit is enforced twice:
- If the server sends a
Content-Lengthheader larger than the configured limit, the download is rejected before reading the body. - If the response is streamed without a usable
Content-Length, the WebApp counts bytes while reading and aborts as soon as the configured limit is exceeded.
The generated build includes an empty template at build/externalURLs.conf. Production deployments should replace or extend this file with the allowed API prefixes.
Because verifyURL downloads are performed by the user's browser, the target API must allow cross-origin requests from the WebApp origin. For the public deployment this means allowing:
Access-Control-Allow-Origin: https://chargy.charging.cloud
When bearerToken is used, the target API must also allow the Authorization request header, for example:
Access-Control-Allow-Headers: Authorization
The WebApp fetches external payloads without credentials, so APIs should not require cookies or browser authentication for these verification payload URLs. Prefer short-lived, unguessable URLs or backend-issued tokens when payloads are not public.
Tokens passed in URLs can appear in browser history, server logs and referrer logs. They should therefore be short-lived, scoped to a single payload and invalidated after use whenever possible.
The development of version v2.x already started and will focus on enhanced security concepts, more digital certificates and pricing information.
- Christian Meusel for more BSM validations.
This Open Source project is partially funded by the NGI Zero Commons Fund as part of our EVQI project.
We also appreciate any additional funding and long-term support for the Chargy family, for example via GitHub Sponsors, as it helps us keep the project sustainable, independent and useful for the entire e-mobility community.
The Chargy Transparency Software is one of the winners of the 1. Thuringia's Open-Source Prize in March 2019. This prize was awarded by Wolfgang Tiefensee, Thuringia’s Secretary of Commerce, in conjunction with the board of directors of the IT industry network ITNet Thuringia.
