3rd Assignment Blog Post

 Power Saver

Power Saver is my series of individual assignments I developed for the IoT 2021 course.

About Power Saver

The aim of power saver is to optimize the power consumption in working places. This is achieved by sensing the environment to detect potential power wastefulness, in terms of artificial lights and heating/cooling system, in the rooms inside a building.

This is achieved by using ambient light intensity and ambient temperature sensors, which periodically measure the light intensity (in lux) and temperature (in °C) respectively. The concept of "power wastefulness" is defined by the following events:

• The lights are on inside a room and the ambient light intensity exceeds a given threshold*.
• The lights are on inside a room while outside the usual working hours (e.g. at night).
• The current season is Summer  (therefore the a/c is supposed to be turned on) and the room's temperature falls below the given lower threshold*  (i.e. the a/c is pumping too much cool air).
• The current season is Winter (therefore the heating system is supposed to be turned on) and the room's temperature exceeds a given upper threshold* (i.e. the system is pumping too much heat).

In the first 2 cases, the light will be turned off by the power saver devices using a relay attached to the illumination system; in the latter 2 cases a RGB led is employed to signal such problems alongside a buzzer which notifies of the status change for a few seconds.

*Note: all the thresholds employed in this series of assignments were chosen after performing multiple measurements with the sensors to decide the most reasonable ones for that kind of sensor based on the received values.

I decided to rely on light and temperature sensors because those two kinds of sensors are also available in the nodes from the FIT/IoT-Lab real-world testbed (used for the 2dn and 3rd assignments) and I was curious to work on real data for these individual assignments.

Assignment 1

The first assignment was developed using:

•  a physical STM-32 nucleo device.
• a photocell (analog sensor).
• a DHT11 humidity & temperature sensor (digital sensor).
• a relay attached to a table lamp.
• a RGB led.
• a passive buzzer.

Here is a picture of the real prototype:

The ambient light intensity and the ambient temperature are measured in parallel (i.e. on two separate threads) at the same time every 30 minutes to detect variations. 

I thought 30 minutes would be a reasonable choice to scan for changes in the ambient, as a lower value would increase the device's consumptions by too much and sensing too often would not make much sense, while a higher value would allow to waste power for too long (in case a bad event happened).

Once the board gets the readings for the light intensity (which is taken 5 times with a 60-second interval and then arithmetically averaged in order to avoid biases during to potential quick variations in the light intensity) and the temperature (which is measured only once in the 30 minute interval, as temperature is more unlikely to change quickly), they are sent to the cloud hosted on the AWS IoT Core facility.  

All the technical details can be found in the relative github repository.

The device communicates with the cloud using the MQTT protocol (mqtt rsmb and a mqtt/sn transparent bridge to support secure communications, which is required by AWS IoT Core).

Once the data reaches the cloud, it is intercepted by an AWS IoT rule and is:

1. put inside a DynamoDB table for history reasons and to display them on the web dashboard.
2. forwarded to an AWS lambda which is tasked with performing the checks described in the "about power saver" section and replying to the device by triggering the available actuators, if needed.

All the readings gathered by the device can be consulted on the web dashboard deployed on AWS Amplify, which uses a series of API Gateways connected to AWS lambdas in order to:

• retrieve the latest readings from the DynamoDB table to show them on the web page.
• activate the device's actuators upon user request.

Conclusions

As it was my first time working on an IoT application, I decided to work on a simple, yet very reasonable in my opinion, idea in order to explore in detail the correct ways to perform the needed tasks and to set up the whole cloud and local infrastructures. I concluded that it was a good choice as it allowed me to explore and study a lot of new technologies and protocols without having to worry about the feasibility or the complexity of my own idea. This was also useful to later work on a more complex idea as the one my group and I developed for our final project.

Assignment 2

For this assignment, the STM nucleo board was replaced by the m3 nodes available in the FIT/IoT-Lab real world testbed, in order to test a deployment involving multiple sensors. The m3 nodes use the  802.15.4 mesh networking technologies and 6LoWPAN protocols to create a wireless sensor network and connect to the internet.

As I previously stated, the m3 nodes are equipped with sensors that allow to measure the ambient light intensity and the temperature intensity, so I did not need to simulate/emulate the read data to send to the cloud, which was really convenient for me as I desired to work on real data for the whole duration of the assignments.

For this assignment I also used an additional m3 node that acted as border router (using the firmware provided by RIOT OS) and an a8 node I used to run the mqtt rsmb broker as well as the mqtt/sn transparent bridge from the first assignment. 

All the technical details can be found in the relative git repository.

The main changes I needed to put in place in this case (with respect to what I developed for the 1st assignment) were:

• to the firmware, as I had to replace the ethos USB technology to get IPv6 connectivity for the nucleo board with the facilities needed to work on a wireless mesh. I also had to change the code for getting the measurements from the sensors, as m3 nodes have different sensors with respect to those I used for the 1st assignment.
• to the web dashboard, in order to display the data coming from multiple devices.

To evaluate the performance of the network, as requested by the assignment, I decided to use the tools provided by the IoT-Lab facility by setting up power and radio consumption profiles for the m3 nodes. I also ran multiple experiments by changing the number of nodes and the topology of the network.

Conclusions

From this assignment I concluded that the mesh networking can present some instability (in terms of packet loss) due to interference in the channel and increasing latency while the topology of the network grew. On the other hand, it was interesting to analyze the results of the performance evaluation of the nodes.

Assignment 3

For the last assignment, the st-lrwan1 nodes from the IoT-Lab facility were employed. These nodes communicate with the cloud using LoRAWAN and TheThingsNetwork. 

Unfortunately this kind of nodes are only equipped with a temperature sensor, therefore I needed to simulate the light intensity readings. 

I decided to integrate The Things Network directly to the AWS IoT Core facility, as it was quite easy to do following the documentation.

Nevertheless, I had to apply several changes to the cloud infrastructure I developed for the first assignment, as due to the integration the messages from the nodes are forwarded to an ad-hoc MQTT topic and the structure of the messages is completely different with respect to the one I designed:

For this reason I had to deploy a new rule to correctly handle these messages and also extend the main lambda by adding the instructions do decode the base64-encoded payload from the devices (stored in the "frm_payload" field) and to store the data to the DynamoDB table (this operation was directly performed by the rule I devised for the previous assignments). 

For the devices, I used the semtech-loramach library from RIOT OS to join TheThingsNetwork and to send the messages to the cloud via the LoRAWAN uplink after base64-encoding them.

Concerning TheThingsNetwork, I created an application and a series of end devices, which provided the information I had to put into my firmware (AppKey and DevEUI) in order for the st-lrwan1 devices to join TheThingsNetwork.

All the technical details can be found in the relative github repository.

About the edge computing part, I decided that the best way to implement edge analytics to be executed within the device (as requested by the assignment) was  to limit the traffic to be sent to the cloud. This was achieved by moving the checks of the light intensity and temperature against the thresholds described above from the cloud to the devices.  In this way, messages are sent from the nodes to the cloud only when an anomalous situation occurs (i.e., one of the sensed values exceeds one of the thresholds); during normal situations (which are verified most of the time) instead, the nodes do not send anything to the cloud. This helps to significantly to reduce the traffic (in terms of number of messages sent every time the sensing phase occurs) and thus also to save power, current, voltage, etc. for the device itself.  As in the previous assignments it was possible to easily change the thresholds once for all the devices (as they were declared in the lambda), to solve  the problem of easily changing the thresholds for this case now the cloud infrastructure also sends their values to the devices alongside the indications to trigger the actuators.  

Conclusions

From this assignment I was able to work with a technology that was completely unknown to me, which I found quite interesting. Moreover, thinking about employing edge analytics ands how to do that in order to save power and reduce traffic was an interesting experience.