## 6 Implementation and Evaluation
### Functional Evaluation  
The functionality for creating, validating, using and deleting entities has been implemented as described above. In this subsection we demonstrate the main functionality of the implementation using a series of screenshots covering the life cycle of an entity. These screenshots are taken while communicating with the sensors in iMinds demo box. Figure 12 shows a screenshot demonstrating the result of sending a CoAP POST request to the EM to create an entity with five heterogeneous  
Figure 11: iMinds IoT portable home automation demo box. (**a**) The upper level shows a map of a house with various sensors and actuators installed; (**b**) Looking at the lower layer of the box the connections of the sensors are shown. members. This request results in the creation of the entity with the URI \"/2\" and in the validation of this entity by querying all members profiles. All complexity related to the creation and validation of the entity is hidden for the client and managed transparently by the EM. At this moment, the entity has been created and the client can use the newly created entity and interact with it by sending a single CoAP request to the entity resource. Figure 13 shows a client issuing a CoAP GET request to the newly created entity on the EM. The request ultimately results in a single reply from the EM, which combines the results of querying all five members of the entity. The client does not have to bother executing all individual requests and processing the corresponding results. The above example demonstrates how an entity can be created and used with default values, since the client did not specify anything about its behavior neither at creation time, nor at usage time. However as described in Section 5, the EM allows the client to customize the behavior of the entity at creation as well as at usage time by using URI queries in the CoAP requests. Some of these features are shown in the example in Figure 14. In Figure 14a the client used URI queries at creation time to create an entity of six members, naming it \"room_temperature\" and specifying that only four out of the six members need to reply before sending the combined reply to the client. Figure 14b shows the profile of the newly created entity, which, among others, shows that the entity supports four entity operations (eo=[\"lst\",\"avg\",\"min\",\"max\"]) with lst being the default operation as it is the first operation listed. As expected, when querying the entity, the Entity Manager returns a list of the first four replies it has received from all members in a single JSON reply in Figure 14c. When the client  
Figure 12: Sending a CoAP POST request to the Entity Manager to create an entity with five members, results in the creation of the entity with the URI “/2” and in the validation of the entity. uses the URI query (?eo=\"avg\") to obtain the average instead of the default list, the individual responses are processed by the Entity Manager and the average value is returned as shown in Figure 14d. Figure 14: Advanced EM features. (**a**) Creation of an entity of 6 members and naming it “room_temperature” and specifying that only 4 out of the 6 members need to reply, before sending the combined reply to the client; (**b**) The profile of the newly created entity; (**c**) Querying the entity with default operation “List Replies”; (**d**) Querying the entity and specifying that the reply should only contain the average of the member values. Figure 13: Sending a CoAP GET request to the entity results in a reply that combines the results of querying all members in the entity. In the last screenshot (Figure 15) we show how a client can select resources from a list of resources obtained from a resource directory to create an entity. The resource directory lists all CoAP resources of the sensors in our real-life wireless sensor network testbed, namely w-iLab.t [35].