🟣
MQTT
Qubitro provides a scalable, distributed, and fully-featured MQTT broker and does support all the behaviors specified in the MQTT v5.0, v3.1.1, and v.3.1 standards.
You can jump to client libraries and examples below if you are familiar with the MQTT libraries.
We strongly recommend using the 8883 port for MQTT over TLS connectivity.
Description | Value |
Host | broker.qubitro.com |
Secure port | 8883 |
Insecure port (for test purpose) | 1883 |
Depending on the client library, a URL format may vary. Check our examples or contact us if you need help with the URL naming convention.
Any MQTT client library that supports username-password authentication can be used to connect Qubitro.
Device ID and Device Token are both unique, generated automatically, and located under the device settings tab in Qubitro Portal.
Value Name | Qubitro Equivalent |
Username | Device ID |
Password | Device Token |
Qubitro offers customized MQTT libraries for some languages and platforms in which username and password methods are replaced with proper method names.
Example: See Ruby client.
The client identifier (Client ID) identifies each MQTT client that connects to an MQTT broker.
Qubitro does not manage client IDs internally therefore client ID must be set with the same value as the device ID.
Value Name | Qubitro Equivalent |
Client ID | Device ID |
The MQTT specification describes three Quality of Service (QoS) levels. Qubitro has support for all QoS options ,but the default options are always 0 unless specified during the connection.
Value Name | Description |
QoS 0 | Delivered at most once |
QoS 1 | Delivered at least once |
QoS 2 | Delivered exactly once |
Qubitro currently has support for key-value paired JSON objects as the data type. Nested values are not supported yet.
{
"Key1" : "Value1",
"Key2" : true,
"Key3" : 90
...
}
If you have further questions or suggestions, feel free to join
-> Qubitro Community Discord via this invitation link.
👇
Last modified 4mo ago