...
If port 8883 is blocked by your firewall, you can also use port 443.
Note: The MQTT standard is defined for implementing a full publish/subscribe broker. However, the managed MQTT bridge run by ClearBlade IoT Core does not support all publish/subscribe operations, such as creating arbitrary topics that devices can use to send messages between them. ( Filtering can be accomplished with downstream processes running on Cloud Pub/Sub. ) ClearBlade IoT Core uses a predefined set of topics and specific topic formats.
...
A
PUBLISHmessage with QoS 1 will be acknowledged by thePUBACKmessage after successfully sending it to Cloud Pub/Sub.PUBLISHmessages with QoS 0 do not requirePUBACKresponses and . They 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.
...
ClearBlade uses Digicert-based certificates (long-term support, 2031, and 1.3K in size). The minimal root.ca can be found here: https://cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem
Configuring MQTT clients
MQTT clients authenticate devices by connecting to the MQTT bridge. To configure an MQTT client to authenticate a device:
...
| Code Block |
|---|
/devices/DEVICE_ID/events
|
The device ID is the string ID of the device specified in the MQTT client ID, and the device ID is case-sensitive.
...
Attribute | Description |
|---|---|
| The user-defined string identifier for the device, for example, |
| The server-generated numeric ID of the device. When you create a device, ClearBlade IoT Core automatically generates the device device’s numeric ID; it's globally unique and not editable. |
| The Google Cloud Platform region of the device registry, for example, |
| The user-defined string identifier for the device registry, for example, |
| The string ID of the cloud project that owns the registry and device. |
| The subfolder can be used as an event category or classification. For MQTT clients, the subfolder is the subtopic after |
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.
...
For example, if the device publishes to the MQTT topic /devices/DEVICE_ID/events/alerts, the subfolder is the string alerts. Messages are forwarded to the additional Cloud Pub/Sub topic if the eventNotificationConfigs[i].subfolderMatches and eventNotificationConfigs[i].pubsubTopicName fields are both set to alerts. Otherwise, messages are forwarded to the default Cloud Pub/Sub topic.
...
Connected devices can report the device state by issuing a PUBLISH message to the following MQTT topic:
| Code Block |
|---|
/devices/DEVICE_ID/state
|
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.
...
You are strongly encouraged to implement a truncated exponential backoff algorithm with introduced jitter for retries.
Keep-alive
When sending a client’s initial MQTT CONNECT message, you You can supply an optional keep-alive value when sending a client’s initial MQTT CONNECT message. 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 more information, see the MQTT specification.
...
ClearBlade IoT Core does not supply its own default keep-alive value; if you choose to specify a keep-alive interval, you must set it in the client.
...
Separate from the keep-alive interval, ClearBlade IoT Core has its own Core’s idle time limit of is 20 minutes. Based on this limit, a client connection will automatically be terminated if the client doesn't send any messages for 20 minutes, even if the keep-alive interval is longer. If a keep-alive value isn't supplied, the default idle timeout of 20 minutes still takes effect.