## 5 Proposed Implementation for Parametric Event Transformation  
Here, we present the implementation of the architecture application that serves an IoT-enabled application context. We assume that the application context is a smart farming case with an IoT-enabled greenhouse, and we provide the implementation that serves this case and can be easily generalized to any IoT-enabled context. Our approach is comprehensive, but we place particular emphasis on how the data are parametrically transformed following a bottom-up approach. More specifically, this implementation will show the transformation cycle of events starting from raw IoT data to their processing and transformation of events for calculating a quantity that we need in the examined IoT-enabled application context. First, we present some assumptions that are necessary for proper conception and assessment of the physical environment. We also present a fundamental example of implementation of specific layers and components of the proposed architecture in Section 3, which include the IoT Physical layer, the IoT Gateway, Event Bus, which is a Kafka broker, and, most notably, the Event Engine. In the physical context, a peripheral structure is installed that allows the connection of all computers and IoT devices to the Internet. An installed and configured local network allows secure communication (both wired and wireless) between IoT devices and computers. There are potent sensors with excellent features on the market. However, the implementation uses a simple, basic custom implementation for each IoT device (i.e., a sensor) in the physical context that can serve various IoT-enabled applications in different application contexts. In our physical context, our setup includes a standard, highly used DHT20 sensor for collecting air temperature and humidity and a Raspberry Pi single-board computer for deploying and running microcontrollers. The DHT20 sensor continuously measures the temperature and allows us to read the measured values as often as we like. It has an overall accuracy of \(\pm\)3% relative humidity and \(\pm\)0.5\({}^{\circ}\)C. It also uses standard I2C, so using it with any Arduino or Linux/Raspberry Pi board is straightforward. The DHT20 sensor is connected to a Raspberry Pi, which offers computational capabilities and a complete and self-contained Wi-Fi networking solution. In Raspberry Pi, a Python application based on CircuitPython (a library designed to program microcontrollers easily) runs and acts as the microcontroller. The microcontroller collects data from the DHT20 sensor in a specified interval, performs fundamental data transformations, and finally pushes the transformed data with the measurement values and the necessary metadata to the IoT Gateway with a POST HTTP request. The microcontroller includes useful information such as the measurement point, the measurement zone, i.e., the location of the sensor, the measurement time, and more, thus providing useful data to the components that will use the measurement data, notably the IoT Gateway and the Event Engine. These metadata allow the Event Engine to perform complex tasks such as grouping, time windowing, and more, as described in Section 4. Each IoT device has a finite operating autonomy and charging capability. Both autonomy and charging are outside the scope of this research. The above description applies to each IoT device, i.e., the sensor, located in the greenhouse. IoT Gateway specifications include support for multiple types of transport, such as HTTP, MQTT, CoAP, SNMP, LwM2M, and more. However, the current implementation is simple, and there is no requirement for two-way communication of the IoT device with the application. Therefore, we use HTTP Transport to forward the IoT device measurements to the IoT Gateway via HTTP. In HTTP Transport of the IoT Gateway, there is a REST Controller. The REST Controller exposes one endpoint that accepts only JSON POST requests.