Indoor Sensing Hub powered by Mozilla Things Framework
December 19, 2018 | #hardware #webofthings #iot #mozilla
The Web of Things aims to build the Internet of Things in a truly open, flexible, and scalable way, using the Web as its application layer. Empowering this idea, Mozilla has been making efforts towards a Web of Things standards, providing a gateway implementation along with libraries for the most common languages. In this blog post, we will go through the process of making a Web of Things device.
Before entering into the details of Web of Things , one must present its origin, the Internet-of-Things. The Internet-of-Things can be seen as the result of the interconnection via the Internet of computing devices embedded in everyday objects, enabling them to send and receive data. This paradigm-shift provoked a ripple effect transforming everyday objects into smart objects, thus being widespread in terms of domains of application.
This paradigm-shift opened a window on new market opportunities that lead to several companies to create new products for these new markets, such as the smart-home. However, despite utopian visions of seamless home automation, the smart home technology market, like every other, is fragmented . Several companies, institutions and other entities (including governmental ones) have been working on standards for assuring the interoperability and reducing the technological fragmentation of IoT.
Web of Things, as part of the Internet-of-Things initiative, proposes the creation a decentralized Internet-of-Things by giving Things URLs on the web to make them linkable and discoverable, and defining a standard data model and APIs to make them interoperable .
Mozilla, as a defender of the mission of “keeping the internet open and accessible to all” and putting efforts on building a better Internet  has embraced the Web of Things initiative and created Project Things . This project distinguishes itself from the other standardization initiatives due to the fact that it is built upon existing web standards such as HTTP, REST, JSON, WebSockets and TLS.
Project Things  is an experimental framework of software and services from Mozilla for connecting “things” to the web and will consist of three main components:
- Web Thing API: A common data model and API for the Web of Things.
- Things Gateway: An implementation of a Web of Things gateway that leverages the Web Thing API.
- Things Cloud: A collection of IoT cloud services.
- Things Framework: A collection of reusable software components for building Web Things, which directly expose the Web Thing API.
The goal of this project is to build a Web of Things device capable of sensing its surroundings by measuring temperature, humidity and sensing motion. Plus be able to show any information in an OLED screen and operating status in a LED.
3D Printed Sensing Hub Box
After searching on Thingiverse we found out this cool 3D printed modular case for a NodeMCU ESP8266 microcontroller. Since it fits my goal of having multiple components, and, even, upgrade it with more components if needed, it was a go-go.
Some modifications were done to this models after printing for fitting a breadboard into the Base_NodeMCU. All the printing was done using an Anet A8 printer.
Parts and Circuits
|1x||PIR Motion Sensor|
|1x||DHT11 Temperature/Humidity Sensor|
|1x||0.96” I2C OLED 128x64 Screen|
|*x||Jump wires (Male-Female)|
The NodeMCU board was picked up since it is cheap, has a built-in wireless shield and is compatible with almost any Arduino libraries and scripts.
All the parts were brought on eBay. You can easily find similar ones on Aliexpress, Amazon or any other hardware parts seller.
Using the Mozilla Things Framework is as easy as adding the
ArduinoJson libraries to the PlatformIO project. Further, for starting a web server in the NodeMCU the
ESP Async WebServer is used.
For the sake of simplicity for reading and writing data from and to the different parts several libs were used, namely:
DHT sensor library: Reading data from the DHT sensor.
Adafruit GFX Library,
OneWire: Writing data on the OLED screen using the I2C connection .
TaskScheduler: For scheduling recurring tasks (due to limitations of the DHT sensor, we cannot read data all the times, so we need to schedule it in the Arduino loop).
After setting up the dependencies, let’s focus on the
Setting up the Internet connection
Using the lib
ESP8266WiFi we can set up the Wireless.
Defining the connection settings:
Setting up the connection:
And we’re now connected to the local network.
Creating a new WebThingAdapter (our web thing)
From this point on we already have our thing being announced to the local network using mDNS  and we can access the device on our browser using the address:
http://indoorsensor.local. The result page presents a JSON (as defined by the Web Thing API) with information about all the devices (components) connected to our thing.
Adding components to our Adapter
This is an example of how to add the DHT sensor to the web thing. A similar process is needed for all the other parts.
Going through the code:
- Firstly we create a component of the thing with the
- Then we add the properties of that specific part with several
- We define a function to retrieve the sensor data
- In this function we create a new
- For each value that we want to update or set we create a temporary variable with the value
value.number = t;and then set this value to the respective
- In this function we create a new
- In each loop we retrieve the values calling the respective function, in the case, the
- At last, we update our adapter with the new data from the sensors.
Connecting all the different components resulted in some extra effort due to particularities of them. Those particularities are described in the following paragraphs.
Reading data from DHT
All the DHT sensors have the need of setting a delay between reads. The documentation mentions a time of approx. 2000 milliseconds between reads. However, the execution period of each loop is lower than that, and it is not guaranteed the exact execution time (can depend on the hardware and components). In order to assure that we just try to read data from the DHT with a given periodicity (above 2000 milis in the case of DHT), we need to keep track of time.
Using the lib
TaskScheduler we can easily create tasks that are executed just at a given time. As an example we can see the following code:
Connecting the OLED Screen
The OLED screen uses I2C communication (reducing the number of pins used). We have a 4 pin connection, the VCC, GND, Serial Data Line (SDA) and Serial Clock Line (SCL) . Using the
Adafruit_SSD1306 for connecting to it, we need to know the hardware address to communicate with it. For finding it out we can use the I2C scanner (gist available here) to check all the pins.
In NodeMCU boards it is recommended to connect any I2C devices to pins D1 and D2 (as presented in the above circuit schematic).
Going through the code:
- Init the
Adafruit_SSD1306lib. In our case the OLED screen doesn’t have a reset pin, so we need to pass a -1 to the function.
- Start the display
- Clean any data that could be on the display and display the data. In this case, the screen must remain empty.
- Call the function that writes to the screen
- The string moz://a iot should appear on the screen.
-> Bonus Tip
In our case, due to the screen used and printing details, we used our screen upside down, so we created a fork of the original Adafruit lib and added a void flip() function that redraws anything on the screen, making it readable in the right direction.
Checking for motion
Since the motion sensor can be triggered at any time, we can’t simply check for motion in the loop. For that purpose, we can use interrupts . So, instead of using the common
pinMode(PIR, INPUT);, we must use the
INPUT_PULLUP flag. This allows us to hook a function when the value of the pin changes (flag
CHANGE). Since we’re working with a digital input, this means that the value changes from 0 to 1 when it senses motion and makes a call to the
motionDetectedInterrupt function toggles the value of the global variable
state when it senses motion, and, then, when it stops sensing it. Then we can easily read this state using the same approach that we used in the case of the DHT sensor, making the boolean data available by calling the respective endpoint.
All the code is available on GitHub.
Resulting JSON Schema
All the data is available by checking the respective
href, and we know a priori the type of data. Further, we can leverage the API to have additional data like descriptions.
In a future post, we gonna talk about accessing the Indoor Sensing Hub data, storing it and, then, visualizing it. And, also, adding MQTT support to it.