This article will assume you have read and understood the “Intro to THINaer’s API”. If you have not read that article it covers how to connect and authenticate with the API along with some organizational tips. This post will cover a simple use case using one Cirrus and a few iris (ii18e), iris 18e holds environmental sensors that monitor temperature and relative humidity. The chip used to monitor temperature is accurate to +/-0.5C and relative humidity to +/-2%. While the ii12 does display something called “internal temperature” it is very inaccurate and should only be used for non essential functions or if you want to take a close guess at temp.
Cirrus (IoT Gateway)
In the previous article I quickly talk about Cirrus and refer to it as an IoT gateway. Cirrus is simply a listener, it listens for BLE devices to transmit anything and then it sends that data through wifi to the THINaer IoT services to get processed and cleaned up for API usage. So simply said, it’s a “gateway to the internet” for our iris beacons.
Taking the Cirrus, I am going to plug it in and follow the setup instructions included in my box. This involves just a few steps:
- Provide power to the device.
- Using your computer with wifi, connect to the “Whisker.IO” wifi network.
- Scan for available wifi networks.
- Select and provide the password.
The Cirrus will power off then on and the blue LED should blink periodically but not with any uniformity. If it continues to blink with uniformity then just try again.
Now let’s place an ii18e indoors about 30 feet away from the Cirrus, and another outdoors about 50 to 80 feet away.
Once you have deployed the hardware it has already begun to collect data! Now that the Cirrus was powered on and connected to wifi it started sending data back to THINaer for use in the API.
Start collecting environmentals
Let’s do some basic organization of our hardware for later use, using POSTMAN or curl (or any programming language) lets place the two iris at a new “venue” but first let’s create a “venue” called “Home”. The API allows a developer to organize it’s devices based on “clients” and “venues”. This comes into play when you are building a multi tenant application using the API. You can then have many “clients” that belong to your application and assign devices to the client as you see fit, providing some separation for your customers. Within the “client” you can then further organize to “venues”, this often relates to physical locations but are really just groups and can be used anyway you see fit.
I will cover Clients and Venues and why you should be using them in a future post, but for now just know they are best practice.
Create a Client
So let’s first create a client to assign all my devices too called “Winn”, if I am building a reusable multi tenant product his would happen in a sign up process for my service.
Create a Venue
Now we are going to use the id (580504eb8c427a849136a3ee) we got back to create and update the devices.
Now lets use the new venue id to assign to the devices so they belong to that venue.
Assign each device to the newly created venue (580833346fca85b59e347c1e):
Our simple application
Now we can write a simple script to collect the data every 15 minutes and save it to the database. In my example below I am using ruby from the THINaer API docs to look for all my devices by my venue_id and then looping them. Once looped and am saving them to redis for later use! At this point you can really do whatever you want to do with the information.
Get devices by venue_id.
Loop the devices and save the data I want to redis.
Front-end HTML view
The API provides the temp in celsius but on the front end I have converted it to fahrenheit.
My next article on the API will cover more in depth on organization and I will touch on movement history and how to see where your beacons have been!