This time lapse was shot on iPhone, taking one image every few seconds over an hour.
Feodor Hilitski – Homepage
This time lapse was shot on iPhone, taking one image every few seconds over an hour.
This tutorial describes how to set-up the communication between Raspberry Pi 3 and AWS cloud. As a concrete example, we will store temperature data tin the cloud and visualize it. This is accomplished in several steps:
As a starting point, we have the Raspberry Pi 3 board with Raspbian Linux and fully configured WiFi connection. Let’s connect it to the Amazon IoT!
This process can be split up into two parts – set-up of security credentials and SDK installation. During the security credentials set-up, it does not matter which SDK you prefer. Amazon has pretty detailed description of how to connect RPi for Javascript SDK, but we can for the large part follow the same steps. Follow this AWS manual to
Once all the certificates (i.e. device certificate, private key, and root CA certificate) are downloaded from AWS, let’s upload them into $ ~/certs
folder on the device.
Now, we will install Python SDK rather than NodeJS. Simply following the instructions here and executing $pip3 install AWSIoTPythonSDK
Let’s also clone the Git repository so we can use its sample code to learn the SDK basics:
$ git clone https://github.com/aws/aws-iot-device-sdk-python.git $ cd aws-iot-device-sdk-python/samples $ ls basicPubSub basicShadow ThingShadowEcho
We’ll take advantage of the basicPubSub.py script. It should be called together with the certificates (so that AWS IoT can identify the device):
# Certificate based mutual authentication $ python3 basicPubSub.py -e <endpoint> -r <rootCAFilePath> -c <certFilePath> -k <privateKeyFilePath>
This sample code will subscibe to sdk/test/Python topic and publish to the same topic in the infinite loop. It is possible to use the external MQTT client (or the on built-into AWS IoT ) to see these messages and validate that the connection with AWS IoT is successful.
We are going to use the connection established in this way to publish ambient temperature to the appropriate topic. But first, we need to read the sensor data.
I am using an affordable and easy to set-up TMP102 sensor from SparkFun, connected to the board using Pi Wedge. The connections are straightforward, as there are only four wires: SDA, SCL, +3.3V and GND.
Now let’s make sure that the I2C is enabled by typing $ sudo raspi-config
and going to the advanced options menu. If I2C is currently off, enabling it requires reboot of RPi board. We also need to install i2c-tools by executing $ sudo apt-get install -y i2c-tools
to be able to communicate through I2C. Let’s see what’s connected by executing i2cdetect command:
$ i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --
We have the TMP102 sensor at its standard address 0x48. The full temperature reading is stored in the first 12 bits with address 0. The first 8 bits provide to get the rounded temperature reading:
$ i2cget -y 1 0x48 0 b 0x19
The returned result 0x19 = 25 C is the room temperature as measured by the sensor. The full 12 but reading will be used later to get more accurate data. For now, we are assured that the sensor is connected and works. All we need is a python script that will read the temperature and send it to AWS.
Let’s use pigpio library to communicate with I2C – seems like it comes pre-installed with Python3. Let’s also install the pyth0n-smbus library: $ sudo apt-get install python-smbus.
First, start a pigpio daemon by executing $ sudo pigpiod
. After that, the script should acquire and print the temperature. We can start it by executing $ python tmp102.py
The source code of tmp102.py is below:
#!bin/python3 #reading TMP 102 sensor import pigpio import time def tmp102_reading(byte0, word0): #calculation of the temperature based on #the first word and the first byte # !!! not tested for negative temperatures !!!! #last 4 bits of the word0 l4b = (word0 & 0b1111000000000000)>>12 temperature = ((byte0<<4) | l4b) * 0.0625 return temperature #i2c bus of the Raspberry Pi 3 i2c_bus = 1 #TMP 102 address on the i2c bus addr = 0x48 dev_pi = pigpio.pi() dev_tmp = dev_pi.i2c_open(i2c_bus, addr, 0) register_n = 0 try: while True: t_byte = dev_pi.i2c_read_byte_data(dev_tmp, 0) t_word = dev_pi.i2c_read_word_data(dev_tmp, 0) t = tmp102_reading(t_byte, t_word) print(' Temperature: {} C'.format(t)) time.sleep(1) except KeyboardInterrupt: pass print('Exiting the loop'); r = dev_pi.i2c_close(dev_tmp)
This script will output the sensor reading every second until Ctrl+C is pressed:
Temperature: 25.59375 C Temperature: 25.59375 C Temperature: 25.625 C Temperature: 25.625 C Temperature: 25.625 C Temperature: 25.625 C Temperature: 25.625 C
Instead of printing the temperature in the console, we need to send it to AWS IoT and repeat the whole thing after a set interval – every minute, for example. The Raspberry Pi has already been connected to AWS during the first step. We will re-use the publish/subscribe code example (basucPubSub.py) from the AWS SDK example to publish to a new topic for our new sensor.
First, let’s create variables for the topic and delay between temperature updates. Plus, we can give our sensor a serial number – in case we build more than one and need to distinguish between them:
delay_s = 60 sensor_sn = '00000001' topic = 'myrpi/'+sensor_sn
Let’s now read the temperature in the loop and send it to AWS (until Ctrl+C):
try: while True: loopCount += 1 t_byte = dev_pi.i2c_read_byte_data(dev_tmp, 0) t_word = dev_pi.i2c_read_word_data(dev_tmp, 0) t = tmp102_reading(t_byte, t_word) timestamp = datetime.datetime.now() print(' Temperature: {} C Loop # {:d}'.format(t,loopCount)) print(' Time: {} \n'.format(timestamp)) msg = '"Device": "{:s}", "Temperature": "{}", "Loop": "{}"'.format(sensor_sn, t,loopCount) msg = '{'+msg+'}' myAWSIoTMQTTClient.publish(topic, msg, 1) print('Sleeping...') time.sleep(delay_s) except KeyboardInterrupt: pass print('Exiting the loop'); r = dev_pi.i2c_close(dev_tmp) myAWSIoTMQTTClient.disconnect() print('Disconnected from AWS')
Remember – this(get the entire file here) is only a (slight) modification of the basicPubSub.py file provided in AWS Python SDK. Path to certificated is still necessary for it to run properly. The shell command to start publishing to AWS is therefore
$ python3 publis_temp.py -e <Your:AWS:endpoint> -r <rootCAFilePath> -c <certFilePath> -k <privateKeyFilePath>
The script publishes the following payload to the myrpi/00000001 topic:
{ "Device": "00000001", "Temperature": "27.0", "Loop": "2670" }
The structure of this payload is very similar to the data sent by the AWS IoT button. Once the data is published we can time-stamp and log it the DynamoDB table. This was described in detail in the post about IoT button.
The IoT button is connected to the AWS cloud and every click is recorded in the DynamoDB. It’s now time to query the database and present the data, preferably in a visual form. Here, we will do everything in the browser, building our app using JavaScript AWS SDK. Thus, the first step is to add the script to the HTML page:
<script src="https://sdk.amazonaws.com/js/aws-sdk-2.5.4.min.js"> </script>
We would like to send requests to the DynamoDB, but the SDK has to be configured before we can do that. The two required pieces of information are the region and credentials. There are several ways to provide credentials securely:
We are going to pick the easiest one and hard-code the credentials into the application. This is also the least desirable method from the security standpoint, used here for the sake of convenience and speed. To do so, open the Identity and Access Management (IAM) console, click on Users menu and Create User. Immediately after the user is created, you can copy (or download) the security credentials and hard-code them into the application:
var user_credentials = { accessKeyId: 'AKIAIV6CXXXXXXXXXXXX', secretAccessKey: 'i8+vtmKkXXXXXXXXXXXXX' };
This newly created user still does not have any service permissions and thus can’t perform any actions. We need to attach a specific policy to allow DynamoDB access. Click on the Users name in the IAM, select the user, open Permissions tab and click Attach policy. Type AmazonDynamoDBReadOnlyAccess, select it and click Attach policy. We are now officially allowed to query the DynamoDB. Permissions are set as read only to mitigate the security risk due to hard-coding the credentials.
Let’s finish configuring the JavaScript SDK by executing a command to update user credentials:
AWS.config.region = 'us-east-1'; AWS.config.update(user_credentials);
To test the newly created user credentials and verify the read-only access to Dynamo, lest first list all Dynamo tables. This is done by calling the listTables() method of the DynamoDB object. Let’s also put all tables into the drop-down menu for easy selection.
var dynamodb = new AWS.DynamoDB(); dynamodb.listTables(function(err, data) { var html_str; if (err == null){ html_str = ' DynamoDB tables: <select>'; $.each(data.TableNames, function(index, value){ html_str += '<option value="' + value + '">' + index+1 + '. '+ value + '</option>'; }); html_str += '</select>'; } else{ console.log(err); html_str = err; } $('#table-list').html(html_str); });
If the credentials are invalid, we will see an error message. If the credentials were crated properly, we can select the table iot-buttons from the menu (that’s the name we decide on in the first part).
Let’s now obtain table info by calling describeTable() method and passing the table name as parameter. For example, let’s get the total number of records in a table:
var params = { TableName: $(this).val() }; dynamodb.describeTable(params, function(err, data) { if (err) { //an error occurred $('#table-list').append('<p>' + JSON.stringify(err) + '</p>'); } else { //successful response var table = data.Table; $('#table-list').append('<p> '+table.TableName + ": # of items= "+table.ItemCount + '</p>'); } });
Finally, let’s query the table to get the data for a particular sensor. Device serial number serves as the primary partition key. Let’s obtain all data from an IoT button with a given S/N. First, we need to create a DocumentClient object:
var docClient = new AWS.DynamoDB.DocumentClient();
We need to pass query parameters to the query() method of this object. This includes the deviceS/N:
var device_sn = 'G030JF05XXXXXXXX'; var params = { TableName : table_name, KeyConditionExpression: "#device = :dev_sn", ExpressionAttributeNames:{ "#device": "device_id" }, ExpressionAttributeValues: { ":dev_sn":device_sn } };
Finally, we can get the data from the table:
docClient.query(params, function(err, data) { if (err) { //output error message if query failed $('#query').append('<p> Unable to query. Error: </br>'+JSON.stringify(err, null, 2)); } else { $('#query').append(JSON.stringify(data.Items)); //data.Items now contains the array with returned item } });
After the successful query, returned data.Items contains all returned items. The variable structured as an array of JSON object, each corresponding to a row in the DynamoDB table:
data.Items = [Object, Object,... Object] Object = {"data": { "serialNumber":"G030JF05XXXXXXXX", "clickType":"SINGLE", "batteryVoltage":"1704mV" }, "timestamp":"1472127527955", "device_id":"G030JF058432MLDB" }
The only thing left is to represent the data in a convenient way.
There are many possible ways to process and visualize the data. For example, one can parse it and represent as HTML table. The voltage and click type can be represented as time-series using one of many available charting libraries.
I wrote two classes for data processing. The first one process data as a HTML table and then adds more functionality to it using dynatable jQeuery plug-in. The second one plots clicks and voltage vs time using plot.ly JavaScript.
To take advantage of these, add the following scripts:
<script src="http://cdnjs.cloudflare.com/ajax/libs/numeral.js/1.4.5/numeral.min.js"></script> <script src="http://momentjs.com/downloads/moment.js" type="text/javascript"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/Dynatable/0.3.1/jquery.dynatable.min.js" type="text/javascript"></script> <script src="https://cdn.plot.ly/plotly-latest.min.js"></script> <script src="plotly_scatter.js" type="text/javascript"></script> <script src="tableprocessor.js" type="text/javascript"></script>
Scripts table_processor.js and plotly_scatter.js require moment.js and numeral.js to propely process the time-stamp data.
Pass the acquired data into the new FH.dataprocess object together with a jQuery object for the output HTML div, and the script takes care of tables and plotting:
new FH.dataprocess(query_data, $('#processed-data'));
To see the details of the data processing scripts, download the repository on GitHub. If your AWS IoT and DynamoDB endpoints are set-up correctly, this sample code will produce IoT button voltage and click time-series plots like the one below.
I recently wrote two introductory posts about configuring the Amazon IoT button and using AWS SNS to receive SMS and email notifications on click.
To log the clicks and battery voltage over time, the payload sent with every click can be time-stamped and stored in a database. A script can be used then to query the database, retrieves the data and plot the time series of this data (using one of many d3js libraries, for example, plot.ly). (Will write about the script later in this post)
Some posts about the Dash button speculated that the battery would last for over 1000 clicks. So far, after >150 clicks the battery voltage shows no signs of decreasing.
At a starting point, we have a fully configured Amazon IoT button with uploaded certificates. We tested that it works and can send SMS notifications on click. We know that the button publishes the following message (payload) in the ‘iotbuttons’ topic of the IoT message broker:
{ "serialNumber": "G030JF058432MLDB", "batteryVoltage": "1739mV", "clickType": "LONG" }
We need to time-stamp this data and store it in a database. Let’s use Amazon’s NoSQL DynamoDB database to store and query the time-series data.
Go to the DynamoDB dashboard and click Create table button. The table requires a name and a primary key. Let’s name the table iot-buttons (we might need to log more than one button for a potential application). While the name choice is rather arbitrary, the partition key is important – elements with different partition keys should have uniform access frequency (more about partition keys). In our case, the serial number is a good partition key. Additionally, we can use a timestamp as a sort key to search within a partition. Both the serial number and the timestamp are strings. After specifying the keys, we can create a table using default remaining settings.
iot-buttons
|
|
device_id (String)
|
|
timestamp (String)
|
With the table created and keys specified, we now can create a rule in the AWS IoT console to write the data into DynamoDB on click. Clicking on the Create resource and choosing the Create a rule opens a dialog window for the new rule. Name and Description fields are again arbitrary. The SQL query should capture all messages sent by (multiple) buttons to our MQTT broker without additional conditions. This is achieved by:
SELECT * FROM 'iotbutton/+'
We need to select the DynamoDB Action from the drop-down menu to insert messages into a database. This selection extends the dialog by several fields. First, choose a table name from the drop-down list (there is also an option to create new table, but we have taken care of this already). We decided to use the serial number as a hash key. It is transmitted in the “serialNumber” field of the payload, so we will specify ${serialNumber} as a hash key value. To specify time-stamp as a range key value, type ${timestamp()} in the appropriate field. Finally, the payload field can be just data, meaning that the entire payload will be stored in the database.
The last step is to specify the role. Luckily, we can click on Create new role and simply specify role name. IoT interface will take care of the rest and create a new IAM role which allows writing data into a particular database.
Click Add action to add this DynamoDB action to the new rule (a rule can have several actions) and Create rule to complete the process. Pressing AWS IoT button now should create a new record in the DynamoDB table with the following content:
dataMap{3} batteryVoltage String: 1760mV clickType String: LONG serialNumber String: G030JF05XXXXXXXX device_id String: G030JF05XXXXXXXX timestamp String:1474212345678
Every click is now recorded into the database. Let’s now look at the ways to retrieve the data and visualize voltage and clicks as a function of time.
AWS IoT functionality is based to a large extent on a publish/subscribe message broker that supports MQTT protocol. The concept is simple: a device can publish messages (for example, sensor readings) to a topic or subscribe to receive messages. AWS Developer Guide has an excellent and detailed explanation of the way message broker operates. AWS IoT main page has a built-in MQTT client that can be used in a web-browser with ease, but the session is lost if the browser window is closed.
It is possible to use one of the freely available MQTT clients to connect to the IoT endpoint. This can be useful in development and debugging of the IoT applications. Here is how to set-up MQTT.fx to work with AWS IoT.
The latest version of MQTT.fx client can be downloaded here. At the moment a large variety of installation packages for Windows, MacOS, Linux is available for version 1.1.0
The nice thing about MQTT.fx is that it allows you to create multiple connection profiles. If you work with several different MQTT brokers, loading saved profiles increases convenience. Let’s first create a new profile for the AWS connection. Either go to Extras > Edit Connection Profiles in the menu or click on the gear icon to open Connection Profiles window.
There should be two default profiles, “local mosquitto” and “M2M Eclipse”. Click on the plus sign (+) all the way on the bottom to create a new profile and give it a name. The Broker Address is your AWS IoT endpoint, usually URL in the form: (iot-address).iot.(region).amazonaws.com Here, region can be, for example, us-east-1; and the iot-address is your personal AWS identifier. AWS IoT uses Broker Port 8883. Unique Client ID can be generated on the spot with the Generate button.
Finally, we need is to provide the SSL/TLS certificates to establish secure connection to the message broker. Click on the SSL/TLS tab, check the Enable SSL/TLS box, and select TLS v. 1.2 as the appropriate protocol. Now, we are going to provide Self-signed certificates (generated by the AWS). Upon selecting this option, several input fields appear, asking us to provide three files: CA, Client Certificate and Client Key.
The root CA file, which serves as proof that we are really communicating with AWS IoT server, can be downloaded here. (More about authentication can be found in the Developer Guide.) The other two files, Client Certificate and Client Key, have to be downloaded when the new certificate is created as the IoT resource.
Creation of certificates was covered in the previous post about the IoT button. When the new certificate is created, the IoT web interface gives you a chance to save keys and certificate files, which are PEM-encoded. Saving the public key is not necessary in this case, we really need only the private key and the certificate.
Going back to the profile set-up window of the MQTT.fx, specify the newly downloaded certificate and private key in the SSL/TSL tab and click OK. The connection parameters are now set up. However, the policy certificates alone does not give a permission to the MQTT client to connect and subscribe/publish to topics in AWS IoT. If you try pressing connect now, the MQTT.fx will display “Connection lost” message. Permissions are granted through specific policies. Therefore, we need to create a policy and attach it to the certificate.
We need to create a policy that allows the MQTT client to connect to the AWS server, receive data, subscribe and publish to topics. This is accomplished in the web-interface by creating a new policy with the following Actions: iot:Connect, iot:Receive, iot:Publish, iot:Subscribe. We are going to use * as a Resource, which allows selected actions on any resource. Finally, we need to explicitly Allow specify that the listed actions. Once all fields in the Create a policy dialog are filled, click Add statement.
The newly crated policy needs to be attached to the certificate. Click on the certificate and choose Attach a policy in drop-down list of available actions. Enter the Policy Name and click attach. Finally, MQTT.fx set-up is complete.
Click on the Connect button in the MQTT.fx now, and the connection indicator will light up green, along with the lock sign indicating secure TSL connection.
You now can subscribe and publish to any topic. For example, to see messages sent by the Amazon IoT button connected previously, subscribe to the “iotbutton/+” topic. The + is a wildcard that matches one level in topic hierarchy, so we are subscribing to all iotbutton messages, even though they might be sent by multiple buttons. Pressing the IoT Dash button now results in the new message in MQTT.fx, displaying the message and previous subscription history.
In the first part of this Getting started with IoT button post, we configured the WiFi connection and set up certificates for secure communication with AWS cloud. The data sent with every button press looks like that:
{"serialNumber": "G030JF05XXXXXXXX",
"batteryVoltage": "1592mV",
"clickType": "SINGLE"}
Besides sending, the device has to do operations with this data like publishing it on a MQTT topic. Since all actions in AWS are tightly controlled for security purposes, the device needs a permission to perform actions. Policy is a form of such permission.
Creating a policy starts with clicking Create a resource and choosing Create a policy tab.
In order to publish to a particular topic, select iot:Publish action (it is easy to find it in the drop-down list after typing the first few letters). The content of the resource field depend on the selected action. Since we selected Publish, we need to provide topic identifier as a resource (read more about resources and topics here). Resources follow somewhat complex naming convention:
arn:aws:iot:your-region:your-aws-account:topic/iotbutton/your-button-serial-number
This is similar to the REST API endpoint, since it contains your AWS account number (endpoint subdomain) and region (for example, us-east-1). We already used the serial number as well when setting up WiFi access. With all previously collected info, it is easy to create the correct ARN:
arn:aws:iot:us-east-1:xxxxxxxxxxxx:topic/iotbutton/G030JF05XXXXXXXX
Check the Allow box, click on Add statement (single policy can contain multiple statements) and Create. The policy is now visible in the list of resources.
In order to work properly, the newly created policy has to be attached to the device certificate. Also, the certificate should be associated with the thing we created in the first part. To perform this association, select the certificate in the resource list and click on Actions menu. Attach both the policy and the thing to the certificate. The certificate is finally complete!
If you press a button on the device at this point, it will send the data and publish it to the iotbutton topic. LED indicator should turn solid green for several seconds, indication successful publish outcome. As a test, try to detach the policy – the LED will flash red. Also try detaching the thing. Surprisingly, the thing really does not make a difference – even without it the message is published.
You can subscribe to a topic and receive messages by using the MQTT client built into AWS IoT or with the standalone application like MQTT.fx (more MQTT clients here). Subscribe to the iotbutton/G030JF05XXXXXXXX topic to view messages for a specific device or iotbutton/+ if you have multiple buttons.
AWS IoT can perform actions when a messages is published through the use of rules. Creating a rule is similar to creating any other resource. In the Create rule dialog, fill in the name and description fields first. We need to create an SQL query that will be used to monitor published messages. This is done by specifying the Attribute field and the Topic filter. Since we are interested in the IoT button topic, type in the familiar iotbutton/G030JF05XXXXXXXX. Attribute can be a specific field of the payload, such as clickType or batteryVoltage, but we can also use * for all fields. Condition is not required and can be left blank, unless we want to trigger the rule only when battery voltage falls below a certain threshold, for example.
Finally, we need to select an action from the expansive list of available actions. We are currently interested in the sending a text message or an email as the click notification, so select the SNS service.
We have not selected any targets for the notification. Let’s follow Create a new resource link to create a target for the AWS Push Notification Service (SNS). Targets for the rules are called topics in the SNS parlance.
Hit Create new topic button on the newly opened SNS dashboard and input name and display name of your topic.
Create the topic and click on its ARN in the list of topics. This should display topic details. As you see, the topic currently has no subscriptions – i.e. addresses or phone numbers to send notifications to. You can add a number or an email address by creating new subscription.
This process is straightforward, as Topic ARN field gets auto-populated, all you need to do is to choose the desired protocol (SMS, email or AWS Lambda function to name a few), enter the endpoint (cell number, email address, etc) and create the subscription. With the subscription and topic in place, lets go back to the IoT dashboard and continue with the rule creation.
SNS target is now the topic name. Message format field is not required and the only remaining thing to do is to specify the Role name. Click Create a new role and specify role name – this is all. AWS will automatically add a new role into the Identity and Access Management (IAM) system and grant it a permission to push IoT notifications. With the role in place, Add action and Create the rule. Notice that a rule can have multiple assigned actions.
Rules are independent of a particular device or certificate. They do not have to be attached to anything. AWS IoT rules engine will continuously monitor the messages and push notifications if the message matches SQL query specified in the rule.
With all steps now complete, pressing a button sends a text message withing a few seconds. There are three distinct click types: single, double and long. In addition, the button sends voltage, which can be monitored over time. Counting clicks is another interesting project for learning AWS basics.
Dash Buttons help you buy stuff on Amazon by simply pressing a button. You can place an order on anything from laundry detergent to soft drinks by pressing one of these. They are essentially free after the first placed order. Amazon recently released the IoT button, which orders absolutely nothing and will cost you $20. Why would anyone buy that? Well, because it is easy and fun introduction to the Amazon IoT platform.
It serves as a perfect introduction to the workflow of the AWS IoT – part of the Amazon Web Services that helps connect devices to the cloud. The Internet of Things has two essential aspects to it. The “things” part are physical devices that interact with the user (a button) or the environment (a temperature sensor). The “Internet” part is the software responsible for processing the data and acting on it (placing an order or sending a text message alert). Getting started with the IoT thus requires working both with hardware and software. Designing and building connected devices might be challenging (although extremely interesting as well). The IoT Button takes care of the hardware part of the equation, and gives you an opportunity to learn the “Internet” side of IoT.
Here is my take on the IoT button workflow – from unpacking to receiving SMS notifications.
The button comes in a neatly packaged and fully charged. Press it right out-of-the-box, and you will see red flashing light, which means the button has not been set up yet. It has no record of WiFi network SSID and password. There is also no destination to send the data.
First, create the Amazon Web Services Account here. After that you should see AWS console with the multitude of provided services. All we need now is to click AWS IoT icon to go to the AWS IoT homepage.
AWS IoT contains the list of all resources you created, a button to create a them and a link connect AWS IoT button. I found myself confused after following the link and decided to go back. I recommend clicking on the Create a resource.
Choose Create a thing from the list of possible options and give it a name (for example, iot-button). It will have no type and no additional attributes so far. Clicking Create will add a thing, which is a virtual representation of some arbitrary physical device. Next, we need to make sure this newly created “thing” in the cloud is associated with the IoT button we have.
The communication between the “virtual” thing and the physical button happens via secure MQTT protocol. This security scheme is using a certificate in combination with the public and private keys. All of them can be created in one simple step. Click on Create a resource again and choose Create a certificate. Certificates have to be activated, you can check the Activate box to do it now (or do it as a separate step later). 1-Click certificate button will create the certificate with keys and add them to the list of resources.
Right after creating the certificate you will have the only chance to save public and private key files. It is extremely important to do it. Private key is essential for the IoT button – this is how the button will identify itself and secure the connection to the cloud. Save all three files in a separate folder.
Apart from the certificates, the IoT button needs a web-address associated with the AWS cloud. You can get this information by clicking on the icon of the newly created ‘iot-button’ thing. The properties tab contains the REST API endpoint. It typically looks like this: https://xxxxxxxxxxx.iot.us-east-1.amazonaws.com/things/iot-button/shadow Here, xxxxxxxxxxx is unique identifier of your IoT endpoint, us-east-1 stands for AWS service region. The rest – /things/iot-button/shadow specifies a particular devices. Record the xxxxxxxxxxx and the region (ex. us-east-1) – this information will be necessary for the IoT button set-up.
We are finally ready to work with the IoT button itself. In order to enter the set-up mode, press and hold the button for 15 seconds, until the LED turns blinking blue. The device switches into Access Point mode and creates a WiFi network with with SSID Button ConfigureMe – xxx. The password is the last eight digits of the serial number located on the back of the button. Connect to the network and type http://192.168.0.1/index.html in your browser. This opens a simple web-form where we enter the previously collected information and attach key and certificate files.
Click Configure and the button will attempt to connect to the provided network, obtain IP and send the info to the IoT endpoint while flashing white LED light.
The certificate identifies the device to the IoT cloud back-end. However, it has not been given permission to actually publish any data. At this point, the LED will be flashing red, indicating unsuccessful publish process. Even though the WiFi connection works, we need to create appropriate rules
In the next post – Getting started with Amazon IoT button (Part II) – I will describe how to set up rules to process this information and send SMS and email click notifications.
Also, check out this post about storing and visualizing IoT button data.
I looked up all NSF funding from 1996 through 2016 and sorted it by city and state. Looks like the amount of NSF funding peaked in 2009 and has been decreasing recently. Also there are two visible spikes in funding levels, in 2002 and 2010. I mapped the funding levels by city using plot.ly interactive maps. Here is one such map for 2015. You can find the rest of them on my plot.ly page.
We attach actin filaments to tiny plastic beads and manipulate them with laser tweezers. In presence of the depletant molecules, two actin filaments form a bundle. We move one of the beads with a certain velocity, thus pulling on the bundled filaments. At the same time, we measure the friction force exerted onto the second bead. Read more in this post: Friction on the molecular scale.
In the Dogic lab, we use time-shared optical traps to manipulate tiny biological polymers. Using this technique, we measured forces exerted onto microtubules by the surrounding molecules. Read more: Depletion-Induced Microtubule Bundles