## 4 Related Work
DDF and glue.things have similarities to our work in that they were built on top of Node-RED [21], a browser-based editor that allows visual data flow programming. However, both of them have only focused on the application development instead of providing a full solution with customisable user applications as App adaptivity does. The most differentiated part of these approaches and others such as Apple Home, Google Home and BACnet, with respect to our work is the application's adaptability to the underlying physical infrastructure without having to connect these devices and recompile the system. This approach is intended to offer a novel framework for developing CoAP-based applications without reconfiguration. Appdaptivity enables the design of applications that are independent of the underlying physical devices and can be easily adjusted without recompiling. The IoT device has to be manually connected in glue.things and DDF and discovery are not supported, whereas Appdaptivity provides run-time discovery and update services that deploy portable user applications based on the IoT devices available at any given moment. PatRICIA [22] is a novel programming model for the IoT which decouples physical devices from user applications. PatRICIA introduces two new abstractions: Intent and IntentScope, which represent desired tasks to be performed in a physical environment and logical group of physical devices respectively. Intents are abstract representations of tasks and are applied on IntentScopes. Device controlling and monitoring are defined by domain experts using tasks through device services. On the other hand, application developers define device-decoupled applications using Intents which are dynamically transformed into tasks based on the information contained. Therefore, application developers define device-decoupled applications which use device-coupled applications written by domain expert users. Our solution differs from PatRICIA in the programming model. Instead of having different roles of development which decouple applications from devices only once, Appdaptivity hasjust one programming model which enables device-decoupled programming with visual components which leads to better results [8; 9]. App adaptivity is based upon a standard and promising IoT protocol, CoAP, with more than 30 open source implementations for IoT devices [23]. This increases the adoption of Appdaptivity as a application development system in the IoT unlike PatRICIA. Moreover, it has not been demonstrated how portable and personalised applications in PatRICIA could be achieved. Lastly, the programming model for device-decoupled applications in PatRICIA requires a familiarity with Intents programming, which increases the development efforts in comparison to visual component programming. A macro-programming framework for wireless sensor networks is also proposed in PyoT [24]. PyoT hides the complexity of the network by providing the available resources as a set of Python objects for the application developers. A Web UI (User Interface) has been incorporated into the system where users can carry out basic operations such as sensor monitoring, actuation control and resource listing. Therefore, application logic can be defined in two ways: a shell interface where application developers use the Python Application Programming Interface (API) to interact with the CoAP resources, and the Web UI for basic operations. PyoT shares some similarities with respect to Appdaptivity. On the one hand, PyoT uses CoAP as application protocol and enables automatic discovery of available resources and event actions to be performed when they are detected in an abstract way for end users. On the other hand, PyoT provides a high-level abstraction framework for developing IoT applications which reduces the aforementioned difficulties in programming such devices. Lastly, although more limited, a Web UI enables the application development for non-expert users.