EVerest API definition for auth token validator - CLIENT side (MODULE) 1.0.0

API for EVerest API clients implementing auth token validator.

  • #EVerest
  • #Auth

Servers

  • mqtt://localhost:1883/everest_api/1/auth_token_validator/{module_id}mqttdefault

    default local MQTT

    object
    module_id
    required
    string

    The ID of the module as defined in the EVerest config file.

Operations

  • REPLY e2m/validate_token

    Direction: EVerest to Module

    Operation IDreceive_request_validate_token

    Available only on servers:

    Accepts the following message:

    Request validate tokenreceive_request_validate_token

    Request to validate token.

    Message IDreceive_request_validate_token
    object

    Examples

    REPLY INFORMATION

    REPLY CHANNEL INFORMATION

    Reply will be directed to the address specified at this location: $message.header#/replyTo

    REPLY address information

    REPLY will be sent to the address provided in:$message.header#/replyTo
  • SEND

    Direction: Module to EVerest

    Operation IDsend_reply_validate_token

    Available only on servers:

    Accepts the following message:

    Reply validate tokensend_reply_validate_token

    Reply to validate token.

    Message IDsend_reply_validate_token
    object

    Result object containing authorization status enum value and an optional parentIdTag

    Examples

  • SEND m2e/validate_result_update

    Operation IDsend_validate_result_update

    Available only on servers:

    Accepts the following message:

    Send validate result updatesend_validate_result_update

    Updated validation result for a given token due to some changes. These can be triggered by TransactionEvent messages or StartTransaction.

    Message IDsend_validate_result_update
    object

    Result object containing an updated validation result for a given token. This is needed since certain information can be updated at a later time.

    Examples

  • RECEIVE e2m/heartbeat

    Operation IDreceive_heartbeat

    Available only on servers:

    Accepts the following message:

    Receive heartbeatreceive_heartbeat

    Heartbeat produced by EVerest as configured via cfg_heartbeat_interval_ms in the EVerest configuration

    Message IDreceive_heartbeat
    Payload
    integer

    64bit unsigned integer. The id of every heartbeat increases by 1 and overflows when the maximum representable value is reached

    Examples

  • SEND m2e/communication_check

    Operation IDsend_communication_check

    Available only on servers:

    Accepts the following message:

    Send communication checksend_communication_check

    Signal to EVerest that communication is good or check shall be stopped

    Message IDsend_communication_check
    Payload
    boolean

    Send 'true' at least every 'cfg_communication_check_to_s' seconds to signal module is alive. Send 'false' to stop communication check'

    Examples

Messages

  • #1Request validate tokenreceive_request_validate_token

    Request to validate token.

    Message IDreceive_request_validate_token
    object
  • #2Reply validate tokensend_reply_validate_token

    Reply to validate token.

    Message IDsend_reply_validate_token
    object

    Result object containing authorization status enum value and an optional parentIdTag

  • #3Send validate result updatesend_validate_result_update

    Updated validation result for a given token due to some changes. These can be triggered by TransactionEvent messages or StartTransaction.

    Message IDsend_validate_result_update
    object

    Result object containing an updated validation result for a given token. This is needed since certain information can be updated at a later time.

  • #4Receive heartbeatreceive_heartbeat

    Heartbeat produced by EVerest as configured via cfg_heartbeat_interval_ms in the EVerest configuration

    Message IDreceive_heartbeat
    Payload
    integer

    64bit unsigned integer. The id of every heartbeat increases by 1 and overflows when the maximum representable value is reached

  • #5Send communication checksend_communication_check

    Signal to EVerest that communication is good or check shall be stopped

    Message IDsend_communication_check
    Payload
    boolean

    Send 'true' at least every 'cfg_communication_check_to_s' seconds to signal module is alive. Send 'false' to stop communication check'

Schemas

  • AuthorizationStatus
    string

    Authorization Status enum

      Allowed values:
    • "Accepted"
    • "Blocked"
    • "ConcurrentTx"
    • "Expired"
    • "Invalid"
    • "NoCredit"
    • "NotAllowedTypeEVSE"
    • "NotAtThisLocation"
    • "NotAtThisTime"
    • "Unknown"
  • CertificateStatus
    string

    Certificate status information

      Allowed values:
    • "Accepted"
    • "SignatureError"
    • "CertificateExpired"
    • "CertificateRevoked"
    • "NoCertificateAvailable"
    • "CertChainError"
    • "ContractCancelled"
  • EnergyTransferMode
    string

    Possible energy transfer modes. The modes AC_single_phase_core to DC_unique apply to DIN70121 and ISO15118-2. The other modes DC to WPT apply to ISO15118-20.

      Allowed values:
    • "AC_single_phase_core"
    • "AC_two_phase"
    • "AC_three_phase_core"
    • "DC_core"
    • "DC_extended"
    • "DC_combo_core"
    • "DC_unique"
    • "DC"
    • "AC_BPT"
    • "AC_BPT_DER"
    • "AC_DER"
    • "DC_BPT"
    • "DC_ACDP"
    • "DC_ACDP_BPT"
    • "WPT"
  • object

    Result object containing authorization status enum value and an optional parentIdTag

  • object

    Result object containing an updated validation result for a given token. This is needed since certain information can be updated at a later time.

  • CommunicationCheck
    boolean

    Send 'true' at least every 'cfg_communication_check_to_s' seconds to signal module is alive. Send 'false' to stop communication check'

  • HeartBeatId
    integer

    64bit unsigned integer. The id of every heartbeat increases by 1 and overflows when the maximum representable value is reached