Atlas of The Internet of Things

[rjcorwin]

One of us:

Hi. We're making it easier to connect that thing to the other thing that sometimes goes through this thing over there but can also go through that thing way up there.

Someone else:

Uuuuuuh... What? #fail

So ya, let's make an Atlas so we don't confuse people like that. It might even help us in our own discussions amongst ourselves. Here's my chicken scratch with missing labels and probably a lot of missing other things, but it's a place to start!

Thoughts on pushing this forward, perhaps we transfer this chicken scratch into something more legible like this Google Drawing and then when we feel like we have it the Atlas fairly nailed down, someone with real art skillz like Don draws it by hand.

[rjcorwin]

To add: Mailperson method

A device carried by a drone or person that travels around picking up messages from nearby remotes, wirelessly or wired, and then does something with that message. This could even be a person taking an SD Card out of a Mote in the field, transferring the content to another drive, carrying it to a place with Internet access and then uploading it to a database.

[rjcorwin]

This one doesn't cover the different ways a Device might connect to a Gateway, but I do think this is a vast improvement over my first draft.

This is also a start on how to describe how the IoT is broken. One example might be an example of three different devices, each would send data to their respective Gateway, each would have their own data service, each would be tied to their own App layer (iftt.com kind of an exception here making inroads with doing conditionals for things like the Belkin WeMo switch and Nest). We're solving the Pipe level so all three devices can be piped to the same database and message service... But that does not imply that there is a data layer we can pipe to that there is then an Analysis, Dashboard, and Conditionals App layer that integrates with it. The Data and Apps layer are quite disconnected at the moment. Lets say we wanted to use...

On the data layer...
database: Phant at data.sparkfun.com
Message service: Dweet.io

On the Apps layer...
Analysis: Academic Soil Analysis model
Dashboard: Freeboard.io
Conditionals: iftt.com

The problems with that are...

• Freeboard.io Dashboard can connect to Dweet.io for live data but Freeboard.io can't connect to any database for historical data.
• iftt.com has no conditions for Dweet.io nor any database.
• data.sparkfun.com has a 50mb limit which makes it not practical for long term historical data (unless you poll at really wide intervals)
• Ever heard of an Academic Soil Analysis Model that integrates with any database service other than its own? Analysis Models are way behind the times, folks in the Academic fields have a hard time with concepts like RESTful API and OAuth.

[rjcorwin]

A Google Drawing

[rjcorwin]

ideal:

reality:

[rjcorwin]

I incorporated these images into The OPK Presentation document on Hackpad.