This section explains how devices can use the HTTP bridge to communicate with Cloud IoT Core. For general information about HTTP and MQTT, see Protocols.
Be sure to refer to the API documentation for full details about each method described in this section.
Complete these steps before using the HTTP bridge:
- Set up one or more device registries, including a Cloud Pub/Sub topic for telemetry events
- Create devices
Authenticating devices
Each request to the HTTP bridge must include a JSON Web Token (JWT) in the header.
curl -H 'authorization: Bearer JWT' -H 'cache-control: no-cache' 'https://cloudiotdevice.googleapis.com/v1/projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{device-id}/config?local_version=1'
The full path of the device can end in the device ID or the device numeric ID. See the section on device registration for more information on device identifiers.
Each request must include the JWT, even if you send several requests in quick succession. Cloud IoT Core does not "remember" authentication over the HTTP bridge. For more information about authentication and JWTs, see the sections on device security and device credentials.
Publishing telemetry events
Use the publishEvent
method to publish telemetry events to Cloud IoT Core. Binary payload data must be base64-encoded.
curl -X POST -H 'authorization: Bearer JWT' -H 'content-type: application/json' --data '{"binary_data": "DATA"}' -H 'cache-control: no-cache' 'https://cloudiotdevice.googleapis.com/v1/projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{device-id}:publishEvent'
Telemetry events are forwarded to a Cloud Pub/Sub topic, as specified in
Google Cloud console or with the eventNotificationConfigs[i].pubsubTopicName
field in the device registry resource. The publishEvent
method provides an
optional subFolder
field for classifying telemetry events. To learn how to
publish data from subfolders to separate Pub/Sub topics, see the
section below.
Publishing telemetry events to separate Pub/Sub topics
Devices can publish data to separate Pub/Sub topics by specifying a subfolder
in the subFolder
field in the publishEvent
method.
curl -X POST -H 'authorization: Bearer JWT' -H 'content-type: application/json' --data '{"binary_data": "DATA", "sub_folder": "SUBFOLDER"}' -H 'cache-control: no-cache' 'https://cloudiotdevice.googleapis.com/v1/projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{device-id}:publishEvent'
This subfolder must be
configured in the device registry resource's eventNotificationConfigs.subfolderMatches
field with a matching Pub/Sub topic in the eventNotificationConfigs.pubsubTopicName
field. When data is sent to a subfolder, it is published to the subfolder's
matching Pub/Sub topic.
As detailed in Creating a device registry, all device registries should have one default Pub/Sub topic with no matching subfolder. If a default Pub/Sub topic exists, devices automatically publish to it in the following cases:
- No subfolder is specified in the
subFolder
field - A subfolder is specified in the
subFolder
field, but it doesn't have a matching Pub/Sub topic in the device registry
In each of these cases, if no default Pub/Sub topic exists, data sent from the device will be lost.
Excessive load and exponential backoff
Cloud 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 are strongly encouraged to implement a truncated exponential backoff algorithm with introduced jitter.
Configuring devices
You can use Cloud IoT Core to configure devices. A device configuration consists of binary data that can be used to update firmware, reboot a device, turn on a feature, or change other properties.
To configure a device using the HTTP bridge, first define the configuration in Cloud IoT Core, then request the configuration via the device.
Compressing HTTP requests
A device can send gzip-compressed data to Cloud IoT Core over the HTTP
bridge. To send compressed data to Cloud IoT Core, each HTTP request
must include the content-encoding: gzip
HTTP header.
Compressing data lets you reduce bandwidth in the device-to-cloud direction. However, you cannot reduce the total cost of your Cloud IoT Core usage by compressing data. For details, see Pricing.
Updating device configuration
When using the HTTP bridge, the device must explicitly request device configurations with the API. Cloud IoT Core does not push configurations to devices over the HTTP bridge; instead, devices must poll for new configurations.
To get the device configuration that's currently available from Cloud IoT Core, use a getConfig
request.
curl -H 'authorization: Bearer JWT' -H 'cache-control: no-cache' 'https://cloudiotdevice.googleapis.com/v1/projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{deviceid}/config?local_version=0'
You can use the localVersion
query parameter to specify the configuration version that's currently on the device. The following table shows how this parameter affects the response:
Device version | API response |
---|---|
localVersion is 0 (default value) |
Most recent version from Cloud IoT Core |
localVersion is nonzero and equal to the version currently available from Cloud IoT Core |
OK (with empty configuration in the binary_data field) |
localVersion is nonzero and older (lower than) the version currently available from Cloud IoT Core |
Current (newer) version from Cloud IoT Core |
localVersion is nonzero and newer (higher than) the version currently available from Cloud IoT Core |
OUT_OF_RANGE error |
Setting device state
Use a setState
request to report device state to Cloud IoT Core. State data must be base64-encoded.
curl -X POST -H 'authorization: Bearer JWT' -H 'content-type: application/json' --data '{"state": {"binary_data": "DATA"}}' -H 'cache-control: no-cache' 'https://cloudiotdevice.googleapis.com/v1/projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{deviceid}:setState'
To retrieve device state data, view the device details in Cloud console or use the API. For more details, see the section on device state.