One of the most important pieces in the Miles Platform, in my opinion, will be the endpoints. In the unofficial dictionary for Miles, we're defining endpoints as the entity that connects the automation platform with physical components. Consider the blog post on automating lights, in that design, an endpoint would control the relay that switches the light on and off.


For the first stab at defining an endpoint, we decided to look at the Arduino. To be specific, we're looking at an Arduino Uno with the Ethernet shield. Our goal is to define a core set of capabilities that an endpoint has that can operate over, at minimum, a REST API. From there, an endpoint could define additional capabilities to enhance the features that it offers.

For this example, we'll take a look at endpoint-arduino, which currently supports the most basic of capabilities, writing to and reading from a pin. The REST API for these calls is defined as follows...

HTTP GET    /pin/[PIN NUMBER]/mode/[input,output] -- Set pin mode  
HTTP GET    /pin/[PIN NUMBER] -- Get pin state  
HTTP POST   /pin/[PIN NUMBER] -- Set pin to HIGH  
HTTP DELETE /pin/[PIN NUMBER] -- Set pin to LOW  

(Side-note, I'm still not happy with the pin mode call)

So, four basic calls. Set the pin mode, set the pin to HIGH, set it to LOW, and retrieve it's current state. All commands return JSON in the following format...

    "category": "pin",
    "command": "value",
    "key": 5,
    "success": true,
    "value": 1

So what does this returned JSON tell us? Let's annotate this a bit...

    "category": "pin", (Call made to /pin)
    "command": "value", (Modified or retrieved value of pin)
    "key": 5, (Pin #5)
    "success": true, (The command that was requested completed successfully)
    "value": 1 (Pin #5's value is 1, true, or HIGH, whichever you perfer)

While this definition is a work in progress, I think it's best if this returned set of data is consistent between both endpoints and their special capabilities.

Endpoint-specific Capabilities

In discussions with Mark Kropf, he brings up being able to use SPI. I also have an immediate use for the Virtuabotix DHT11 Temperature and Humidity Sensor which, while it offers a very handy and easy to use library, would be difficult/impossible to operate by reading from and writing to individual pins over HTTP communication. This is our next step of development, where Mark has said he'll be looking at SPI, I'll be adding an interface to the DHT11.