Abstract
Internet of Things (IoT) based systems have revolutionised the way real world systems are inter-connected through internet. At present the application of IoT based systems is extend to real time detection and warning system. However, cost has been a major factor for development and implementation of IoT systems. Considering the cost, ease of implementation, this paper proposes a low cost yet efficient IoT system called FireNot for warning and alerting fire incidents. FireNot is a cloud based system that uses sensors (hardware) to detect fire and alert the user through internet and is maintained and monitored using a simple Android app. The FireNot system uses Raspberry Pi programmed through Python language and utilises Google API for location detection. The FireNot system is also intended to provide an expandable platform for additional daily monitoring tasks and more importunately, resiliency against most cyber-attacks and hi-jacking that targets IoT-based system lacked in most of similar IoT-based designs. This paper practically demonstrates the FireNot system through extensive testing on various operations and the FireNot system is proven to be efficient.
Introduction
Internet of Things (IoT) initially appeared as an automation of processes, but smart IoT allows to achieve the paradigm of reaching the result, where the goal is a paramount and not methods for achieving it. IoT is a continues support for a man by the things which surround him. IoT is a clarity of processes and focus on result. IoT is not to tell how to do, but what should be in the outcome. Basically, things are agents for performing processes. Life cycle of things are quite simple. First, they collect the information from the real world, then they process it or in the other words, they plan some actions. The actions will be executed by commands.

System Architecture.
Agent of a man communicates with agents of things, giving them commands and exchanging information. This relationship between man and surrounding things can provide comfort in living, prevention of disasters and saving lives.
The safety of any person is the most important part of living. Unfortunately, accidents and misfortune can happen even inside of any house. One of the threat is an open fire, which can take place due to uncontrolled cooking, unfinished smoking or simply due to electrical failure. There can be different reasons, but the outcome is always dangerous [4,13,14]. Despite domestic fire alarms availability and installation inside premises, there are number of cases, when fire alarm does not function as supposed to or simply when nobody is around, when fire alarm goes off. IoT based Fire Alerting System “FireNot” is designed to give a second cross check in alerting people of possible fire on the premises. When the system senses smoke or fire, it alerts the user through their mobile phone, giving them notification of possible fire on the location. From here, the user can take any additional steps and action to check the premises, ask somebody else to check, if the user is away from the premises, or even call the fire brigade. The system is designed to use modern day technologies of Internet of Things, such as Raspberry Pi minicomputer, compatible smoke sensitive sensors, all of which communicates to an Android mobile application via Google Cloud. There is no man-to-man or man-to-machine interaction involved, therefore, it provides efficient inexpensive solution for a cross check in case of fire. The Fig. 1 shows the system architecture.
The other aspect, which is added to a business value of the system, is affordability in terms of cost of hardware. The Internet of Things technologies, available today, gives flexibility in terms of functionality, supported pool of open source knowledge, scalability, robustness and continues development. There is a definite demand for this type of solution for every household or business premise. Target audience include basically every layer of society. The development is decided to use Agile Software Delivery methodology due to most suitable project methodology available for software delivery. Its flexibility, clarity and absence of work overload provides great opportunity for successful delivery of the project within the timeframe. The main goal of the project is to provide the efficiently working system, which will be detecting any fire/smoking activity taking place on the premises, and alerting the user, who is located distantly, or in case of failure of fire alarms. The methodology for the development is Agile and Lean Software Delivery with several iterations, each of which has its own backlog of tasks and user stories.

Raspberry Pi 3.
The rapid advances in IoT development have made possible to employ technology in new fields, such as smart cities [1–3,7]. There are alert communication primitives for designing distributed applications [26]. The researchers have also explored the use of wireless sensor technologies and IoT for fire alerts, home or warehouse management, and agriculture [6,8,9,12,24,25,27,29]. For, example, Saeed et al. [20] propose an IoT-based home fire prevention system which has several sensors. The authors run several simulation experiments and conclude that the system can detect early fire and keeps the energy consumption of the sensors at an acceptable level. In [11], the researchers also build smart home hardware for fire alarm and suppression which is part of an IoT architecture that use cloud services to monitor and control room temperature. The paper aims to implement an IoT scenario based on the use of the MQTT protocol in the AWS platform. In another work, Vijayalakshmi S.R. and Muruganand S. [28] designed a low-cost fire detection node and build an experimental WSN to compare two fire exposure algorithms. Maguluri, L. P. and others [16] also propose a fire detection solution based on IoT. They build a smoke alerting device and test it in a smart emergency response network for fire hazards.
Duraivel et al. [10], Kulkarnie et al. [22], R. Arthi et al. [21] and K. Okopujie et al. [18] separately designed and implemented IoT-based fire alarming, monitoring and authentication systems for warehouse, textile workhouse, and complex buildings capable of sending an automated message, raising an alarm and in last two cases, also spraying water to the affected area. Sowah et al. [23] designed a fire detection system for vehicle using fuzzy logic, capable of using air-conditioning system to extinguish fire in 20 second. Numerous similar IoT-based home security surveillance systems has been also designed and implemented [10]. In all above cases, researches have been mainly focussed on the end-point design and implementation and, no or very little attention has been paid to the security of platform or against mitigation of cyber-attacks and prevention of hi-jacking of the IoT-based platforms. Security of the platform, resiliency against cyber-attacks, system hi-jacking and raising false alarm has been considered throughout the design of “Fire Not” system.Mirai DDoS attack on IoT-based devices was just a beginning of such cyber-threats, the reality of cyberspace and importance of designing a secure platform for IoT-based systems. “FireNot system” is also a low cost back-bone design, easily expandable to full smart.
Our work will be part of those emerging solutions for fire detection that exploits the IoT features to create smarter buildings.

Gas sensor Connection Diagram.

Smoke Sensor MQ2.
Raspberry Pi 3
The Raspberry Pi I (Fig. 2) is one of the most popular applications which is used as a small computer in IoT industry. In the experiments, Raspberry Pi Model 3B was used over the 2nd Generation board since it is suitable for increasing CPU speed, power supply efficiency and built-in Wi-Fi chip [19]. The study of comparing the Raspberry Pi’s performance and capabilities to the Arduino Uno, BeagleBone and Phidgets boards said that the Pi has limitations such as no Analog to Digital Converter (ADC) or real-time clock (RTC) and the number of digital I/O ports available is limited [17]. Even though most of IoT users suggest Arduino Uno for connecting Smoke sensor like MQ2 because of ADC, this limitation could not be the problem and Raspberry Pi’s strengths are much over the other boards since Pi can easily connect to the Internet and support processing power available. Moreover, some users who are using Raspberry Pi and MQ2 sensor for detecting smoke explained that it is fine to receive the digital data when the sensor detects smoke.
Smoke sensor (MQ2)
There are many sensors for detecting smoke and other gases. MQ2 (Fig. 3) is chosen which can detect smoke, LPG, CO, H2, CH4, alcohol and Propane because of detecting smoke. The sensor operation mainly depends on heater coil, the sensor heater uses 5V Dc supply otherwise PWM pulses from 2V to 5V amplitudes. Important thing is No H pins (heater) directly connected to Raspberry Pi because of receiving the output voltage. The sensor gets warm by using this heater and this time taken for warm is called as “burn-in time” it may take up to 3 minutes for MQ sensors.
The sensor which has the own board on the bottom has four pins to connect Raspberry Pi. These are power, ground, analogue output and digital output Fig. 4.
MQ2 sensor has the sensitivity characteristics for each gas for detecting (Fig. 5). According to these data curves, Resistance value of MQ-2 is different to various kinds and various concentration gases. LPG gas is the most sensitive to detect and smoke is likely to be normal sensitive, and propane gas is the least sensitive. Therefore, it is good to detect smoke in a closed place such as closing home or office when the fire happens.
Google Firebase Cloud Messaging (FCM)
To send the notification to the mobile device, Google Firebase Cloud Messaging [5], hereafter FCM, is used for our system. FCM is a cross-platform solution for messages and notifications for Android, iOS and web applications which currently can be used at no cost. First of all, user account was registered on Google webpage in order to use Google Firebase Console. And then, our project can be added on Firebase, and can modify the setting of the project for utilising Firebase features. This key is necessary and used for sending notification to mobile devices. Also, users can download the JSON file which should be used for Android mobile application on this webpage (Fig. 6).

MQ2 Sensitivity Characteristics for different gases.

Android Mobile Application page.
The Firebase Realtime Database is a cloud-hosted database. Data is stored as JSON and synchronised in realtime to every connected client. When you build cross-platform apps with our iOS, Android, and JavaScript SDKs, all of your clients share one Realtime Database instance and automatically receive updates with the newest data. First, an android mobile application was developed using Android Studio, and the mobile devices were registered on Firebase Realtime Database by using the application and have got the tokens for each device from Firebase. After that, all the registered data can be shown on Firebase Realtime Database page. Among the data, the tokens are very important because they should be used when the project system would send notification.

Google Map API.
For displaying the location where the fire happens, Google Maps Android API was used which can show the map based on Google Maps data to our application (Fig. 7). The API automatically handles access to Google Maps servers, data downloading, map display and response to map gestures. Also, developers can use API calls to add markers, polygons, and overlays to a basic map, and to change the user’s view of a particular map area. These objects provide additional information for map locations, and allow user interaction with the map. Because the project was already registered with Firebase console account, the google map API key can be accessed by just linking the project on the Google Cloud Platform webpage (Fig. 8).

Google Cloud Platform Webpage.
This webpage shows the services which Google company supports (Fig. 9). Firstly, Google Maps Android API is selected on Dashboard category after choosing API and services category in order that the service is available.

Google Cloud Platform.
And then, go to Credentials category, Android key is available for our application (Fig. 10).

Google Cloud Interface.
Network Architecture
At first, users register their information by using the android application in the mobile devices. After that, Firebase in Google Cloud system makes tokens for the registered devices and save them to the realtime database with other information (Fig. 11). Later, when smoke sensor (MQ2 sensor) detects smoke, it sends signal to Raspberry Pi linked. Raspberry Pi has Python program which can call Firebase realtime database in Google Cloud system. Python program sends the tokens of users to Firebase realtime database in order to check whether the tokens are matched or not. If the tokens are matched, Firebase sends the notification to users. Users can open the application when the notification is arrived and can push a button to check the location which fire happen. And then, Google map api sends the map location to users’ devices. Finally, users can see the map where the location is (Fig. 13).

Google Cloud API architectures.
For users’ mobile application, Android Studio program was selected for implementation:
Graphical User Interface (GUI)
Graphical User Interface of the mobile application is simple for users. When a user installs the application at his/her mobile, the application shows the title of our project application and 2 blank to input user’s information. A small square box is to check whether users receive the notification or not when the fire happen. And “Location” button is for displaying where the house is located.
When a user registers his/her mobile, the application sends the user information to Firebase realtime database, and Firebase makes a unique token for the mobile device and store it at the database. This token is very important when Firebase sends the notification to the mobile device.
For using Firebase and Google Map API, the application codes in Android Studio has modified as follows.
Project gradle is needed to add google service version, and Module gradle is needed to add Firebase service and google map api service.
The validation results of sensors and other devices used for experiments
The validation results of sensors and other devices used for experiments
Experiment results Raspberry Pi system Testing
(Continued)
Experiment results for Firebase and Google maps application
Experiment results of the experiments testing the Android application user interface
AndroidManifest.xml is needed to add service name of firebase and google map api key.
System Testing
The following Tables 1–4 show the validation results of sensors, and other devices (Table 1), Raspberry System testing (Table 2), Firebase and Google maps application (Table 3), and Android application user interface (Table 4). The columns in each table represent the testing criteria, expected result, measured result and actual results. Table 5 discusses experimental results of evaluation of threat control interfaces for the system.
In addition, Fig. 14–16 represent the successful code execution for google api operation (Fig. 14), detection operation (Fig. 15), and android system operation (Fig. 16).
Test Devices
Mobile application for “FireNot System” was installed on the following two Android-based devices, used by team members to validate system architecture during implementation and testing.
Samsung Galaxy S2 API 10 LG Gpad10.1 API 21
Security (STRIDE)
To ensure the system is secure, the analysis has been performed throughout the whole system. Threat Modelling gives the theoretical insight into security degree of each element of the system with the opportunity to provide controls for any potential attack or failure.
According to Microsoft STRIDE threat model, threats are categorised and vulnerabilities are exposed and provision of controls. Spoofing, Tampering, Repudiation, Information Disclosure, DOS and Elevation of privilege are analysed throughout to ensure the security of the system. Security has been also the key consideration during the design and implementation. The authentication back-end engine has been specified in the configuration instead of plaintext password that can be easily intercepted. The password is hashed and stored in a restricted access hidden directory out of server’s scope. Lighttpd web server is also installed and configured to act as a proxy server before traffic reach streamer [15]. Port forwarding feature was used to switch known services on well-known port to specific ports known to the administrator only. Dyn’s Web Hop feature allow designating another domain as a mean to access to Raspberry controller and therefore blocking direct access to the controller.
Attack Points Analysis
Figure 17 below shows the system implementation architecture to identify potential attack surface and attack point analysis.
Raspberry Pi
As a main hardware element of the system, Raspberry Pi will be placed in secured hard casing to avoid any physical damages. Also, due to Raspberry Pi is running the code for continues listening the gas sensor, the access to Raspberry Pi is limited to authorised people only to prevent any alterations and modification to the code script. The factory provided default password is changed to a new one, which is a combination of different characters. Manually tuned firewall can be installed for a further security and will be allowing only a connection to Firebase.
Firebase (FMS)
Google is a owner of Firebase Messaging Service, therefore, any system, which integrates its services, rely on their own security state. Independent audit reports from Google (SOC 1, SOC2, SOC3) analyse infrastructure and its operations. Certificates ISO 27001, ISO 27017 and ISO 27018 are earned by Google, which are security standards for Cloud division of Security and Privacy.
Operations Team
Operation Team currently includes team members only. Eventually, there can be other members, when the final product enters the market. Each authorised member will have its own login credentials for accessing the Firebase control panel. The login history will be saved with time, login name and other attributes. All this information will be providing opportunity for successful investigation if any attack will be performed. The login process also will be implemented with multi-factor authentication and authorisation.
Experiment results – Evaluation of threat control interfaces
Experiment results – Evaluation of threat control interfaces

Login interface of Fire Alarm.

Location Identifier: Google Maps.

Code window representing the line of code executed for google api operation.

Code window representing the detection operation.

Code window representing the android system operations.

System implementation architecture.
Initially, mobile application won’t have and would not really need a password access (Fig. 12). It is a warning app, giving notification about smoke/fire activity in the premises with installed system. However, attacks can be performed for general damage with no further motifs or as a destruction indirect element of a bigger strategy. Thinking as an attacker, the app can be accessed via the smart phone and the notification alert can be altered and prevented by additionally loaded piece of malicious code. For this case, the app can integrate password access in further updates or, as a primary protection, can use “lock app” features of other apps, which available at Google Play Store.
Network
Networking component of the system can use either message queuing telemetry transport protocol MQTT or Secure sockets layer/Transport Layer security SSL/TLS encryption. The latest version is TLS 1.2.
Conclusion
This paper presents a low cost IoT based fire alerting system called FireNot. The system provides a real time monitoring of the fire incidents and provides an alert to the user through computer and mobile interfaces. FireNot uses Raspberry Pi with the interfaced programmed using Python which provides low cost yet efficient system interns of both hardware and software.
The key contribution of this paper is boosting the IoT research and encouraging the possibility of building IoT systems that are portable, low cost and can be built using open source hardware and software. The ability of proposed FireNot is demonstrated through extensive testing and application. The integration of physical and software systems is been thoroughly tested.
The future implementations are concentrating and looking at developing an interface that could provide customisable interfaces and can report the incident to concern people (may be fire station/emergency or others) to provide an immediate action. The development of an API to provide access to external software and hardware systems is also another direction of research. Further, implementation of multiple locations and multiple systems to provide an overall a cloud based fire alert service through government or private organisations may also be considered.
