Internet of Things–based smart home system using a virtualized cloud server and mobile phone app

Abstract

This article proposes an Internet of Things–based smart home system composed of a virtualized cloud server and a mobile phone app. The smart Internet of Things–based system includes a sensing network, which is developed with the ZigBee wireless communication protocol, a message queuing telemetry transport, a virtualized cloud server and a mobile phone app. A Raspberry Pi development board is used to receive packet information from the terminal sensors using ZigBee wireless communication. Then, the message queuing telemetry transport broker not only completes transmission of the message but also publishes it to the virtualized cloud server. The transmission can then be viewed through the website using a mobile phone. The designed app combines the application of the virtualized cloud server, client sensors and the database. Verification experiments revealed the measured average response time and throughput of approximately 4.0 s and 6069 requests per second, respectively, for the virtualized web server and approximately 0.144 s and 8866 packets per second, respectively, for the message queuing telemetry transport broker. The designed functions of the mobile phone app are a global positioning system home monitoring, family memo, medical care and near-field communication key. Both interlinkage and handler methods are proposed to facilitate a powerful function without delay in displaying information. The proposed system integrates with software and hardware to complete the data analysis and information management quickly and correctly. It can cater to user needs with superior ease and convenience.

Keywords

Smart home system IoT ZigBee Raspberry Pi cloud server mobile phone app

Introduction

Recently, the Internet of Things (IoT) and Industry 4.0 have become global trends. Many terminal devices, such as handheld and wearable devices, can be connected to the Internet,¹ allowing communication among the devices as well as their access and control. By using a large number of sensors, extensive awareness and reliable delivery of information as well as big data analysis can be achieved, thereby realizing comprehensive intelligent processing of data. The number of sensing devices in the IoT is projected to reach approximately 50 billion by 2020.² The IoT devices generally produce a large amount of sensing data, which are transmitted in various data formats and stored in cloud servers. These data are processed in the cloud server in many ways, such as file accessing, data sharing and resource sharing. Furthermore, a cloud server functions as a real-time controller by transmitting the data through big data analysis and data computing. Virtual cloud servers are being used widely to realize these designed functions. Due to its low cost, high speed and good stability, a cloud server can easily perform network administration and manage data transmission from sensors to servers.³

In general, elements of the global IoT are broadly categorized into sensor, network and data processing. The sensor, an important device, captures useful information, which is transmitted through the network layer to the cloud server immediately and stored there. By using a proper communication technology with the corresponding communication protocol, this process provides effective file access, data sharing and resource utilization. The sensing information obtained from artificial intelligence processing or big data analysis is stored in the cloud server for future analysis.⁴ A high-performance, highly reliable virtual cloud server has many features including small size, balanced resources, low price and good burst capability of the CPU and network.^5,6

Current IoT technology has yet to achieve the characteristics of ‘unity’, ‘integration’ and ‘simplicity’. IoT technology cannot easily achieve a uniform format and a consistent specification without the characteristic of unity. Each IoT device introduces unique specifications and functions, making communication between the devices difficult. On demand of the specific application, a large number of IoT devices need to be used. Moreover, the IoT devices can be individually controlled using mobile phones. Therefore, the cost and size of IoT devices can only be reduced by data and resource sharing. Furthermore, IoT devices must be simplified to cater to the needs of users. The use of various communication methods for IoT results in many technical problems concerning complexity of communication protocols, high power consumption, communication disconnection and low security strength, severely restricting IoT’s market expansion.^7,8

This study proposes a mobile phone application (hereafter, the app) to control many IoT devices and connect to the databases in cloud servers and client sensors, including electronic door keys, carbon dioxide sensors, smoke sensors and infrared human body sensors. The designed functions of the app provide the positioning of users, public memorandum for important event reminders, positioning/tracking of the elderly, emergency calling and maintenance of medical records. The app can administer the sensing information by processing it with big data analysis, thereby providing mobile phone users with predictions or judgements.⁹ The IoT-based smart home system app for mobile phones is expected to be popular and closer to the needs of users due to the extensive use of mobile phones. Therefore, it is designed to be more comprehensive and safe and have an interlocking function. The app enables exchange of sensing information among various IoT devices, and its performance can be improved by software and hardware integration.

The remainder of the article is structured as follows. In section ‘IoT-based smart home system’, the design of the IoT-based smart home system is described. The hardware and software implementations of the IoT-based smart home system and their relative functions are also elucidated. Functional verification and measurement are presented in section ‘Functional verification and measurement’, and conclusions are drawn in section ‘Conclusion’.

IoT-based smart home system

Figure 1 shows the IoT-based smart home system, which is composed of sensors, gateways, servers, web browsers and a mobile phone app. The client always uses the smart sensor at home. The gateway is established using the Raspberry Pi ARM Cortex-A53 single-chip development board (Raspberry Pi Foundation, Cambridge, UK), which has a built-in 1GB LPDDR2 RAM with the Linux operating system (OS) for system development, Ethernet, built-in Bluetooth and Wi-Fi, and an RJ-45 network port.¹⁰ The server is a cloud server with many virtual machines (VMs). The ZigBee wireless protocol is used between the sensor and gateway, and the local area network (LAN) is used between the gateway and the server. The web browser can read or write the data from or into the database of the cloud server through the Ethernet system, and the mobile phone is connected with wireless communication.

Figure 1.

IoT-based smart home system with a sensor, gateway, server, web browser and mobile phone app.

Figure 2 shows the flowchart of the IoT-based smart home system. First, the Dongle programme is executed to search for client sensors. The nearer the sensor is, the higher the priority will be. Next, the pairing function is executed to pair sensors successfully. Then, the sensing data are packaged as packets and sent to the Raspberry Pi development board through ZigBee wireless communication. The received packets are analysed by the Raspberry Pi development board using two methods. One is to display the entire captured packets with the sensing data, and the other is to analyse the received packets and extract three parameters, namely, shortAddress, clusterId and value. Note that a checksum process is generally used to guarantee that the packet is not tampered during the delivery. If a valid packet is received, the message queuing telemetry transport (MQTT) broker is enabled. The received three parameters are published into the MQTT broker and stored in the database for further analysis. A graphical management interface is used to view the stored sensing data through a webpage. In addition, the mobile phone app is designed to view the stored sensing data through wireless communication. That is, by using the Ethernet and wireless communication, everyone can monitor the present status of the sensor and the judgement and prediction can be completed anywhere and anytime.

Figure 2.

Flowchart of the IoT-based smart home system.

MQTT service

MQTT is an ISO standard (ISO/IEC PRF 20922) publish/subscribe-based messaging protocol.¹¹ It works on top of the transmission control protocol (TCP)/Internet protocol (IP) and is a simple messaging protocol designed for high latency or unreliable networks.¹² It is popular for use in IoT and mobile applications consisting of premium bandwidth and battery power. Figure 3 shows the operation diagram of the MQTT service. The sensing datum of topic (also called message) is published to the MQTT broker. The subscriber such as a web browser or mobile phone app subscribes to the broker to receive the message in the MQTT broker, and the publisher sends the message to the subscriber.

Figure 3.

Operation diagram of the MQTT service.

Quality of service

In addition to the aforementioned functions, the MQTT provides three types of quality of service (QoS): QoS 0, QoS 1 and QoS 2.¹³ Figure 4 shows the flowchart of the QoS. QoS 0 is serviced a maximum of one time. The TCP guarantees the message is delivered to the destination correctly. However, because the MQTT is located on the application layer, the lower layer (TCP/IP) cannot confirm if the message is delivered successfully. QoS 0 is suitable for monitoring systems because the subsequent message will be received immediately, and it may work well with a lost message or repeated delivery. MQTT is an ISO standard (ISO/IEC PRF 20922) publish/subscribe.

Figure 4.

Flowchart of three QoSs: QoS 0, QoS 1 and QoS 2.

QoS 1 is serviced at least one time and guarantees that the message is delivered to the destination successfully. This service will work with a repeated delivery. After the subscriber receives the message from the MQTT broker, it replies by sending a PUBACK (Publish Acknowledgement) signal to the publisher confirming that the message was received correctly. If the publisher does not receive the PUBACK signal, it will be assumed that the subscriber has not received the message and the message will be resent to the MQTT broker.

QoS 2 is serviced exactly one time, that is, the message will be delivered to the destination once. When the MQTT broker (reporter) receives the message, it replies by sending a PUBREC (Publish Received) signal to the publisher and stores the message temporarily. After the publisher verifies the packet identification code of the received message, it sends a PUBREL (Publish Release) signal to the MQTT broker and a returned PUBCOMP (Publish Completion) signal is published to the publisher to end the Publish service. In the meantime, the temporary packet identification code is deleted.

In this study, the database is built with MongoDB, which is a popular data model. It allows our teams to easily organize, use, and enrich data in real time and anywhere. MongoDB is a file-oriented non-Structured Query Language (NoSQL) database management system written in C++ language that is increasingly used in big data and real-time web applications. MongoDB is also written in C, JavaScript, Java, Python, Ruby and other languages. A client can edit, load, delete and update the sensing data to the database through a graphical user interface. In general, an SQL database mainly stores data in a table (column or row), whereas NoSQL mainly stores data in a collection (document). The file storage format of MongoDB is JavaScript Object Notation (JSON), which is a lightweight data exchange language based on text and is easy to be read.¹⁴

A Node.js programme is designed on the basis of the Chrome V8 engine in a web server and is used to handle the webpage. When the user starts the webpage or mobile app, the query event is triggered and the browser or app sends an HTTP request to the web server. The web server executes the Node.js programme and sends a request to the MongoDB, which updates the database in the web server and returns the information (data) to the webpage or app. After the information (data) is received, the webpage or app is renewed. Figure 5 shows the web server architecture, which is composed of an application programming interface (API) and Mongo driver.

Figure 5.

Web server architecture with API and Mongo driver.

Proposed virtualized cloud server architecture

In general, a traditional server set is built with at least three physical servers: the MQTT broker, HTTP server and database. A traditional server generally exhibits poor performance. When the three servers are virtualized and integrated into one physical server, each VM works with independent CPU and memory. VMs occupy a small space and are characterized by high performance, good stability and high robustness. In case a VM is attacked by a hacker, the existing data can be transferred to a new VM and the affected VM can operate independently.

The proposed virtualized cloud server is established with the bare-metal hypervisor, also traditionally referred to as a Type 1 hypervisor, of the Linux kernel-based virtual machine (KVM), which is a modular approach to virtualize the Linux system.¹⁵ The hypervisor is a layer of software running between the physical server (hardware) and the quest OS. It not only runs directly on the hardware virtualization but also provides hyper call for virtual OSs and applications.

In addition to the basic capability of monitoring the VMs, a complete set of virtualization software is combined with high-performance input/output (I/O) devices, virtualization capability and management architecture, namely, a quick emulator (QEMU) and libvirt. QEMU is an open-source emulator that performs with a complete virtualization system to create and install the VMs separately. The libvirt is composed of management platforms, a virtualized open-source interface and management tools. The key feature of the Linux virtualization is the integration of the KVM module with the QEMU virtualization software and libvirt management platform. Figure 6 shows the proposed virtualized cloud server architecture.

Figure 6.

Proposed virtualized cloud server architecture.

Mobile phone app for IoT-based smart home

The IoT-based smart home system is composed of sensors, a gateway, a server and a mobile app. Many types of sensors are used in the proposed smart home system such as temperature sensors, humidity sensors, CO₂ sensors, door sensors, smoke sensors and smart sockets. The sensing data pass through the gateway and Internet and are stored in the database of the cloud server. The mobile phone app retrieves the stored data through a mobile network such as 3G, 4G and Wi-Fi. Note that the designed app can be executed continually in the background while the mobile phone is in use. Emergency information, notifications and alerts can be displayed in real time as a pop-up window on the user’s mobile phone. Although the IoT system uses existing networks and devices, the architecture, security, message format and massage size of the MQTT and HTTP differ.¹⁶ Table 1 shows a processing comparison of the MQTT and HTTP protocols.

Table 1.

Processing comparison of MQTT and HTTP protocols.

Protocols	MQTT	HTTP
Architecture	Publish/Subscribe	Request/Response
Transport protocol	TCP/IP
Security	TLS	HTTPS
Message format	Binary format with2-byte header	ASCII format
Message size	Small	Large
Link layer	802.15.4, Wi-Fi,Ethernet, 4G, and so on

MQTT: message queuing telemetry transport; HTTP: HyperText Transfer Protocol; TCP: transmission control protocol; IP: Internet protocol; TLS: Transport Layer Security; HTTPS: HyperText Transfer Protocol Secure; ASCII: American Standard Code for Information Interchange.

Figure 7 shows the network diagram between the app and the server. Upon opening the smart home app, the user needs to register and login to gain access to the webpage. This procedure ensures system security between the app and the server, prevents others from controlling the home equipment and avoids leakage of private data. Furthermore, group members such as family members, company members, friends and medical caregivers can share the resources in the server and communicate with each other. As shown in Figure 7, each app is composed of a global positioning system (GPS), and home monitoring, family memo and medical care functions. The Node.js API server is composed of several software packages,¹⁷ namely Server.js, webhook.js, getSystemData.js, MemoIOData.js and GPSData.js. The Server.js package serves as the main application script in the standard scaffold application. The webhook.js package is a user-defined HTTP call-back, which is usually triggered by some event. When the event occurs, the source site makes an HTTP request to the uniform resource identifier (URI) configured for the webhook. The designed functions based on HTTP can be integrated into web services without adding a new infrastructure. The remaining software packages are getSystemData.js, MemoIOData.js, and GPSData.js, serve system data, I/O data, and GPS data, respectively.

Figure 7.

Network diagram of communication between the app and the server.

Designed functions of mobile phone app

The mobile phone app comprises five applications. The first four functions of GPS positioning, home monitoring, family memo and medical care can access through the web server database. The last function, a near-field communication (NFC) key, is used within commercial facilities and may be prone to hacking because of a protocol vulnerability.¹⁸ Figure 8 shows the five functions of the mobile phone app:

GPS positioning: It is designed to detect and manage the locations of group members in a wider area as well as to track the user’s, especially children’s and elderly individual’s, whereabouts instantly, thus enhancing homecare security. The designed app will automatically detect the current status of the mobile phone and select the most suitable positioning method from the GPS, wireless network (wireless) and passive positioning (passive). If an emergency call is activated, the positioning information of the triggered mobile device is transmitted to the web server and the group members receive the message, which is displayed on their phone panels.

Home monitoring: Many sensors can be used at home, including a temperature sensor, humidity sensor, CO₂ sensor, gas sensor, CO sensor, infrared motion sensor, particulate matter (PM) 2.5 air pollution quality sensor, alarm bell, door sensor and smart socket. The sensed information from these sensors is transferred to the gateway through ZigBee, Wi-Fi or Ethernet. These data are uploaded from the gateway to the web server through the LAN. Data acquisition and transmission are coded in parallel processes. That is, when data acquisition is operating, data transmission is not interrupted and is executed in the background. In general, an interlocking is set to trigger a chain of reactions. Figure 9 shows the interlocking setting in different sensors.

Family memo: The family memo function uses two databases: the SQLite database (local database), which is used on the user’s phone, and the MongoDB server (server database), which is used on the web server. When the user records a reminder on the family memo app in the local database, the memo data also update the database on the web server and send a reminder to the mobile phones of the user’s group members.

Medical care: This function is designed for the elderly and those people suffering from diseases. The user’s personal data such as the user’s name, contact number, emergency contact number and medical history can be set in the app from his or her medical card. Multiple emergency contacts can be set in the app, and when the user triggers an emergency call, the app will call the first phone number immediately. If there is no response in a limited period, the app will call the subsequent numbers. This function is always integrated with the GPS positioning function. When the user triggers an emergency call, the GPS location will be transmitted to the web server and be displayed on the panels of the group member’s phones. Figure 10 shows the interlocking function between medical care and GPS positioning.

NFC key: The user needs to ensure that the NFC key is enabled successfully by turning on the NFC setting and searching for the NFC key number. This function will automatically encode the communication protocol of the NFC in a portable device such as a smart phone and write the card number into the NFC data. NFC is a set of communication protocols that enable two electronic devices, one of which is usually a portable device, to establish communication when they are placed within 4 cm of each other. NFC-enabled devices can act as electronic identity documents and key cards. It is convenient and intelligent to open electronic doors with an NFC key in the user’s mobile phone. The NFC key can be operated in the card simulation mode, that is, the power can be supplied through a radio frequency (RF) contactless reader. Therefore, even if the battery of the mobile phone is drained out, the NFC key works normally.¹⁹

Figure 8.

Five functions of the mobile phone app.

Figure 9.

Interlocking setting in different sensors.

Figure 10.

Interlocking function between medical care and GPS positioning.

The dispatch mechanism to send an NFC tag to other applications is as follows. In a tag dispatch system, an intent is generated by encapsulating the NFC tag and its identifying information. If many applications handle the intent, the user can select the activity through the Activity Chooser. The tag dispatch system defines three intents – NDEF Discovered, TECH Discovered and TAG Discovered – which are listed from the highest to the lowest priority. The tag dispatch system works according to the following steps:²⁰

Step 1: The system tries to start an activity with the intent created by the tag dispatch system.

Step 2: If no activities filter for that intent, it tries to start an activity with the next lowest priority intent until all possible intents are tested.

Step 3: If no applications filter for any of the intents, no action is taken.

Functional verification and measurement

The sensors for the experiment are provided by SensingTEK Co., Ltd, which is devoted to wireless sensor network technology research and development. The ZigBee home automation (HA) protocol wireless communication is used between the sensor and the gateway. The sensor’s packet is received through a dongle, a small piece of hardware that connects to devices to provide it with additional functionality. The communication between the dongle and the gateway proceeds according to the universal asynchronous receiver–transmitter (UART) protocol, which is implemented on Raspberry Pi (gateway). As shown in Figure 1, the sensing information, stored in the UART of the gateway, is read and analysed to guarantee accuracy of data. Then, the information is published to the MQTT relay station (broker) through LAN and stored in the web server database. The stored information (data) can be accessed by a mobile phone or a web browser.

In general, the SQL database is mainly stored in a table where the stored data are called a column or row, whereas the NoSQL mainly stores the data in a collection where the stored data are called a document. MongoDB’s file storage format is JSON, which is a lightweight data exchange language.¹⁴ It can be edited with many popular languages such as C, C++, JavaScipt, Java and PHP. The data format in the database is as follows:

{

“_id”: ObjectId(“5b1265fca9b17004a52b529e”),

“topic”: “temperature”,

“payload”: “2718:0402:09f2\n”,

“qos”: 0,

“retain”: false,

“_msgid”: “dfc6e3.67cfa92”,

“date”: ISODate(“2018-06-02T09:40:12.196Z”),

}

Figure 11 shows the hardware verification system, composed of sensors, a gateway and a web server. The sensing information is stored in the database of the virtualized web server through the Raspberry Pi development board (gateway), which is set by the Node-RED programme, a visualization tool for wiring the IoT. Figure 12 shows the homepage of the designed web browser. Four categories of sensors are displayed on the homepage: environmental monitoring detector, passive infrared sensor, alert sensor and smoke detector. Figure 13 shows the temperature data on the webpage, which was last updated on 25 July 2018. Note that 56,179, 84,784 and 211,876 are the results for the last week, last month and total amount, respectively. Figure 14 shows the gas data on the webpage, which was last updated on 23 July 2018. The result 137 pertains to the latest week. In the historical gas data, 625 and 2082 are the results for the last month and the total amount, respectively.

Figure 11.

Hardware verification system composed of sensors, a gateway and a web server.

Figure 12.

Homepage of the designed web browser.

Figure 13.

Temperature data on the webpage, which was last updated on 25 July 2018.

Figure 14.

Gas data on the webpage, which was last updated on 23 July 2018.

The human–machine interface of the monitoring system enables remote monitoring of the home environment. With change in the sensing information of the environmental sensor, the detected data are analysed in the gateway. The corresponding device code, project code and project value are analysed and stored in the database of the virtualized web server. The historical data obtained are transferred to another table in the virtualized cloud database, also in the JSON format.

To measure the performance of the virtualized web server and MQTT broker, the Apache JMeter software (Windows system) is adopted for setting 20,000 users/clients for the web server and 40,000 users/clients for the MQTT broker, depending on the size of the virtualized web server and MQTT broker. The JMeter software is an open-source software and a pure Java application designed for testing web applications and other test functions. It can be used as a load testing tool for analysing and measuring the performance of various services. When the JMeter software is started, the time is set to 180 s for measuring the average response time and throughput, which are viewed from the Listeners (View Results Tree). Table 2 shows the performance comparison of the proposed system with the previous IoT cloud server. For the virtualized web server, the measured average response time is approximately 4.0 s and the throughput is approximately 6069 requests per second (req/s) for 20,000 users. For the MQTT broker, the measured average response time is approximately 0.144 s and the throughput is approximately 8866 packets per second (pac/s) for 40,000 users. As shown in the performance comparison in Table 2, the throughput of the proposed system is better than those in Hou et al.,²¹ Jutadhamakorn et al.²³ and Grabovsky et al.,²⁴ but inferior to those in Oprea and Reiter.²² The aforementioned measured results greatly depend on the computer hardware and performance evaluation software. In this study, the processor is an Intel Xeon E5-2620 v4, which is a 64-bit octave-core ×86 microprocessor, and the evaluation software is Apache JMeter. Note that the performance evaluation software was designed by Oprea and Reiter,²² even though the hardware specification of the processor in Oprea and Reiter²² is inferior to that in this study.

Table 2.

Performance comparison of the proposed system with previous IoT-based cloud servers.

Items		This study	Hou et al.²¹	Oprea and Reiter²²	Jutadhamakornet al.²³	Grabovskyet al.²⁴
Averageresponsetime (s)(users/clients)	Web server	4.0 (20,000)	8.0 (20,000)	0.135 (16,000)	−	19 (23,078)
Averageresponsetime (s)(users/clients)	MQTT broker	0.144 (40,000)	10.0 (40,000)	−	34.29(500,000)	−
Throughput(req/s)or (pac/s)(users/clients)	Web server	6069 (20,000)	2600 (20,000)	142,857 (16,000)	−	1481 (23,078)
Throughput(req/s)or (pac/s)(users/clients)	MQTT broker	8866 (40,000)	5000 (40,000)	−	1474.5(500,000)	−
Processorspecification		Intel XeonE5-2620 v4	4-Beta parallelprocessors(PM2)	Intel Pentium4 2.80 GHz	Intel Corei7 – 2.90 GHz	Intel Corei5 – 2.3 GHz
Performanceevaluationsoftware		Apache JMeter(Windows)	HAProxy3(Linux)	Proposediterativealgorithm	NGINX version1.12.1 (Linux)	Apache JMeter(Windows)

MQTT: message queuing telemetry transport; PM: particulate matter.

Next, the five designed functions of the proposed mobile phone app are verified using commercial sensors. Sensors, including gas sensors, infrared sensors, alarm devices, PM 2.5 sensors, CO₂ sensors, thermometers and hygrometers, are used to establish the home monitoring function. Figure 15 shows the wireless connection between the mobile phone and the sensors.

Figure 15.

Wireless connection between mobile phone and sensors.

GPS positioning

Figure 16 shows the GPS function, the main function in mobile phones. The user can view his or her position as well as the group members’ locations displayed on the map. In general, the GPS is integrated with the other functions. For example, the GPS displays the user’s location when an emergency call is triggered.

Figure 16.

GPS function displays the user’s location on the panel of the mobile phone.

Home monitoring

When the home monitoring function is selected, the app accesses the sensing information from the web server and displays it on the screen of the mobile phone. Figure 17 shows the home monitoring function of the user’s mobile phone. Each sensing device displays the corresponding results according to its detectable items. For instance, the first sensing device displays the detection values of temperature and CO₂, whereas the second sensing device presents the status of gas sensor. Next, the infrared motion sensing device displays the status and the values for the last sensing devices, including temperature, humidity and PM 2.5 detection.

Figure 17.

Home monitoring function of the user’s mobile phone.

In addition to displaying the independent sensing device, the interlock setting is a very powerful function. Many different sensing devices can be set as an interlinkage. Figure 18 shows the interlinkage function between the temperature sensor, humidity sensor, CO₂ sensor, gas sensor and alert device. That is, when one of the sensing devices is triggered, an alert is initiated with the interlinkage setting and simultaneously the alert status is sent to the user’s group members.

Figure 18.

Interlinkage function between temperature sensor, humidity sensor, CO₂ sensor, gas sensor and alert device.

Family memo

By selecting the memo function, the user can check the execution of or key in reminders. Figure 19 shows the family memo function of the user’s mobile phone. The first item in the figure is a reminder for taking medicine at night and the second item is a reminder to pick up children at 8:00 in the evening. When the ‘save’ button is clicked, the app informs the user the time of modification of the memo item. The updated information (text) is loaded to the web server and stored in the database.

Figure 19.

Family memo function of the user’s mobile phone.

Medical care

Figure 20 shows the medical care function of the user’s mobile phone. Two functional buttons exist on the screen of the mobile phone. The upper button is for an emergency call, which is used to dial the present phone number in case of an emergency. The lower button is for the medical card, which is used to provide the user’s medical record. The medical card information includes the user’s name, phone number, emergency contact number, medical history and specific prescriptions. These data are retrieved from the web server database and displayed on the mobile phone screen immediately.

Figure 20.

Medical care function of the user’s mobile phone with two functional buttons.

NFC key

The NFC key function serves as a smart key to open electronic doors without a physical key, thereby facilitating easy and convenient smart homes. First, the card number of the electronic key is copied and written into the NFC key. Next, by placing the mobile phone in front of the electronic door lock, the door can be opened quickly. Figure 21 shows the NFC key function where the user’s mobile phone is used to open the door. Note that the mobile phone establishes communication when it comes within a distance of 4 cm from the electronic door lock.

Figure 21.

NFC key function of the user’s mobile phone to open an electronic door.

The advantages of this designed app are as follows:

The set interlinkage between functions provides a powerful function. For instance, the interlocking between medical care and GPS enables the broadcast of the user’s position to the group members when a medical care emergency is triggered.

A handler method is proposed to execute the functional software smoothly without a delay in displaying information. The designed subroutine programme receives the sensing task and sends a new datum every 2 s to update the web server database.

A standard deletion function is proposed in the family memo function to quickly delete data. When the user double clicks this function, the data in the mobile phone (local data) and the corresponding data in the web server database can be deleted simultaneously.

Conclusion

In this study, we have proposed an IoT-based smart home system with a virtualized cloud server and a mobile phone app. The sensor-based intelligent networking system is composed of various sensors provided by a cooperative enterprise and used as the end devices, a ZigBee wireless sensing network, a gateway device with a Raspberry Pi single-chip computer and a virtualized web server LAN. A remote monitoring system is established through the human–machine interface by connecting the sensing devices to the IoT. The sensing device detects environmental information, including the device code, project code and project value, which is analysed in the gateway device and transferred to the database of the virtualized cloud webserver in a JSON format. The Apache JMeter software (Windows system) is adopted to measure the performance of the virtualized web server and the MQTT broker by setting 20,000 users/clients and 40,000 users/clients, respectively. The throughput of this study is better than those in Hou et al.,²¹ Jutadhamakorn et al.²³ and Grabovsky et al.,²⁴ but inferior to those in Oprea and Reiter.²² The key advantage of this study is that both HTTP and MQTT protocols are used in this article. However, only an HTTP protocol or an MQTT protocol is used in the literature.^22–24 Note that the proposed functions of the mobile phone app access the virtualized web server database in GPS, home monitoring, family memo and medical care, and that the proposed NFC key is used to communicate with commercial facilities. These HTTP-based functions can be integrated into web services without adding new infrastructure.

Footnotes

Handling Editor: Miguel A. Zamora

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship and/or publication of this article: This work was supported by the Ministry of Science and Technology (MOST), R. O. C. (Contract No. MOST 106-2221-E-027-075).

ORCID iD

Guo-Ming Sung

References

Phill

. 2018 for the Internet of everywhere: IoT-enabled world & the edge of the Internet. IoT Evolution-fog Computing Feature News, January 2018, pp.1–4.

Dave

. The Internet of things-how the next evolution of the Internet is changing everything. Cisco Internet Business Solutions Group (IBSG), 2011, pp.1–11, https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf

Moura

Hutchison

. Review and analysis of networking challenges in cloud computing. J Netw Comput Appl 2016; 60: 113–129.

High-performance virtual cloud servers help you grow and maximize your business . San Antonio, TX: Rackspace US, 2018.

Dubois

Casale

. Autonomic provisioning and application mapping on spot cloud resources. In: Proceedings of the international conference on cloud and autonomic computing, Boston, MA, 21–25 September 2015, pp.57–68. New York: IEEE.

Farooq

Zhu

. Adaptive and resilient revenue maximizing dynamic resource allocation and pricing for cloud-enabled IoT systems. In: Proceedings of the annual American control conference (ACC), Milwaukee, WI, 27–29 June 2018, pp.5292–5297. New York: IEEE.

Altayeb

Sharif

Abdella

. The internet-of-things and integration with wireless sensor network comprehensive survey and system implementation. In: Proceedings of the international conference on computer, control, electrical, and electronics engineering (ICCCEEE), Khartoum, 12–14 August 2018, pp.1–6. New York: IEEE.

Narendra

Truong

. HINC-harmonizing diverse resource information across IoT, network functions, and clouds. In: Proceedings of the 4th international conference on future internet of things and cloud (FiCloud), Vienna, 22–24 August 2016, pp.317–324. New York: IEEE.

Sung

Wang

. Hardware design on FPGA for Ethernet/SONET bridge in smart sensor system. In: Proceedings of the 7th international symposium on next generation electronics (ISNE), Taipei, Taiwan, 7–9 May 2018, pp.1–4. New York: IEEE.

10.

Raspberry Pi 3 model B, https://www.phoronix.com/scan.php?page=article&item=raspberry-pi3bplus-wifi&num=1

11.

ISO/IEC 20922: 2016 Information technology – Message Queuing Telemetry Transport (MQTT) v3.1.1.

12.

Luzuriaga

Cano

Calafate

, et al. Handling mobility in IoT applications using the MQTT protocol. In: Proceedings of the internet technologies and applications (ITA), Wrexham, 8–11 September 2015, pp.245–250. New York: IEEE.

13.

Eurotech and International Business Machines Corporation (IBM). MQTT V3.1 protocol specification, 1999–2010, pp.1–37, http://minatu2d.github.io/MQTT_V3r1_Protocol_Specification_vi.htm

14.

Lawrence

. Integration and virtualization of relational SQL and NoSQL systems including MySQL and MongoDB. In: Proceedings of the international conference on computational science and computational intelligence, Las Vegas, NV, 10–13 March 2014, pp.285–290. New York: IEEE.

15.

Raghavendra

. Virtual CPU scheduling techniques for kernel based virtual. In: Proceedings of the international conference on cloud computing in emerging markets (CCEM), Bangalore, India, 16–18 October 2013, pp.1–6. New York: IEEE.

16.

Yokotani

Sasaki

. Comparison with HTTP and MQTT on required network resources for IoT. In: Proceedings of the international conference on control, electronics, renewable energy and communications (ICCEREC), Bandung, Indonesia, 13–15 September 2016, pp.1–6. New York: IEEE.

17.

Ogasawara

. Workload characterization of server-side JavaScript. In: Proceedings of the international symposium on workload characterization (IISWC), Raleigh, NC, 26–28 October 2014, pp.1–6. New York: IEEE.

18.

Lee

, et al. Taiwan perspective: developing smart living technology. Int J Automat Smart Technol 2011; 1(1): 93–106.

19.

Saparkhojayev

Nurtayev

Baimenshina

. Access control and management system based on NFC-technology by the use of smart phones as keys. Middle East J Sci Res 2014; 21(7): 1130–1135.

20.

NFC basics. Developers Guides, 2018, pp.1–16, https://developer.android.com/guide/topics/connectivity/nfc/nfc.

21.

Hou

Zhao

Xiong

, et al. Internet of things cloud: architecture and implementation. IEEE Commun Mag 2016; 54: 32–39.

22.

Oprea

Reiter

. Minimizing response time for quorum-system protocols over wide-area networks. In: Proceedings of the 37th annual international conference on dependable systems and networks (DSN’07), Edinburgh, 25–28 June 2007, pp.1–10. New York: IEEE.

23.

Jutadhamakorn

Pillavas

Visoottiviseth

, et al. A scalable and low-cost MQTT broker clustering system. In: Proceedings of the 2017 2nd international conference on information technology (INCIT), Nakhon Pathom, Thailand, 2–3 November 2017, pp.1–5. New York: IEEE.

24.

Grabovsky

Cika

Zeman

, et al. Denial of service attack generator in Apache JMeter. In: Proceedings of the 2018 10th international congress on ultra modern telecommunications and control systems and workshops (ICUMT), Moscow, 5–9 November 2018, pp.1–4. New York: IEEE.