RHDS Final Report — What we accomplished

Executive Summary:

We undertook this challenge with a thought in mind; “Imagine being able to reduce your home energy bill, increase comfort, and create a healthier living environment on the planet”. Yes we had our share of skeptics come forward. Nevertheless we pursued our goal. The motivational factor for us to enter this competition was the following statement found on the Challenge: main page: “At Eclipse we are developing a community of IOT projects that make it easy for developers to build IoT solutions”. That was enough for us to enter the IOT challenge and find out for ourselves.


We are pleased to report that, based on our experience, indeed it’s a valid point. The RHDS project, from our perspective, is a success and was relatively easy to assemble. Thanks in part to many sources of available open source software components with examples.

It was not all smooth sailing, mainly due to numerous learning curves. That

aside, we were able to build a working IOT solution in the time frame allowed. 

RHDS is a fully functional, scabable and stable system which moves 
raw data from a group of Sensors to the cloud for processing and presentation. 
That was project goal number "Build an IOT solution". Please see our blogs for 
a full  functional overview. overview.

Project goal number two was “put the IOT solution to work”. The use case is to help Homeowners and/or Service organization monitor,self-diagnose and optimize energy consumption related to Heating and Cooling and thereby reduce their homes carbon footprint. Our aim was to prove it is possible to apply Building Science physics to an IOT solution to reproduce the result of a home Energy Audit (EA). Presently, an EA is the established method to determine a households energy consumption and carbon footprint. We are please to report that it is possible to reproduce the measurements of an EA using IOT components and the results can be see here. Following are the EA numbers we were to reproduce. Please see our third blog to find out about Energy Audits and what these represent. The key numbers in an EA report are as follows:

  • Design Heat Loss
  • Estimated Annual Space Heating Energy Consumption
  • Estimated Green House Gas emissions
  • Air Changes per hour (ACH)

We are pleased to report that we are able to reproduce the EA numbers with a high degree of accuracy. RHDS operates as a “do-it-yourself” (DIY) Energy Audit system. This means that the average home owner can, if they so choose to, learn more about their Heating and Cooling energy use and lowering their homes carbon footprint. We believe that the system can be built with $200 or less. A one time Energy Audit can set someone back $300 – $500. RHDS at a price point of around $200 has a solid  Return On Investment (ROI).

We did have a third goal for RHDS which perhaps in hind sight was a bit ambitious. We wanted to implement a Device Management (DM) capability for my Heating Ventilation Air Conditioning (HVAC) unit; “the furnace”. Attempting to interface directly with my homes HVAC system was not a good idea. After several consultation with those in the know we were advised against proceeding without input from the manufacturer. So we decided not to go beyond basic connectivity, between Leshan and Wakaama, as a DM proof of concept. For the time being we can demonstrate that Device Management is potentially feasible with respect to managing an HVAC unit. More work needs to be done to make DM a reality.

But wait. While trying to interface to the HVAC we ended up in an interesting scenario. With all the back and forth with different HVAC specialist, etc, we had a “break thru” and serendipity happened. RHDS evolved into a totally passive system. This is big news! RHDS can be implemented without the need to connect to anything other than the TI sensortags. By using analytics RHDS can follow and approximate the HVAC on and off cycle. No need to connect to the “furnace”, which means RHDS really is very close to a “plug and play” type system. As a side note, approximating the HVAC on/off cycle helped us to provide value added metrics and go beyond the basic EA reporting.

On the topic of “plug and play”, we are also pleased to report a second break thru. Sensors can be added at will. KURA will automatically scan and pick up the BLE TI sensortags and send the captured data, via MQTT, up to the cloud, see here. This was completely unexpected. We thought manual intervention would be required when adding Sensors; ie. having to adjust a config file somewhere. Turns out not. Thank you KURA!

I mentioned serendipity earlier. This happened when we began to network with HVAC specialist. They said, “you can do what!”. We have entered into encouraging discussions with two organization to see what can be done to move things forward. “Sensoring” up a home seems to be of interest for a variety reasons! IOT makes things happen.

The remainder of this report will focus on specific details we were asked to discuss. I also go thru the User Interface in detail in the attached video

Project Description:

What is RHDS?:

RHDS is SMART ENERGY IOT solution for performing Residential Home Diagnostics. The Solution allows Homeowners and/or Service organization to monitor, self-diagnose and optimize energy consumption related to Heating and Cooling. The system goal is to promote efficient energy management at the consumer level in support of Smart Cities which are greener and more sustainable.

In essence RHDS performs a near real-time home Home Energy Audit on a minute by minute basis

Our Goal:

Our opinion is that a diagnostic system, like RHDS, in the hands of a homeowners would allow them to make more informed home improvement decisions, perhaps improvements that are more adaptable and responsive to seasonal weather change. The obvious net benefits would be to drive down energy cost, improve comfort and reduce their carbon output footprint.

retrofit work can result in energy savings and a carbon reduction of potentially 60-80% — Source

The Challenge we All face — Long Term Sustainability:

In a typical home, heating and cooling accounts for more than half of the energy use, making it the largest expense for most home owners. Simultaneously, governments are raising the bar for compliance with energy standards and reduction in carbon footprints. Calling in an expert to perform an energy audit can cost between $300- $500 per visit.

the average person in an industrialized country has a carbon footprint of 11 tons of CO2 per year. However, the estimated target for long-term sustainability is only 2 tons of CO2 per year! — source

Our Solution:

RHDS, as an IOT Open Source / Open technology initiative which tracks the efficiency of a home’s Building Envelope (thermal performance) by consistently measuring the time it takes to heat a building up to a given temperature above the outside temperature; vice versa for cooling. Using various, well known, Building Science formulas for calculating Heat loss thru a Building envelope., RHDS is able to, in near real-time, calculate and present the Key Metrics of a professional Energy Audit.

Some of the benefits of visualizing “Heat Loss” are as follows:

  1. Assist a home owner to lower their Home Carbon Footprint;
  2. Determine a households suitability for retrofit work.
  3. Validate energy savings retrofit work thru “after the work is done” performance improvement monitoring;
  4. Verify HVAC (Heating, Ventilation and Air Conditioning) system sizing, an over or undersized condition based on actual performance;
  5. Detect HVAC and supporting control systems operational faults such as no heat;
  6. Improve homeowner comfortability;
  7. Education. Help people understand the value of using Smart Home products towards lowering energy consumption and improving the indoor environment.

Technical Details

data-flowThe entire system has been documented in our last four (4) blogs. We will not at this time rehash all the technical aspects since it’s readily accessible. Please see the following blogs for the System Overview and Technical aspects. We address the following topics:

System overview and Technical details outlined include:

  • Introduction, Goals and Objectives
  • Components and Installation
  • Extract, Transform and Load (ETL) aspects
  • Data Warehousing
  • User Interface (UI)
  • Sensor Placement

Blog #1: Introducing the Residential Home Diagnostic System (RHDS)

In our first blog we out outline our motivation for entering the challenge and layout our approach on “how to” deliver a working RHDS in the time allotted.

Blog #2 Project Update — Let’s Build a RHDS System from Scratch (part 1)

In the second blog we discuss all the “Bits & Pieces” of the system, the hardware and software components, and how to put them together to build the base RHDS platform.

Blog #3 Energy Audit — Let’s get some baseline data for the project

For the third blog we go thru how an actual an actual Home Energy Audit (EA) is done and show the Home Owner version of the EA report produced by the HOT 2000 EA application. The HOT 2000 report served as the “baseline” reference we used to validate the empirical data produced by RHDS.

Blog #4 Project Update — Let’s Build a RHDS System from Scratch (part II)

The fourth blog covers in detail the system architecture, data flow model, User interface and much, much more. Here you will read about how the system works form end to end, from gathering data from the Sensor, to moving the data to the Cloud, to accessing the data via a public URL, to the Presentation layer User Interface (UI)

Public REST URL (live):AWS REST API (JSON Data)

User Interface (live): Working RHDS System (best viewed w/ Safari browser)

What did we learn?:

  • Don’t listen to those that say it can’t be done.
    • When we started the project we really didn’t know if we could do it. You have to believe in what you are doing.
  • The value of Blogging.
    • No of us on the team ever ran a blog before. As the project moved forward the benefits became obvious. Beyond just sharing our progress, the blog took on a unique role of serving both as a Documentation resource for the team. It’s amazing how many times I’ve gone back to our own Blog for Info.
  • Look forward to success.
    • We experience several moments of doubt throughout the project. Giving up is easy, treading on is hard. Keep the  project vision in mind and look toward success.
  • The quality and support behind Open source / Open technology is impressive.
    • I can’t say enough of how we appreciate the help we received to resolve our technical issues from the unsung heroes working the Forums. The fact that I’m in a position to write  this blog speaks to how valuable they are!
  • The small Team Effect:
    • We only had three people on the team. What we were able to accomplish as a team working together speaks for it self. You don’t always need an army to make things happen. Small teams properly motivated can be made to work.

What Open Source and Open Technology did we use?:

  1. Eclipse (software): Acted as our Integrated Development Environment (IDE). All development was done using Eclipse IDE.
  2. Eclipse KURA: System Gateway. Performs the function of collecting senor data and then pushing it the data to the cloud.
    1. Implementation details can be viewed at: Project Update — Let’s Build a RHDS System from Scratch (part II)
  3. Eclipse Leshan: OMA LWM2M server for Device Management: 
    1. Implementation details can be viewed at:Project Update — Let’s Build a RHDS System from Scratch (part 1)
  4. Eclipse Wakkaama: LWM2M Client/Server for Device Management:
    1. Implementation details can be viewed at:Project Update — Let’s Build a RHDS System from Scratch (part 1)
  5. Freeboard.io: a rapid prototyping real-time IOT dash board User Interface; Our UI
    1. Implementation details can be viewed at: Project Update — Let’s Build a RHDS System from Scratch (part II)
  6. Mongodb: NoSQL cross-platform documented-oriented database; provided Data warehouse functionality:
    1. Implementation details can be viewed at: Project Update — Let’s Build a RHDS System from Scratch (part II)
  7. json-server: Rapid pro-typing JSON REST API.
    1. Implementation details can be viewed at:Project Update — Let’s Build a RHDS System from Scratch (part 1)
  8. Protocols:
    1. MQTT, CoAP, LWM2M. Implementation details can be viewed at: Project Update — Let’s Build a RHDS System from Scratch (part 1); Project Update — Let’s Build a RHDS System from Scratch (part II)

Note: We did use COTs solutions: Amazon Web Services (AWS) for the Cloud storage and REST API., and Texas Instruments Sensor tag cc2650 for Temperature and Humidity data.

What is the applicability of RHDS to a specific Industry?

Smart Cities: “Lower the Carbon Foot print of a home.. In essence help city mangers to meet their climate change targets by empowering  home owners and property managers to do their part”

Smart Grid: “Improve the uptake rate for Utility Demand Management initiatives by providing visibility into a homes real-time energy use. Presently uptake on these programs is low due to homeowner skepticism. With RHDS both utility companies and their customers can visualize the impact of Demand Management initiatives on a case by case basis. In other words, both parties can see whats’ going on when the utility company decides to turn off the heat or air conditioning to protect the Energy Grid during Winter and Summer peaking periods”

Smart energy: “Visualize energy use. The first step towards implementing any sort of a strategy to use a renewable energy source is to better understand actual seasonal energy consumption. To this end RHDS can assist by tracking the day to day energy demand of a home. This information would play a key role in helping to “right-size” alternative energy sources”

Heating Ventilation Air Conditioning:

  • “A tool to assist with reducing the time it takes to do heat load calculation. This would improve upon the conventional method today which is a lengthy manual process and quite often not done which leads to improper HVAC sizing, increased energy use, higher carbon footprint”
  • “Opportunities to improve home comfort by visually sharing with the home owner their actual indoor environmental conditions”
  • “Implementing IOT device Management to monitor HVAC operation. This would lead to reduced truck rolls, better customer support and increased system up time”

Home Retrofit Industry: a tool to assist home renovation companies to encourage home owners to implement; weatherization, insulation, window doors and exterior wall improvements”

Education for Students and Home Owners: “provide real-time information, at home., which can be used to better understand and learn about the impact of behavioral choice issues related to home heating and Cooling. At present this information eludes most home owners as it;s simply not available to them without  having an expert perform an Energy Audit. This is not only expensive but impractical as there are simply not  enough Auditors to go around to each and every home. This situation is ripe for an IOT solution (RHDS) to enter the picture”

Final Words:

Thank you to the IOT challenge organizers and other Team participants for their encouragement and support throughout the challenge.

Climate change is real. The bar for compliance with energy standards and reduction in carbon footprints is real and is rising. Thanks to ongoing Internet of Things (IOT) initiatives, we can do our part to lesson the effect of climate change at a price point affordable to all. The task of lowering the average families carbon foot print seems overwhelming but it brings to light the opportunity before us to change things starting right at home..

Please support our fight to slow climate change and support our project, and remember:

“The Changes We Make At Home Today Will Have a Global Impact on the World Tomorrow”

Project Update — Let’s Build a RHDS System from Scratch (part II)


In this tutorial, we will conclude the series on how we built our “Energy Modelling” system. The working RHDS system can be seen here. The best browser to use is Safari. Here’s an example of what you will see.


We will cover the following areas in this tutorial:

  • Extract, Transform and Load (ETL) aspects
  • Data Warehousing
  • User Interface (UI)
  • Sensor Placement

To recap, the system use case is to help homeowners self-diagnose and optimize energy consumption related to Heating and Cooling. The main purpose of RHDS is to measure conduction heat loss through the building envelope and report on Green House Gas/Carbon output, Energy consumption and home comfort aspects.

The system is implemented as a “Service Platform” with Device management capabilities to allow third parties to provide support to the homeowner.

Let’s begin with a brief overview of the system and data flow model.

preliminary_architectureSystem Description: Things have progressed since the last update. We were able to simplify the data flow architecture thereby improving system integrity.The base hardware platform is still the Raspberry Pi 2. The IoT gateway application is Eclipse Kura. To measure the indoor environment conditions such as temperature and humidity we use the TI Sensortag. We continue to use Mongodb as a local data store primarily for data staging and data cleansing. To measure external outdoor conditions we use Internet available weather data. The End user and Service application is Freeboard. The cloud platform is Amazon Web Services (AWS)

Note: Device Management of the Gateway and HVAC (Heat, Ventilation, Air Conditioning system) is done thru an NXP microcontroller, Eclipse Leshan and Wakaama. As Device management was a secondary priority, we decided not to go beyond basic connectivity aspects already covered in Part 1. We were advised against interfacing with a live Heating System w/o professional input. As a proof-of-concept, basic connectivity between Leshan and Wakaama is sufficient toward demonstrating that Device Management is feasible in respect to managing a HVAC unit.

data-flowDataflow Model: The heart of the system is Kura an IOT Gateway. Its primary job is to (1) connect to multiple TI Sensortags, via BLE, and (2) packetize the sensor data into a JSON format and (3) create an MQTT data stream back to Amazon AWS for cloud storage (Data Warehouse). Kura’s secondary responsibility is to push a copy of the sensor data, JSON format, to a local Data Store running on Mongodb. The fronted UI application is Freeboard, “a damn-sexy, open source real-time dashboard builder”. Freeboard is served with JSON data from Amazon Dynamodb thru the Amazon API Gateway REST interface. Device Management is provided by Leshan and Wakaama utilizing LWM2M and CoAP protocols.

Connect the Senor Data to the Cloud

etl_2Establishing a robust ETL mechanism to collect sensor data and push it to the cloud was the most complex part of the project. Since a major objective was to implement RHDS as a Service Platform, reliability and scalability were paramount consideration. Our biggest challenge turned out to be working in an OSGI scenario. None of us on the team had any experience with OSGI. Creating the Kura bundle is not really the challenge. It’s setting up the project manifest correctly. Once that’s understood, it’s pretty much pure JAVA coding. We are very grateful for the assistance provided by the folks working the Eclipse Kura Forum to help us sort out our OSGI issues.

We were very fortunate to be able to use an example Kura project (org.eclipse. kura.example.ble.tisensortag) as the code base to collect and forward the sensor data. It had most of what we needed. It provided a seamless BLE connection process to the TI Sensortag and solid integration points for our valued modules and a simple to implement MQTT payload interface.

After we got the “example.ble.tisensortag” project working the way we wanted it was just a matter of adding various value added software components and integrating them. We will post the entire project on Github as soon. In the meantime here are a few examples of some of the components.

To connect Kura to Mongo we use the Mongo API (java-java-driver-3.4.1.jar) To get it to work in an OSGI fashion we constructed the project manifest like this. Here is an example of the java class we created to connect and work with Mongodb.

To collect the sensor data from Mongo using Kura we did this.

To collect weather data from Environment Canada we did this.

We use Python scripts to do data cleansing, staging and to create value added data.

Data Warehouse

data-warehouseWe implemented two data warehouses for “lack of time sake”. We use Mongodb which runs on the Pi2 and Dynamodb which is part of the AWS cloud service. Mongodb was used for two purposes. The first is to act as “data-pick-up” staging area for Kura. All data forward by Kura via MQTT to Amazon is first staged. The second purpose was to provide a platform to allow for data cleaning prior to forwarding the data to AWS, and enable a way to add value data processing outside of Kura. We recognize that the second function could have been accomplished ALL in the cloud (AWS). However we felt the learning curve to implement unfamiliar AWS services would jeopardize our ability to deliver the project on time.

The interface to Mongodb was implemented using the Mongodb Java driver as explained in the previous section and pymongo API for scripting. All valued data processing was done using Python scripting. Fast and easy!

Connecting the MQTT data stream to AWS Dynamodb is amazingly straight forward. The trick is twofold. 1) Ensure the JSON Key value pairs are all at the root level of the JSON string. If this consideration is acceptable the Dynamodb will automatically load the MQTT payload in a table of your choice. Dynamodb Table selection is achieved thru setting of a AWS rule to match the MQTT Topic. Use the “Split Message – DynamodbV2” option under rule setup for automatically loading MQTT payloads in columns. Also, adding a new column to Dynamodb is a breeze. Just add the new key value pair to the MQTT payload. There is one note of caution. Ensure there are no JSON Key value pairs that contain empty strings like: {“foo“: “”}. If so, the entire MQTT packet will be not be loaded into Dynamodb. That was fun to figure out!

REST API Gateway (AWS)

rest-apiTo serve the User Interface (UI) with JSON data we implemented the AWS “API Gateway service” https://aws.amazon.com/api-gateway/  Although at first the learning curve was high, in hindsight it’s not that bad. Implementing a new REST interface can be done in minutes. There is an excellent video here which discuss the process here:

In the end it comes down to (1) making sure that the API Gateway service has the proper access privileges to AWS Dynamodb. This is all explained in the YouTube example video, (2) setting up the db query properly (Integration Request, see diagram) and (3) transforming the data (Integration Response, see diagram) from Dynamodb format to JSON. Code snippets for step (2) and (3) are here.

User Interface (URL)

The public User Interface (UI) is served up using Freeboard: It’s very easy to use and ideal for prototyping scenarios. To get a “dashboard like” view going simply connect an external “datasource” to a FB view object (pane). In our case we are serving up JSON data via an AWS REST interface which is front ending the AWS Dynamodb data warehouse containing the sensor and value added data.

You can see our public AWS REST API example URL here: https://aut9f18u61.execute-api.us-east-2.amazonaws.com/beta10/uisplitapi/dbjson

screen-shot-exampleThe following is an example of the current FB Dashboard UI which is operating on a “real-time” basis.




These are the main UI components:

  • Sensor Connectivity Panel
    • Show the status of connected sensors; very handy for troubleshooting
  • External Environmental Conditions
    • These is basically a mini weather station, the data is required to perform most of our calculations; a weather station is nice side benefit from the project
  • Internal Environmental Conditions
    • Sensor data; Temperature and Humidity; excellent for assessing temperature variances in the home. Now my wife can prove her office is the coldest room!
  • Building Envelope Energy Heat Loss (BTU / kWh)
    • Equivalent to Energy Audit Design Heat Loss; this number represent how much energy is used to heat/cool the home per hour
  • Green House Gas Carbon Output
    • Equivalent to Energy Audit Estimated Green House Gas Emissions; this number presents the yearly estimated Carbon Output (Footprint) of the home
  • Energy Audit data vs. Empirical comparison chart
    • The chart shows the delta between the Energy Audit Heat Load Assessment and RHDS derived values. There are actually three lines on the chart. The EA assessment and RDHS line up exactly and are shown one on top of the other. The third line, which show a minor deviation represent where we started. We call the Graph Line — the “Text Book” assessment.
  • Air Changes per Hour (ACH)
    • Equivalent to Energy Audit Estimated ACH; we were able to calculate the ACH rate and the deviation between EA and RHDS is absolutely negligible. Although we show ACH with a decimal point value, in practical terms it’s not really relevant to assessing the number of air changes per hour.
  • HVAC cycles per hour
    • A representation of how often the HVAC unit is cycling per hour; this number can be used to asses how efficiently the HVAC unit is performing and how well the home building envelope is performing. The shorter the HVAC cycles On and the longer is stay Off translates to lower energy bills and CARBON output. Now the home owner can see whats going on!
  • Indoor Temperature Hysteresis
    • Shows the hi-low range of temperatures in the house; this can be used to optimize the Home Thermostat setting to the appropriate comfort level. It also indicates whether or not the Thermostat is operating correctly, as they do fail. The homeowner should not see more then a 1C temperature swing. Anything more means it’s time to replace the Thermostat.
  • Indoor Comfort level / Humidity Analysis
    • Indicates the comfort level in the home; typically homes should operate between 40% and 60%. Below 40% is typically too dry and above 60% is typically too moist.

Sensor Placement

sensor-orientWhere to place the sensors was an iterative process. In the end we went with four (4) sensors to measure the Temperature and Humidity. The ideas was to “ZONE” off the home into four (4) quadrants, North, South, East and West. This gave us (1) the most consistent results and (2) provides a real-life view of how the homes Building Envelope performs relative to its geographical orientation ( “compass points”). Now the homeowner can see the hot and cold zones and make the necessary adjustments to improve heating and cooling efficiency by re-purposing the hot/cold air to where it’s needed or not.

That concludes this tutorial. We will provide more information related to RHDS system Application and Use in the final wrap-up Video-Blog.

Energy Audit — Let’s get some baseline data for the project

In this tutorial we will we take you through an actual home Energy Audit (EA) and share the report that the Energy Advisor produced.

So why did we need to do an EA? We needed to establish the actual energy use of my home. The EA data will serve as a baseline reference and help to validate the information produced by RHDS. Since we needed to do an EA to get the baseline data we decided to video the process and share it with you.

We have attached the actual report, you can view it here: https://github.com/tmorocz/RHDS/blob/master/HLHG%20-%20TM.pdf

The energy use “baseline data” we were after is show below. These are the reference data points we will use to validate the empirical data produced by RHDS. If the numbers from the EA line up with RHDS we will know the the system is producing valid energy modeling information.

Key EA Numbers:

  • Design Heat Loss at -16.60 F: 44797.24 BTU/hr
  • Estimated Annual Space Heating Energy Consumption: 27747.17 kWh
  • Estimated Green House Gas emissions: 12.506 tonnes/year
  • Air Changes per hour (ACH): 1.68 /hr.

For more information concerning an Energy Audit you can check out the site at National Resources Canada (NRCAN): http://www.nrcan.gc.ca/energy/efficiency/housing/home-improvements/5005



Project Update — Let’s Build a RHDS System from Scratch (part 1)


In this tutorial we will outline how we built our “Energy Modelling” system that measures conduction, heat loss through the building envelope. To recap, the system use case is to help homeowners self-diagnose and optimize energy consumption related to Heating and Cooling. The system is implemented as a “Service Platform” with Device management capabilities to allow third parties to provide support to the homeowner.

All software components are Open Source or purpose built and the hardware components are COTS (commercial off-the-shelf).

Overall the construction of the first RHDS went smoothly. However, integrating KURA with Mongo-dB was more technically challenging than we would have preferred. The Eclipse Forum folks helped us work thru our scenario. We now have a much better understanding on how to build an OSGI bundle for KURA.

This tutorial will focus on installation of the major system building blocks. We will follow up this tutorial with part II which will discuss the purpose built application software, system modifications and operation.

Let’s begin!

System Description:

preliminary_architectureThe base hardware platform is a Raspberry Pi 2. The IOT gateway application is Eclipse Kura. At project launch Kura did not support PI-3. That has since changed, but we stayed with the Pi-2, for now. To measure the indoor environment conditions such as temperature and humidity we use the TI Sensortag. For external outdoor conditions we use Internet available weather data. Device Management of the Gateway and HVAC (Heat, Ventilation, Air Conditioning system) is done thru an NXP microcontroller, using Eclipse Leshan and Wakaama. The End user and Service application is Freeboard. The cloud platform is AWS, Amazon Web Services.

Major system components:



  • (1) Raspberry PI 2
  • (1) Power Supply 5,25V/2.4A
  • (1) Bluetooth 4.0 LE USB adapter
  • (1) Wi-Fi Nano USB adapter; EDIMAX N150
  • (1) Kingston 16GB SD
  • (4) Texas Instruments Sensortag 2650 V1.3
  • (1) mbed NXP LPC1768
  • (1) mbed Application Board (for LPC1768)


Data-flow Model:

dataflowThe heart of the system is Kura an IOT Gateway. Its primary job is to (1) connect to multiple TI Sensortags, via BLE, and (2) packetize the sensor data into a JSON format and (3) create an MQTT data stream back to Amazon AWS for cloud storage. Kura’s secondary responsibility is to push a copy of the sensor data, JSON format, to a local Data Store running on Mongodb.  Freeboard, a damn-sexy, open source real-time dashboard builder is the fronted UI application. Freeboard is served with JSON sensor data by JSON-SERVER, a simple REST like interface connected to Mongodb. Device Management is provided by Leshan and Wakaama utilizing LWM2M and CoAP protocols.

Installing System Building Blocks: We will cover the basic steps involved. There are plenty of excellent guides available on the net, if you get stuck “google is your friend”.

Raspberry Pi-2 (Base Hardware Platform): Getting the Raspberry PI operational out-of-the-box is very straight forward and there is plenty of online help available, see: https://www.raspberrypi.org/

The Raspbian OS download site is: https://www.raspberrypi.org/downloads/  For this projects we went with: Raspbian Jessie 2016-09-23

A handy tool for creating the Raspbian SD image can be found at: https://sourceforge.net/projects/win32diskimager/

Once the Pi system is booted up it’s a good idea to do a couple of things, at a minimum. From the console run “sudo raspi-config” and select option 1 and expand the filesystem. Also select option 4 and set up the proper time zone and keyboard setting. From there it’s a good idea to upgrade the OS to the latest and greatest: From the console run “sudo apt-get update” and then “sudo apt-get upgrade”.

Kura V2 (IOT Gateway Application): Eclipse offers excellent resources to get you started.  Everything you need from setting up your IDE to creating the “hello world”. Working examples are also available. The installation instructions are here: https://eclipse.github.io/kura/doc/kura-setup.html

Working examples of Kura OSGI bundles are available. Downloads are here: https://www.eclipse.org/kura/downloads.php

We relied heavily on the following working example to connect to the TI Sensor tags: org.eclipse.kura.example.ble.tisensortag

There is a solid tutorial for connecting Kura to AWS (Amazon Web Servics) here:  https://blog.benjamin-cabe.com/2015/10/23/tutorial-connecting-eclipse-kura-to-aws-iot

Mongodb (Data Base / Store): I found a simple to follow guide for installing Mongodb on a Pi 2 or 3. Everything you need is here:  http://andyfelong.com/2016/01/mongodb-3-0-9-binaries-for-raspberry-pi-2-jessie/

Json-sever (a REST like, simple to use API): This is a very handy tool for prototyping an application where you need to serve up some JSON data in a hurry. It works like a REST server, only you don’t need to do any coding. The installation instructions are here:  https://github.com/typicode/json-server

Freeboard (UI – A damn-sexy, open source real-time dashboard builder for IOT): It doesn’t get any easier to create a simple Dashboard for your IOT application than Freeboard. Just point the system at some JSON and you are done. Get it here: https://github.com/Freeboard/freeboard

You will need a web service to front-end Freeboard. We use a Python service since as it comes bundled with Raspbian OS. To start a web service just change to directory of where Freeboard is installed and issue the following from the Pi console:  “python –m SimpleHTTPServer <preferred-port-number> “

Leshan (Device Management – an OMA Lightweight M2M (LWM2M) implementation): You can find the project here: https://github.com/eclipse/leshan

Get and run the demo server:

Get and run the demo client:

Wakaama (Device End-point Management – LWM2M Client interface): The project can be found here: https://github.com/eclipse/wakaama

In addition there is a working example here for the LPC1768:

Also check out this tutorial which discusses LWM2M, Leshan, Wakaama and LPC1768: https://blog.benjamin-cabe.com/2015/07/08/remote-management-of-an-arm-mbed-device-using-lwm2m-wakaama-leshan

Texas Instruments Sensortag (Sensor Solution): Here is the main site: http://www.ti.com/ww/en/wireless_connectivity/sensortag2015/?INTC=SensorTag&HQS=sensortag

The “Tear Down” section contains a lot of helpful information: http://www.ti.com/ww/en/wireless_connectivity/sensortag2015/tearDown.html

That’s it for now. In a part II follow up we will expand on how we connect things up and introduce the purpose built code.