# Open-Source MQTT-Based End-to-End IoT System for Smart City Scenarios
## 4 Proof-of-Concept
### Webservice Dashboard  
As previously stated, one of the main features of the proposed architecture is the real-time monitoring of the statistics collected by the sensors mounted on the wearable devices. This enables whoever is using our E2E architecture, e.g., a certain company deploying their services, to supervise the activity that is being performed by the users of that certain service. This feature is particularly important in those applications targeting VRUs since they have a higher probability of being engaged in accidents, putting their life at risk. Hence, being able to have a real time and accurate pool of data helps provide a clearer overview of the statistics of one user's health, as well as the environmental ones. This knowledge is fundamental since it allows the provider to offer immediate first aid in case of an unwell user. With such premises, we developed a webservice dashboard that enables receiving the sensors' data through the Android smartphone and the MQTT connection. Such dashboard has been implemented exploiting the Javascript functions inherited from the open-source Paho library, enabling a browser-based Javascript MQTT Client. The developed web application relies on Websockets in order to allow bi-directional communication between the dashboard and the MQTT broker. It is worth noticing the HTTP, due to its architectural structure, which is not designed for real-time full duplex web applications [36]. Moreover, in IoT systems, especially those requiring real-time data exchange, latency is one of the main issues. In the case of HTTP, we would have to implement HTTP polling, where the client sends a request to the server every polling interval. Therefore, in order to use this method, we should be aware of the frequency used by the sensor for updating the data, which is unfeasible to acknowledge with an asynchronous architecture. By increasing the polling interval, we would also cause a high number of requests, which might be inconsistent, as the server might not have the value of the new sensors yet, leading to a non-optimized IoT solution. This latter problem might be solved with long polling, which efficiently handles the information push from servers to client by holding the client's request until there is a new sensor value available to send as a response rather than sending an empty response PDU. However, it has been demonstrated how the Websockets protocol is the overall best solution for full-duplex communications when packets have to travel long distances over congested networks [37]. MQTT over Websockets allows receiving the messages we have in a standard publish/subscribe paradigm in an environment, the web browser, where the defined paradigm is request/response, thus allowing the browser to leverage all MQTT features, such as displaying real-time information from the Android gateway. Since the web service only accepts Websockets, the broker must be able to handle them by encapsulating the MQTT packets in Websockets frames. The dashboard has been developed with a rather simple graphic interface, and the first thing to do is define the IP address and port of the MQTT broker that the client has to connect to. In this specific case, the port number is 9001, which is the one generally used for Websockets; it is mandatory to enter the username and password that were previously set up during the configuration of the browser, as described in Section 4.3.1. Once the connection has been established, it is possible to receive the sensor's readings, which will then be displayed on screen, as shown in Figure 5.  
The Paho MQTT client running in background allows the user to subscribe to two different topics. The first one concerns the wearable device to be monitored, picked up through the scrolling menu where there is a list of all the wearable devices that have been deployed.