...
ClearBlade IoT Core supports the MQTT protocol by running a managed broker that listens to the port 8883. Port 8883 is the standard TCP port reserved with IANA for secure MQTT connections. Connections to this port must use TLS transport, which is supported by open-source clients like Eclipse Paho.
...
ClearBlade IoT Core does not support QoS 2. Publishing QoS 2 messages closes the connection. Subscribing , and subscribing to a predefined topic with QoS 2 downgrades the QoS level to QoS 1.
...
A
PUBLISHmessage with QoS 1 will be acknowledged by thePUBACKmessage after successfully sending it has been successfully sent to Cloud Pub/Sub.PUBLISHmessages with QoS 0 do not requirePUBACKresponses , and may be dropped if there is any jitter along the message delivery path (for example, if Cloud Pub/Sub is temporarily unavailable).The ClearBlade IoT Core MQTT bridge maintains a small buffer of undelivered messages in order to retry them. If the buffer becomes full, the message with QoS 1 may be dropped, and a
PUBACKmessage will not be sent to the client. The client is expected to resend the message.
...
When QoS is 0, a given configuration version will be published to the device only once. If the device does not receive the configuration, it must resubscribe. A QoS of 0 is thus useful when a configuration is frequently updated (on the order of seconds or minutes), and it's not necessary for the device only needs to receive every updatesome updates.
When QoS is 1, the latest configuration update will be retried until the device acknowledges it with a PUBACK. If a newer configuration is pushed before the older one is acknowledged, the older one will not be redelivered; instead, the new one will be delivered (and redelivered). This level is the safest mode for device configurations: it guarantees that the device will eventually get the latest configuration.
Downloading MQTT server certificates
ClearBlade uses Digicert-based certificates (long-term support, 2031, and 1.3K in size). The minimal root.ca can be found here:
...
The device ID is the string ID of the device specified in the MQTT client ID. The , and the device ID is case-sensitive.
Messages published to this MQTT topic are forwarded to the corresponding registry's default telemetry topic. The default telemetry topic is the Cloud Pub/Sub topic specified in the eventNotificationConfigs[i].pubsubTopicName field in the registry resource. If no default Pub/Sub topic exists, published telemetry data will be lost.
...
Note: If you try to publish a device telemetry event without specifying a Cloud Pub/Sub topic for the device's registry, the MQTT connection closes automatically. To verify why the connection closed, get the device details and check the "lastErrorStatus" field in the response. This applies only to telemetry events, not state data.
...
| Code Block |
|---|
/devices/DEVICE_ID/state |
To categorize and retrieve state messages, configure Configure the registry with a device state topic to categorize and retrieve state messages. The device state topic is the Cloud Pub/Sub topic specified in the StateNotificationConfig.pubsubTopicName field. If the registry is configured with a device state topic, these messages are forwarded to the matching Cloud Pub/Sub topic on a best-effort basis.
...
ClearBlade IoT Core limits projects that generate excessive load. When devices retry failed operations without waiting, they can trigger limits that affect all devices in the same Google Cloud project.
For retries, you You are strongly encouraged to implement a truncated exponential backoff algorithm with introduced jitter for retries.
Keep-alive
When sending the a client’s initial MQTT CONNECT message from a client, you can supply an optional " keep-alive " value. This value is a time interval, measured in seconds, during which the broker expects a client to send a message, such as a PUBLISH message. If no message is sent from the client to the broker during the interval, the broker automatically closes the connection. Note that the keep-alive value you specify is multiplied by 1.5, so setting a 10-minute keep-alive actually results in a 15 minute interval.
...
For best results, set the client's keep-alive interval to a minimum of 60 seconds. Many open-source client libraries, including the Paho MQTT libraries for C, Python, Node.js, and Java, use 60 seconds by default.
...