Choosing the Best Fit for Your Use Case: MQTT, REST API, or AWS S3 Bucket?

July 26, 2023
Connected car data offers multiple consumption methods, including on-demand, live, or optimised for collecting data from high volumes of vehicles. The introduction of streaming technology has opened up new possibilities for utilising this data. However, not every technology is suitable for every need, and the article provides insights on when to use each specific technology.

Technology-fit for Connected Car Data use cases

High Mobility provides a variety of options for integrating with connected car data, offering a total of 8 different ways to connect. Among the most popular approaches we have the REST API, which allows for regular data retrieval, the MQTT API, which enables streaming data using a push approach, and the AWS S3 bucket integration, a convenient no-code link between High Mobility's platform and the cloud services offered by AWS.

In order to start consuming connected car data for your specific use case, we are recommending going through each of the following steps. Every underlying aspect will be explained in more detail both in the video of our 11th Open Dev Talk and this blog post.

  • Check data point availabilities
  • Identify use case requirements
  • Select best-suited technologies
  • Use testing tools to validate your decisions

Identifying required data points and their capabilities

In order to determine the best-suited technology for a given use case, it is crucial to clearly define the goals and purpose of processing the data. At High Mobility, each use case is defined as a data container, associated with one or multiple data points. Our platform simplifies the identification of necessary data points through categorised lists of permissions. We highlight the availability of each data point on a per-brand level because not every cooperating brand provides all data points.

If you are managing multiple fleet-related purposes, you can access our content for the Open Dev Talk 09, where we have outlined the achievable use cases in 2023 and how to manage them on our platform. Once a data container is created with the desired data points, it is recommended to explore our data point catalogue for a closer examination.

The Airtable overview serves as an advanced database, containing detailed information such as descriptions, availability, frequencies, and billing packages for all available data items. The brand columns indicate whether the corresponding data points can be accessed via Pull and/or Push methods. Pull refers to using the REST API or GraphQL API to access the data on-demand, while Push signifies compatibility with the MQTT API or our AWS S3 bucket link, where data is provided with each new update from the vehicle.

For instance, certain data points like speed can only be provided via push, making the decision to use the MQTT protocol automatic. Matching the pull and push availability with the selected data points for a specific use case can be a useful indicator of suitable technologies and APIs to employ. It also highlights any potential restrictions when implementing the corresponding use case. However, it's important to note that most data items can be accessed through both pull and push approaches, and therefore, the Airtable overview should not be the sole criteria for selecting a technology.

Use case characteristics

During Open Dev Talk 09, we explored a wide range of use cases that can be achieved with connected car data in 2023. Each of these use cases has distinct characteristics that play a crucial role in selecting the most suitable technology.

One prominent use case is Mileage Tracking, which encompasses scenarios like PAYD, car pool utilisation, odometer tracking for car subscription billing, and mileage fraud detection. These cases typically require a live data update at a specific point in time, such as the end of the month. Continuous second-by-second updates of mileage count development are generally unnecessary.

Another use case is Charging & EV route optimisation. Here, monitoring battery health and reimbursing charging costs rely on charging data. For effective tracking of charging sessions and monitoring their progress, a continuous data stream is best. Since vehicles are typically charged for a limited time each day, frequent update requests every few seconds are not practical. The same applies to intelligent route planning, where live location and state of charge information are constantly needed to optimise the route plan, especially for logistics purposes.

Location Monitoring & Trips are also significant use cases. For live location tracking, geofencing, stolen vehicle recovery, and general trip detection, minimising the delay between data generation and consumption is crucial. It is essential to ensure that data updates are not missed, allowing the recreation of the complete history of location changes.

Vehicle Health & Maintenance offer numerous ways to utilise vehicle data. If the current condition of a car needs to be checked, a one-time data request is sufficient. However, for dynamic reactions to dashboard lights, tire pressure losses, or overdue maintenance, real-time data consumption is best. On the other hand, when detecting statistical and analytical correlations, such as for predictive maintenance, a continuous data stream is ideal. In such use cases, the delay between data generation and storage is typically less critical compared to other scenarios.

Matching use cases and technologies

When a snapshot of data is needed, such as for retrieving the current mileage for PAYD, billing automation, mileage fraud detection, or checking the car's maintenance condition, the REST or GraphQL API should be utilised. The REST API allows data to be requested on-demand, providing the latest known state of all data points. The data values are accompanied by timestamps that indicate the time of data generation in the vehicle. Furthermore, the REST API can be employed to request additional data following an event received through MQTT or a webhook.

For use cases like charging monitoring, EV route optimisation, trips and location tracking, as well as reacting to changing vehicle health conditions, MQTT is the optimal choice. MQTT is particularly well-suited when it is crucial not to miss any data updates. It ensures that all data point updates are transmitted as soon as they are generated, and data consumers have the flexibility to subscribe to only a subset of the data stream and take further actions based on the incoming events.

When dealing with large data collections required for statistical reports and AI models, such as in the case of predictive maintenance or battery health analytics, AWS S3 buckets are an excellent choice. They provide an ideal solution for building large-scale data collections and utilising vehicle data within the AWS ecosystem.

Testing different approaches in the sandbox environment

Before fully integrating the API, the High Mobility platform offers the convenience of trying out different technologies. The vehicle simulator and console, introduced during the "The one true sandbox for Connected Car Data" session, serve as the core tools within our comprehensive sandbox. To generate vehicle data, our car simulator is available, designed to accommodate brand-specific data sets as well. Data can be updated and accessed through both push and pull technologies, allowing for validation of the chosen approach in a real-life scenario. For this tutorial, it is assumed that you have already added the vehicle to a fleet or completed the B2C consent flow.

REST API: For authentication you can reuse the sample code provided in High Mobility’s GitHub repository and the config which includes the API credentials in the corresponding data container tabs. In order to receive data from the virtual car an access token needs to be requested via the access token endpoint utilising the Auth Token generated in the first step and the VIN of the corresponding car simulator. The access token can then be used to call the vehicle status endpoint which will deliver all data points configured in the associated app container. The Pull request will be automatically logged in the vehicle simulator console, the request and response payload can be inspected in detail. Using the car simulator, data point values can be adjusted and changed by for example manipulating the odometer data point. While the pull request is repeated, it will always result in returning the most recent car data values which are set at the time the request has been performed. Data point updates happening in between the requests will be missed. 

MQTT: For testing our MQTT streaming directly in the console we recommend using Mosquitto and reviewing our Third Open Dev Talk. Certificates can be generated and downloaded in Data Streaming tab of the Data Container. The Mosquitto sub can be connected to our sandbox environment using the endpoint ‘sandbox.mqtt.high-mobility.com’ port 8883. To facilitate testing you can configure a subscription to all topics using ‘sandbox/level13/your-app-id/#’. Whenever data points are changed in the simulator, the updates will be pushed via MQTT. No data updates will be missed and the use of resources will be minimised as long as no new data is generated. An even more convenient way of testing can be achieved with the help of the multi-platform Open Source solution MQTTX. Connection parameters and certificate files can be simply added via the user interface of this free service. Once connected, new subscriptions can be created with help of the topic that has been mentioned before. Incoming messages generated by our simulator will be directly visualised in the UI making it simple to experience the behaviour of our push service. 

S3 Bucket As an no-code alternative to MQTT High Mobility’s platform offers switching the push mode to the AWS S3 bucket integration. While MQTT forwards the data as soon as it is received the S3 bucket will persist all incoming data only every 1000 messages or every five minutes respectively. More detailed information can be retrieved from our documentation and our corresponding Open Dev Talk. After having prepared the AWS S3 configuration, the unique bucket name can be entered directly into the S3 form of our High Mobility console. If the test setup has been run successfully, simulated data can be stored directly into the bucket which is the ideal starting point for large-scale data analytics in the AWS ecosystem.


-------------------------------
High Mobility Open Dev Talks 

At High Mobility, we are passionate about new technology. We offer free open source tools and developer friendly documentation for any projects to be integrated smoothly. More than 800 developers and product managers have already signed up for our moderated community platform and we are hosting connected car competitions for your innovative, connected car ideas. 

Join our community on Slack

Read Next