OCPP - Event - Session - Fault Log

[chris1howell]

Log and save each charge session to WiFi Flash.
Plug in - log Start date and time
Un-plug - log Stop date and time time, elapsed time and energy

Start, Stop, elapsed, energy

[jeremypoulter]

Can certainly look at this, may need to consider how much history is maintained. Should be ok from the point of view of not wearing out the flash, but maybe a future revision of the WiFI board should include an SD card slot?

[chris1howell]

Agreed, It will depend on how much space is available for the logs and how much space is used for each entry. We would not want to erase and rewrite too often. Home stations would likely be less than one entry a day. I am sure there is a better structured and more efficient way to do this... But Something like this is 71 bytes {"Start":202101121914,"Stop":202101130215,"Elapsed":601,"Energy":24342} If we set aside 512KB of the 4MB Flash that would be a little more than 7200 Sessions or 20 years. That is probably a bit excessive to keep on flash...

…

On Wed, Feb 17, 2021 at 6:57 PM Jeremy Poulter ***@***.***> wrote: Can certainly look at this, may need to consider how much history is maintained. Should be ok from the point of view of not wearing out the flash, but maybe a future revision of the WiFI board should include an SD card slot? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#134 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN5QH7YJYQ4BNBLK3NNTTDS7RJXFANCNFSM4VB3WHNQ> .

[chris1howell]

OCPP Charge Point operators require Fault and Event logs.

Event, Session and Faults should be logged to Flash for display in the OpenEVSE Web portal, MQTT and OCPP.

A entry in the log should be created any time the EVSE State changes or Temperature throttling starts/stops

Type - Time - EVSE State - elapsed time - Pilot Current - energy - temperature - temperature max for the current session - Connector/Vehicle status - Divert mode

Type
1 Information - Session info
2 Notification - Temperature throttling etc.
3 Warning - Errors GFCI, Ground Fault, Temperature Shutdown etc.

Type
1 Information - Session info
2 Notification - Temperture throttoling etc.
3 Warning - Errors GFCI, Ground Fault, Temperature Shutdown etc.

OCPP should send status, Charger Fault and Events to OCPP provider.

[jeremypoulter]

In terms of space there is actually not a lot of free flash, OTA requires the same flash space as the app, currently the flash map is:

EEPROM: 20K
OTA data: 8K
app 0: 1.185M 
app 1: 1.185M 
File system: 192K

So basically it is a section out of the 192K of the file system we have for storage, still can probably to a significant amount

[matth-x]

Okay, thank you for the hint, I definetly have to consider this.

From the point of view of the OCPP library, there are internal events (like a successful transaction end) and external events (like throttling due to high temperature). And the same goes for the EVSE state.

I think a human readable plain-text log is more suitable than a well-defined structured log. The format would look like this:
<type> <timestamp> <internal state> <external state> (<internal event> or <external event>), e.g.
2 | 2021-07-26T13:00:00Z | txId=123, charging | plugged, active, 110°F | end temperature throttling

This will lead to two additional functions in the API, log_event(enum type, const char *event) and log_state_cb([]() -> const char*). And for the European Union, I will introduce preferences to filter out specific internal data if the client has objections regarding the GDPR, which will be set at initiation of the library.

To limit the size of the logs, the plain-text approach requires to chunk the log and delete the oldest chunk if some threshold is exceeded (like occupied memory). When uploading the logs to the server, the chunks will be concatenated to a single file.

Do you agree with that approach or have any improvements in mind?

[jeremypoulter]

@matth-x I have already started on this from a generic POV. I still think it makes sense to store as JSON lines, is just easier to extract the data back out that way, don't have to write a parser. We don't have to impose a strict format on this. Each record will have some common fields, but nothing to say they all have to have the same data (but probably will).