The world of Internet of Things (IoT) is constantly evolving. If you look at just the history of Salesforce demonstrating IoT at Dreamforce, you’ll see a spectrum from simple hobbyist projects (from Arduinos to Makey Makey keyboards) to AI-powered robot arms and entire LEGO cities connected to the cloud.

(Photo credit: @jyoti__gupta on Twitter)

Salesforce recently introduced platform events, which allow Salesforce apps to communicate with IoT devices. Platform events enable the modality of a publication / subscription model for communication with Salesforce. Platform events work directly with a message bus which handles the queue of incoming events and processes listening for them. The bus is designed for highly transactional event messaging as opposed to long-term storage and reporting of records.

Before platform events

To fully appreciate why platform events are useful tools for working with IoT devices, we should look at how things worked before platform events were implemented. At that point, working with IoT and Salesforce was like any other third-party integration — you inserted what you needed via the regular REST API.

So let’s say you wanted to track the state of a fridge. You could create a custom object which describes that fridge: Make, Model, Serial Number, etc. The object could also have fields to track the current state of the fridge: temperature and humidity. To make your fridge smart, you add some Internet connected hardware which can make REST callouts on a frequent basis. Based on an external ID such as the serial number, the callout constantly populates records in the custom object with current temperature and humidity. Within Salesforce, declarative business automation logic is set up to create a case when the recorded temperature and humidity values cross acceptable thresholds.

This setup will completely work. However, it does have a couple of flaws:

1. It ties an IoT device directly to an actual record in Salesforce. This kind of relationship works great for traditional integrations (say, a third-party web service) but is less than ideal for the high-volume, high-latency traffic of IoT. Traditional REST API’s are designed for operations and are not tuned for a constant stream of data, much of which may not even be actionable data.
2. The fact that a device is directly communicating with a record makes it simple, if not attractive, to add record-specific business logic on the device or the device’s integration layer. Logic that resides on the device has to be duplicated across all devices, so that logic is more efficient if centralized close to the record level as possible (in this case the Lightning Platform). It’s easier to maintain a single Process Builder flow or IoT orchestration than hundreds or even millions of devices in the field.

Back to our fridge example, if we create a device which handles not only the transmission of data but business logic as well, that means each device will need to be to be updated for any fixes or changes to the logic. If it’s only responsible for transmitting sensor readings, it’s unlikely the code will need to be modified down the road. With platform events, we’ve reduced the task to one simple thing: convert sensor readings into a message.

From custom objects to platform events

Creating a platform event is similar to creating a custom object definition. There are some important distinctions:

1. They are not normal records but events recorded to the message bus.
2. You can only use basic types of data (no rich fields like Phone or Geolocation).
3. Aspects of the platform such as Process Builder and IoT Orchestrations can react to the message bus.
4. Platform events can be subscribed in a way similar to the Streaming API.

This falls in line with exactly what we need for an IoT device: sensor data described in a straightforward way which will be sent out repeatedly to an endpoint which applications can react to in near real time.

Getting on board the message bus

If you have an older IoT implementation that hasn’t taken platform events into account, getting on board the message bus would look roughly like the following:

1. Create a platform event which describes the incoming sensor data and a unique identifier.
2. Change your outgoing requests from your IoT layer to match the platform event.
3. Move any remaining business logic to the Lightning Platform. Focus on IoT Explorer to take advantage of its state engine and visualizations.
4. Profit.

Well, I cannot guarantee #4, but it will simplify the code that is required on your device and centralize your reactions to changes in the sensor data to be on the Lightning Platform. This also means that any device capable of doing a platform event callout is instantly IoT enabled on Salesforce. Simplifying the work required on the device layer makes it far easier to get them up and running in the cloud.

Want to check it out yourself? You don’t even need to have any existing hardware — you can try the IoT Explorer Quick Start, which uses a virtual smart thermostat sending platform events out. If that gets you hooked, you can go ahead and make that Smart Fridge using the IoT Integration with Electric Imp project.

About the author

Josh Birk is a Director of Developer Evangelism for Salesforce. Wrangler of strings and sometimes cats, he works out of a small study in Chicago when not heading out to show audiences on a range of topics from Lightning Components to defeating toy zombies with an Amazon Alexa.