Reid Carlberg

Connected Devices, salesforce.com & Other Adventures

Tag Archives: IoT

Access IoT Data in Salesforce using Heroku Connect OData

1

Yesterday I wrote about getting IoT Data into Heroku.  It’s pretty cool, but other than looking at a Heroku PostgreSQL Dataclip, there’s not a lot you can do with the super simple IoT host app I built.  Which made me wonder:

OK, I have the data. Now what?

Well, my usual tool of choice is Force.com, but this kind of high-frequency, low-difference data doesn’t work well when fully imported to that environment. This got me thinking about two relatively new and completely exciting things: Lightning Connect and Heroku Connect External Objects.

Lightning Connect (earlier blog, cool tutorial) is a product that includes external data in Salesforce by reference — the data is accessed via the OData protocol and is never copied into your org.  Hence it does not count against storage limits. Heroku Connect (Pat’s awesome blog) is all about easy data synchronization between Salesforce and a Heroku PostgreSQL database. But Heroku Connect also includes an External Objects (@vzmind‘s awesome blog) option that publishes any Heroku PostgreSQL table you request in OData format.

So, um ….. HOLY SHIT I WONDER IF THIS WILL WORK.

I started by adding the Heroku Connect add-on and then opening it.

heroku addons:add herokuconnect
heroku addons:open herokuconnect

Heroku Connect demo edition is free, which is great, but you’ll need to file a ticket to have External Objects activated. Once that is done it’s super simple. Note: External Objects are activated per app, not per user. If you create a new app, you’ll need to request them again.

Start by creating a connection:

heroku-connect-create-connection

Next initialize your username and password.  These will come to your email.

heroku-connect-start

You’ll now see your OData URL as well as a list of tables you might want to share.  Note that the listing of available tables appears to be an asynchronous process — it takes a minute for them to show up. Grab a cup of coffee. Then check the ones you want to share.

heroku-connect-readings-shared

External Data Source configuration is super easy (with many examples), the only difference here being that the Identity Type is Named Principal and the Authentication Protocol is Password Authentication.  Settings example below based on my setup.

force-external-data-source-with-username-password

And now we have the Heroku Readings object in Salesforce!

heroku-readings-in-salesforce

Which is super cool.  But we can make it cooler by connecting this IoT data with something meaningful in Salesforce.  For example, a Device record. As long as I have an External ID field on the Device, I can create an Indirect Lookup between that Device and the Heroku Readings by modifying the Reading’s “Device Name” field type.

create-indirect-lookup-between-device-and-data]

And now we have live IoT data meaningfully connected to Salesforce data without importing it and using up storage.

heroku-connect-device-with-data

Which, I gotta say, feels pretty much like a HOLY SHIT moment to me.

Node.js IoT Host on Heroku: The Simplest Thing that Might Possibly Work

3

TL;DR – Look ma — CODE that stores DATA which becomes usable in SALESFORCE via OData.

For the last couple of days, I’ve been talking about some hardware I’ve put together (here and here).  These efforts all come from a pretty simple problem I have:

My house is old, drafty and hard to heat. And I live in Chicago.

This problem is particularly noticeable in January and February, but July and August can be just as bad in the other direction so I need to address it somehow. Ugh.

arduino-then-what

Well, that which can be measured can be improved, right?  So that’s where I’m going to start. Measurement is actually the easy part. Simple Data Recorder handles that.  Where I’ve struggled is figuring out where to put that data which I measure, how to put it there and then what to do with it.  This post covers the first two.

Most of the time, I work on the Force.com side of the Salesforce1 platform.  I’m extremely comfortable in it, but the free Developer Edition will run out of storage very quickly if you start throwing a new record at it every minute or so. Enter the other side of Salesforce1: Heroku.

Naive IoT Host, deployed to Heroku, solves my storage problem. I’m using the free tier of everything so far, and should be able to for ~20 days at my current rate of data production. You can see a live dataclip of conditions in my house right now should you be interested. If you’ve even glanced at the code, you know it won’t scale to 100,000 devices any time soon.  But it will do a couple of dozen just fine, and that’s just the scale I need for this experiment.

The high level end to end looks something like this:

arduino-rpi-heroku-nodejs-postgresEverything starts out on the Arduinos.  The Raspberry Pi polls the Arduinos for data, transforms that data into JSON, and then posts that to a Node.js app running on Heroku. The Node.js app augments that data with current weather conditions and then writes it to a PostgreSQL table.  I have it set to do this about every 5 minutes.

The basic Node.js app is built using Express, but I haven’t spent any significant time optimizing it.

I’m using ipfilter to ensure that only someone from a whitelisted IP address can make a request on the app.  If you aren’t calling from some recognized IP, you get an “unauthorized” response.

wtf-sql

Sequelize coordinates the database activities.  For some reason I didn’t look at ORM when I wrote that tweet a couple of months ago. Sequelize isn’t perfect, but it’s super fast as a getting started tool, and it’s way better than anything I might write.  You start by declaring a model, which it then automatically creates for you in the actual database.  It doesn’t do database modifications as far as I can tell — there’s some kind of a separate module for that which I haven’t investigated yet.

var Reading = sequelize.define('Reading', {
	deviceName: Sequelize.STRING,
	rangeStartDate: Sequelize.DATE,
	rangeEndDate: Sequelize.DATE,
	maxBrightness: Sequelize.INTEGER,
	minBrightness: Sequelize.INTEGER,
	maxTemperature: Sequelize.DECIMAL(4,2),
	minTemperature: Sequelize.DECIMAL(4,2),
	weatherSummary : Sequelize.STRING,
	weatherTemperature: Sequelize.DECIMAL(4,2),
	weatherWindSpeed: Sequelize.DECIMAL(4,2),
	weatherWindBearing: Sequelize.INTEGER
});

Lastly, the Forecast module connects me to Forecast.io to get the current outside weather conditions.  I thought this would be useful information to keep in mind as I start to look at the data. Now, I could have chosen to work with current-condition-then data in a number of ways, including querying for it analysis time (whenever that turns out to be), but the incremental cost of including it with each reading was so trivial I decided to do it.

And voila — for your enjoyment — the data.

OK, so far so good.

Next: Accessing the data in Salesforce using Heroku Connect External Objects OData

Connect I2C Devices Using Cat5 and RJ45 Ports

1

The other day I shared my approach to reading data off a couple Arduinos with a Raspberry Pi using I2C and Node.js. Works great, but the wiring was ugly and brittle.2arduinos1pi

Mess or not, the wiring did teach me two things: I2C works as long as there is conductivity and yes you can power a couple of Arduinos from the RPi. I2C doesn’t require a particular wiring sequence or whole bunch of cables extending from a central point to a single device, so when I decided to beef it up a bit, I started to imagine a way of connecting devices over a small distance. I was hopeful it would be easy and not require 100% custom wiring. The requirements boiled down to something like this:

raspberry pi arduino i2c

I decided to look for a solution built around Cat5 cable — it’s cheap, has great connectors and I’ve worked with it a fair amount. I found it at Microcenter.  I’m using a couple of el cheapo cable splitters and an RJ45 F-F joiner, for most of the connection, and it works great. I still need to solder 1/2 a Cat5 cable for the Raspberry Pi and another 1/2 for each device, but I can now put the Arduinos (somewhat) arbitrarily far away from the RPi node and add more until my power runs out.

raspberry-pi-arduino-i2c-cables

Still not ideal, but like I said it works great.  Although relatively inexpensive, each splitter is about $10, and I could do without stripping the Cat5 wires and soldering them to pins.  Next up I think I’ll add a couple of RJ45 ports to a proto shield, and connect that directly to each Arduino.  I’ll net a little more soldering, but it will be easier soldering so should be faster.

Here’s what the current system actually looks like in my attic.  Note that the Arduino and RPi are far enough away that it’s impractical to photograph them together.

raspberry-pi-i2c-cat5-example

Questions I’ve pondered:

Why am I doing this instead of just getting an Arduino with an Ethernet shield?  I’m trying to solve two problems, communication and power.  if I go with the Ethernet shield, I’m in it for $60 each if I include a power over ethernet (POE) module, which is a lot.  It solves the power problem and the connectivity problem, but I still have to wire ethernet.

Why don’t I just go wireless? Well, I could.  In fact, I have a bunch of XBees sitting around from Dreamforce 13 that I could harness.  However, I’d still have to get power to each one of these devices, so I’ve only solved one problem.

How will I scale this beyond my attic? I’ll probably need to scale this to the other floors of my house to get the data I want.  I suspect the easiest way to scale it will be to add a nearly identical system on each floor.  Otherwise I’ll have to deal with stringing wires, and I hate stringing wires.

Five Enterprise Internet of Things (IoT) System Architecture Patterns

3

Updates based on feedback at the bottom.

I’ve said before that all Internet of Things (IoT) projects should start with a great use case that matters. In this post I want to discuss the next logical question: how to architect a system capable of handling the use case. I divide these use case centric IoT deployments into five architectural patterns, and I call them Anonymous, Direct, Buffered, Gateway and Cloudy. I’m going to first introduce a simple metaphor for how to think about IoT systems and then describe these core architectures, discuss their capabilities and limitations and review some interesting variations.

Note that I use Salesforce products here to represent key business systems, but each architecture could be adapted for use with other offerings (although you should really have Salesforce in the mix IMHO).

Also note that these architectures are more about generating actionable insights than they are about managing devices deployed in the field. Great Salesforce partners like Devicify and Cycle30 can help with these issues.

The Metaphor & Key Considerations

The easiest metaphor for a robust Internet of Things system is the nervous system. Signals come in from the extremities, they are processed in the brain, and muscles take action. In an IoT style solution, sensors send signals up the chain, those signals are aggregated and analyzed, and new signals are sent to actuators of some kind. Note that these actuators may be devices, other systems or people.

iot-system-architecture-metaphor

(You might enjoy reading about the nervous system over on Wikipedia, which is also where I found this great image.)

When you’re designing your system, you should consider:

  • Device Sophistication: What is the minimum viable device I can use to gather the signals I’m interested in?
  • Reporting Frequency: How often will that device need to report data in order for me to accurately analyze and understand the conditions I’m interested in?
  • Next Action: Once the information is aggregated and analyzed, what happens next and is it driven by a person or an automated system?
  • Distance: How many steps are there between understanding the need for action and the ability to take action?

A key difference between a standard animal nervous system and a robust IoT system is that the nervous system has private pathways for signals to flow. Most IoT systems will be running on the public Internet, and so will have significant concerns around signal encryption. That is the subject for a different article.

Anonymous

Anonymous implementations take advantage of APIs originally designed for use with basic websites. In the Salesforce world, these would be the Web2Case and Web2Lead APIs. These are incredibly easy to deploy by design, but, also by design, they lack many of the features considered standard in today’s business and IT climate, including authentication that clearly identifies the individual user or device reporting an issue. Example implementation: Create a case in Salesforce with the Staples Easy ButtonDevice sophistication: high. Reporting frequency: very low. Next action: human intervention. Distance: Low.

anonymous-enterprise-iot-architecture-pattern

Direct

The first step above Anonymous is Direct, where the device knows how to authenticate and is powerful enough to communicate securely using standard REST APIs. Direct integrations require standard credentials embedded in each device, and so is generally appropriate for higher order systems and higher value add situations. This architecture isn’t well suited to high volumes of data or transactions, but works great for systems that report, for example, once per day. Example implementation: Control Philips Hue from SalesforceDevice sophistication: high. Reporting frequency: low. Next action: human intervention. Distance: low.

direct-salesforce-enterprise-iot-pattern

Buffered

The Buffered architecture enables systems to communicate at higher transaction volumes without requiring the destination system to be aware of the originating devices in a detailed way. Buffered architectures simplify IoT systems by allowing you to create a custom API and to define your own interaction models. On the Salesforce1 Platform, you can easily create a buffered architecture by combining Heroku services with Force.com services. Heroku would be responsible for device interaction and information aggregation. The system would then sync summarized information to Force.com using Heroku Connect or standard REST APIs. Device sophistication: medium-high.  Reporting frequency: medium. Next action: automatic or human response.  Distance: medium.

buffered-salesforce-enterprise-iot-pattern

Gateway

Gateway architectures allow you to include much lower power devices in your IoT system. These low power devices communicate with a more sophisticated gateway device that is powerful enough to connect with either a custom API built on Heroku or a standard Force.com API. Although I’ve used Bluetooth to represent the low power device, it is not limited to bluetooth. Gateway architectures open your system to a much greater variety of participating devices since the gateway can serve as a broadly capable adapter class. Device sophistication: low for the device, high for the gateway. Reporting frequency: high. Next action: automatic or human response. Distance: high to medium.

gateway-salesforce-enterprise-iot-patterns

Cloudy

Cloudy architectures are interesting because they essentially roll-up functionality starting with the device end of the typical IoT value stream. The core model is to combine a core piece of hardware with Internet connectivity. The connectivity ends in a cloud service, and the cloud service becomes the end point for talking to business systems. This pattern requires a higher level device in the field along with rich connectivity between that device and cloud system. The integration is then cloud to cloud. This is a great way to get started, but, like any tightly coupled design, your ability to change and modify the system is bound to the strengths and limitations of your supplier’s platform. Device sophistication: high.  Reporting frequency: indeterminate.  Next action: automatic or human response. Distance: low to medium.

cloudy-salesforce-enterprise-iot-pattern

Variation #1: Direct (Augmented)

Sometimes you’ll want to interact with Salesforce APIs directly, but you’ll want to augment that interaction with computing resources located on another system, e.g. an app running on Heroku. This is useful when you need processing not typically handled on the Force.com platform, such as image analysis.  In that case, you can easily upload data to Force.com, trigger a Heroku process based on that data, and then complete the interaction by putting the actionable results back in Force.com. Device sophistication: high. Reporting frequency: low. Next action: human response. Distance: medium.

direct-augmented-enterprise-iot-patterns

Variation #2: Buffered by Partners

The Salesforce ecosystem has a rich variety of partners, including several focused on building end-to-end solutions for our customers. One way of deploying a system is to use a partner solution as your aggregation layer, looking something like the picture below. Note that the device below could be replaced by a collection of lower powered devices connecting to a more powerful gateway. Example implementation: Get Started with the Internet of Things in 10 Minutes.  Device sophistication: medium-high. Reporting frequency: medium. Next action: automatic or human response. Distance: medium.

buffered-partner-enterprise-iot-pattern

Variation #3: Double Buffered

It’s also possible to create a double buffered system that puts a partner solution in front of a custom API deployed to Heroku, which then connects to Force.com. This creates a more complicated system, but might be justified by your business case. Device sophistication: medium-high. Reporting frequency: medium. Next action: automatic or human response. Distance: far to medium.double-buffered-enterprise-iot-pattern

Next Steps

I hope this discussion is useful for you.  I’m going to be doing a longer version of this at ThingsExpo in Santa Clara this week (November 6), which also includes some background, use cases and predictions.

If you have comments, I’d love to hear them. If you’re working on an IoT deployment, I’d love to hear about that too.

 

Updates & Feedback

@MJFreshyFresh put together a scatter plot of patterns AND sketched some ideas about how actuators and sensors might have different pathways.  Pretty sweet!

@AliNajefi points out that examples would be helpful, so I’ve added links where I’ve created examples.  Great feedback!

Me, Myself and Dreamforce ’14

0

Last year I attempted to chronicle Every Internet of Things Thing at Dreamforce 2013.  It took me one post (albeit a long one) and I think I caught every session.

2014-09-iot_robot

This year, I ignored everything but my little portion — the DF14 DevZone Internet of Things area — and it still took me three pretty long posts and almost 3000 words.  What a difference a year makes!

So yes, 48 hands on IoT workshops.

28 great IoT partners (yes, we had one join since I wrote the post — Automatic).

12 picture worthy things you can checkout and probably — estimating here — 25 plastic shoe boxes of components you can build stuff with.

And a lot of demos.  Something new every single day of Dreamforce.

Devices, Wearables and Robots — my oh my.  See you there!

40 Wearables in 400 Years (or iWatch, smiWatch)

1

Whether we finally see an iWatch tomorrow or not, all of this frenzy around wearables made me curious what the timeline on the architectural approach looks like. So I did a little research and came up with the following table.  This is incomplete for sure, but I found a few things that surprised and entertained me, so here it is for your enjoyment.  Comments, additions, criticisms all welcome on @ReidCarlberg.

sfdcbloodpressure2

Format: Earliest Date Seen or Announced – Name (Category) – Link for More Information

  • 09/09/2014 – Apple iWatch Maybe (Unknown) – Apple.com
  • 09/07/2014 – Intel / Fossil Smartwatch (UI) – Gizmodo
  • 09/05/2014 – Moto 360 – Watch, Pulse, Steps (UI) – Motorola.com
  • 09/05/2014 – Daqri Smart Helmet (UI) – Daqri.com
  • 09/02/2014 – Samsung Galaxy VR (VR) – Samsung
  • 09/01/2014 – Garmin VivoSmart – Fitness & Notifications (UI) – $170 – Garmin
  • 07/15/2014 – Moov (Performance) – $80 – Moov
  • 07/08/2014 – Pebble Steel Smart Watch (UI) – $230 – Pebble
  • 05/24/2014 – Interaxon Muse Headband (Biometrics ) – Venture Beat
  • 05/08/2014 – Samsung Galaxy Gear 2 Smartwatch (UI) – Samsung
  • 03/31/2014 – Bragi Dash Hearables (UI) – Kickstarter
  • 02/25/2014 – Meta Glasses (UI) – SpaceGlasses.com
  • 01/06/2014 – Garmin Vivofit (Fitness) – $130 – Garmin
  • 12/15/2013 – Misfit Shine (Fitness) – $100 – Misfit
  • 12/07/2013 – Jawbone Up 24 (Fitness) – $120 – Jawbone
  • 12/01/2013 – Thalmic Labs Myo (UI) – $150 – Thalmic Labs
  • 10/16/2013 – Samsung Galaxy Gear Smartwatch (UI) – Samsung
  • 10/10/2013 – Fitbit Force (Fitness) – Wikipedia
  • 09/15/2013 – Emotiv INSIGHT (Biometrics ) – Kickstarter
  • 07/25/2013 – Vuzix M100 (UI) – Vuzix
  • 06/01/2013 – Google Glass (UI) – $1500 – #ifIhadglass
  • 05/09/2013 – Epson Moverio (UI) – Epson
  • 05/07/2013 – BioNym Nymi (Biometrics ) – $80 – GetNymi
  • 05/01/2013 – Fitbit Flex (Fitness) – Wikipedia
  • 11/26/2012 – Jawbone Up (Fitness) – $129 – Amazon
  • 09/17/2012 – Fitbit One (Fitness) – Wikipedia
  • 09/17/2012 – Fitbit Zip (Fitness) – Wikipedia
  • 08/03/2012 – GigaBryte (TinkerTags) (Education) – GigaBryte.com
  • 08/01/2012 – Oculus Rift VR (VR) – OculusRiftVR
  • 07/21/2012 – Emotiv EPOCH (Biometrics ) – Emotive
  • 04/11/2012 – Pebble Watch (Fitness) – $150 – Kickstarter
  • 01/19/2012 – Nike FuelBand (Fitness) – Nike
  • 10/03/2011 – Fitbit Ultra (Fitness) – Wikipedia
  • 09/09/2008 – Fitbit Classic (Fitness) – Wikipedia
  • 01/01/2003 – Garmin Forerunner (Fitness) – Garmin
  • 01/01/2003 – Fossil Wrist PDA (PDA) – $250 – Wikipedia
  • 01/01/1999 – FitSense (Fitness) – FitSense.com
  • 01/01/1983 – Casio Databank CD-40 (PDA) – Wikipedia
  • 01/01/1982 – Pulsar Calculator / Data Watch (PDA) – Wikipedia
  • 01/01/1600 – Abacus On a Ring (Math) – Wikipedia

Note: when a month or date wasn’t readily available, I simply assumed the first of the month or the first of the year.

Thanks Etherios for the great picture of our Dan Harrison.

littleBits cloudBit Module Review & Salesforce1 Platform Example

0

littleBits makes it easy for people to experiment and play with a variety of DIY electrical components. It’s fun and easy, and yesterday they made it even better by introducing the littleBits cloudBit.

The cloudBit is a unique and powerful way anyone can create fun Internet of Things style solutions for whatever is important to them.  Today, I’m going to create a fun alert that fires when new Leads are added to Salesforce.

Let’s take a look at the bit itself.  It has the same basic architecture as other bits — magnetic connectors on both sides with a direction indicator — and then a USB wifi connector on the front and a 4GB micro SD card on the back containing Linux.

Yes, that’s right, Linux. In fact, as the description notes, “The cloudBit is a single board computer running Linux.”  Later they also note, “We’ve left pads on the bottom of the board so that you can connect to the cloudBit’s serial console using 3.3V UART (8-N-1, 115,200 baud) and poke around.”  OK, that’s now on my //TODO list.

Front:

20140724-104014-38414493.jpg

Back:

20140724-104013-38413677.jpg

 

Configuring the WiFi is pretty easy. When you first power on your cloudBit, it creates a new hotspot. You connect to that hotspot, and then configure it to connect to whatever your local setup is. This is a familiar pattern for a lot of new connected devices, so you’ll probably find it easy.  Once you’ve configured it, the basic operation is pretty simple, as I demonstrate in the video below.

Ok those are the basics. So, you might be asking, what can you do with it?

Quite a bit as it turns out.  I like to create fun things in Salesforce, so I decided to create a real world alert that tells me when a new Lead is added to the system.  I did this using a cloudBit, Twilio and LEGO. Check out this video for a demo and an explanation.

There you have it.  There’s really no meaningful code required, it’s mostly done with a few clicks.  If you’d like to try it yourself, you can get a littleBits cloudBit for $59 and try out the Twilio Salesforce integration for free.

 

 

%d bloggers like this: