Electric Imp + Carriots

Hi

There’s a new Alert System saga tutorial in Carriots (How to connect a Electric Imp to Carriots and build an Alert System)

What other examples could be used mixing Electric Imp & Carriots?

Enjoy Carriots!

I’m bringing up an old thread, but I am curious if there is any Carriot objects or code repositories available that might not be published. I’ve used the Carriot platform before on a different hardware system, and would like to use it again with Electric Imp.

Not that I’m aware of…

The tutorial @amendoza linked to shows the basic functionality… if you wrap that up in a class that meets our Style Guide we’ll happily turn it into a library you can require with a line of code :slight_smile:

Carriots is a very good cloud administrative system, as well as a data logger / visualiser / event notifier, due to the way you have to structure a project hierarchy in order to link it to an Imp Agent/Device pairing.

One very useful function is that Carriots allows you to pool multiple Imp agents into one overall project which is dead handy if you have multiple device/agents all within one application (quite useful for version control etc using the Carriots status stream). If you apply the status or data update timeout parameters correctly you can also get a nice overview of which imp device/agent pair is disconnected etc. through your Carriots dashboard.

Once you have set up your Project – Service – Group – Device structure within the Carriots dashboard (or you’ve created this through the API using your keys), you will get different device ID’s (in the format: deviceID@UserName.UserName) for your project. Typically you would want one device ID to match each of your Imp agents. This is what is used to identify where to store the data when the API keys match yours.

Once all that structural set up is sort out, it is relatively straightforward to then send data to Carriots. This is the key code snippet from the above tutorial which you will use:

`
function CarriotsPostHandler(data) {
local url = “https://api.carriots.com/streams/”;
local streamData = { “protocol”: “v2”, “checksum”: “”, “device”: Carriots_Device , “at”: “now”, “data”: data };
local headers = { “carriots.apikey” : Carriots_API_KEY, “Content-Type”:“application/json”, “User-Agent” : “ElectricImp-Carriots” };
local request = http.post(url, headers, http.jsonencode(streamData));

local response = request.sendsync();
server.log("Data sent to Carriots. Response: "+response.statuscode+" -> "+response.body);
return response.statuscode == 200;

}
`

Quick explanation of the code.
“carriots.apikey” is your API key – note that this needs to have write capability (don’t use your read api key)
“protocol” is more often “v1” according to documentation but “v2” works.
“device” is your device ID, e.g. deviceID@UserName.UserName
"at" is your timestamp and “now” merely instructs Carriots to use current date/time

Note that your CarriotsPostHandler “data” parameter can be jsonencoded data too as within the Carriots data stream it will store the data in json format, e.g. {“node”:“193”, “info”:“T is 17 and H is 41”, “msgType”:“3”}

You can then create “Rules” and data “Listeners” which is more coding to automatically review your data and create triggers. Hence if one of your agents has failed to update Carriots beyond a certain time threshold you can create an event the notifies you of that fact.

That’s basically it…

Thank you guys for the response. I hadn’t come across the Style Guide yet in my reading, I’ll be sure to make use of that.

When working with Carriorts before, I enjoyed the structure and characterization that the system allows. Hopefully I’ll go forward with them and develop a library to share with the community.

That will be fantastic and a great time saver. It would be really helpful, for me anyway, if the new library encompasses the full carriots api functionality. So at a minimum for data management, we would have the ability to post both data and status streams and then have the ability to extract data lists and create data triggers from the data & status streams. Next on my wish list list would be the Device Management API and the Rules API.

Noted!