With Cloud IoT Core, you can monitor the state of each connected device. State is reported by the device as binary data. Device state updates are typically triggered by a change to the device — either a configuration update from Cloud IoT Core, or a similar change from another external source, such as a firmware update.
Device state differs from device configuration. Configuration data is sent to the device from Cloud IoT Core. State data is sent by the device to Cloud IoT Core. You might think of configuration as an external instruction, and of state as an internal representation.
Cloud IoT Core can help you answer basic questions about configuration and state: What does the device currently "think" it should be doing? How does that compare to the most recent configuration for the device?
Limits
State updates are limited to 1 update per second, per device. However, for best results, device state should be updated much less often — at most, once every 10 seconds.
The update rate is calculated as the time between the most recent server acknowledgment and the next update request.
Reporting device state
MQTT bridge
To report state to Cloud IoT Core through the MQTT bridge, publish messages to the /devices/DEVICE_ID/state
MQTT topic. You can select a Cloud Pub/Sub topic to store state events when you create or update a registry.
For more details, see Publishing over the MQTT bridge.
HTTP bridge
To report state to Cloud IoT Core through the HTTP bridge, devices should use a setState
request. The binary state data is passed in the body of the request as a base64-encoded string.
For more details, see Publishing over the HTTP bridge.
Getting device state data
This section explains how to get the state data that's reported to Cloud IoT Core by devices. (Devices themselves cannot read state data from the cloud.)
State data is returned in binary format. State data may have a different structure than the configuration data that triggers the state change.
For example, suppose you have a device with several fans. Your configuration data might be a JSON object containing a simple Boolean that enables or disables cooling:
Example of configuration data
{
'cooling': true
}
But the device's state data might include diagnostic information, as well as the fan data that you'd expect to see in response to a 'cooling'
change:
Example of state data
{
'fan1_target_rpm': 1000,
'fan2_target_rpm': 1200,
'firmware_version': '1.2.3b'
}
The device's firmware_version
is not related to the configuration data, but the device returns the full internal representation of its state. This example illustrates how device state can be useful for debugging in general, as well as for confirming that devices have acknowledged specific configurations.
You can get device state data using a Cloud Pub/Sub topic, Cloud Platform Console, the Cloud IoT Core API, or gcloud.
Cloud Pub/Sub Topic
Cloud IoT Core retains state data in storage. You can also configure an optional state notification Cloud Pub/Sub topic in each device registry, via Cloud console, gcloud, or the API. This topic can be the same as or different from the telemetry event topic.
State data is published to Cloud Pub/Sub on a best-effort basis: if publication to the topic fails, it will not be retried. If no topic is defined, device state updates are still persisted internally by Cloud IoT Core, but only the last 10 states are retained.
Console
- Go to the Registries page in Google Cloud console.
Click the ID of the registry for the device.
In the registry menu on the left, click Devices.
Click the ID of the device to go to the Device details page.
Click Configuration & state history. Use the checkboxes to display configuration history, state history, or both. By default, both are shown.
- A green checkmark indicates that the device has acknowledged the configuration (MQTT only).
- A yellow warning symbol indicates that the device has not yet acknowledged the configuration (MQTT only).
- Click a row to get the full configuration or state data in JSON, as well as the timestamp and version.
Click Compare to compare the configuration data with the state data. This view can help you debug configurations and, if you are using MQTT, make sure devices have acknowledged specific configuration versions. (The HTTP bridge does not support acknowledgment of configurations.)
gcloud
To get the most recent state messages for a device (up to 10), run the gcloud iot devices states list
command.
gcloud iot devices states list \ --registry=REGISTRY_ID \ --device=DEVICE_ID \ --region=REGION
A state notification Cloud Pub/Sub flag (--state-pubsub-topic
) is available for the gcloud iot registries create
and update
commands:
gcloud iot registries create REGISTRY_ID \ --project=PROJECT_ID \ --region=REGION \ [--event-notification-config=topic=TOPIC,[subfolder=SUBFOLDER] [--event-notification-config=...]] [--state-pubsub-topic=STATE_PUBSUB_TOPIC]
gcloud iot registries update REGISTRY_ID \ --project=PROJECT_ID \ --region=REGION \ [--event-notification-config=topic=TOPIC,[subfolder=SUBFOLDER] [--event-notification-config=...]] [--state-pubsub-topic=STATE_PUBSUB_TOPIC]
API
Use the Device states.list
method to get the most recent device states (up to 10). Each Device
resource has a DeviceState
field that contains the state most recently received from the device. The DeviceRegistry
resource has a StateNotificationConfig
field that can be used to specify a state notification Cloud Pub/Sub topic when creating or updating a registry.
The following sample shows how to retrieve device state from a device registry: