Archives for August 2015

Mobile Weather Sensors Using ESP8266 – Phase 5: Ant+ Heart Rate Monitor

31st August 2015 by InternetOfHomeThings in All Posts, ESP8266 : An IoT System on Chip, Internet of Things | Leave a comment

Adding a Heart Rate Monitor (HRM) wraps up the Mobile Weather Sensor project. To get started, a sensor selection was needed. And since I already have and use a Garmin HRM with a wireless chest sensor, using that same sensor with my setup was the logical choice.

But how to do it?

That was the challenge…

First thing was to figure out how the Garmin unit worked. What sort of RF signal was being sent to my handlebar mounted display? And what message protocol is used? What will it take to interface with my Android, wirelessly?

After some research, I found that the Garmin HRM used an Ant+ interface.

What’s that? Ant+ does look a bit intimidating at first glance. Take a look here.

Fortunately. I was able to boil things down to the bare essentials of what was needed in order for my android phone to receive heart rate data from the sensor. There were several elements needed to make things work…

  • An ant+ radio was needed in the smartphone
  • The ant+ API works directly with a native android app. But since the Weather Sensor App uses the Cordova web interface, a method of communication was needed between the Cordova JavaScript code and the native Java code.
  • The phone app needed to automatically detect the HRM and pair with it (like bluetooth).

These modifications to the existing android app integrate the Java Ant+ API, the Heart Rate Monitor and JavaScript.

The Phone Ant+ Radio

Fortunately, my Samsung Galaxy Note 3 has a built-in ant++ radio. But in order to access this interface, an App must be installed from the Google Play Store. It is called ANT+ Plugin Service. It is really simple. There is no App icon to launch. This is how it works…

Once installed, the service is called anytime an App attempts to connect with an ant+ device. My phone is an ancient model, almost two years old now. Many of the newer phone come with this service pre-installed.

this-is-ant

JavaScript to Java Interface

With an interest in portability between android and iOS phones, the Mobile Weather Sensor App has been built with a standard web interface. This presented a problem since the API provided by the ANT+ team supports android native Java (.java files) but not JavaScript.hrm-code

Fortunately, a mechanism has been provided to “extend” the Cordova Web API to communicate with Java code. Here is the source of the information I used to implement the interface between my App and the native code needed to communicate with my heart rate monitor.

First thing to do was to add a reference to this interface code to the project’s config.xml file:

<feature name="HeartRateMonitor">
       <param name="android-package" value="org.apache.cordova.antplus.heartrate.HeartRateMonitorInterface" />
       <param name="onload" value="true" />
</feature>

The first parameter identifies the file containing the feature class object. In this case, the Java code is contained in the file “HeartRateMonitorInterface.java”. The second parameter makes this feature available upon loading the application’s Web view.

But how do we call the Java code from JavaScript?

Here is the Cordova mechanism used to call Java feature “actions” from JavaScript:

cordova.exec(
    callback-if-successful,    //JavaScript Callback function if call 
                               //to Java code was successful
    callback-if-error,         //JavaScript Callback function if call
                               //to Java code was not successful
    "feature name",            //Feature name from config.xml file.
    "feature action",          //Feature action to be executed from 
                               //the .java file
    ["parameter array"]);      //Parameter array to send to Java code

As we shall see, the Java code can return any string back to the JavaScript callback functions. That is how the heart rate received by the Java code is returned JavaScript.

Only two feature actions were implemented to support the heart rate monitor interface:

  1. ConnectHeartRateMonitor – This method establishes a connection between the App and the Heart Rate Monitor
  2. GetHeartRate – This method retrieves the newest heart rate from the Java code.

ConnectHeartRateMonitor is called once at the start of the application while GetHeartRate is called each time the app refreshes the sensor values.

The Java Code

The Java code implements the  class “HeartRateMonitorInterface”. This class contains the following key methods:

  1. execute – This required methods is executed when JavaScript “cordova.exec(()” is called. As noted above, this method only supports two actions.
    1. ConnectHeartRateMonitor makes a call to the Ant+ API method “.requestAccess”. Fortunately, the API does all the hard work of connecting to the Heart Rate Monitor. The Class callback “base_IPluginAccessResultReceiver.onResultReceived” methods is invoked to report the status of the call.
    2. GetHeartRate simply returns the latest heart rate value back to JavaScript.
  2. base_IPluginAccessResultReceiver.onResultReceived is the callback invoked when the ant+ “.requestAccess” method is called. If access was successfully granted, we subscribe to the Heart Rate Monitor Events. Whenever a new event is received, the callback “HeartRateDataReceiver().onNewHeartRateData()” is invoked.
  3. IHeartRateDataReceiver().onNewHeartRateData() receives updates from the heart rate. Upon receipt of a new sensor value, the heart rate is saved to a class variable for retrieval, on-demand, from the JavaScript.

Conclusion

We now have a working application that supports all of the capabilities planned. The Eclipse project files for this application are on GitHub here. The data collected on this mobile application include:

  1. Temperature
  2. Barometric Pressure
  3. Humidity
  4. Speed
  5. Direction
  6. Coordinates
  7. Heart Rate
  8. Altitude
  9. UTC timestamp
  10. Internal ESP statistics

Who knows, there may be more added…

I am looking forward to the coming change of season. With this App and the ESP sensors, I expect to collect some interesting information about significant changes in micro-climate in the span of short distances along the local mountain trails. It will be great to finally quantify what is felt externally as you must peel on and off layers of clothing with changing conditions.

I hope you have found this information is useful to you in your own projects…

Loading

Share This:
FacebooktwitterredditpinterestlinkedintumblrFacebooktwitterredditpinterestlinkedintumblr

Mobile Weather Sensors Using ESP8266 – Phase 4: Mobile App Gadgets

24th August 2015 by InternetOfHomeThings in All Posts, ESP8266 : An IoT System on Chip, Internet of Things | Comments Off on Mobile Weather Sensors Using ESP8266 – Phase 4: Mobile App Gadgets

speedAs I found myself staring at the information collected by the Mobile Weather Sensors, searching for ideas on how to best present the information visually, the reality hit me….

While this is a decent App for collecting information on-the-go, it data itself and the environment it is collected in does not lend itself well to real-time visualizations.

Two problems…

First of all, there is a significant lack of visibility of the smartphone screen outdoors. You could have developed the most magnificent display, with eye-catching vividly colored displays. Great inside, but the screen appears almost blank when taken outside in the direct sunlight. And that is where this mobile sensor system is most of the time.

The other issue is the slow moving, almost static values of the sensors. Temperature, humidity and pressure do not vary much moment by moment.

Despite the limited usefulness of GUI displays for this application, I decided to throw a few in anyways.

There is always something to be gained…

You see, these added screens can be used in any App. Providing quick and easy-to-implement options to display your data.

Since this App has been structured with a standard web page format (html to render the GUI, CSS to style and JavaScript for processing), JavaScript charting is the obvious and most logical choice for real-time visualizations of the sensor data.

The good news is that there are many options available.

This site provides access to 15 different Javascript Charting Libraries. D3.js seems to be the crowd favorite. It has lots of flexibility. But I did find it somewhat more complex to get started with, and the charts were not responsive to different screen sizes.

So I chose Chart.js. Why? It was quick and easy to implement. Yup, their claim actually rang true for this application “Simple, clean and engaging charts…”. And yes, they are also very responsive to the smaller smartphone screens.

A Speed Chart

The first chart displays velocity. It is essentially a speedometer. The code simply updates and displays the last 10 speed values received from the GPS sensor. The current reading is displayed as the next point on the right side of a line chart. This new speed value pushes the other 9 readings one position left on the chart, with the left-most reading dropping off the chart.

As I mentioned, the smartphone display is nearly impossible to view outdoors in the direct sunlight. For a test of this real-time chart, I simply held my phone upright and rode my bicycle down the street. Using an independent Garmin GPS device for reference, I rode at varying speeds to confirm that the smartphone app display values correlated.

The current speed value (mph) is also displayed under the chart.

I was pleased to observe the accuracy of the display.

Perfect Widgets

No, there really is no such thing as “perfect”. But I have gotten a few gadgets from Perfect Widgets which have now been added to this application.

First, I tested a compass widget, using only the “heading” value from the smartphone’s GPS sensor. After reviewing a recording of the display, it became apparent that considerable lag occurred between a change in direction. The audio was recorded along with the display. While the sound quality is not great, it clearly illustrates the lag in responsiveness when direction changes.

The lag could easily be overcome my using the Android magnetometer sensor in place of the GPS heading value. But since we are focusing on the real-time sensor displays, that change will be pushed off into a future upgrade.

Clock Widget fed from GPS Sensor

Sure, you can readily extract the time from the phone or even pull up a timeserver. But for this Application, let’s use the GPS time-stamp.

So now a dynamically changeable clock image was needed…

Once again, I looked the the “Perfect Widgets” library for a clock gadget. In this case, 3 sliders must be updated to maintain the clock. One for each of the moving clock needles (Hours, Minutes, Seconds). Minutes and seconds are easy, since the are extracted from the Date object every time it is refreshed (a value from 0 to 59).

But the same hour is returned for 60 minutes. As we all know, analog clocks move smoothly minute-by-minute from 1 hour to the next. And so we must add a fraction equal to the current minute divided by 60 to get the current “partial hour”. The Date object also returns the hour as a number between 0 and 23. This must also be adjusted for our 12-hour analog clock widget.

var d = new Date(position.timestamp);
se.setValue(d.getSeconds(),false);
mn.setValue(d.getMinutes(),false);
if(d.getHours<13) {
    hr.setValue(d.getHours()+(d.getMinutes()/60),false);
}
else {
    hr.setValue(d.getHours() - 12 + (d.getMinutes()/60),false);
}

Here is what the gadget looks like…

Small Yet Useful App Update

 Some times I have wanted to use the smartphone App alone.

Without the ESP8266 running…

In those cases, I found it necessary to record sensor data while omitting the ESP8266 information. This was particularly useful in times when it was easier to check things out without taking the extra steps to activate my ESP8266 module.

The simple solution was to add a button to the  top of the navigation bar to toggle enabling/disabling the use of the ESP8266 in the log file. The following screenshot shows this added button in the default “ESP used” state.

appupdate

Conclusion

We now have a few real-time visual representations of the Mobile Sensor Data. There are many more possibilities for the creation of visual displays. Here again is the link  that provides a reference to some of the best JavaScript charting tools available.

Want to see the code behind the charts I have present? The code developed thus far (Phases 1-4 of this project) is accessible on Github here.

I hope you find these tools useful in your projects…

Loading

Share This:
FacebooktwitterredditpinterestlinkedintumblrFacebooktwitterredditpinterestlinkedintumblr

Mobile Web Sensors Using ESP8266 – Phase 3: Google Map Visualizations

17th August 2015 by InternetOfHomeThings in All Posts, ESP8266 : An IoT System on Chip, Internet of Things | Comments Off on Mobile Web Sensors Using ESP8266 – Phase 3: Google Map Visualizations

This is a continuation of the “Mobile Web Sensors Using ESP8266” series.

Mobile Web Sensors Using ESP8266 – Phase 1
Mobile Web Sensors Using ESP8266 – Phase 2

Google Map and Excel Visualizations

This is where things get interesting. I just got back from a yoga class. This was a simple 4 mile bicycle trek across town; a perfect opportunity to collect some data using the Mobile Sensor System.

For this test run. a USB battery was used to power the ESP8266-12 based device. I simply plugged a USB cable in to powered it up, stuffed it into a fanny pack, connected my Android phone to the device’s WIFI signal and started the App.

I could tell it was working by observing the UTC time change rapidly on the phone app’s GUI. Another look at the display upon arrival at my destination confirmed that the data collection was still  running. Success!

But the raw data file was not in a very human readable form:

timestamp,lat,lon,spd,alt,btmp,dtmp,bp,dh,syst,sysh,syslp
1439830613611,34.2943768,-118.8439855,null,null,80.6,57.79,29.23,50.70,120,30840,37
1439830614632,34.2943768,-118.8439855,null,null,80.6,57.90,29.23,50.59,121,30840,38
1439830615646,34.2943715,-118.8439865,null,null,80.24,57.90,29.23,50.59,122,31280,39
1439830618611,34.2945713,-118.8441038,0,180,80.24,57.90,29.23,50.50,125,30832,42
1439830619607,34.2945664,-118.8441046,0,180,80.24,57.90,29.23,50.50,126,31280,43
1439830621616,34.2945921,-118.8441143,0,181,80.42,57.90,29.24,50.50,128,30840,45
1439830625549,34.2945638,-118.8440880,0,175,80.42,57.90,29.23,50.40,132,30840,49
1439830625649,34.2945638,-118.8440880,0,175,80.42,57.90,29.23,50.40,132,30840,49
1439830627653,34.2945510,-118.8440810,0,175,80.60,57.90,29.23,50.40,134,31280,51
1439830630563,34.2945510,-118.8440807,0,175,80.60,58.0,29.23,50.79,136,31280,53
1439830631631,34.2945508,-118.8440805,0,175,80.60,58.0,29.23,50.70,138,29112,55

Collecting this sensor data and saving it to a file was an important step. And now, the next thing to do was to present the data in a visually useful format. I had intended to import the CSV file containing the data into Excel. However, while creating custom Excel spreadsheet charts and graphs was a quick and simple method of visualizing the data, my first approach was to seek out possible on-line tools already available for this purpose.

So the search began. It did not take long to find a way to import the spreadsheet into google maps. But would it be simple? would I have to crop out the latitude and longitude values from my data file for the mapping program to use it?

I was surprised at how easy it was…

The web site was www.gpsvisualizer.com.

After opening a web browser to that site, you simply click on “Choose File” and select the csv file created from the Android App.

Then, just click on “Go” and a satellite map with the tracks from the data appears.

Googlemap2

No changes to the csv file were needed. What a great tool! It figured out the appropriate data fields for lat & long and overlay-ed them on the map with a red trace.

Okay, what other options are available with this “GPS Visualizer”?

gpsvisualizer1

The “Choose an output format” revealed several image options as well as an elevation profile. The elevation profile looked like it might be interesting…

But I noticed the default units were meters. Being a US resident, feet are preferred. These units, along with many other options, were select-able by clicking on the link “Profiles (elevation,etc.)”.

Googlemap2-3

Here, you could set the X and Y Axis plots to any of the fields shown above. I was stoked to see the list included “Heart rate”. My Heart rate sensor will be added to this project at some point soon. Plotting it against elevation change should present some interesting results.

I created a test plot of elevation over distance traveled along this 4-mile route. While any field could be selected, this sample plot colorizes the speed. Again, the plot shows the speed to generally stay below 20 mph, typical for city street bicycling.

Googlemap2-4

That steep slope (and slow speed–red plot color) at about the 3.5 mile distance correlates with the only significant hill climb along the route. Nice to confirm that the data collected makes sense!

But then it hit me. Nice to see that this “GPS Visualizer” can portray the GPS data in charts…but what about the customized sensors? Like temperature, barometric pressure, and the relative humidity? Could this tool also support these unique fields in the plots?

I was pleased to discover that the answer is…

YES!

Note that the last field in the drop-down above is “custom”. Selecting this option allows you to enter any field name. Those are the field names in the first row of the CSV file of the data captured with our mobile sensor system. I selected “humidity” for the y-axis as a test case with a colorization of the speed.

Googlemap2-5
I was surprised to see the drop in relative humidity from the start to the finish of the ride. It was probably due to the sensor drying out someone with motion. It had been in the controlled, air conditioned environment of the yoga studio at the start and was then exposed to our dry Southern California air.

Looks like this “GPS Visualizer” tool will come in handy to produce quick charts from the sensor data.

Visualizations Using Excel

While most everyone if familiar with excel, this discussion would not be complete without a few chart example produced from the raw CSV file.

But when the CSV file was opened using Excel, a couple of issues had to be addressed first before plotting the data.

  1. The timestamp field was shown in scientific format. this was corrected by changing the format from “General” to “Number” with 0 decimal places.
  2. The first 3 entries for the spd and alt fields were “null”. These were changed to the value of the 4th entry, the first one with valid values. Note: these values came from the GPS API in the Android code. Neither one accurately represents the actual speed and altitude. Yet the google plots were accurate. This problem was due to assuming the parameter units incorrectly:
    1. The altitude was reported in meters. Since we were looking for feet, it must be converted using the scale factor
      of 3.28084 feet/meter. This has now been corrected in the Android App code.
    2. The speed is reported in meters per second. Since we were looking for MPH, it must be converted using the scale factor of 2.23694 miles/hour per meter/second. This has now been corrected in the Android App code.
    3. For the evaluation of the data collected in excel, two columns were added to perform the conversion: MPH and altitude.Problem with the speed, however, is that many of the samples returned 0 meters/sec as the speed. To solve this, I may introduce a new speed algorithm to the mobile app code to convert two GPS coordinates to distance. This distance, along with the change in timestamp values would be used to calculate speed.
  3. The “dtmp” values (temperature as read by the humidity sensor) are incorrect. The temperature starts at 57.79 degrees while the temperature read by the barometric sensor starts at 80.6. It looked to me like the conversion is missing the “plus 32” in the ESP8266 code. But a review of the code did not reveal any problems. The conversion did include the required “plus 32). I would like to hear from anyone else using the DH22 to see if they are all off in temperature or it is just my sensor that is incorrect. For now, the DH22 temperature reading will be discarded as invalid.

The first thing I tried was to plot the coordinates over the ESP system time(seconds since reset).

excel1

Problem with this plot is the relatively small change in latitude and longitude. It essentially looks like a straight line. This was easily rectified by plotting the latitude and longitude separately.

exce2.
Okay, and now let’s plot the elevation again, like we did with the GPS visualizer.

exce3
Yes, this does look the same as the GPS Visualizer. Except colorizing the plot with a 3rd parameter is not an option. Even with just these few sample plots, I am definitely liking the visualizer of standard Excel charts.

Conclusion

As you can see, there is more than one option available to visually represent data collected with IoT sensors. And it is worthwhile to investigate tools that may be readily available before attempting to build your own charts, from scratch. Here we just explored a fraction of what is available for this purpose.

Phase 4: Mobile App Gadgets is next. In that post, I am going to add some visualizations to the Android application. This will add a real-time visual element to the crude data windows created in phase 1.

I hope you find this information useful…

Loading

Share This:
FacebooktwitterredditpinterestlinkedintumblrFacebooktwitterredditpinterestlinkedintumblr

Mobile Web Sensors Using ESP8266 – Phase 2: Data Recorder

16th August 2015 by InternetOfHomeThings in All Posts, ESP8266 : An IoT System on Chip, Internet of Things | 1 Comment

Collecting data from sensors and displaying them on your phone while you are on the go is great, but without a storage method the data is lost. Sure, you could snap a picture of the display, but that is just a frozen set of data points. And not in a format suitable for data analysis.

I thought this might be a difficult task. But much to my surprise, it was amazingly simple to save data to a non-volatile file on the smartphone’s SDcard.

Here is how it’s done…

Starting with the data collection framework from Phase 1 of this Mobile Sensor series, we now add code to record the sensor data as it is sampled. To make things simple yet useful, each data set will be saved in CSV (comma separated value) format. The file, consisting of a series of data sets, can then easily be imported as an excel spreadsheet.

The FileSystem API will be used to open and save the data to an Android device SDcard. Fortunately, the code developed for Phase 1 of this project already has the required permissions included so we can gain access to the OS file system. First, the projects res/xml/config.xml must include the following feature:

<feature name="File">
    <param name="android-package" value="org.apache.cordova.file.FileUtils" />
    <param name="onload" value="true" />
</feature>

And the AndroidManifest.xml file must include the permission:

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

Since there are two sources of inputs (the gps sensor and the ESP8266), two CSV strings are built at the time the data is received. The GPS CSV string is added to the “onGeoSuccess()” callback:

gpssavestring = position.timestamp + "," 
              + "," + long.substring(0, 12)
              + "," + latt.substring(0, 11) 
              +,"," + position.coords.speed
              + "," + position.coords.altitude;

Five geo values are to be saved: UTC when coordinates were received, lat, long, speed and altitude.

Likewise, a CSV string is created each time the weather sensors are updated in the function updateWeatherSensorData():

 sensavestring = "," + thedata.B_Temperature 
               + "," + thedata.DH_Temperature
               + "," + thedata.B_Pressure
               + "," + thedata.DH_Humidity
               + "," + thedata.SYS_Time
               + "," + thedata.SYS_Heap
               + "," + thedata.SYS_Loopcnt + "\n";

Finally, the two CSV strings are concatinated and written to a file on the SDcard using the File System API:

//--------------------------------------------
//Update Save Data to File 
//--------------------------------------------
function saveData2File() {
	window.requestFileSystem(LocalFileSystem.PERSISTENT, 0, gotFS, fail);
}
function gotFS(fileSystem) {
    fileSystem.root.getFile("mydata/dsa.csv", {create: true, exclusive: false}, gotFileEntry, fail);
}

function gotFileEntry(fileEntry) {
    fileEntry.createWriter(gotFileWriter, fail);
}

function gotFileWriter(writer) {
    if(gotFileWriter.started == undefined) {
        gotFileWriter.started = 0;
        gotFileWriter.tosave = "initial";
    }
    if(gotFileWriter.started!=1234) {
        if(writer.length>0) {
            writer.truncate(0);
        }
	    writer.seek(0);
	    writer.write("timestamp,lat,lon,spd,alt,btmp,dtmp,bp,dh,,syst,sysh,syslp\n");
        gotFileWriter.started=1234;
    }
    if(gotFileWriter.tosave != gpssavestring) {
        save2filestring = gpssavestring + sensavestring;
        gotFileWriter.tosave = gpssavestring; 
        writer.seek(writer.length);
        writer.write(save2filestring);
    }
}

Note that the data is saved to a hard coded path/filename on the Android Smartphone SDCard (mydata/dsa.csv). Before running this project, the folder mydata must be created on your phone’s SDCard.

The code for mobile data sensors with data recording is available on Github here.

Conclusion

That’s it. This mobile sensor project now saves the data captured to an SDcard file. It’s time to take the system out on a mobile excursion. I’m going to take this project out for a ride on my bicycle now to collect some data samples. In the next phase, the data collected will be imported into excel and google maps to produce more visually appealing representations of the information.

Loading

Share This:
FacebooktwitterredditpinterestlinkedintumblrFacebooktwitterredditpinterestlinkedintumblr

ESP8266 Amazon Web Service (AWS) API

10th August 2015 by InternetOfHomeThings in All Posts, ESP8266 : An IoT System on Chip, Internet of Things | 6 Comments

Using AWS Cloud services for the Internet of Things back-end can be beneficial for applications of all sizes, small to very large. Small and simple DIY home projects can leverage the power of AWS services while staying within the no-cost free-tier level of usage. And the larger systems, with many sensor and control devices can take advantage of the reliability and virtually unlimited scalability that AWS offers.

If you have an urgent need for an AWS API for the ESP8266 right now, I have placed it on GitHub here.

My initial interest was in some simple home automation projects. And I was planning to use the ultra-cheap ESP8266 to push my sensor readings up to the AWS database storage services and the receive control commands from the AWS Lambda service.

But there was a problem.

I could not find an API targeted for the ESP8266 in the AWS SDK. Yet the solution was right there….within the SDK. All that had to be done was to adapt one of the currently supported micro-controller APIs for use with the ESP8266. After reviewing the APIs offered, the one that had the most in common with the ESP8266 was the Spark Core API.

My first step was to build and test the sample code for the Spark Core (now known as “Particle”). Fortunately, I had a Spark Core device available for this purpose. While there were a few issues with the SDK library which caused the compile process to fail, it did not take long to get working Spark Core/AWS sample application up and running. Code changes included:

AWSClient2.cpp         
Change: Declarations missing for AWS_DATE_LEN2, AWS_TIME_LEN2 and HASH_HEX_LEN2

AmazonDynamoDBClient.h
Change: Added "MinimalList<MinimalString > SS;" to the class "AttributeValue"

After correcting the SDK code, the compile completed successful. And the subsequent testing on my device confirmed the functionality of the API, interfacing flawlessly with AWS.

The next step was to compile this SDK code with the Arduino IDE for ESP8266.

Since both the Spark Core and the Arduino IDE for ESP8266 used the sketch/library model, the structure of the API did not have to be revised. The device specific library code was put in the  Esp8266AWSImplementations.h/.cpp files.

The most significant thing missing from the ESP8266 base library was a time server. The function “updateCurTime()” was added to the Esp8266AWSImplementations.cpp file to fill that void. That function attempts to retrieve the current time in JSON format from a yahoo timeserver. While the timeserver URL works properly from a web browser, an error is returned from the ESP8266 “http GET” request. But, fortunately, the http error response includes the current GMT time. Since that is what is needed for the AWS API, it is simply scraped off the response string and used to build an AWS request.

I also revised the AWS demo program (designed for the Spark Core) to eliminate the need for a switch trigger. Instead of initiating an AWS request from the change in state of a switch, the AWS API interface is tested continuously in the sketch’s loop() function.

This is what the demo sketch does:

setup()
- connects to your local Wifi and initializes an AWS database client.
- a web server is also started, but is not used for this demo sketch
 
loop()
- first gets the current RGB values from a dynamoDB table
- then sets the dynamoDB table RGB values to an increment of the value from the 'get'

The next step

With this framework, you can exploit the low cost implementation of AWS Cloud-based IoT systems of all sizes. Sure, many applications can be handled locally within the confines of your network enabled ESP8266. But that solution has limited scalability, and is subject down-time associated with power outages and system crashes.

Here are just a few applications that come to mind for AWS Cloud IoT systems for the DIY explorer:

  1. Home Security: Apply some redundancy to your local system by pushing your sensor values and even camera images up to the AWS Cloud at a consistent interval. Then, apply ITTT (if this then that) logic running on your AWS account to take action (send text or email or phone someone or sound an alarm) when a sensor detects an intruder, power outage (sensor updates stopped), fire, smoke, water leak, ect.
  2. Hot attic: When an attic sensor (sent to the AWS Cloud) exceeds a trigger temperature, the AWS Cloud sends a command to your local ESP8266 to turn on a fan to vent the heat.
  3. Water usage: If the water flow meter readings (sent to AWS regularly from an ESP8266) senses unusual water flow, a signal is sent by the AWS Cloud to an ESP8266 based control valve to shut the water off. This sort of thing can be scaled to distribute the monitoring and control to each and every valve and faucet in the house, so that the problem is isolated to it’s source.

Conclusion

There are many more IoT applications that can marry the ESP8266 with the AWS Cloud computing resources. Almost anything you can imagine can now become a reality; and for a tiny fraction of the cost needed just a short time ago. The API presented here brings the low-cost network enabled sensor/control power of the ESP8266 SoC to the all encompassing AWS Cloud.

I hope you find this information useful.

Loading

Share This:
FacebooktwitterredditpinterestlinkedintumblrFacebooktwitterredditpinterestlinkedintumblr