about 12 years ago
Kickoff Summary, and other offerings!
Read the notes here from our Kickoff session at the Dallas Makerspace this past Sunday! This summarizes our discussion of application ideas, protocols to use, available hardware, emergency procedures, and three very important reminders:
- Keep it simple!
- Stay within the legal operating limits when broadcasting in areas of the RF spectrum requiring a license!
- Remember, submissions are due on May 4 at the judging place & time! All are welcome to submit and attend judging.
We have antennas to loan to those looking to provide RF offerings or expand the range of a device that uses a less powerful antenna. Remember that government regulations may prevent you from using detachable antennas or antennas with gain in some applications. Nevertheless, we have:
- 4x MMCX-ternimated wifi antennas
- 2x SMA wifi antennas
- 1x MS-151 to SMA converter
- 1x MS-156 to SMA converter
Dave Josephsen, Developer Evangelist at Librato, has come forward to offer us developer accounts for anyone interested in using their time-series data collection, display, and dashboarding service. Dave is also local, and has graciously offered to be available for assistance in case we need help using the service. They might also be willing to fork over some money to reward a compelling application!
On a similar note, Joe Bossalini of AT&T just gave a presentation on their M2M offering, the AT&T M2X API. This could be useful for collecting all sorts of data from an army of devices and sensors, and the presentation really cleared up how to get started using it. Unfortunately, I didn't think of it until about 10 minutes after it started; definitely not enough time to get the word out! The recording of this presentation won't be available for another week or so, thus I took some notes to share with participants. See them below!
Site: http://m2x.att.com
Sign up for a free account. Developer accounts will be created later. The "free" account remains free for 1 year.
First-time users will be offered a Getting Started tutorial. You need to set up a "Blueprint" and "Streams" to start collecting data. The blueprint is a template where you can assign attributes such as strams, triggers, location information, and metadata.
Your Blueprints are associated with prototype data sources. It's a 1:1 mapping of dataset :: blueprint. When creating a blueprint, provide:
- Name
- Description (optional)
- Visibility -- public (coming soon) or private
Each blueprint access point gets its own API key; the API endpoint helps you access the data. There's also a Master Key that'll help you access data across any & all devices.
Before pushing data in, define the data points the device will be collecting. For this, you will add a Stream with "Add Stream." Provide:
- Stream ID (such as "Temperature from Arduino")
- Units & symbols (optional -- such as degree Fahrenheit, ^F)
- Log an initial value (optional)
There are no limits to the number of streams; you might want to create one stream per sensor located on your device. However, you're limited to one device per blueprint; for each device you deploy, there's one data source that goes along with it. The service needs to know how to distinguish which device the data comes from (usually you don't just want a pile of data going into one pot).
The streams log time-series data. All data points will have a timestamp added by the server, or you can provide your own timestamp to pass in historical data.
The "API Cheatsheet" page gives you pre-populated curl commands you can use to experiment with manipulating your device. Important note: any action you do on the Web interface can be replicated using API calls. The Website UI is simply a front-end for the API itself.
http://m2x.att.com/developer/client-libraries features code allowing you to write software clients in C, Java, .NET, etc., plus hardware-oriented libraries like Android, Arduino, BeagleBone, Electric Imp, iOS, mbed, and Raspberry Pi. Third are Community Libraries for languages you want that aren't supported yet by AT&T -- the one now is "Go." The links there direct you to GitHub code with comprehensive README files so you can get up & running quickly.
On an Arduino, you'll need the jsonlite library plus the M2XStreamClient library. The M2XStreamClient comes with plenty of simple Arduino sketch examples, including constantly posting data it reads from the attached circuit.
The heart of the Arduino example is the call to m2xClient.post(feedId, streamName, dataPoint).
The data "Stream" on the AT&T M2X API Web view will update live as the data is sent to it.
You can add additional API keys to share the data with certain people/robots, and select what permissions and stream(s) they have access to. The Expiry Date will give them access until that specified date, or if unset, until you revoke that key. These extra keys have "Edit", "Regenerate", and "Delete" options.
Add a Location to your device by searching for it in the GUI if it's static, or you can have your device send in its own location data.
Triggers:
Trigger features let you evaluate the data and perform actions on it in real-time. For this, you need:
- Trigger name
- Stream
- Condition
- Threshold value
- Callback URL - this will send an HTTP POST request when the condition has been met. The POST contains a JSON payload describing the trigger, the device that fired the trigger, and providing the actual value that triggered the condition.
So now that you have your template & done your prototype, you ned to move into the "LAUNCH" phase. This is where you can create multiple instances of the device so you can scale and add multiple devices with all their associated sensors. When you LAUNCH, this launches a "Data Source Batch" -- a grouping of data sources that uses a particular blueprint as a template.
- Batch Name
- Batch Description (optional)
- Visibility (private or public) -- do you need an API key or not
- Data source Blueprint -- shows all the associated streams.
Once your batch is created with this process, it only created a template and ID. Now you need to add data sources. You can add programmatically through the API, or you can go through the Developer Portal website. Provide a serial number that relates to a physical device with its physical serial number that describes its uniqueness. So if you do have devices that you'll be granting serial numbers, why not use their serial number as the data source ID?
Session Q&A:
All devices with any sort of IP-based connectivity are supported. It doesn't have to be a pure device; it can be an application running on a PC, server, or mobile device.
Enhancements down the road will allow for API keys for batches so that if you have multiple customers that each have multiple instances of your product, you can batch API keys pertaining to specific devices for each client.
There will be a recording of this presentation at developer.att.com in about a week.
One device per Blueprint or multiple devices per Blueprint? You could configure a blueprint to accept data from multiple devices.
Can device/Blueprints be aggregated -- say, individual devices in the same room being treated as a set of incoming data? Yes, that is possible. Most likely, a single blueprint with one or more streams per device would be the simplest approach.
Your device can push multiple data points with one single API call, and then pull data back out from the M2X data store (such as the last data point or w/e).
Can you do pulls to the server-side as well as the pushes you've described? Yes, the API can be used to pull data as well.
Command-control functionalities are coming soon.
Device streams can, of course, be added in real-time -- all the actions you do in the developer portal get sent to the API back-end to get executed there. The "PUT" command will facilitate this.
The development backlog contains an item to make the feature that'll allow users to visualize multiple streams on the same screen/graph.
Email developer.program@att.com if you have additional questions.