MQTT
MQTT is the most widely used and known protocol for IoT devices. Let's have a basic look at MQTT and how could we use it with IoTIFY
The MQTT protocol is based on TCP and is one the most commonly used publish/subscribe protocol in use today. For a detailed overview of MQTT let's refer you to Hivemq tutorial which have covered this subject pretty well
Introducing the MQTT Protocol - MQTT Essentials: Part 1
What you should know about MQTT
  1. 1.
    MQTT requires that all client connect to a broker. There are several public broker available today and you could launch your own MQTT broker as well.
  2. 2.
    The clients of MQTT publish data on the topics which are hierarchical in the nature. E.g. A topic could be formed for a university as follows:
  3. 3.
    MQTT protocol provides three quality of service namely
    1. 1.
      QoS 0:
    2. 2.
      QoS 1:
    3. 3.
      QoS 2:

Overview of MQTT Template Settings

Snapshot of MQTT settings in Template page
In the template settings, you could modify several settings of the MQTT Protocol:
Endpoint URL: The name or IP address of the server along with port number. It must be a public server IP address which is reachable over the internet.
KeepAlive: The keepalive timer duration for the protocol. The hello message is sent every keepalive interval to make sure server is aware of the client being connected.
Topic: The topic on which messages should be published. The topic field is scriptable, i.e. you could use template strings in Topic to dynamically change the content of the topic. E.g.
1
/iotify/temperature/{{client()}} // will translate to /iotify/temperature/0
Copied!
Any field within {{ }} will be evaluated at runtime and will be replaced with the actual contents. E.g.
1
/iotify/temperature/{{state.topic}}
Copied!
Will change to whatever state.topic variable value is at the run time.
For performance reasons, make sure that the fields are not too complex.
QoS: QoS settings ensures the delivery of message is guaranteed. Higher the QoS Settings, more will be the latency of packet sending as server will need to ensure that the messages are delivered with guarantee.
Retain: Whether the server should retain the messages for a future delivery.
Subscribe: The topic at which the client should subscribe to. This field is scriptable but only at the beginning of the simulation (past the setup function). E.g. if you use {{state.topic}} within the subscribe string, the subscription will be initialized to whatever value the topic had past the setup function. However, the content will not change as the simulation runs.
Client Id: The client ID string which will be known at the server. It is always a good idea to use a random client ID for each client as the server may disconnect the older client, if a new client connects with the same ID.
Timeout: The timeout value to establish a connected with the server and wait for message to be sent. If the operation doesn't complete within the timeout period, it is marked as failed.
Last modified 1yr ago