Today we’re sharing an overview of the Xively platform. Xively is an IoT platform that utilizes the MQTT protocol (Message Queuing Telemetry Transport) to allow devices to communicate in a lightweight and efficient manner. For instance, one might use Xively to connect a network of temperature sensors in a factory. There are a plethora of tutorials and documentation on the Xively site, but today we’ll focus on an overview of the core concepts.

As mentioned, Xively utilizes the MQTT protocol, which uses the publish-subscribe pattern to allow devices to communicate with each other. Devices are represented in the Xively platform as “reflections,” which consist of fields that store device state. Devices in Xively have the default properties listed here, four default custom fields (deviceVersion, location, name, and purchaseDate) and additional custom fields that you define. You can create device templates, devices, users and groups using the Xively web app or using the Xively HTTP API.

The Xively MQTT broker handles communications, allowing devices to publish updates to device state and subscribe to be notified of changes in device state. Devices connect to this broker with device credentials to publish and subscribe. The four default topics for each device in Xively are _set/fields, _updates/fields, _rejected, and _log. The full topic names are set up using the following template:

xi/blue/v1/<accountID>/d/<deviceID>/<topicName>

Publish to the _set/fields topic on a device to change the device reflection. Your message should be in JSON format, with a “state” field in an enclosing JSON object like so:

Subscribe to the _updates/fields topic on a device to receive changes in its reflection. Upon subscribing, you will receive all of the device state in the state JSON object in a message on _updates/fields. After that, changes in state will send only the changed fields in the state JSON object.

Subscribe to the _rejected topic to be notified when an attempted update to the device’s reflection fails.

To connect to the Xively broker, use the Xively device id you would like the connecting client to identify as (there needs to be an existing device in the Xively platform with that ID) as your username and your clientId and use the password for the device in the Xively platform (needs to be generated) as the password. The client will also need the Xively account id to construct topic names. The Xively HTTP API isn’t the focus of this article, but administrative tasks like creating new devices and generating device credentials (as you might do when registering a new device) can be done using that API, which is documented here.

We’re currently in the process of working on a client project that utilizes the Xively platform. We’d love to hear from you if you’ve worked with Xively before! What has your experience been? And if you’re a client looking for support with your IoT solution, be sure to contact us today!