## 6 Evaluation and Demonstrator Use Cases
### Smart Home Demonstrator  
The smart home demonstration environment implements commonly used smart home functionality in a doll house. Smart home functionality as such is not a novel feat. However, the approach in setting up and implementing the features is of interest. The following criteria were evaluated:* Transferability of functionality
* Time
* Reusability  
A comparison with traditional implementation of embedded devices is intended. In this doll house, as shown in Figure 5 the following sensors are physically implemented:  
* two Photovoltaic (PV) modules,
* five temperature sensors, and
* one motion detector.  
The following actuators are integrated to control the smart home environment:  
* five heating elements, simulating heaters,
* two sets of WS2812 NeoPixel LEDs, simulating television and bathtub,
* five LEDs, simulating lightbulbs, and
* one set of LEDs, simulating an oven  
Each of those sensors and actuators was described by a data point containing information such as value and unit. This definition was reusable between devices and IoT platform.  
These elements were controlled by four embedded devices, two ESP32 micro-controllers that were connected to the IoT platform via Ethernet, one nrf9160 micro-controller, that was connected to an ESP32 via Bluetooth that, in turn, routed communication to and from the platform. Finally, an STM micro-controller Nucleo-L073 RZ, that was connected to the other ESP32 via UART, was used. The sensors and actuators were distributed among these four micro-controllers. An overview of this architecture is shown in Figure 6.  
From a technical perspective, this architecture is more complex than necessary. However, the aim of this demonstrator scenario was to create complexity. A central IoT platform based on Node-RED was successfully used to control four distributed devices, of which only two had direct access to the platform. A PID controller was implemented for the heating elements, combining temperature values from one physical device with output values from another. Conditions and connections of sensor values and actuator were created in a simple fashion, due to the unified data point-structure. In the course of the demonstrator scenario, several micro-controllers were used. Exchange of devices was simple and quick due to the abstraction layer, provided by the SBT framework, as well as the underlying Zephyr toolchain. The following findings were derived. he base code remained the same. Also the data point definitions were used on every device. The implementation had to be done only once. That means Zephyr provided a base for any feature  
Figure 5: Picture of the employed doll house.  
implementation. These features were dependent on data points providing information about sensor values and setting actuator targets. The logic was created on the Node-RED platform. Generally, the same code could run on boards of different vendors, with only the pin-layout needing to be adapted. In Zephyr, this can be done with an overlay file that maps logic pin descriptions to the physical pins. Additionally, communication stacks could be integrated into the solutions and were wrapped with standardised interfaces. That allowed transfer of functionality between communication channels. Generally, the SBT functions as a building toolbox that connects hardware drivers, an IoT platform and expressive data point definitions to functionality with few manual labour. The time to change a micro-controller board while maintaining the same functionality was considerably less than a reimplementation would have required.