Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error Reporting via OCPP201 #824

Merged
merged 5 commits into from
Oct 14, 2024
Merged

Error Reporting via OCPP201 #824

merged 5 commits into from
Oct 14, 2024

Conversation

Pietfried
Copy link
Contributor

@Pietfried Pietfried commented Aug 8, 2024

Describe your changes

This PR adds support for reporting errors that are raised within EVerest over OCPP2.0.1. Errors that are reported will initiate a NotifyEvent.req using the information provided via the Error object.

Adds documentation for the Error Handling via OCPP2.0.1.

Current Limitations

In OCPP2.0.1 errors can be reported using the NotifyEventRequest
message. The eventData property carries the relevant information.

This format of reporting errors deviates from the mechanism used within
EVerest. This data structure forces to map an error to a
component-variable combination. This requires a mapping
mechanism between EVerest errors and component-variable
combination.

Currently this module maps the Error to one of these three Components:

  • ChargingStation (if error.origin.mapping.evse is not set or 0)
  • EVSE (error.origin.mapping.evse is set and error.origin.mapping.connector is not set)
  • Connector (error.origin.mapping.evse is set and error.origin.mapping.connector is set)

The Variable used as part of the NotifyEventRequest is constantly defined to Problem for now.

The goal is to have a more advanced mapping of reported errors to the respective component-variable combinations in the future.

Issue ticket number and link

Checklist before requesting a review

  • I have performed a self-review of my code
  • I have made corresponding changes to the documentation
  • I read the contribution documentation and made sure that my changes meet its requirements

…w the EventDataType is derived from the EVerest Error Type

Signed-off-by: pietfried <[email protected]>
@Pietfried Pietfried force-pushed the feature/ocpp201-error-handling branch 2 times, most recently from 0b39a5d to 8256c5f Compare August 22, 2024 07:33
…ceived within EVerest. Added documentation about the current limitations, which includes that currently no proper mapping to Components and Variables is implemented

Signed-off-by: pietfried <[email protected]>
@Pietfried Pietfried force-pushed the feature/ocpp201-error-handling branch from 8256c5f to 52e9fc7 Compare August 22, 2024 07:34
@Pietfried Pietfried merged commit 8f8a6f7 into main Oct 14, 2024
9 of 10 checks passed
@Pietfried Pietfried deleted the feature/ocpp201-error-handling branch October 14, 2024 14:35
@hikinggrass hikinggrass added the include-in-release Tag that this PR should be included in the current merge window for the upcoming release if possible label Oct 25, 2024
hikinggrass pushed a commit that referenced this pull request Oct 25, 2024
* Implemented on_event in OCPP201 and add documentation for how the EventDataType is derived from the EVerest Error Type
* Added implementation to trigger NotifyEvent.req in case errors are received within EVerest. Added documentation about the current limitations, which includes that currently no proper mapping to Components and Variables is implemented
---------

Signed-off-by: pietfried <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
include-in-release Tag that this PR should be included in the current merge window for the upcoming release if possible
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants