HWB Standard 1.0.1

Technical documentation and specifications for message exchanges between hardware devices and sales clients in bus. All communication is to be done through MQTT with JSON as payload.

Scope of this specification is primarly for Møre og Romsdal Fylkeskommune and FRAM, but the overall ambition is for a broad consensus with other operators and authorities.

Operations

  • RECEIVE device/[deviceId]/diagnostics

    Specification: Diagnostics

    Allows client to subscribe to diagnostics from specific device.

    Sends diagnostics information for device to sales clients. Could be used by sales clients to show alerts, debug and keep general status of connection information of different devices.

    • Topic: /device/[deviceId]/diagnostics
    • Direction: Publish (Inbound to client)
    • JSON Schema: diagnostics.schema.json
    • MQTT QoS: 0 (Default)
    • Interval: On device startup and on request

    Description

    Devices should respond with diagnostics in two cases: on initial startup and as a response to a diagnostics check. See related topics in next section.

    This topic is available for sales clients to subscribe to diagnostics data on specific devices.

    • See same topic for all devices: /device/diagnostics
    • See related topic for requesting /device/diagnostics/request and /device/[deviceId]/diagnostics/request

    Examples

    {
  "manufacturer": "Acme",
  "model": "NFC2000b",
  "serial": "F0A222100004",
  "firmwareVersion": "0.9.6.0",
  "standardVersion": "1.0.0",
  "ipAddress": "192.168.99.11",
  "label": "front",
  "functionality": ["nfc", "barcode"],
  "status": "OK",
  "statusText": "no errors"
}

    {
  "manufacturer": "Acme",
  "model": "LocOmotive2",
  "serial": "LL0A222100004",
  "firmwareVersion": "0.9.0.0",
  "standardVersion": "1.1.0",
  "ipAddress": "192.168.99.12",
  "label": "",
  "functionality": ["location"],
  "status": "OK",
  "statusText": "no errors"
}
    Operation IDpublish

    Accepts the following message:

    object [DeviceDiagnostics]
    uid: https://github.com/mrfylke/frammr-mqtt-validator/specifications/diagnostics/[deviceId]/diagnostics.schema.json

    Diagnostics information for specific device

    object

    Examples

  • SEND device/[deviceId]/diagnostics/request

    Specification: Requets Diagnostics on specific Device

    Request diagnostics from a specific device. Can be called periodically by polling from sales client. A request will cause a diagnostics event to be passed from device specidied by deviceId in topic.

    • Topic: /device/[deviceId]/diagnostics/request
    • Direction: Consume (Outbound from client)
    • JSON Schema: request.schema.json
    • MQTT QoS: 0 (Default)

    Description

    Request diagnostics check from specific device. See related topics in next section.

    • Subscribing to topic on device level: /device/[deviceId]/diagnostics
    • Subscribing to all diagnostics: /device/diagnostics
    • See related topic for requesting on all devices /device/diagnostics/request

    Examples

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "eventTimestamp": "2023-04-22T10:28:37.337Z"
}
    Operation IDsubscribe

    Accepts the following message:

    object [RequestDiagnosticsDevice]
    uid: https://github.com/mrfylke/frammr-mqtt-validator/specifications/device/[deviceId]/diagnostics/request/request.schema.json

    Request diagnostics check from specific device

    object

    Examples

  • RECEIVE device/diagnostics

    Specification: Diagnostics

    Sends diagnostics information for device to sales clients. Could be used by sales clients to show alerts, debug and keep general status of connection information of different devices.

    • Topic: /device/diagnostics
    • Direction: Publish (Inbound to client)
    • JSON Schema: diagnostics.schema.json
    • MQTT QoS: 0 (Default)
    • Interval: On device startup and on request

    Description

    Devices should respond with diagnostics in two cases: on initial startup and as a response to a diagnostics check. See related topics in next section.

    • See same topic on device level: /device/[deviceId]/diagnostics
    • See related topic for requesting /device/diagnostics/request and /device/[deviceId]/diagnostics/request

    Examples

    {
  "manufacturer": "Acme",
  "model": "NFC2000b",
  "serial": "F0A222100004",
  "firmwareVersion": "0.9.6.0",
  "standardVersion": "1.0.0",
  "ipAddress": "192.168.99.11",
  "label": "front",
  "functionality": ["nfc", "barcode"],
  "status": "OK",
  "statusText": "no errors"
}

    {
  "manufacturer": "Acme",
  "model": "LocOmotive2",
  "serial": "LL0A222100004",
  "firmwareVersion": "0.9.0.0",
  "standardVersion": "1.1.0",
  "ipAddress": "192.168.99.12",
  "label": "",
  "functionality": ["location"],
  "status": "OK",
  "statusText": "no errors"
}
    Operation IDpublish

    Accepts the following message:

    object [Diagnostics]
    uid: https://github.com/mrfylke/frammr-mqtt-validator/specifications/diagnostics/diagnostics.schema.json

    Diagnostics information on device

    object

    Examples

  • SEND device/diagnostics/request

    Specification: Requets Diagnostics

    Request diagnostics from all connected devices. Can be called periodically by polling from sales client. A request will cause a diagnostics event to be passed from all devices.

    • Topic: /device/diagnostics/request
    • Direction: Consume (Outbound from client)
    • JSON Schema: request.schema.json
    • MQTT QoS: 0 (Default)

    Description

    Request diagnostics check from device. See related topics in next section.

    • Subscribing to topic on device level: /device/[deviceId]/diagnostics
    • Subscribing to all diagnostics: /device/diagnostics
    • See related topic for requesting on specific device /device/[deviceId]/diagnostics/request

    Examples

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "eventTimestamp": "2023-04-22T10:28:37.337Z"
}
    Operation IDsubscribe

    Accepts the following message:

    object [RequestDiagnostics]
    uid: https://github.com/mrfylke/frammr-mqtt-validator/specifications/device/diagnostics/request/request.schema.json

    Request diagnostics check from all devices

    object

    Examples

  • RECEIVE sensors/location

    Specification: Location

    Provides periodic GPS location data specified in decimal format by latitude and longitude. Should be send once every second. No need for a MQTT QoS guarantee as package loss is acceptable.

    • Topic: /sensors/location
    • Direction: Publish (Inbound to client)
    • JSON Schema: location.schema.json
    • MQTT QoS: 0 (Default)
    • Interval: Atleast once per second

    Description

    Provided periodic location data.

    Examples

    {
  "traceId": "48b12d1f-6b96-4f70-94f9-f785cef96812",
  "eventTimestamp": "2023-09-01T23:45:52Z",
  "latitudeDegree": 62.734393,
  "longitudeDegree": 7.150033,
  "altitude": 124,
  "messageNumber": 12345,
  "speedOverGround": 15.3,
  "trackDegreeTrue": 324,
  "signalQuality": 1,
  "numberOfSatellites": 12,
  "hdop": 2.4
}

    Notice:

    Specification based on and should be compatible with Ruter specification. As such it it is licensed under Apache License 2.0 and originally created by Ruter AS.

    Operation IDpublish

    Accepts the following message:

    object [Location]
    uid: https://github.com/mrfylke/frammr-mqtt-validator/specifications/sensors/location/location.schema.json

    Location sensor data

    object

    Examples

  • SEND validators/[deviceId]/configure

    Specification: Configure specific device

    A method for setting specific configuration for specific device. Can set one or many options at once. Will only overwrite the passed configuration.

    • Topic: validators/[deviceId]/configure
    • Direction: Consume (Outbound from client)
    • JSON Schema: configure.schema.json
    • MQTT QoS: 1 (at least once)
    • Trigger: Client setting configuration through UI or automated requests.

    Settings

    • dumpCardMode: See NFC flow chart for implications of card dump mode.
    • timeout: Settings for timeout behavior with timout in seconds and message when it is timed out. Timeout of 0 will be no timeout (not recommended)
    • Request for sending current: /validators/[deviceId]/configure/request
    • List current configuration: /validators/[deviceId]/configure/current
    • Setting configuration for all devices: /validators/configure

    Examples

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "eventTimestamp": "2023-04-22T10:28:37.337Z",

  "dumpCardMode": true
}

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "eventTimestamp": "2023-04-22T10:28:37.337Z",

  "timeout": {
    "timeInSeconds": 10,
    "message": "Ingen kontakt med tjeneste. Gå på bussen"
  }
}

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "eventTimestamp": "2023-04-22T10:28:37.337Z",

  "dumpCardMode": true,
  "timeout": {
    "timeInSeconds": 10,
    "message": "Ingen kontakt med tjeneste. Gå på bussen"
  }
}
    Operation IDsubscribe

    Accepts the following message:

    object [Configure]
    uid: https://github.com/mrfylke/frammr-mqtt-validator/specifications/validators/[deviceId]/configure/configure.schema.json

    Set new configuration

    object

    Examples

  • RECEIVE validators/[deviceId]/configure/current

    Specification: List Current Configuration

    Subscribe to topic to get list of currently set configuration for specific device. Payload will be similar to /validators/configure and /validators/[deviceId]/configure.

    • Topic: /validators/[deviceId]/configure/current
    • Direction: Publish (Inbound to client)
    • JSON Schema: current.schema.json
    • MQTT QoS: 0
    • Trigger: Sales client requesting configuration
    • Request for sending current: /validators/[deviceId]/configure/request
    • Setting new configuration: /validators/[deviceId]/configure

    Examples

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "eventTimestamp": "2023-04-22T10:28:37.337Z",

  "dumpCardMode": true,
  "timeout": {
    "timeInSeconds": 10,
    "message": "Ingen kontakt med tjeneste. Gå på bussen"
  }
}
    Operation IDpublish

    Accepts the following message:

    object [CurrentConfiguration]
    uid: https://github.com/mrfylke/frammr-mqtt-validator/specifications/validators/[deviceId]/configure/current/current.schema.json

    List of current configuration

    object

    Examples

  • SEND validators/[deviceId]/configure/request

    Specification: Request Current Configuration

    Request currently set configuration from specific device.

    • Topic: /validators/[deviceId]/configure/request
    • Direction: Consume (Outbound from client)
    • JSON Schema: request.schema.json
    • MQTT QoS: 0
    • Response sent from device: /validators/[deviceId]/configure/current
    • Setting new configuration: /validators/[deviceId]/configure

    Examples

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "eventTimestamp": "2023-04-22T10:28:37.337Z"
}
    Operation IDsubscribe

    Accepts the following message:

    object [RequestConfiguration]
    uid: https://github.com/mrfylke/frammr-mqtt-validator/specifications/validators/[deviceId]/configure/request/request.schema.json

    Request current configuration

    object

    Examples

  • SEND validators/[deviceId]/response

    Specification: Validation Response

    Response sent after finished validation on client. Response can be both success, fail and error. In the current specification the response method is limited to a variant type/enum, and it's up to the device to handle the proper response in form of icon, color and sound.

    Device should optionally recieve title and description if supported by the device.

    • Topic: validators/[deviceId]/response
    • Direction: Consume (Outbound from client)
    • JSON Schema: response.schema.json
    • MQTT QoS: 1 (at least once)
    • Trigger: After validation result on client

    Examples

    {
  "traceId": "48b12d1f-6b96-4f70-94f9-f785cef96812",
  "eventTimestamp": "2023-09-01T23:45:52Z",
  "result": {
    "title": "Godkjent",
    "description": "Validert 22/04/2020 13:19 Enkeltbillett 1 Voksen ",
    "validity": "VALID"
  }
}
    Operation IDsubscribe

    Accepts the following message:

    object [Validation Response]
    uid: https://github.com/mrfylke/mtbuss-mqtt-validator/specifications/validators/[deviceId]/response.schema.json

    Response sent to devices after inspection result has been found.

    object

    Examples

  • RECEIVE validators/barcode

    Specification: barcode

    Passenger want to use the service and presents their barcode containing a token referencing an account containing possible travel rights.

    Barcode should be transmitted as base64 encoded URL string without padding.

    • Topic: validators/barcode
    • Direction: Publish (Inbound to client)
    • JSON Schema: barcode.schema.json
    • MQTT QoS: 1 (at least once)
    • Trigger: Once every time a passenger presents a barcode to the barcode reader.

    Examples

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "deviceId": "flv202400004",
  "eventTimestamp": "2023-04-22T10:28:37.337Z",
  "barcode": "CtYBCtMBCtN...VDRFNBKgsIpdicoAYQ4NeUdzAB"
}
    Operation IDpublish

    Accepts the following message:

    object [Barcode Validation Request]
    uid: https://github.com/mrfylke/mtbuss-mqtt-validator/specifications/validators/barcode.json

    A barcode containing account tokens to be validated.

    object

    Examples

  • SEND validators/configure

    Specification: Configure all devices

    A method for setting configuration for all device at once. Can set one or many options at once. Will only overwrite the passed configuration.

    • Topic: validators/configure
    • Direction: Consume (Outbound from client)
    • JSON Schema: configure.schema.json
    • MQTT QoS: 1 (at least once)
    • Trigger: Client setting configuration through UI or automated requests.

    Settings

    • dumpCardMode: See NFC flow chart for implications of card dump mode.
    • timeout: Settings for timeout behavior with timout in seconds and message when it is timed out. Timeout of 0 will be no timeout (not recommended)
    • Request for sending current: /validators/configure/request
    • List current configuration: /validators/configure/current
    • Setting configuration for specific device: /validators/[deviceId]/configure

    Examples

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "eventTimestamp": "2023-04-22T10:28:37.337Z",

  "dumpCardMode": true
}

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "eventTimestamp": "2023-04-22T10:28:37.337Z",

  "timeout": {
    "timeInSeconds": 10,
    "message": "Ingen kontakt med tjeneste. Gå på bussen"
  }
}

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "eventTimestamp": "2023-04-22T10:28:37.337Z",

  "dumpCardMode": true,
  "timeout": {
    "timeInSeconds": 10,
    "message": "Ingen kontakt med tjeneste. Gå på bussen"
  }
}
    Operation IDsubscribe

    Accepts the following message:

    object [Configure]
    uid: https://github.com/mrfylke/frammr-mqtt-validator/specifications/validators/[deviceId]/configure/configure.schema.json

    Set new configuration

    object

    Examples

  • RECEIVE validators/configure/current

    Specification: List Current Configuration

    Subscribe to topic to get list of currently set configuration for specific device. Payload will be similar to /validators/configure and /validators/[deviceId]/configure.

    • Topic: /validators/configure/current
    • Direction: Publish (Inbound to client)
    • JSON Schema: current.schema.json
    • MQTT QoS: 0
    • Trigger: Sales client requesting configuration
    • Request for sending current: /validators/[configure/request
    • Setting new configuration: /validators/configure
    • For specific device: /validators/[deviceId]/configure/current

    Examples

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "eventTimestamp": "2023-04-22T10:28:37.337Z",

  "dumpCardMode": true,
  "timeout": {
    "timeInSeconds": 10,
    "message": "Ingen kontakt med tjeneste. Gå på bussen"
  }
}
    Operation IDpublish

    Accepts the following message:

    object [CurrentConfiguration]
    uid: https://github.com/mrfylke/frammr-mqtt-validator/specifications/validators/[deviceId]/configure/current/current.schema.json

    List of current configuration

    object

    Examples

  • SEND validators/configure/request

    Specification: Request Current Configuration

    Request currently set configuration from all devices.

    • Topic: /validators/configure/request
    • Direction: Consume (Outbound from client)
    • JSON Schema: request.schema.json
    • MQTT QoS: 0
    • Response sent from devices: /validators/configure/current
    • Setting new configuration for all devices: /validators/configure

    Examples

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "eventTimestamp": "2023-04-22T10:28:37.337Z"
}
    Operation IDsubscribe

    Accepts the following message:

    object [RequestConfiguration]
    uid: https://github.com/mrfylke/frammr-mqtt-validator/specifications/validators/[deviceId]/configure/request/request.schema.json

    Request current configuration

    object

    Examples

  • RECEIVE validators/nfc

    Specification: nfc

    When a passenger intends to use the service, they present their travel card, which may have a token referencing an account with corresponding travel rights. In cases where there is no token present, the serial number of the travel card will be used. If there is a customer account associated with that serial number, a potential token will be generated and written back to the travel card. See diagram for total flow.

    Token should be transmitted as base64 encoded URL string without padding.

    • Topic: validators/nfc
    • Direction: Publish (Inbound to client)
    • JSON Schema: nfc.schema.json
    • MQTT QoS: 0 (at most once)
    • Trigger: Once every time a passenger presents a travel card to the barcode reader.

    Card content dump

    If the device is configured accordingly, the complete content of the card can be transferred from the device, as depicted in the flow chart. This simplifies the client's perspective as it enables direct access to the card's content. Please refer to the validators/configure topic for the configuration flag that determines whether cardContent is set. Below are examples demonstrating the scenarios when cardContent is enabled.

    This concept is applicable in situations where the smart card holds various types of travel rights and there is a requirement to prioritize among them. Examples of such types include NOD (Name Origin Destination), account-based, and others.

    Only supported type for now is nsd and that needs to be set as type, for future proofing when new types are added.

    Examples

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "deviceId": "flv202400004",
  "eventTimestamp": "2023-04-22T10:28:37.337Z",
  "travelCardNumber": "323116753",
  "token": "CtYBCtMBCtN...VDRFNBKgsIpdicoAYQ4NeUdzAB"
}

    Example with card content

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "deviceId": "flv202400004",
  "eventTimestamp": "2023-04-22T10:28:37.337Z",
  "travelCardNumber": "323116753",
  "cardContent": [
    {
      "appId": "<ID>",
      "type": "nsd",
      "files": [{ "fileNumber": "<FileNumber>", "content": "0x0032" }]
    }
  ]
}

    Flow

    flowchart TD
    A[Customer shows card] --> B(NFC device\nreads card)

    B --> B1{Is supported card?}
    B1 -->|no| ResponseInvalid_0[Built in response:\n Not valid]


    B1 -->|Yes| C{Device contains\naccess keys}

    C -->|Yes| AC1_Dump{Is dump card content\nconfig active?}
    AC1_Dump -->|Yes| AC1_Dump_1(Read entire\ncard content)

    AC1_Dump_1 -->|/validators/nfc|AC4

    AC1_Dump -->|No| AC1(Read card,\nfetch NSD serial number and\npotential token)
    AC1 --> AC2{Is token\non card?}
    AC2 -->|Yes| AC3(Read token)

    AC3 -->|/validators/nfc| AC4{Does token\nexists at Provider?}
    AC4 -->|Yes| AC5(Validate Token)
    AC5 -->|"/validators/[deviceId]/response"| AC6[Show response\nto customer]
    AC4 -->|Blocked/removed| AC7(APDU Subprocess\nRemove token from card)
    AC7 -->|"/validators/[deviceId]/response"| ResponseInvalid


    C -->|No| NAC1(Fetch NSD serial number)
    NAC1 -->|/validators/nfc| NAC2(APDU Subprocess\nFetch token)
    NAC2 --> NAC3{Is token\non card?}


    AC2 -->|No| AC2_Get(Send only serial number)
    AC2_Get -->|/validators/nfc| NoToken(Get token from\nserial number)

    NAC3 -->|No| NoToken
    NAC3 -->|Yes| NACToken1{Does token\nexists at Provider?}

    NACToken1 -->|Blocked/removed| NACToken1No(APDU Subprocess\nRemove token from card)
    NACToken1No  -->|"/validators/[deviceId]/response"| NACToken1NoResponse[Show response\nto customer]

    NoToken --> FetchTokenStatus{Does token\nexists at Provider?}
    FetchTokenStatus-->|Blocked/removed| FetchTokenInvalid(No valid travel right)
    FetchTokenStatus-->|Not found| FetchTokenInvalid
    FetchTokenInvalid -->|"/validators/[deviceId]/response"| ResponseInvalid[Show response:\n Not valid]

    FetchTokenStatus-->|Found| FetchTokenFound(APDU Subprocess:\nWrite token to card)

    FetchTokenFound -->|Yes| FetchTokenFoundValidate(Validate Token)
    FetchTokenFoundValidate -->|"/validators/[deviceId]/response"| FetchTokenResponse[Show response\nto customer]

    NACToken1 -->|Found| FetchTokenFoundValidate
    • The APDU sub-processes are custom command transceive processes that utilize the apdu topics for communication and data exchange.
    • In the flow chart, the "Provider" refers to the Account Based Ticketing (ABT) provider. This provider handles tasks such as customer data management and ticket purchases within the ABT system.
    Operation IDpublish

    Accepts the following message:

    object [NFC Validation Request]
    uid: https://github.com/mrfylke/mtbuss-mqtt-validator/specifications/validators/nfc/nfc.schema.json

    Validating NFC card containing account tokens to be validated.

    object

    Examples

  • SEND validators/nfc/apdu/[deviceId]/transmit

    Specification: APDU Transmit

    Transmit series of APDU commands in hexadecimals. Each command with an specified ID. Commands will generate response passed from device to client on topic validators/apdu/receive with corresponding commandId.

    APDU commands can be used to read or write specific values from travel cards or other NFC based devices.

    transceiveId can be used to link transmit and receive events. eventTimestamp is the time the command transmit request is generated.

    • Topic: validators/nfc/apdu/[deviceId]/transmit
    • Direction: Consume (Outbound from client)
    • JSON Schema: transmit.schema.json
    • MQTT QoS: 1 (at least once)
    • Trigger: Result from transmitted commands.

    Hex and expected status

    All commands should be represented as hex, starting with 0x. See examples. Expected status is optional. If result of executing command does not match expected status prefix, result is ommited in the receive event.

    0xAF and continuation

    Continuation on 0xAF is handled implicitly if expStatus is set as 0x00, depending on apdu type. See description below.

    desfire (native)

    • If expStatus=0x00 or empty and first bytes in response indicates more data (0xAF) the device should fetch all data until end and give result as concatinated byte array.
    • If expStatus=0xAF is transmitted it is not handled automatically by the device.

    See related transmit topic: validators/nfc/apdu/receive.

    Examples

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "deviceId": "flv202400004",
  "eventTimestamp": "2023-04-22T10:28:37.337Z",
  "transceiveId": "c28f206d-8016-4d22-b21b-70d8d6d2fea4",
  "apduType": "desfire",
  "command": [
    { "commandId": 1, "frame": "0x0080", "expStatus": "0x00" },
    { "commandId": 2, "frame": "0x000000100000", "expStatus": "0x00" },
    { "commandId": 3, "frame": "0x0180", "expStatus": "0x00" },
    { "commandId": 4, "frame": "0x07", "expStatus": "0x00" }
  ]
}

    Additional information

    Link to APDU-documentation.

    Operation IDsubscribe

    Accepts the following message:

    object [APDU Command Transmit]
    uid: https://github.com/mrfylke/mtbuss-mqtt-validator/specifications/validators/nfc/apdu/[deviceId]/transmit.json

    Transmit sequence of APDU commands

    object

    Examples

  • RECEIVE validators/nfc/apdu/receive

    Specification: APDU Receive

    Recieve result from commands passed through transmit topic. Will contain list of results corresponding to the results transmitted, with the same specified commandIds.

    transceiveId can be used to link transmit and receive events. eventTimestamp is the time the first command result is generated.

    • Topic: validators/nfc/apdu/receive
    • Direction: Publish (Inbound to client)
    • JSON Schema: receive.schema.json
    • MQTT QoS: 1 (at least once)
    • Trigger: Result from transmitted commands.

    Hex and expected status

    All result frames should be represneted as hex, starting with 0x. See examples. If result of executing command does not match expected status prefix passed in the transmit event, result should be ommited.

    0xAF and continuation

    Continuation on 0xAF is handled implicitly if expStatus as passed in by transmit is set as 0x00. See description below.

    desfire (native)

    • If expStatus=0x00 or empty and first bytes in response indicates more data (0xAF) the device should fetch all data until end and give result as concatinated byte array.
    • If expStatus=0xAF is transmitted it is not handled automatically by the device.

    See related transmit topic: validators/nfc/apdu/[deviceId]/transmit.

    Examples

    {
  "traceId": "543070fe-ef32-11ed-a05b-0242ac120003",
  "deviceId": "flv202400004",
  "eventTimestamp": "2023-04-22T10:28:37.337Z",
  "transceiveId": "c28f206d-8016-4d22-b21b-70d8d6d2fea4",
  "apduType": "desfire",
  "result": [
    { "commandId": 1, "frame": "0x00" },
    { "commandId": 2, "frame": "0x0090800002000280" },
    { "commandId": 3, "frame": "0x00" },
    { "commandId": 4, "frame": "" }
  ]
}

    Additional information

    Link to APDU-documentation.

    Operation IDpublish

    Accepts the following message:

    object [APDU result receive event]
    uid: https://github.com/mrfylke/mtbuss-mqtt-validator/specifications/validators/nfc/apdu/receive.json

    APDU results given on specific transceiveId

    object

    Examples