Navixy IoT Gateway supports multiple protocols such as UDP, TCP, HTTP, and MQTT for device-to-server communication. This makes it flexible, capable of working with various types of devices and handling different communication needs.
MQTT (Message Queuing Telemetry Transport): MQTT is a lightweight protocol with a publish/subscribe model. This is particularly useful for IoT devices that need to save power and data. Use MQTT over TLS for secure communication. The JSON formatted data is sent as the payload of MQTT messages.
UDP (User Datagram Protocol): UDP is a connectionless protocol that's well suited for situations where speed is more important than reliability. For instance, a GPS tracker might use UDP to rapidly report position data, even if some packets are lost along the way. You can implement DTLS (Datagram Transport Layer Security) for security. Again, send JSON formatted data in UDP datagrams.
TCP (Transmission Control Protocol): TCP, unlike UDP, is a connection-oriented protocol and guarantees the delivery of packets in the same order they were sent. This is useful for applications where data reliability is crucial, such as dashcam video uploads. Use TCP over TLS for secure communication. JSON formatted data is sent in TCP segments.
HTTP (Hypertext Transfer Protocol): HTTP is a request-response protocol widely used on the Internet. It's well-suited for device-to-server communication when you need to integrate with web-based services or APIs. HTTP inherently supports JSON, making it easy to structure and send data. For secure communication, use HTTPS (HTTP over TLS).
Navixy IoT gateway handles data effectively regardless of the protocol used by providing corresponding endpoints. If you are not sure which works best for your case, we recommend testing network conditions to understand their performance and reliability.
The protocol suite consists of MQTT, UDP, TCP, and HTTP, along with JSON as the data format. Depending on the specific needs of a device or scenario, one or more of these protocols may be used. For example, MQTT might be used for routine status updates from a device, while TCP might be used for uploading larger data files. HTTP could be used for interactions with web-based APIs, and UDP might be used for rapid, real-time data updates where occasional packet loss is acceptable.
This combination of protocols provides a versatile and robust solution for communication between IoT devices and the Navixy server. They allow your system to effectively handle a wide range of data types, transmission speeds, and reliability requirements.
Broker address (Host)
This is the address of the MQTT broker that manages the MQTT communication. Devices will use this address to establish a connection.
The MQTT broker listens on a specific port for incoming connections. Standard MQTT uses port 1883, and MQTT over TLS uses port 8883.
Each MQTT client (device) needs a unique identifier to connect to the broker. The unique identifier (Client ID) is included in the CONNECT packet when the device first attempts to establish a connection with the broker.
Upon receiving a CONNECT packet, the Navixy IoT Gateway will validate and register the client based on this Client ID. If the ID is unique and passes the validation checks, the gateway establishes a session for that client and maintains it for the duration of the connection.
If the MQTT broker is set up to require authentication, these parameters are used by the device to provide a username and password. On the device side, the authentication parameters (username and password) are included in the CONNECT packet alongside the Client ID.
In this example, "DeviceUsername" and "DevicePassword" are the authentication credentials of the device. When the Navixy IoT Gateway receives this CONNECT packet, it will validate the credentials. If the username and password match a valid user in the system, the gateway allows the connection; otherwise, it rejects the connection.
MQTT is based on a publish/subscribe model, and topics are the "channels" that devices publish to or subscribe from. The gateway should provide a way for devices to specify the topic(s) they will publish their data to.
Quality of Service (QoS)
MQTT supports three levels of QoS: 0 (at most once), 1 (at least once), and 2 (exactly once). The Navixy IoT gateway allows the device to specify the QoS level for their messages.
Keep alive Interval
This is the maximum time interval that is permitted to elapse between the point at which a Client finishes transmitting one Control Packet and the point it starts sending the next.
This parameter specifies whether the broker should remember the client's subscriptions and undelivered messages when it disconnects.
This is a message that the broker will publish on behalf of the client if it unexpectedly disconnects.
This feature is particularly useful for monitoring the connection status of clients, as other clients can subscribe to the will message's topic to be notified when a device goes offline.
When the client first establishes the connection with the broker, it includes the Will message in the CONNECT packet. This message includes the topic, the payload, and other properties of the Will message such as QoS (Quality of Service) level and the retain flag.
Server IP address (Host)
The IP address where the Navixy IoT Gateway is running. Devices will use this address to send UDP packets.
The port that the Navixy IoT Gateway is listening to for incoming UDP packets.
Timeout (not supported)
Though UDP is connectionless, a timeout may still be useful to know how long to wait for a response in a request-response model.
Currently, this feature is under consideration and is not yet supported by the Navixy IoT Gateway.
The method used to encode the data as it is sent over the network.
Currently, the data is expected as a UTF-8 encoded string only.
Server IP address (Host)
The IP address where the Navixy IoT Gateway is running. The devices will use this address to establish a TCP connection.
The port that the Navixy IoT Gateway is listening to for incoming TCP connections.
The maximum amount of time the server should wait for a response from a device before closing the connection. This could be set to a default value but could also be adjustable depending on the needs of the application.
A setting to periodically send a message to the device to check if the connection is still active. This can help to detect when a device has disconnected unexpectedly.
The method used to encode the data as it is sent over the network. Currently, the data is expected as a UTF-8 encoded string.
If the data being transmitted is sensitive, you might want to encrypt the TCP connection using SSL or TLS. This requires additional parameters like a certificate and private key.
The HTTP(S) URL that the IoT devices or IoT proxy servers will send their data to. This includes the server address (IP or domain name) and the specific path on the server that will handle the incoming data.
This could be POST, PUT depending on how the devices will be sending data.
Here are simple examples of what a POST and PUT request might look like:
In these examples, the IoT device sends a JSON payload to the Navixy IoT Gateway with either a new GPS location (using POST) or an updated device status (using PUT).
These headers tell the server (in this case, the Navixy IoT Gateway) how to process the request.
In current version of the implementation Navixy IoT Gateway exclusively expects JSON data, this parameter is optional, but recommended for the future compatibility. Then all HTTP requests from IoT devices should include the header
Here is an example of what an HTTP POST request might look like from an IoT device to the Navixy gateway:
In this example, the
Other headers like
If the data being transmitted is sensitive, you might want to use HTTPS (HTTP Secure) which uses SSL/TLS to encrypt the HTTP connection.
To ensure the data is coming from an authenticated device, some form of authentication may be required. This could be Basic Authentication (username and password), Bearer Token, or API key.
You need to specify the structure and format of the payload that devices are expected to send. This could be a JSON object, XML, or another format, depending on the needs of the application.
It the current version of implementation, Navixy IoT Gateway exclusively expects JSON data.
The maximum amount of time the server should wait for a response from a device before closing the connection.