How to get started with the pioneering functions of MQTT in VT280?

MQTT

The foundation of MQTT

MQTT (Message Queuing Telemetry Transport) is a kind of published/subscribed messaging protocol. The prevalent advantage of MQTT is that it can deliver you with real-time tracking and consistent message services for connecting remote devices with minimal code and limited bandwidth. The MQTT stands for a low-overhead, low-bandwidth instant messaging protocol that makes it more extensively used in the Internet of Things, small devices, and mobile applications.

Executing the MQTT protocol necessitates the client and the server to complete the communication. And furthermore, during the communication process, there are three kinds of identities in the MQTT protocol: Publish, Broke, Subscribe. Among them, the publisher and subscriber of the message are clients, and the message broker is the server.

Messages transmitted by MQTT are divided into two categories: Topic and Payload

(1)Topic- it can be understood as the type of the message. After the subscriber subscribes, it receives the message content of the topic.

(2)Payload- it can be understood as the content of a message, which refers to the content that the subscriber can specifically obtain and further use.

I. Publish/Subscribe Mode

Dissimilar from request/answer this synchronization mode, publish/subscribe mode decouples the relationship between the customer (publisher) and the customer (subscriber). That means there is no direct connection needed between the publisher and the subscriber. Take for an example; if you call a friend, you have to wait until your friend answers the phone before you can start your communication. It is a characteristic synchronous request/answer scenario. But sending mails to your friends is not the same, you can do your own things, friends are free to check emails whenever they can. It is a typical a synchronous publish/subscribe scenario.
(1)Publishers and subscribers do not have to be known to each other as long as they are completely aware about the same message broker.
(2)Publishers and subscribers do not need to interrelate, publishers do not need to wait for subscribers to confirm and cause locks.
(3)Publishers and subscribers do not need to be online at the same time, and they are free to decide when to read messages.

II. Topic

Generally, MQTT categorizes messages by topic. It is fundamentally a UTF-8 string, but multiple hierarchical relationships can be represented by backslashes. Themes do not require to be created and can be used directly.

Same with the case of Subscribers, as they also support the use of wildcards to filter on subscription topics!

Amongst them, + can filter one level, and # can only come into view at the end of the topic indicating the level of filtering at any level. (Note: Publishers are not allowed to publish messages using wildcards).

VT280 Integration Instructions

I.VT280 Subject definition
VT280 defines five subjects. Currently, it is a fixed topic. The definition is grounded on the direction on the device.

• Theme Level: [/direction/device identification number/data type]

• The first level means Publish or Subscribe.

• The second level is the exclusive identifier of the device, which is generally the IMEI.

• The third level is the data type and currently includes four releases and one subscription.

The subject is defined as follows:

Ignition package:/pub/{imei}/poweron [Device-side publishing, server-side subscription]
Real-time data:/pub/{imei}/realtime [Device-side publishing, server-side subscription]
Alarm package: /pub/{imei}/alarm [Device-side publishing, server-side subscription]
Instruction package: /sub/{imei}/command [Device-side publishing, server-side subscription]

Pay load definition
The payload in VT280 is defined by Protocol buffers for easy identification and different data types are distinguished by subject, and the payload format is the same for each type of data. You can use Protocol buffers to directly de-serialize the related data. See the Protocol buffers definition file for data definition.

III. ThinkRace MQTT Server Information

MQTT Sever Address:120.24.83.93

MQTT Port:1883

MQTT TLS Port:8883

User Name:demo

Password:demo

Sample Code:
MQTT has relatively complete library of various languages, the more commonly used Paho library, including the implementation of various languages

PAHO Download Address:http://www.eclipse.org/paho/downloads.php

ProtobufDefinition File

// ThinkRace Connected Vehicle Protocol

// Copyright 2016 ThinkRace. All rights reserved.

//

// Protocol definition files using Protocol Buffers – – Google’s data interchange format

//

syntax = “proto3”;

package ThinkRace.Cvp;

option csharp_namespace = “ThinkRace.v1”;

option cc_enable_arenas = true;

option objc_class_prefix = “ThinkRaceCvp”;

// import proto definitions from google.protobuf package

// Issue #2575 in protobuf (https://github.com/google/protobuf/issues/2575)

// need to have google/protobuf as path for importing well-known types

import “google/protobuf/timestamp.proto”;

/////////////////////////////////////////////////////////////

//

// [START AlertDataReading_Definition]

//

message AlertDataReading {

// Timestamp of message creation.

// Using Timestamp type from protobuf:

// See https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#timestamp

// Timestamp represents point in time independent of any timezone or calendar,

// represented as seconds and fractions of seconds at nanosecond resolution in UTC Epoch time.

// Range is from 0001-01-01T00:00:00Z to 9999-12-31T23:59:59.999999999Z.

// By restricting to that range, we ensure that we can convert to and from RFC 3339 date strings.

// See https://tools.ietf.org/html/rfc3339

google.protobuf.Timestamp timestamp = 1 [json_name = “ts”];//Timestamps

uint32 alertType = 2; //charging circuit is abnormal 1;shock 2;trailer 3;

float gpslat = 3;//latitude

float gpslong = 4;//longitude

float gpsrspeed = 5;//Speed kilometers per hour

float gpsangle = 6;//Orbit mode angle, north is 0

uint32 tripId = 7; //Travel ID

}

//

//// [END AlertDataReading_Definition]

////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////

//

// [START PoweroffDataReading_Definition]

//

message PoweroffDataReading {

// Timestamp of message creation.

// Using Timestamp type from protobuf:

// See https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#timestamp

// Timestamp represents point in time independent of any timezone or calendar,

// represented as seconds and fractions of seconds at nanosecond resolution in UTC Epoch time.

// Range is from 0001-01-01T00:00:00Z to 9999-12-31T23:59:59.999999999Z.

// By restricting to that range, we ensure that we can convert to and from RFC 3339 date strings.

// See https://tools.ietf.org/html/rfc3339

google.protobuf.Timestamp timestamp = 1 [json_name = “ts”];//Timestamps

float gpslat = 2;//latitude

float gpslong = 3;//longitude

float gpsrspeed = 4;//Speed kilometers per hour

float gpsangle = 5;//Orbit mode angle, north is 0

uint32 satInView = 6;//Number of satellites in use

uint32 gsmsignal = 7;//gsmSignal quality

uint32 maxrpm = 8; //Maximum engine speed

uint32 minrpm = 9; //Minimum transmitter speed

uint32 maxspd = 10; //Maximum speed (km/h)

uint32 avgspd = 11; //Average speed (km/h)

uint32 maxacl = 12; //Maximum acceleration(km/h)This is the maximum difference in speed between two seconds

float mile = 13;//The mileage (km)

float fuel = 14; //The fuel consumption (L)

float miles = 15; //Total mileage (km)

float fules = 16; //Accumulated total fuel consumption (L)

float times = 17; //Driving time (H)

uint32 starts = 18; //Driving time(H)

uint32 brakes = 19; //Number of brakes

uint32 racls = 21; //Number of rapid acceleration

uint32 power = 22; //Current status of the car (1: running 0: flameout)

uint32 tripId = 23; //Travel ID

}

//

//// [END PoweroffDataReading_Definition]

////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////

//

// [START PoweronDataReading_Definition]

//

message PoweronDataReading {

// Timestamp of message creation.

// Using Timestamp type from protobuf:

// See https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#timestamp

// Timestamp represents point in time independent of any timezone or calendar,

// represented as seconds and fractions of seconds at nanosecond resolution in UTC Epoch time.

// Range is from 0001-01-01T00:00:00Z to 9999-12-31T23:59:59.999999999Z.

// By restricting to that range, we ensure that we can convert to and from RFC 3339 date strings.

// See https://tools.ietf.org/html/rfc3339

google.protobuf.Timestamp timestamp = 1 [json_name = “ts”];//Timestamps

float gpslat = 2;//latitude

float gpslong = 3;//longitude

float gpsrspeed = 4;//Speed kilometers per hour

float gpsangle = 5;//Orbit mode angle, north is 0

uint32 satInView = 6;//Number of satellites in use

uint32 gsmsignal = 7;//gsm signal quality

uint32 tripId = 8; //Travel ID

}

//

//// [END PoweronDataReading_Definition]

////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////

//

// [START RealtimePayload_Definition]

//

message RealtimePayload {

repeated RealtimeDataReading measures = 1 [json_name = “measures”];

}

//

//// [END RealtimePayload_Definition]

////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////

//

// [START RealtimeDataReading_Definition]

//

message RealtimeDataReading {

// Timestamp of message creation.

// Using Timestamp type from protobuf:

// See https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#timestamp

// Timestamp represents point in time independent of any timezone or calendar,

// represented as seconds and fractions of seconds at nanosecond resolution in UTC Epoch time.

// Range is from 0001-01-01T00:00:00Z to 9999-12-31T23:59:59.999999999Z.

// By restricting to that range, we ensure that we can convert to and from RFC 3339 date strings.

// See https://tools.ietf.org/html/rfc3339

google.protobuf.Timestamp timestamp = 1 [json_name = “ts”];//Timestamps

float gpslat = 2;//latitude

float gpslong = 3;//longitude

float gpsrspeed = 4;//Speed kilometers per hour

float gpsangle = 5;//Orbit mode angle, north is 0

uint32 satInView = 6;//Number of satellites in use

uint32 gsmsignal = 7;//gsm signal quality

float batteryvoltage = 8;//Battery voltage

uint32 enginerpm = 9;//Engine speed

uint32 vehiclespeed = 10;//Speed

float absolutethrottleposition = 11;//Absolute throttle door opening

float engineload = 12;//Engine load

uint32 coolanttemperature = 13;//Coolant temperature

float remainingoil = 14;//Remaining oil

float instantaneousfuelconsumption = 15; //Unit L/100KM(Instantaneous fuel consumption,This is 0 when the speed is 0)XM

float idlespeedfuelconsumption = 16; //Unit L/H (Instantaneous fuel consumption)XH

float especialfuelconsumption = 17; //Instantaneous fuel consumption value Y needs to be multiplied by the displacement of the current vehicle。 YM

float especialidlespeedfuelconsumption = 19; /// Unit L/H (instantaneous fuel consumption) Y needs to be multiplied by the displacement of the current vehicle. YH

uint32 totalmileage = 20; //The mileage (meters)

float totalfuels = 21; //The amount of fuel used for this trip (l)

uint32 totaltimes = 22; //Travel time (seconds)

uint32 acuteaccelerationtimes = 23;//Number of Rapid acceleration

uint32 brakingtimes = 24;//Number of brakes

float accel_x = 25;//X-axis acceleration

float accel_y = 26;//Y-axis acceleration

float accel_z = 27;//Z-axis acceleration

string diagnostics = 28;//Error code

uint32 tripId = 29; //Travel ID

}

//

//// [END RealtimeDataReading_Definition]

////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////

//

// [START Command_Definition]

//

message CommandDataReading {

uint32 exportInterval = 1;//Upload frequency changes

uint32 duration = 2;//Frequency change duration

uint32 checkversion = 3;/Query version

}

// Identifies a command response from the vehicle

message CommandResponsePayload {

uint32 errorCode = 1; //Return status

oneof versionProperty {

string version = 2;//Return version

}

}

/////////////////////////////////////////////////////////////////////////////////

//

//// [END Command_Definition]

////////////////////////////////////////////////////////////