An IoT-based Coastal Recreational Suitability System using Effective Messaging Protocol

Coastal recreational activities are one of the main attractions for local public beachgoers and overseas tourists. The accessibility to better-quality coastal water will enhance safety and public health awareness when the information is available. Existing platforms showing the risk of whether a beach is suitable for public recreational use is less available in Malaysia. The Internet of Things (IoT) based system design specifically for coastal recreational suitability may differ from the existing configuration depending on the environment and requirements. This paper reports the design and implementation of an IoTbased system to capture the coastal environmental data and recommend recreational suitability. The system captures sensor data, store it in a database and displays the result using a dashboard. The variable data include the temperature, humidity, rain, pH, turbidity, oxidation-reduction potential (ORP), and total dissolved solids (TDS) in a coastal area. The hardware used in the design is the development boards such as Raspberry Pi, Arduino Uno, and ESP32 controller. The system is developed using PHP, MySQL, and Apache Web Server and can be accessed online at https://ipantai.xyz. When using Message Queuing Telemetry Transport (MQTT) as the effective messaging protocol and HiveMQ broker, the result has shown improvement for message size, throughput, and power consumption. The further potential of an IoT-based system is to bring value for coastal management and serve as a powerful tool to determine whether the coastal area is suitable for the public to access water recreational activities. Keywords—Coastal recreational; internet of things; message queuing telemetry transport; sensor; water quality


I. INTRODUCTION
Most countries in the world are surrounded by the ocean. The length of coastlines in the world is estimated at 1.16 million kilometres. Malaysia has about 4,800 kilometres of coastline comprising two distinctly different physical formations, namely the mangrove-fringed mudflats and sandy beaches. The coastlines are about equally divided between mud coast and sandy beaches. At least 50% of the adult population in the world visits the public water areas such as beaches, islands, etc. for recreational purposes [1]. Beachgoers rarely receive water quality information, whether the waters are suitable for recreational activity or vice versa. Poor water quality (such as microbial contamination) in coastal water poses a public health threat due to waterborne diseases. The risk of exposure to microbial contamination can be reduced by informing beachgoers in advance about the water quality. Recreational water activities improve when the water has better quality [2], [3] but users do not always recognise poor water quality or its associated health risks [1]. Coastal recreational activities are rapid development of economy and urbanisation can promise highly to expose to nearest water resources including the coastal area that ultimately embraces poor water quality severely by time excluding the existing harmful microbiology in the coastal ocean area. Therefore, understanding the problems and trends of water quality are crucial and significant to determine the water quality at a specific coastal area, formulate prevention and control, also to educate the public in terms of health risk by establishing related public information and regulation at the coastal recreational area.
In the 21st century, the accessibility to data and information is known at the fingertip. The Internet of Things (IoT) has become the basis of digital transformation and automation in delivering new ideas and service offerings to improve the way we live, work, and entertain ourselves [4], [5]. IoT is foreseen as a technology enabler in various cases. This paper reports the design and development of an IoTbased system for coastal recreational suitability. The system serves as a means to capture and monitoring for beach water quality. The system can be accessed by the public and potentially provide an initial awareness of clean coastlines. The coastal recreational area effectively contributes not just to public attraction as part of a tourism attraction but also contributes to the comprehensive economic driver for the state [6]. To understand and propose a solution to overcome the issue, this paper intends to explore an integrated approach suitable for coastal recreational suitability. The objectives are to:  Design and develop an IoT-based system for coastal recreational suitability systems.
 Implement an IoT-based system to suit the requirements for capturing, storing, and reporting coastal environment data.
The paper is organised into several sections. The first section introduces the research idea. The next section presents the related work in the area. Followed by methodology for system development and experiment set up. Afterwards, the *Corresponding Author

B. IoT in Coastal Research
Some research has been undertaken on coastal recreation using IoT. Be Right Beach (BRB) was developed consisting of a sensor network with a UV sensor, thermometer, humidity sensor and a camera for crowdedness estimation [13]. The data was collected by a cloud platform that provides useful information about the beaches and suggestions where to go based on user preferences like weather, crowdedness, time of travel etc. Another research example was blockchain innovation and IoT will help all users to get involved together in economic activities [14]. Next, researchers found out that the design, development, and deployment of an IoT-based marine environment monitoring and protection system is needed to address some critical issues including autonomy, adaptability, scalability, simplicity, and self-healing [15]. Another researcher [16] suggests application layer is to provide smart application services to meet user needs. In IoTbased marine environments, the application layer covers water quality monitoring, coral reef monitoring, marine (either offshore or deep-sea), fish farm monitoring and wave.

C. Water Quality
The context of water quality has been recognised to be the main highlight that requires important information about public health, environmental concern, and the quality of beach water for public usage. Over the years, coastal water was habitually exposed to anthropogenic and industrial pollution that led to negative consequences to public health and recreational activities [17]. In general, water quality is described as the assessment of sanitary and microbial water quality collectively. The results of the assessment should give a proper clarification about the water quality around the investigated beaches to inform the public, provide on-site guidance and information to the public relative to the safety aspect, assist and promote effective recreational management and formulate regulatory compliance based on the recreational area. Fig. 1 shows the classification matrix of water quality assessment.

D. Recreational Suitability
The detection of faecal contamination at the coastal beaches is subjected to extensive water quality that includes wastewater discharge, industrial waste over and surface runoff. As a result, the suitability of recreational areas is as crucial as the conservation of recreational areas by providing informative and presentable data about water quality trends in the coastal area. One of the recreational suitability assessments is from the Suitability for Recreational Grade (SFRG) [17]. The grading for the recreational suitability is determined by SFRG via the relationship between Microbiological Assessment Category (MAC) and Sanitary Inspection Category (SIC) [17]. Based on the recreational suitability assessment from SFRG via the relationship between the MAC and SIC, proper recreational management will be implemented to measure proper risk management action and formulate legal regulation before the public safety at the recreational area. There are four major field interventions which are compliance and enforcement control and abatement technology, public awareness and information and public health advice and interventions [17]. In this research outlining a better water quality assessment system is crucial to give better guidelines to formulate legal regulation and action plans based on the data generated by the water quality system used at the recreational area.
There has been less research conducted in IoT for coastal recreational suitability. Previous research focuses on environmental water quality using IoT. Similar research applies IoT devices to monitor beaches and crowd detection [13]. Several research reviews on [18] LoRaWAN implementation as an effective for IoT-based monitoring systems with a frequency below 1GHz which and some using GSM and Thingspeak [19]. In this research, we look at the IoT protocols specifically the IoT design for coastal recreational suitability using Message Queueing Telemetry Transport (MQTT) protocol. (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 12, No. 8, 2021 560 | P a g e www.ijacsa.thesai.org

A. System Development
In this project, the prototyping method is selected as the approach for system development. A prototype is a software model and through the prototype interaction, users can understand the desired system better. The prototyping method works best in situations where the requirement of the project is unknown. In addition to that, it is a method of iterative, trial, and error that takes place between the system developer and the client.
The advantages of using prototype methodology are:  It will be easier for the clients to understand the design of the project.
 Real-time monitoring and continuous client-developer interaction assist to build a good relationship.
 Risk factors are easily identified along with steps to mitigate the risk factor.
 Developer can get any input from a client earlier in the development cycle and save time.
In this research, the steps involved in prototyping methodology in Fig. 2 are described.

1) Requirement analysis and information gathering:
The first step of prototype methodology involves understanding the very basic requirements of the product, particularly about the user interface. It is possible at this point to neglect the problem in IoT and the messaging protocol that has been developed.
2) System design: The next step is the design the system. As this project must create a web-based system as it is included in client requirements, there need to use an HTTP protocol that relates to a database and world wide web (WWW). To integrate the MQTT protocol in a web-based system, Socket is needed and there is also a need for a Platform as a Service (PaaS) in the computing model. Heroku is used because this platform equips us with a ready runtime environment and application servers. Heroku will be designed as a medium (server) to create a connection to the MQTT broker so it can subscribe to the message from the broker itself. Every browser will request an HTTP upgrade so they can receive the real-time data using SocketIO. The sensor is hardware that is being chosen to measure certain parameters such as humidity, temperature, turbidity, and pH.

 HiveMQ
The research proposes the cloud HiveMQ as a broker. The reason for using the cloud was because it is cost-effective and lightweight. The setup for coastal recreational involves many locations, a centralised broker is needed in Fig. 3, and a cloud broker is appropriate. HiveMQ cost is free for a certain limit and suitable for a prototype project. The sensor will publish the data to the HiveMQ broker, and it will publish the message to the client who subscribes to it. Since MQTT are bidirectional communication, it can subscribe and publish at the same time. It enables real-time, bi-directional communication between web clients and servers. It has two parts: a client-side library that runs in the browser, and a server-side library for Node.js. Both components have a nearly identical API.
Since the project needs to communicate with a broker, socket io can communicate with the MQTT broker and is suitable for this project. Socket.IO primarily uses the WebSocket protocol with polling as a fallback option while providing the same interface. Although it can be used as simply a wrapper for WebSocket, it provides many more features, including broadcasting to multiple sockets, storing data associated with each client, and asynchronous I/O. Socket.IO provides the ability to implement real-time analytics, binary streaming, instant messaging, and document collaboration.

 Apache (HTTP)
Since MQTT does not have a database feature, using the HTTP protocol, it becomes possible to store the data. For the first process of HTTP, the sensor collects the data and transfers it to the Raspberry Pi. The Raspberry Pi, which acts as a web server and uses as a local host for the initial prototype. The sensor is connected to Arduino and Raspberry Pi. The port is going to use port 80. Fig. 4 shows how the HTTP protocol works initially started when a client requested a packet. Send the HTTP header using the TCP/IP protocol and the webserver is decoding, creating the header and formatting data before sending the HTTP response header back to the client. 561 | P a g e www.ijacsa.thesai.org 3) Developing initial prototype: In this step, the initial prototype is created, demonstrating the basic requirements, and providing user interfaces. It will implement the MQTT protocol with HiveMQ as a cloud broker. Then it will be connected to the Socket IO server that will subscribe to HiveMQ data. Once it gets the data, it will broadcast the message to the client whenever connected to the server. The initial prototype has an explore module that will retrieve the MQTT data in real-time on a webpage. This initial prototype will be presented to the client for client evaluation.

4) Client evaluation:
The next step is the client initial evaluation. In this step, the proposed system will be presented to the client for an initial evaluation. The user will verify the function created and it will tally with the client requirement itself. It will help to determine the strength and weaknesses of the coastal recreational system. Comments and suggestions will be collected from the client and provided to the developer. 5) Refining prototype: In this phase, if the client is not satisfied with the current prototype, the prototype must be improved according to feedback and suggestions from the client. For example, every time was adding new function and module, the user will verify and check the requirement. For example, in this system development, the first module been created are explore module, then the home page module, login/signup module, sensor entry module and sensor reading module. This phase will not be completed until all the client specified requirements have been met. Once the client is pleased with the existing prototype, based on the approved final prototype, a final system is produced. (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 12, No. 8, 2021 562 | P a g e www.ijacsa.thesai.org 6) Implementation and maintenance: Once the final system is developed based on the final prototype, it is thoroughly tested and deployed to production. The system undergoes routine maintenance to minimising downtime and prevent large-scale failures. For example, there is a need to check the sensor onside rather than remote access periodically and to make sure the sensor is cleaned and no obstructions. The system was also tested on a web-based system by checking on Cloudflare to see if there are any attacks on the webserver.

B. Network Design
In this project, three locations are being presented. The system displays based on single locations. For example, the ODEC beach is shown in Fig. 6. These single locations are connected to the HiveMQ cloud broker to publish the message. Socket IO is implemented, and it subscribes to the messages from the HiveMQ broker. Furthermore, SocketIO will publish a broadcast message to every connected client that requests to view the data. Clients that view the data must request io.emit that has been applied on server ipantai via JavaScript. The JavaScript will automatically emit socket io to the server to make a TCP connection via SocketIO. If the connection is successful, every message transmitted by the sensor will be broadcast by the socket io server to the client.
IV. SYSTEM IMPLEMENTATION System analysis is gathering and interpreting data to recognise the problems and decomposition into its component. In this phase, the requirements and functionality of this project are determined. The technique used to conduct this analysis is to compare the benchmark with another similar project that uses MQTT with different parameters. Parameter involved for comparison is the message size of MQTT, throughput, and power consumption. After the process of data gathering and comparison, a prototype is developed. Some features in the existing system are based on interviews with stakeholders which are new and unique. Fig. 5 shows the context diagram of the IoT Based System for Coastal Recreational Suitability with six entities which are IoT Client, HiveMQ Cloud Broker, Heroku Server, Motion Sensor, Webcam and User. Fig. 7 shows a use case diagram of this system works as there are 16 uses cases for this system. For the MQTT part, only five uses case is involved while the remaining 11 are from client requirements. In this use case, three core parts will have their function such as HiveMQ Broker, Heroku Server and ipantai Webserver.       Experiments are conducted to measure MQTT size for full system parameter message size. The script is run in Raspberry Pi that will publish the MQTT message to the broker. The python script will run for looping every second to transmit the message to the broker. The information is processed and can be viewed by subscribing to the message. Fig. 12 shows a script implemented on Raspberry Pi to publish a message to a broker.  564 | P a g e www.ijacsa.thesai.org Fig. 13 shows packets captured by Wireshark during transmission. It shows that the cloud broker used is HiveMQ are using Transport Layer Security V1.2 and it was captured using Wireshark. Before that, an MQTT broker is a server that receives all messages from the clients and then routes the messages to the appropriate destination clients. An MQTT client is any device (from a microcontroller up to a fullyfledged server) that runs an MQTT library and connects to an MQTT broker over a network. From a client to connect to a broker, it must run the TLSV1.2 encryption protocol to gain access with the MQTT broker. Fig. 13 also shows HiveMQ connections are in port 8883 which are more secured than 1883 because SSL will verify that the connection is encrypted using a certificate belonging to the domain name that you were trying to connect to. The two ends will also encrypt all traffic so that an observing party will be unable to eavesdrop. Without SSL IoT devices become vulnerable to a malicious broker impersonating the one you want to connect to. It is also possible that a third party might tamper with the data received. And an eavesdropper might attacker could see MQTT username and password. From observation has been made using Wireshark found total frame lengths are 297 bytes. Layer 1(Ethernet Frame) size is 14 bytes which contain source and destination IP addresses. Layer 2 (IP header) contains 20 bytes, Layer 3(TCP header) contains 32 bytes, Layer 4 (SSL Header) are 5 bytes. So, the total header involves 71 bytes. The encrypted application data contain 226 bytes per message transmitted. With a sum of 226 bytes and the header will contain exactly 297 bytes.

 Client Publish (Single Parameter)
The next experiment uses a single parameter to send a message from the client to the broker. From the observation shown in Fig. 14, a single message packet contains a total of 159 bytes that contain ph value and identifier of location. For example, "data": {"ph": "6.48"}, {"unique_id": "odec_beach"}. Layer 1 (Ethernet Frame) size is 14 bytes which contain source and destination IP addresses. Layer 2 (IP header) contains 20 bytes, Layer 3(TCP header) contains 32 bytes, Layer 4 (SSL Header contain 5 bytes for header and 88 bytes for the application data. In comparison, the header between single and multi-parameter are the same but has a huge difference on application data. Using multi-message that only contain 226 bytes from an average of 28.25 bytes per parameter. Thus, it shows three times better for saving network consumption and reducing complexity in MQTT system design.

B. Throughput
Testing MQTT message throughput is important for an IoT application. It is also important to identify the maximum message throughput a single MQTT broker instance, as well as an elastically scaling MQTT broker cluster, can support without service degradation. This will help with capacity planning and can ensure deployment scale when the increase in usage.
The experiments are conducted to measure the throughput using ntopng installed on Raspberry Pi. It provides a web GUI to access accurate monitoring data. It provides detailed views on active hosts, flows, IP addresses, Mac addresses, Autonomous Systems, and throughput. From that, it can easily identify MQTT brokers and Pi. Throughput is how much information gets delivered in a certain amount of time. Most of the time network throughput is measured in bits per second (bps). The higher the throughput, the better the network and able to send data without packet drop. Fig. 15  This experiment is conducted within three days. There are approximately 1400 messages sent every hour and it approximately generates 42,000 messages per day. The python code will run every second to collect sensor data. The result for three days analysis is shown in Table I. The result includes the date and time, duration, throughput (Raspberry Pi and Broker), network consumption (Raspberry Pi and Broker), and message size.  Based on the table above, the throughput of Raspberry Pi is consistent between 5.63 kbit/s until 10.49 kbit/s with an average of 8.23 kbit/s. For MQTT broker throughput, it shows 1.05 kbit/s until 3.17 kbit/s with an average of 1.76 kbit/s. With the speed mentioned, it is considered average and consistent for sending 297 bytes packets to the broker. When testing on the ipantai system that connects with the broker, there is no delay of data. Therefore, the result supports MQTT as the suitable protocol for a system requiring less bandwidth, constrained devices, and high latency. The design principle is to minimise the network bandwidth and device resource requirements while attempting to ensure reliability and some degree of delivery assurance. However, in this research, there are no studies about other brokers that may outperform the investigated HiveMQ broker.
The network consumption depends on throughput. If there are more throughput in the network, more network consumption will be generated. For network consumption in Raspberry Pi, it consumes 72.15 MB during the three days observation. With that, an average of 24.05 MB bandwidth consumption per day is reasonable for an IoT based system to handle and maintain. If the device consumes 24.05 MB per day, it only consumes 721.5 MB per month. Thus, a user only needs to find an Internet plan with the said minimum requirement of 1GB quota per month. In this case, most providers in Malaysia offer around RM19 (USD4) per month/GB. It is affordable for developers to maintain. Since this project is using the beach as the focus of research for data gathering, the Internet bandwidth and coverage are not always available. However, MQTT serves as a lightweight protocol and keeps bandwidth requirements to an absolute minimum, handles unreliable networks and requires little implementation effort for developers. The message sizes are still consistent between 296 bytes and 297 bytes with 296.7 bytes as the average size within the three days. The message size depends on the reading. If there are more decimal places on the readings, more bytes need to be sent. For example, if the temperature increases from 31.0 to 35.456-degree Celcius, more bytes are being sent from the publisher.
The result shows better performance in terms of throughput and message sizes being transmitted compared to previous research [20][21] [22]. The possible reason is different hardware [20] is using Wemos D1 R2 as microcontroller and Mosquitto as a broker, different message size [21] and using different cloud brokers such as Mosquitto and Paho [22]. MQTT performs better than AMQP in bandwidth usage and message throughput.

C. Power Consumption
This project uses the smart plug from Tenda for capturing and monitoring power consumption. The model used is Tenda Smart Wi-Fi Plug with Energy Monitoring (SP-9). Tenda SP-9 has included an energy monitoring function that can measure the power used by day/week/months/year. It can handle input from 100 V until 240 V between 50/60 Hz with 13A maximum load. To use the Smart Wi-Fi plug, a mobile device having Android 4.4 or higher or IOS 9.0 or higher is required. A WIFI network is also preferable. The experiment measured the power consumption of the broker and Raspberry Pi for three days. Table II shows an overview of the result taken and  presented in the form of a table. The table shows the date and time, duration, current power (W) and power usage (kWh).
In Table II, it is found that the reading is consistent from 0.12kWh until 0.13kWh per day with an average of 0.126kWh. Next, the current power is used steadily from the range 5.26W until 5.65W with an average power of 5.44W. The power consumption of Raspberry Pi depends on the activity running on the operating system. If there is heavy activity such as streaming, the power consumption is significantly higher than usual. This result shows lower power www.ijacsa.thesai.org consumption within the range of 0.12kWh to 0.13kWh per day. If it is multiplied by 30 days (1 month), it will consume approximately 6kW. The average electricity tariff per kWh in Malaysia is approximately RM0.32 (USD0.06). Therefore, it cost a minimum amount of about RM1.14 (USD0.30) per month. However, if the Raspberry Pi is powered up by solar, there should be no monthly cost for electricity which is possible for an IoT-based system. The research is that using Raspberry Pi and Arduino compared to another research using different hardware and sensor such as Arduino Uno and Waspmote [23] resulting in more power consumption while publishing data. Some other improvements in designing the IoT-based system may include security features using a goalbased approach [24], [25], explore suitable machine learning algorithms in water research [26], [27] and improve IoT networks using single-on with MQTT [28].

VI. CONCLUSION AND FUTURE WORK
In summary, the research has uncovered several significant discoveries. The objectives are to design and develop an IoTbased system for coastal recreational suitability systems and implement an IoT-based system to suit the requirements for capturing, storing, and reporting coastal environment data. The research presented an IoT based system design using MQTT protocol and conducted several experiments measuring the i) message size ii) throughput and iii) power consumption. The result has shown the specified design and system development benefits from using MQTT as the primary protocol of communication between IoT devices. The message size is captured in small packets, which means less data consumption and power required than certain protocols, such as HTTP. The smaller message size makes it ideal for situations where bandwidth is limited, which is an important aspect of IoT devices. The next finding obtained from this research is better performance was presented using HiveMQ broker as part of the configuration compared to previous research. The throughput captured by HiveMQ cloud brokers is faster to send and receive data efficiently. This has also shown that MQTT is lightweight, quick, energy-efficient for a system, which is crucial for the implementation of IoT. Therefore, these findings summarise that the HiveMQ cloud broker has several advantages and is suitable for coastal recreational configuration. As this setup may involve many locations, a cloud broker is suitable and possible future work may need to centralise the connections between many places.
Finally, the findings hope to promote MQTT as the main communication specifically in the industry 4.0 (IR4.0) era. IR 4.0 could enable technologies and a new dimension in environmental monitoring systems to preserve and provide a safer environment for people to undertake coastal recreational activities. In the future, these systems can provide real-time data, decentralise analytics and support decision making.