Getting device state

With ClearBlade IoT Core, you can monitor each connected device’s state. The device reports it as binary data. Device state updates are typically triggered by a device change — a configuration update from ClearBlade 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 ClearBlade IoT Core. The device sends state data to ClearBlade IoT Core. Configuration is an external instruction, and state is an internal representation.

ClearBlade IoT Core can help you answer configuration and state questions: What does the device think it should be doing? How does that compare to the most recent device configuration?

Limits

State updates are limited to 1 update per second per device. However, for best results, the device state should be updated much less often — at most, once every 10 seconds.

Reporting device state

MQTT bridge

To report the state to ClearBlade 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 the state to ClearBlade IoT Core through the HTTP bridge, devices should use a setState request. The binary state data is passed in the request’s body 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 reported to ClearBlade IoT Core by devices (devices 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 Boolean that enables or disables cooling:

{
  '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:

{
  'fan1_target_rpm': 1000,
  'fan2_target_rpm': 1200,
  'firmware_version': '1.2.3b'}

The device's firmware_version is unrelated to the configuration data but returns its state's full internal representation. This example illustrates how the device state can help debug and confirm that devices have acknowledged specific configurations.

Retrieving the device state from a device registry code examples

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 specify a state notification Cloud Pub/Sub topic when creating or updating a registry.

Node.js

// const cloudRegion = 'us-central1';
// const deviceId = 'my-device';
// const projectId = 'adjective-noun-123';
// const registryId = 'my-registry';
import { DeviceManagerClient } from '@clearblade/iot';
const iotClient = new DeviceManagerClient({
  // optional auth parameters.
});

async function listDeviceStates() {
  const devicePath = iotClient.devicePath(projectId, cloudRegion, registryId, deviceId);

  const [response] = await iotClient.listDeviceStates({ name: devicePath });
  const states = response.deviceStates;
  if (states.length === 0) {
    console.log(`No States for device: ${deviceId}`);
  } else {
    console.log(`States for device: ${deviceId}`);
  }

  for (let i = 0; i < states.length; i++) {
    const state = states[i];
    console.log('State:', state, '\nData:\n', state.binaryData.toString('utf8'));
  }
}

listDeviceStates();

ClearBlade IoT Core