FEDER:ESP8266 Experimentation: Difference between revisions

From UNamur InfoSec
Jump to navigation Jump to search
Line 64: Line 64:
We have performed all the scenarios listed in Section I. Since some scenarios require real-time data communication, the response time is out prime investigated parameter.
We have performed all the scenarios listed in Section I. Since some scenarios require real-time data communication, the response time is out prime investigated parameter.
*Local Area Network
*Local Area Network
**System Deployment Description: The wireless network with NetGear access point was set up.  7 micro-controller with 5 different sensors we used to build this wireless sensor network. MQTT-mosquitto private broker was installed in the private  
**System Deployment Description: The wireless network with NetGear access point was set up.  7 micro-controller with 5 different sensors we used to build this wireless sensor network. MQTT-mosquitto private broker was installed in the private network for managing the communication messages between different components of the system (see Figure). An extended XACML policy validation engine is used for controlling the access to different sensors in the network. A java-based application was built, it can be used to remotely control and actuate the devices in the network.  
network for managing the communication messages between different components of the system (see Figure). An extended XACML policy validation engine is used for controlling the access to different sensors in the network. A java-based application was built, it can be used to remotely control and actuate the devices in the network.  
**System Deployment Description
**System Deployment Description
**Observation
**Observation

Revision as of 11:12, 10 March 2017

Summary

We have constructed a Wifi sensor network with ESP8266 Huzzah micro-controllers with different type of sensors such as: Temperature, movement, humidity, luminosity, vibration sensors. We have also developed the access control module to be used to control different devices (sensors) for different testing scenarios. The scenarios are connected to smart home system environment, which is built based on our defined smart home system architecture shown below. It is the functional smart home architecture: IoT SH F architecture.png

1. Device controller is responsible for controlling all the sensors and actuators installed in the network. For example, how the devices join and be registered in the network. Context-handler is responsible for forming/constructing the request query for access control engine. The structure of query depends on the access control engine used and language supported by the engine. For example, XACML engine (https://en.wikipedia.org/wiki/XACML) uses XML language to express the access query and access control policies.

2. Access controller engine is responsible for validating access control policies based on the request from device controller. It is worth noting that in our proposed architecture, multiple access control engine can be used in a network.

3. MQTT Broker is a MQTT server allowing devices (other system components) to publish or subscribe for information.

4. End-Devices are the sensors or actuators installed in the network. Those devices can act as subscriber or publisher.

5. Request-entities are the medium for accessing/controlling/interacting with the system such as, web-app or app-smart-devices.

I. Implementation description

Based on the proposed system architecture, we implemented a complete and functional smart home system with different scenarios required in day-to-day home activities and security/safety. The goal of implementation is to evaluate the system performance and also the effectiveness of the devices used (micro-controllers and sensors). The tests were done for both Local Area Network and Wide Area Network (Internet).

Scenarios

We implemented five different scenarios for smart home environment. They are:

a. Turn on lamp when it is dark and the home owner is at home

b. Turn on alarm when temperature raised above 25 degree C

c. Turn on alarm when movement sensor detects movement and the alarm message is also sent to home owner.

d. Turn-on and off lamp from web-application.

e. Alarm is turned on when strong vibration is detected

List of the complete scenarios can be found in https://doc.info.fundp.ac.be/mediawiki/index.php/File:List_of_Smart_Home_Scenarios.pdf

II.Technologies used

1. Technical specifications: network technologies

Wifi network is used

2. Sensors used

Temperature, humidity, movement, vibration, luminosity

3. Type of microcontroller used

Feather HUZZAH ESP8266

4. Communication and messaging protocol used

MQTT: Mosquitto

5. Implementation: Raspberry pi

6. Access control engine and language

XACML: Extensible access control makeup language

7. Languages:

Java

For more information one can find here. File:IOT FEDER 21 02 2017.pdf

III. Performance analysis and observation

We have performed all the scenarios listed in Section I. Since some scenarios require real-time data communication, the response time is out prime investigated parameter.

  • Local Area Network
    • System Deployment Description: The wireless network with NetGear access point was set up. 7 micro-controller with 5 different sensors we used to build this wireless sensor network. MQTT-mosquitto private broker was installed in the private network for managing the communication messages between different components of the system (see Figure). An extended XACML policy validation engine is used for controlling the access to different sensors in the network. A java-based application was built, it can be used to remotely control and actuate the devices in the network.
    • System Deployment Description
    • Observation

After running serval tests for different scenarios presented above, we observe that there are two major issues: erroneous sensors and synchronization of data arrival from different sensors. sdsgsd

  • Wide Area Network and Internet