## 8 Differences between CoAP, the CoAP++ Framework and Appdaptivity  
Consider that you want to create an application to manage and monitor some conditions in your work building or at home. You could deploy some CoAP servers together with some sensors and actuators. You could also get the same sensors and actuators for direct use from from lock-in vendors, but it is clear that this way only creates a vertical silo in the IoT. Then, you get resource-constrained devices to work with CoAP, such as Zolertia Re-Motes. In the next step, you would have to program the low level details for accessing these sensors and actuators in the Erbium framework. After that, you could interact with these sensors and actuators through CoAP, using for example the well-known CoAP web client Copper (Cu). However, you may also require other functionalities such as a HTTP-CoAP proxy, an RD, or being able to create groups of resources and conditional observations, and therefore decide to use the CoAP++ framework, installing it on a Raspberry Pi. Again, you can interact with the physical infrastructure with extended functionalities and the possibility to use any HTTP client to interact with the CoAP network, e.g., a web browser. Nevertheless, you would like  
Figure 14: RAM and Flash memory usage in the Zolertia RE-Motes and the Zolertia Orion router. (**a**) Memory average usage in the sketches of the Zolertia RE-Motes; (**b**) Memory usage in the sketch of the Zolertia Orion Router. to have a smartphone application to do the same tasks with your smartphone. You have decided to use the CoAP framework Californium and the Android platform to develop one. Now it is time to program your application logic. You can create automatic tasks that open the windows when the measurements of the CO2 sensors reach above a set level, a button to control all your lights and charts and alerts showing your location conditions such as temperature and humidity. Note that until this point App adaptivity has not been used nor required. Now, you have seen that the system works well with the use of open standards and you decide to control another room with new sensors and actuators. If you have programmed a specific functionality for the previous devices as is usually the case, you will have to program and re-compile the application to incorporate the new devices. Alternatively, your application may be able to automatically discover new CoAP servers together with the sensors and actuators of the new room, but normally you have to create an application with these new components. In these cases, you create device-coupled applications. Nevertheless, you could have created an application that automatically discovers the new devices in the CoAP networks and adapt the application logic as App adaptivity does. Let's suppose you can control the illumination of your space. You can use the group communication of the CoAP++ framework to create a group for managing them. In the case that there are new lights or changes in them, App adaptivity will update the corresponding behaviours, and also update their corresponding groups to ensure an up-to-date configuration. Furthermore, the rest of the behaviours that depend on these changes will also be updated, e.g., the trigger component that checks presence sensors to actuate over these lights. With App adaptivity, if you control n components and you deploy a new CoAP server with the same component, you will have the opportunity to control n+1 components automatically. This can be extrapolated to other behaviours, e.g., if you are displaying statistics about conditions of some sensors, each change in these sensors will be detected by App adaptivity and the associated configuration will be updated. App adaptivity will also enable the portability of the IoT applications to new CoAP networks in the future. In the case of personalised applications the challenges are higher.