Chargepoint sent a first specification of their approach to the German Eichrecht, which uses charging stations crypto keys instead of smart meter crypto keys. This requires some changes within the internal data processing.

• Support the chargepoint charge transparency record format
• Support of secp224k1 signatures
• Support of secp256r1 signatures

I found a bug to report

Within the charge point data format the value "total_energy = 0.0" will be misinterpreted as a missing value (praise JavaScript magics!).

Expected behavior

Use another method to validate if all mandatory parameters exist and are well defined.

Some customers want to use Chargy for ALFEN charging stations

• Support ALFEN transport via chargeIT JSON container
• Support ALFEN transport via SAFE XML container
• Parse and display ALFEN transparency data
• Verify ALFEN signatures
• The format uses BigInt internally which is converterd to Number. Could this become an issue somewhen in the future?

I would like to request/propose a feature

The public key of Chargepoint charging stations is not part of the charge transparency record, but an external file. Allow this file as additional input and merge it into the other charge transparency records.

I would like to request/propose a feature

As a user I want to select multiple charge transparency records/files, to get a consolidated view of all my charging sessions and to save this list of charging sessions as shown within the app on my computer.

This means add a button or similar to the app which will store the given charging sessions using the Chargy data format.

The regulators want to be able to see the software version of the...

1. Charging Station
2. EVSE (if it is not just a part of the charging station)
3. Smart Meter (if it is a device having its own regulations)

Some customers want to use Chargy for Mennekes charging stations

• Documentation of the Mennekes "metra"-XML received
• Support Mennekes transport via metra XML
• Support Mennekes transport via chargeIT JSON container
• Parse and display Mennekes transparency data
• Verify Mennekes signatures

I would like to request/propose a feature

As a user I want to select multiple charge transparency files at once. Such files could be different charging sessions and public key files. All data should be aggregated and merged.

The PTB/CSA wants to see the user authorisation information within the overview of all charging processes (main screen, left side).

Background is that even a single ev driver might have different ways for authorisation: Multiple RFID cards, multiple eMA Ids, ...

Currently the "obis" code is represented as a array of bytes, e.g. "0100011100FF".
Of course the better representation would be: "1-0:1.17.0*255"

1. Ids in the chargepoint format differ between different firmware versions. Therefore compare them case-insensitive. Let charge point define the default format for presenting those Ids within Chargy to the end user (e.g. 'all upper', 'all lower', ...).

The installation path of the normal Windows version and the MSIX version are different.

Simon wants a directory of test data

All charge transparency file names should have the extention .chargy
Open at least on Windows .chargy files via the Chargy Desktop App.

• EMP already has some App
• EMP wants a dedicated documentation and examples how to use Chargy as a library
• Explanations how to use and verify the public keys and certificates

Show digital certificates of energy meter public keys, but do not verify them

Already implemented within the ChargyMobileApp.

• Show if the application hash matches or not
• Show, but do not verify digital signatures

• First publication
• Refined publication

PTB whats that the TS calculates and shows the differences of time, consumption, ...

The PTB wants something like an optical divide or marks which parts of the shown data is regulatory important (German: "eichrechtlich relevant") and which is just meta data.

EMP wants to attach tariffs and/or price infos signed with his private key.
Tariffs for charging, parking, reservation, ...

• Add a "update available"-notification mechanism to notify the user that a new version of the software is available.

• Show a little red icon when the current version of the software is out of date

• Do not install anything automagically, as PTB is not a fan of this (at the moment)

• Use GitHub for serving the version file, as we do not have access to any logfiles (privacy)

1. Regulators want the see which version of Chargy is certified with which version of a charging station, EVSE and smart meter.
2. Having something like a digital certificate for this would be positiv
3. This also means that they might allow us to release new minor versions of Chargy without recertifing Chargy with every type of charging stations in the market :)

Create and update the list good and bad examples for charge transparency records

1. For test cases
2. Showing different (optional) features

I have a question or need help

hello, come across this implementation and would like to ask you if you can explain more about general works as documentation is actually low.

In particular I cannot understand how data has to be certified and in which format ( all chargepoint uses different format? ) and what exactly the charging station need to create at the end of session to create the certified data.

For my understanding the software simply read a signed file sent from the station ( but I could be wrong) . So if have time can u better explain me this flow ?

Thanks !

gsettings get org.gnome.shell favorite-apps
['firefox.desktop', 'org.gnome.Nautilus.desktop', 'org.gnome.Software.desktop', 'yelp.desktop', 'org.gnome.Terminal.desktop', 'chargytransparenzsoftware.desktop']

Support not only secp192r1, but also secp256r1, secp384r1 and secp521r1 for the EMH EDL40++ format.

Extend measurement verification interface to allow results like: (In)ValidStartValue, (In)ValidIntermediateValue, (In)ValidStopValue and StartValue, IntermediateValue, StopValue (without any verification at all) as this is assumed to be more userfriendly

• Add Open Charging Cloud root certificate
• Make sure, that the versions.json is digitally signed by one or more organizations
• Verify the certificates/signatures of the entire versions.json
• Verify the certificates/signatures of a version
• Verify the certificates/signatures of a version package
• Verify the certificates/signatures of a energy meter public key
• Verify the certificates/signatures of another certificates/signature (build a chain/web of trust)
• Sign entire CTRs

Ein Charging Station Operator bzw. ein E-Mobility Provider könnte sich wünschen gewisse Farben und Texte der App nach seinem Corporate Design Vorgaben anzupassen:

1. Via dem Transparenzdatensatz, d.h. Anpassung erst nach Laden des Datensatzes
2. Via einer Zusatzdatei bei der Installation der Software (JSON, CSS), d.h. Anpassung nach Start der App

The EU directive 2016/2102 of the European Parliament and of the Council of 26 October 2016 on the accessibility of the websites and mobile applications of public sector bodies ( https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016L2102 ) defines an "accessibility" feedback mechanism for people with a disability. This is directive is transformed into local law e.g. in Thueringia in http://parldok.thueringen.de/ParlDok/vorgaenge/69750/1

There is already an optional feedback mechanism within the app, but this is focused on technical issues. This mechanism should be extended.

Version 7.0.0 of electron remarks: "The electron.asar file no longer exists. Any packaging scripts that depend on its existence should be updated. #18577"
https://github.com/electron/electron/releases/tag/v7.0.0
electron/electron#18577

This file is used to calculate the application hash value, a PTB feature.

The PTB wants that the software version and its hash value, as printed on the "Baumusterprüfbescheinigung" is shown in the software.

Add Chargy's additional meta data, e.g. geo coordinates of the EVSE, to the SAFE XML using an OCC namespace.

The PTB want us to disable the autostart of removable media within the Linux Live DVD

The meter status information gives information about e.g. errors occured and the status of the internal clock.

Document all the PTB relevant features of the Charge Transparency Records (CTR) Format.

• The PTB wants a simple diagram on the software structure.
• Add this also to the git repository

When multiple transparency files are load but some of them are broken (invalid transparency format) then those files are ignored and not shown. VDE would like to get an error message instead.

Expected behavior

Add an item "$filename: Invalid transparency format" to the list of loaded charging sessions.

Add socket type, max energy, ... to CTR data format and show it within the app (if present)...

I would like to request/propose a feature

Chargepoint charge transparency records are TAR archives compressed via BZIP2. Allow at least BZIP2, GZIP, ZIP files as input. Extract and merge the content of those compressed archives.

A user should also be able to put several charge transparency records/files (and public key files) into a single TAR/ZIP archive and open this file directly.

Chargy should also support archive files within other archive files, as e.g. Chargepoint charge transparency files are tar.bz2-archives and users might want to combine multiple into a single ZIP-archive.

The PTB wants more information about which crypto software is used to verify the signatures.

Problem: Strictly speaking two software libs are used. One for SHA256 and one for ECC.

The PTB want a TRuDI-style self check of "all" files. This means to enumerate all files, calculate the SHA256 hash over all those files, calculate a common hash value and compare it with the stored value. If both are the same the software was not modified.

Strictly speaking this is an obsolete security feature. To make if at least a bit useful we additionally will sign the common hash value with the GraphDefined/OCC private key and verify this signatures via its public key.

Some customers want to use Chargy for charging stations using the OCMF v1.0 format

• Support OCMF transport via chargeIT JSON container
• Support OCMF transport via SAFE XML container
• Parse and display OCMF transparency data
• Verify OCMF signatures

• Show all signers of a smart meter public key
• Verify certificates/signatures for smart meter public keys

End-Customers want more information about charging session when clicking on a bubble within the map, e.g. highlight/open the charging session and show its details.