## 3 Relaying
### Collecting with CoAP  
To address the complexities of IoT communications within a sophisticated network environment, a comprehensive solution was developed to bridge the gap between CoAP and HTTP protocols through the implementation of a RESTful micro-server. This approach was realized using Python, a language chosen for its flexibility and extensive support, and because of its presence in the core of HA technology; thus, leaner integration between them can be achieved if needed. We took advantage of Flask [41], a microframework celebrated for its minimalistic yet powerful features at the same time that it helps us accelerate web-related coding.  
The backbone of this communication server is the CoAPython library [42], which plays a pivotal role in integrating CoAP protocol functionalities, facilitating seamless interactions between IoT devices. CoAP messages are accordingly parsed, as stated by the simple data model of the 6 LoWPAN devices deployed in this project.  
In this fashion, significant data values and sensor states can be extracted from CoAP messages, then incorporated into a more common, current, and suitable format. This process mostly involves data _JSONification_ and basic modeling. This conversion process, although not intricate, is critical for ensuring that data from foreign IoT devices are discoverable, easily accessible, and manageable through common Internet web technologies. In Figure 3, the reader can see a simple diagram of the network abstracted to the upper layers that depicts the changes in protocols we are dealing with.  
The server architecture is designed with resource efficiency in mind, as always-first, major IoT mantra, allowing for lightweight operations that maintain system performance while handling data exchanges. Flask's ability to create a minimal yet functional web server environment has been instrumental in this regard, providing only essential components to support RESTful interactions and CoAP compliance, whilst not overwhelming the system with unnecessary matters. Moreover, the server's configuration includes a set of predefined routes, each catering to specific data retrieval or device interaction needs, as one of the main  
Figure 3: A coarse, protocol-oriented representation of the IoT chain.  
intricacies with iPv6 networks is their routing's lack of ease and iPv4 direct compatibility, a fact that is usually worsened by the _(ab)_ use of NAT and tunneling.  
This structured, kind of isolated approach not only simplifies usability for developers and system integrators, but also enhances the system's reliability and scalability by clearly defining communication pathways and data processing methodologies, helping future-proofing. In our actual testing deployment, the server was connected via Wi-Fi to the same LAN as the 6 LoWPAN coordinator was connected to.  
The server periodically queries every IoT device comprising the designated 6 LoWPAN network, as claimed by the coordinator. Note that there are also methods implemented to retrieve network characteristics from the coordinator, such as lists of devices, individual device information and sensing capabilities thereof, network telemetries and quality indexes, sensor data and states per se, etc. As stated, the server collects and organizes data into JSON documents following the appropriate models. These data are now available to be pushed to the middleware: PyBytes.