A Survey on IoT Programming Platforms: A Business-Domain Experts

Perspective

FATMA-ZOHRA HANNOU∗ , EDF R&D, Paris Saclay, France

MAXIME LEFRANÇOIS, Mines Saint-Etienne, Univ Clermont Auvergne, INP Clermont Auvergne, CNRS, UMR
6158 LIMOS, F-42023 Saint-Etienne, France
PIERRE JOUVELOT, Mines Paris, PSL University, France, France
VICTOR CHARPENAY, Mines Saint-Etienne, Univ Clermont Auvergne, INP Clermont Auvergne, CNRS, UMR 6158
LIMOS, F-42023 Saint-Etienne, France
ANTOINE ZIMMERMANN, Mines Saint-Etienne, Univ Clermont Auvergne, INP Clermont Auvergne, CNRS,
UMR 6158 LIMOS, F-42023 Saint-Etienne, France

The vast growth and digitalization potential offered by the Internet of Things (IoT) is hindered by substantial barriers in accessibility,
interoperability, and complexity, mainly affecting small organizations and non-technical entities. This survey paper provides a detailed
overview of the landscape of IoT programming platforms, focusing specifically on the development support they offer for varying
end-user profiles, ranging from developers with IoT expertise to business experts willing to take advantage of IoT solutions to automate
their organization processes. The survey examines a range of IoT platforms, classified according to their programming approach
between general-purpose programming solutions, model-driven programming, mashups and end-user programming. Necessary IoT
and programming backgrounds are described to empower non-technical readers with a comprehensive field summary. In addition, the
paper compares the features of the most representative platforms and provides decision insights and guidelines to support end-users in
selecting appropriate IoT platforms for their use cases. This work contributes to narrowing the knowledge gap between IoT specialists
and end users, breaking accessibility barriers and further promoting the integration of IoT technologies in various domains.1

Additional Key Words and Phrases: Internet of Things, IoT programming, IoT platforms, Smart Building, Smart Agriculture

ACM Reference Format:

Fatma-Zohra HANNOU, Maxime Lefrançois, Pierre Jouvelot, Victor Charpenay, and Antoine Zimmermann. 2024. A Survey on
IoT Programming Platforms: A Business-Domain Experts Perspective. ACM Comput. Surv. 1, 1 (October 2024), 35 pages. https:
//doi.org/XXXXXXX.XXXXXXX

1 Due to space constraints, this paper has been abridged. An extended version of the original work is available at the following link: https://hal.science/hal-
04159987

Authors’ addresses: Fatma-Zohra HANNOU, [email protected], EDF R&D, Paris Saclay, France; Maxime Lefrançois, [email protected],
Mines Saint-Etienne, Univ Clermont Auvergne, INP Clermont Auvergne, CNRS, UMR 6158 LIMOS, F-42023 Saint-Etienne, France; Pierre Jouvelot, Mines
Paris, PSL University, France, France; Victor Charpenay, [email protected], Mines Saint-Etienne, Univ Clermont Auvergne, INP Clermont
Auvergne, CNRS, UMR 6158 LIMOS, F-42023 Saint-Etienne, France; Antoine Zimmermann, [email protected], Mines Saint-Etienne, Univ
Clermont Auvergne, INP Clermont Auvergne, CNRS, UMR 6158 LIMOS, F-42023 Saint-Etienne, France.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not
made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components
of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to
redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected].
© 2024 Association for Computing Machinery.
Manuscript submitted to ACM

Manuscript submitted to ACM 1

2 Hannou et al.

1 INTRODUCTION
The emergence of the Internet of Things (IoT) has opened up a broader, deeper, and more realistic perception of the
surrounding environment by transforming any “thing” into a quasi-continuously available data source or control lever.
It has demonstrated an unlimited potential for boosting the digitization of many aspects of everyone’s daily life [47]. It
also supports companies in optimizing process automation, increasing operational efficiency, and optimizing costs. The
IoT market has witnessed tremendous growth (from 300 billion USD in 2021 to an expected 600 billion USD in 2026 [48]),
offering many new device technologies, tools, architectures, and projects, either generic or tailored to specific use cases.
While this diversity accelerates the adoption of IoT within multiple domains, such as building automation, healthcare,
agriculture, or energy management, it raises interoperability and access challenges. The subsequent complexity might
represent a significant barrier to the immediate IoT technologies use for small organizations (or non-technical companies)
that cannot afford the cost of hiring IoT expert teams to handle complex architectures and deployment processes. IoT
platforms combine hardware and software technologies to enable the building and deployment of IoT applications [1]
through a common user interface, easing access and interoperability within the IoT ecosystem. It provides services and
facilities to develop IoT solutions, including device integration, data storage and processing, user communication and
development tools. Yet, the promise of easy-to-deploy, easy-to-configure IoT systems has not been entirely fulfilled. In
most cases, IoT systems are developed on generic platforms offering predefined routines with limited customization
options. Domain-oriented tools are often focused on fixed architectures, device ranges, and features that do not
necessarily match the organization’s needs, especially those covering overlapping vertical domains (e.g., building
management and healthcare, agriculture and industry), requiring the combined automation of both domains’ processes.
Somewhere between the average end user and the IoT specialist, the so-called “vertical domain expert” increasingly
expresses the will to obtain the most out of the IoT technologies by going beyond the ‘configuration routine” mode. To
meet these expectations, a new generation of IoT platforms has widened the spectrum of their user profiles by creating
simplified user interfaces (UIs) with more expressive power. These UIs, often rely on domain-specific languages [27]
(DSLs), with the aim to reach larger end-user communities, including those with no or little technical background.
As an end-user, understanding the extent of what an IoT platform offers, its characteristics, and whether it makes
a suitable choice for the use case at hand is a challenging matter. Committing to a specific IoT deployment requires
a positive cost-benefit balance and compliance with additional requirements: interoperability, domain tasks, level
of abstraction (following user skills), maintenance cost, or documentation availability. These factors, among others,
are of variable importance depending on the application use cases. For example, the user/developer should consider
interoperability guarantees when dealing with heterogeneous devices, protocols or sub-domains. In other cases, as
within healthcare or building management fields, sensitive data and processes have to be protected against disclosure
and unauthorized access risks, making security and privacy guarantees of utmost importance. Other requirements
include reliability, latency, autonomy, and cost.
Unfortunately, the current scientific literature does not, to our knowledge, provide a comprehensive comparison
and evaluation of IoT platforms based on the practical requirements of end-users across different domains. Most of the
existing works discussed in the Related Work section in the Supplementary material (Appendix A) consider the study
of IoT platforms from a single perspective such as interoperability, architecture, connectivity, standards, security or
cloud services. The specialized nature of these papers increases the difficulty of getting a comprehensive understanding
of all these platforms while taking into account all their necessary practical characteristics. This survey paper aims to

Manuscript submitted to ACM

A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 3

lower the access barriers to IoT technologies by filling this gap, evaluating IoT platforms on multiple key factors, and
providing end-users with actionable insights to make informed decisions when selecting an IoT platform.
In this survey paper, we consider these key factors to describe the landscape of IoT programming platforms and
exhibit some of their strengths and weaknesses. However, given the vast spectrum of available technologies, this survey
focuses solely on the development side of IoT applications.
Accordingly, particular attention is paid to the support the existing platforms offer to users aiming to develop
applications. This technology segment is explored based on the most relevant parameters, such as the abstraction
level of IoT-specific programming languages, the expressiveness or richness of the associated toolboxes, etc. Various
programming languages are accessible through IoT platforms, from the lowest abstraction level to high-level DSLs
dedicated to vertical domains, with adapted representations and vocabularies.

Contributions and Audience. This survey aims at providing vertical domain experts striving to develop IoT applications
with programming-related resources to understand the existing IoT landscape. IoT platforms are presented following
different development approaches that match more or less target users’ profiles. It is intended to be used as a resource
by this particular developer community for making an informed decision regarding which platform presents the
best characteristics for their expected application. As such, the contribution of this work is twofold. First, it provides
background on the IoT field with a particular focus on programming languages. The most relevant characteristics are
defined and serve as a basis for assessing platforms. Second, it produces an analysis of the IoT landscape driven by
end-user/developer requirements, examining platforms’ families and characteristics.

Related surveys. Several works survey IoT platforms and technologies, with variable focus points. Note that several
related topics fall outside the scope of this survey, such as IoT architectures, interoperability projects, software archi-
tectures, security, or DSL implementations. Some of these aspects are mentioned in the high-level description of the
IoT platforms, and therefore introduced in the survey background to support reader understanding decision insights
completing programming features. However, no study covering these matters is conducted here. For more details about
related works, we refer the reader to the Related Surveys section in the Supplementary material (Appendix A).

Organization. The remainder of this paper is organized as follows (see the roadmap illustration provided in Figure 1).
Section 2 introduces two running examples used along the paper to illustrate representative usage scenarios of IoT

BACKGROUND ON PROGRAMMING DOMAIN DEDICATED DISCUSSION AND

INTRODUCTION USE CASES CONCLUSION
THE IOT THE IOT IOT PLATFORMS INSIGHTS

Contribution-
Building automation Building Summary table
audience Heterogeneity- Methodology
Smart irrigation Automation Decision insights
Related surveys Interoperability GPL
Paper organization System Model-Driven tools Smart Agriculture
architectures Mashups
Cost and licences End-User
programming
platforms

Fig. 1. Roadmap of the paper

platforms. The first scenario deals with a building automation application for indoor air-quality monitoring, and the
second considers precision agriculture through the case of a smart irrigation process. Section 3 provides an overview of
Manuscript submitted to ACM
4 Hannou et al.

the IoT field to introduce some key platform characteristics such as interoperability, software architecture, licences, or
business domain. Appendix B in the Supplementary material also provides background information about programming
languages with a focus on domain-specific languages highly used within the IoT community. Section 4 presents an
insight into generic IoT platforms grouped by programming approaches. It showcases how the technical characteristics
of each tool can be exploited in an automation scenario and to what IoT task it contributes. Section 5 covers specific
agriculture and building automation IoT solutions. Section 6 summarizes the outcomes through a comparative table
highlighting discussed platform’s properties and decision making insights.

2 USE CASES
This section introduces two use cases for IoT programming technologies, for the building automation and the precision
agriculture domains (see Fig. 2). These two domains have been selected as they are good representatives of the user
community of IoT technologies, and rely on similar physical sensing techniques but with contrasting semantics,
purposes, and deployment architectures (indoor/outdoor), providing thus an insightful spectrum of possibilities.

(a) Indoor air quality monitoring through automatic window (b) Smart irrigation scenario through environment indicators
opening processing

Fig. 2. Two example use cases for IoT programming technologies.

Building Automation Use Case. Building-automation scenarios often aim at fulfilling energy-optimization strategies
while guaranteeing users’ health and comfort. Modern building management relies on sensor networks that collect
data about environmental indicators, energy consumption, or room occupancy. Various actuators are deployed within
the building for automatic window and door opening or controlling heating, ventilation, air conditioning, or lighting
equipment. In the use case illustrated in Fig. 2a, sensors continuously monitor the indoor temperature and CO2 levels
to determine the air quality in a classroom. These data, enriched with room occupancy information (course schedule),
can be used to determine the air quality and user preference for optimal temperature. Heating can be triggered as late
as possible such that the comfort temperature is reached when the users come in. If the observed CO2 level is too high,
the window is opened automatically and the heater is shut down.
Manuscript submitted to ACM
A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 5

Smart Irrigation Use Case. Precision agriculture techniques automate and optimize different crop-related processes,
for example to supervise the irrigation process by automatically triggering or stopping crop watering. In the use
case illustrated in Fig.2b, sensors and actuators are deployed in the outdoor plots and the indoor greenhouse of a
Farm. Sensors 1, 2, and 3 respectively observe the current indoor temperature, humidity, and soil moisture within the
greenhouse. The outdoor sensors measure the soil moisture of the plots, and the local weather station provides current
and forecasted weather data. Data is centralized and enriched with the crop-development state. Neuro-symbolic AI
techniques are applied to support a twofold decision-making process to ensure optimal crop development: when to
start/stop the watering, and what amount of water to deliver via water valves. The optimal strategy also considers
budget, regulations, water-availability planning, productivity constraints, heat waves, etc.

3 BACKGROUND ON THE INTERNET OF THINGS

The IoT allows physical objects to have digital identities and connect to the Internet. This enables them to generate and
exchange data about their status and surroundings. Kevin Ashton coined the term IoT in 1999, linking it to networks
of Radio-Frequency Identification (RFID) chips [3]. The IoT has numerous definitions, often emphasizing specific
deployment cases or architectural considerations. The International Telecommunication Union (ITU) provides the
following definition [32]: a global infrastructure for the information society, enabling advanced services by interconnecting
(physical and virtual) things based on existing and evolving interoperable information and communication technologies.
Objects in the IoT context can be any physical entity that can connect directly or indirectly to the Internet. With the
advancement of technology and connectivity standards, more objects can now be part of the IoT. In 2008, the number of
connected objects surpassed the number of humans accessing the Internet (Cisco Internet Business Solutions [31]).
Cloud-based application services [4] have become increasingly popular across a wide range of applications and scales:
industry [105], smart buildings [54], healthcare [49], agronomy [86], and more [93].
The main characteristics used in this survey to describe IoT platforms are grouped into five topics: interoperability,
software architecture, licence and cost, business domain, and development support. This section presents the first four
dimensions, and how tools are evaluated according to their subsequent criteria. Given that the primary focus of this
survey is the programming of IoT applications, the development support is detailed in the Supplementary material
(Appendix A).

3.1 Heterogeneity-Interoperability
Adapting to the high pace of technological advances, IoT tools and platforms constantly expand support to new devices,
protocols, and services, increasing the heterogeneity of IoT systems and raising new interoperability challenges.
This section reviews common heterogeneity/interoperability sources such as device, connectivity, syntax, and
semantics , and provides an overview of related interoperability issues.

3.1.1 Device. The diversity of IoT technology providers led to a mixture of billions of devices with heterogeneous
hardware specifications coexisting within IoT systems. Within an IoT network architecture, nodes correspond to
devices with computing capabilities. They are generally categorized according to their resources, mainly RAM, storage,
CPU, communication protocols, energy supply, transmission power, and the architectural layer they belong to. These
characteristics are determined by the tier in which they are deployed (Cloud, Fog, Edge) [87]. Related taxonomies
prosper and sometimes differ (see, e.g., [91, 94]), but a frequently used classification builds upon three levels: low or
constrained devices with limited resources, middle or FOG devices, and powerful nodes such as cloud infrastructures.
Manuscript submitted to ACM
6 Hannou et al.

3.1.2 Connectivity. One early challenge the IoT field faced was the strong requirement for continuous object connec-
tivity. Building reliable smart applications relies on the quasi-timely availability of sensing and actuating capabilities.
The device heterogeneity and the need for reliable data exchange channels require deployment strategies to leverage
hybrid networking and messaging protocols.
At the infrastructure (network) level, an extensive set of communication networks are inherited from the Wireless
Sensor Network field [107], providing a wide spectrum of constrained objects with their inherent power specifications
and connectivity range. Power requirements are an intrinsic characteristics of these devices, often linked to specific
supervision needs to avoid high maintenance costs. While some devices support multiple protocols, the connectivity
range is defined according to the deployment and application scenario: indoor or outdoor installation, device mobility,
available gateways, etc. The connectivity protocols at the lower layers (Physical-Data Link in the OSI model [95]) are
commonly identified by their operating range [69]: Contact area (e.g., RFID, NFC), Wireless Personal Area Network
(WPAN) protocols such as ZigBEE and Bluetooth, Wireless Local Area Network (WLAN) such as WiFi, Wireless Wide
Area Network (WWAN), including cellular and Low-Power Wide Area (LPWAN) networks, up to 100 km such as
LoRaWAN. At the top (application) layer of the devices communications, the most popular protocols are [25] HyperText
Transfer Protocol (HTTP), Message Queue Telemetry Transport (MQTT) and Constrained Application Protocol (COAP).

3.1.3 Syntax. Syntactic heterogeneity denotes the variability of formats and data structures used to exchange informa-
tion between IoT system components (nodes and services). IoT systems rely upon the representations most frequently
used on the Web: plain text, comma-separated values (CSV), JavaScript Object Notation (JSON), Extensible Markup
Language (XML), or Resource Description Framework (RDF) (different serializations). The RDF formats and schemas
may turn out to be unsuitable for the most constrained devices that generate and process increasing amounts of data.
More lightweight formats with binary representations have been defined, such as Efficient XML Interchange format
(EXI) by the W3C,2 Constrained Binary Object Representation (CBOR) of the IETF,3 or CBOR Linked Data (CBOR-LD)
and Header, Dictionary, Triples (HDT) as RDF binary serializations for linked data. These formats intend to standardize
data exchange, but they do not apply everywhere [80].

3.1.4 Semantics. Semantic heterogeneity relates to data understanding. IoT systems communicate data between their
nodes to achieve data-centric services. When two entities exchange data, their meaning is not necessarily understood
the right way by the receiver. The message integrity is threatened, leading to unreliably processed outputs. Metadata
can be used to describe data content and its production context to facilitate the interpretation and use of the data. Still,
node software might use distinct schemas to generate the metadata, increasing interpretation mismatches. One way to
homogenize the knowledge representation in a field of study are ontologies. An ontology is defined, according to [96],
as “a formal, explicit specification of a shared conceptualisation.” This definition underlines that ontologies provide
machine-readable (explicit) abstractions of real-world phenomenon concepts, their relationships and constraints.
IoT ontologies such as Semantic Sensor Network (SSN) [45] / Sensor, Observation, Sample, and Actuator (SOSA) [52],
Thing Description (TD) [17] or Smart Applications REFerence (SAREF) [23] have been defined to create a common data
interpretation ground for IoT systems. They cover various aspects (e.g., objects, context, communications) to different
extents. These ontologies, originating from different organizations, may overlap and do not necessarily share the same
structure or terminology. Moreover, the granularity level of an ontology varies from generic cross-domain descriptions
to domain-specific ontologies (energy, agriculture, etc.). Alignments are not systematically made explicit.
2World Wide Web Consortium, https://www.w3.org/
3 InternetEngineering Task Force, https://www.ietf.org/
Manuscript submitted to ACM
A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 7

3.1.5 Interoperability. As an answer to the high fragmentation of the IoT ecosystem, multiple standard development
organizations (SDOs) and initiatives deliver tools, models and guidelines to improve interoperability. Interoperability
denotes the ability of different systems to work together [104], and has been very quickly identified as a challenging
topic for the IoT field development [5]. The ISO/IEC 19118 standard [51] defines interoperability as “the capability to
communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have
little or no knowledge of the unique characteristics of those units.” This definition showcases the utmost importance of
ensuring seamless user access with low effort while considering scalability issues. Reaching global interoperability in
the context of IoT enables earning reliability and lowering the time it takes to access (connectivity and communication),
read (syntax and schemes), understand and transform data into valuable knowledge (semantics). Many research works
survey interoperability in IoT [1, 11, 80] and propose classifications, frequently correlated with sources of heterogeneity.
Standards such as communication protocols, data formats or standard ontologies have been defined to overcome
heterogeneity. Platforms include a standardization layer at their lowest level, where several devices with variable
communication and access protocols can connect to a unique interface. At the application layer, application programming
interfaces (APIs) and cloud services interfaces offer data storage and analysis services to enhance collaboration with
other platforms and systems. Although platforms play the interoperability game by developing access interfaces such
as APIs/software development kit (SDK) or gateways, the diversity of these interfaces complicates the cross-platform
and cross-domain application definition task. Several projects have been or are being developed to offer a reference
solution for IoT interoperability: IETF SenML [97], OGC SensorThings API [67], and W3C Web of Things (WoT) [43].

3.2 System Architectures

Software architecture refers to the overall design and structure of a software system, including its components,
their properties and the rules shaping their connections and interactions [8]. A system’s architecture substantially
constrains its non-functional requirements [15, 20]. IoT systems often have a complex and heterogeneous architecture,
interconnecting multiple hardware and software components at varying abstraction levels.
Standard ISO/IEC 25010:2011 [50] defines a taxonomy for software quality dimensions, such as efficiency, reliability
and maintainability. Across the literature [44, 77, 88], some qualities are frequently associated with the evaluation of
ubiquitous systems, a class of systems that greatly overlaps with IoT systems: availability (the system remains accessible
to users), scalability (the system can be extended to more components), reliability (the system is fault-tolerant) and
performance efficiency (the system is functional with minimal resource usage).
In an IoT system architecture, it is important to distinguish between thing components, capable of sensing and
actuating in the physical world, and pure software components, only interacting physically via communication protocols
(on the Internet or on restricted ZigBEE, BLE or LoRaWAN networks). Things tend to have low availability and low
reliability and to offer no scalability (taken in isolation) and limited computing resources. In contrast, cloud-based IoT
platforms are generally considered to offer a high quality of service (combining availability and reliability constraints),
to scale on demand and to have virtually infinite resources. The quality of an IoT system combining things with a
third-party software platform thus depends on the quality of the interactions between the things and the platform.
From a programming point of view, it is also worth distinguishing between software components that are pro-
grammable and those that are not. We will refer to the former as application-runtime components and to the latter
as middleware components. In some cases, the application runtime is embedded in things themselves. Depending on
the level of abstraction chosen to describe the system’s architecture, a thing can be seen either as the combination
Manuscript submitted to ACM
8 Hannou et al.

Thing
Thing
Runtime
Thing Thing Thing
Thing Thing Thing Thing
Runtime Thing Thing
Thing
Runtime
Runtime
Middleware

Thing

(a) Kernel style (b) Blackboard style (c) Orchestrator style (d) Peer-to-peer style

Fig. 3. Common architectural styles for IoT platforms (⊏⊐: component, □: connector, →: connection)

of a sensing/actuation component and a runtime component, deployed on the same platform, or as a single compo-
nent, whose interface to other components is at the physical layer. In the following, we consider the highest level of
abstraction—with the least number of components–and only consider physical-layer connectors between components.
A thing hosting an application runtime will therefore be considered as a single component.
Given the three types of architectural components of IoT systems (things, runtimes and middleware components),
the following criteria are relevant for a comparison of IoT platforms.
• Number of components (of each type). Every IoT system architecture has at least 1 thing component but it may
have 0 runtime and/or 0 middleware component. There may be 𝑛 things, runtimes or middleware components.
• Number of distinct connectors per component. Each component has 1 or more interfaces to other components.
Each interface is implemented by one connector (e.g., a library, linked statically or dynamically as an add-on to
the component’s main program). If connectors can be added dynamically to a component, it is assumed that a
finite number of connectors can be added to the component. Some IoT platforms are used jointly with a software
artifact repository from which add-ons may be downloaded (similar to Maven Central for Java or PyPI for Python,
and to Linux package repositories). In this case, the number of connectors provided by the platform component
equals the number of (communication-related) artifacts in the repository.
• Number of connections. Two interacting components must have compatible connectors to communicate (e.g., both
components embed an MQTT client or an HTTP library). If the connectors of two components are compatible, a
connection exists (at the architectural level) between the two components. For simplicity, broadcast and multicast
communication is modeled as a set of one-to-one connections between components.
• Type of connections. A connection may be unidirectional or bidirectional. It is unidirectional if only one of the
components can initiate communication (regardless of the number of subsequent messages being exchanged
between the two components): an HTTP connection is directed from the client towards the server; an MQTT
connection is directed from the client (taking either the role of a publisher or a subscriber) towards the hub.
Certain combinations of values for these 4 criteria can be factorized into architectural styles, as per usual terminol-
ogy [99, p. 72]. Figure 3 shows some of the main architectural styles in use in the IoT literature: the kernel, blackboard,
orchestrator and peer-to-peer styles. In the kernel style, the platform is a single runtime able to interact with a het-
erogeneous set of things via multiple connectors. It is analogous to an operating system kernel that exposes a high
number of system calls and can handle a high number of I/O signals. A kernel platform is not naturally scalable,
but it tends to provide good performance and a fair level of reliability. A blackboard platform has a small number of
connectors (usually 1 or 2, to read and write content) such that any thing with the suitable interface can write data
(or read commands) and any application runtime can read data (and write commands). The blackboard is a passive
Manuscript submitted to ACM
A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 9

middleware that can compensate low availability of things, but that may not match the performance of a kernel for
asynchronous communication. To overcome this problem, the application runtime may be hosted on the same platform
as the blackboard. One then obtains the orchestrator style (one runtime, few connectors). An orchestrator has qualities
similar to those of a kernel. Finally, in the peer-to-peer style, there is no dedicated runtime and no middleware. Things
drive the application in a fully decentralized manner, all things having a connection to all other things. The reliability
of a peer-to-peer system is low in general, but its scalability may be high.
Architectural styles impact the quality attributes of the final application [77]. Complex systems often use more than
one architectural style [36] and their combination provides trade-offs between targeted quality attributes. Authors in
[44] proposed an assessment framework for Edge Computing, but no such work applied to IoT systems exist.

3.3 Cost and Licenses

A product license is a legal agreement detailing the terms and conditions governing the use of the product and its
possible modification or distribution. It specifies in which context the product can be used and the underlying fees
potentially charged. Software product licenses fall under five categories, with broad variations in the detailed terms.

• Open Source Licenses: The product code source is open, free for use, modification and distribution.
• Proprietary Licenses: The product is provided to users under precise access conditions, often involving fees.
Extending the product features is impossible since the code source is unavailable for modification or distribution.
• Free Licenses: This license is similar to an open-source license, where the user can access the platform for free.
However, the modification of the software code source and its distribution is reserved to its owner.
• Freemium Licenses: They rely on a cost model where a basic version of the product is available for free, while
the full version, including more advanced services and features, is only provided by subscribing to a paying offer.
• Commercial Licences: Here, the use or modification of the product requires paying fees.

Licensing is an important factor when selecting an appropriate product; users should carefully review the terms
and constraints, mainly for financial reasons, but also to check the legal compliance with their intended use. Some
solutions, although adapted to the requirements in terms of features, require an unaffordable budget, which blocks use.
Consequently, licensing also has a significant role in adopting IoT technologies for organizations that cannot afford
proprietary solutions [12]. Furthermore, some cost models restrict access to the product to a predefined number of
devices/users/scenarios, preventing the scalability of the developed applications.

4 PROGRAMMING THE IOT

Creating applications for the IoT is of significant complexity, even for experienced domain developers. This is mainly due
to considerable hardware and software heterogeneities, requiring advanced knowledge to achieve interoperability. As
discussed in Section 3.1, device heterogeneity, due to hardware specification, communications, or resource limitations,
makes programming IoT systems borrow a mix of different computational patterns with different styles and programming
languages with varying technical abstractions. In layered architecture deployments (cloud, fog, or edge), several
programming tools are used to increase technology coverage, widening the range of skills programmers must have.
An IoT-compatible program, either written using a GPL or a DSL, and depending on the role of the node running
the program, should present some features for reliability and ease of use [6]: (1) lightweight footprint and efficient
resource use; (2) fault tolerance to support connectivity and access instability; (3) interoperability support through
libraries and APIs covering various devices; (4) scalability, managing access to masses of services, devices, and data
Manuscript submitted to ACM
10 Hannou et al.

(load-balancing) [108]; (5) concurrent access and coordination between computations performed in distributed parallel
systems; (6) availability of language tools and community via development environments, plugins, specific IoT libraries
(e.g., General Purpose Input/Output - GPIO -, communication protocols).
Choosing a programming language requires defining the expected outcomes of the application, affordable cost,
and time effort. The set of skills necessary for a programmer (end user of the language) to create a full end-to-end
IoT system application is getting larger and larger, including knowledge of embedded devices, cloud systems, mobile
and web development [98]. Developers use different levels of IoT software stacks depending on the aforementioned
considerations but also their expected capabilities to fit the specificities of different deployments.
To make the potential of IoT accessible to end users regardless of their technical proficiency, a wide range of
technologies and domain platforms have been defined to enable both developers and end users design smart applications,
breaking down the complexity and providing abstractions for low-level specifications. The IoT landscape offers hundreds
of such platforms, and a selection methodology has been followed to present those relevant to this paper audience.

4.1 Methodology
This survey follows a purposeful selection approach in identifying Internet of Things (IoT) platforms. The following
selection criteria were adopted to ensure a holistic representation of available technologies.

• C1: Open Source Platforms. Preference is given to open-source platforms for the benefits they guarantee for
seamless access, collaboration and community extent. This aligns with the purpose of offering end-user/developer
affordable and easy testing. This criterion has been relaxed for domain-specific platforms, considering the
predominance of commercial solutions and the high adaptability that might offer to these domain use cases.
• C2: Domain-Specific Language (DSL) Support. Platforms that offer a DSL designed for IoT applications are
prioritized. The use of a DSL can simplify complex tasks, improve productivity, and enrich the community with
additional programming resources.
• C3: Various Programming Approaches. The survey aims to present platforms adhering to different programming
approaches. Some criteria might be relaxed to favour platforms that accommodate multiple paradigms.
• C4: Richness of the toolbox. Platforms offering different programming channels adapt better to larger user-profile
communities. Modelling or mashup platforms might offer scripting APIs for GPL-based programming or leverage
VPL to support non-technical end-users.
• C5: Interoperability. Platforms that enable interoperability are chosen to ensure the potential for seamless
integration with different IoT devices, protocols, and systems. Given the heterogeneous nature of IoT ecosystems,
higher interoperability support enlarges platform applicability and impact.
• C6: Established User-Base. Preference is given to platforms with a solid user-base over those in the early
development phase. Community supports users to master the platform and adapt its features to their use cases.

Following these criteria, the search process has been manually conducted across multiple platforms and databases.
Since many IoT programming platforms are industrial solutions developed outside academia, only part of them have
associated published research papers. To ensure a comprehensive coverage, a first step has been to establish a list of
platforms that falls into our scope and conforms to selection criteria, by looking at:

• Scientific databases and search engines: Google Scholar, Scopus, ACM digital library, IEEE Xplore Digital Library.
• IoT blogs and industrial platforms websites.

Manuscript submitted to ACM

A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 11

Afterwards, priority was given to platforms compliant with the selection criteria above. A selection of open-source
platforms has been made to enable presenting platforms covering various programming paradigms, and with rich
toolboxes. For commercial platforms, preference is given to solutions with specific domain features descriptions, which
is compliant with the purpose to offer small organizations and less-technical users with tracks on non-complex solutions
they can afford. While this approach does not provide an exhaustive overview of all the available platforms, it aims to
present a representative sample of the most relevant solutions relying on various programming approaches.
We analyze each selected platform in terms of the following programming characteristics: (1) the type of exposed DSL
language (refer to Appendix B in the Supplementary material); (2) whether the platform provides a visual programming
interface; (3) if the user interface is textual or graphical; (4) if the programming approach is model-driven programming,
mashups, or end-user programming (see Section B.3 in the Supplementary material); (5) the types of tools that support
developers’ activities; and (6) the programming languages developers can access to develop applications, extend
platforms functionalities and set interoperability options. We also analyze the platforms in terms of the characteristics
identified and defined in Section 3. We identify if an extension point is defined and documented for supporting more
devices, protocols, exchange formats, or data models. We identify the system and components interaction paradigm
(see Section 3.2). We also take note of the license of the platform (see Section 3.3), and distinguish between generic,
domain-oriented, and task-oriented platforms. Table 1 provides a summary of these IoT platforms characteristics.

4.2 General-Purpose Languages

When dealing with a small limited number of devices, IoT systems programming does not much differ from traditional
web or mobile development. Interoperability and distribution concerns are less critical, and common general-purpose
languages are convenient to use, assuming device resources can afford the requirements of the output programs.
To this extent, one tends to take as the main criteria the device’s capabilities and computational power, which
explains why assembly language makes a strong comeback among the top ten languages, according to the TIOBE index
for the most used programming languages.4 By using assembly or C, developers trade productivity in code writing for
performance and adequacy to a broader device range.
On larger dimensions, building an IoT system requires dealing with a system of systems [35], where handling
low-level programming drawbacks is no longer reasonable. Many cloud-based solutions (Section 3.1) (Platform as
a Service and Software As A Service) provide a “golden middle” solution, abstracting devices interoperability while
offering web-enabled programming environments through high-level programming languages SDKs (such as Java,
python). Still, these solutions are tied to a subset of devices and low-end technologies.
Every year, the Eclipse IoT working group produces an IoT developer survey [28], tracking the most used technologies
by IoT developers. Top programming languages are orderedby cloud, fog, and constrained devices tiers. The IoT-
programming languages’ ranking (last updated June 2022) correlates with the general programming trends, where
python takes for the first time the top position, overpassing Java and C.
In addition to its extensive adoption for machine learning-based programs, the use of MicroPython (embedded python
language) overcomes the lack of resources by providing complete OS and programming features. Constrained-device
programming is evolving with advances to hardware technology, from one-shot configuration (plus multiple flashings)
to dynamic programming capabilities that allow many computations with increasing high-level abstractions [98].

4 Latest TIOBE Index, https://www.tiobe.com/tiobe-index/. Accessed: 2023-07-10.

Manuscript submitted to ACM
12 Hannou et al.

The use of general-purpose languages for IoT is supported by multiple libraries handling specific IoT features (General
Purpose Input/Output - GPIO -, communication protocols, etc.), and IoT plugins extending development environments.
The top three general IDEs following their adoption by the IoT community are [28]: Eclipse desktop, Visual Studio Code,
and IntelliJ. Besides, other vendor-specific and board-specific tools carve a niche: ESPlorer (for ESP8266 programming
with lua and python), Android Studio, Thonny IDE (for micropython programming), Eclipse Orion.

4.3 Model-Driven Tools

The literature pays considerable attention to MDE works for the IoT domain. Malavolta and Muccini [73] and Essaadi
et al. [29] survey generic or domain-specific tools. In the following, we discuss the most significant IoT domain-specific
modeling languages.

4.3.1 ThingML. ThingML [46] is an open-source project offering a DSML, along with a set of tools for cross-platform
code generation through model transformation, plugins for the Eclipse IDE, a standalone text editor, and method-
ological/documentation support. A first version of the platform has been released in 2012. The cross-platform code
generation framework is designed for use in distributed systems with heterogeneous nodes with support for C, C++,
Java, JavaScript and Arduino. ThingML generated code can be run on devices with varying capabilities and operating
systems: windows/linux servers, Rasberry Pi, ESP32... It is intended for a hub-based system but can be considered for
cloud use in a client-server architecture. Unlike many DSMLs, the ThingML language has a textual descriptive syntax
allowing users to model: (1) Things, for the structure of the system components with asynchronous message interfaces;
(2) State machines, with UML state-charts-like configuration files describing the components (things) behaviors and
their interactions. Things communicate in an asynchronous fashion ; (3) Events, with an imperative action language
(platform-independent) for event processing in an (Event-Condition-Action) fashion.
A multi-platform code-generation framework enables model transformation into target languages such as Java,
JavaScript, C, Arduino. The generated implementation contains the executable code and configuration files for different
target devices. It offers wide support for devices and communication protocols, and allows for the definition of custom
data types and structures that can be used to represent data in a variety of formats (XML, JSON,...). In addition, ThingML
provides a rich toolbox, including APIs (Java API, Rest API) along with Eclipse IDE SDK allowing developers to interact
with the generated model-based generation code. While the ThingML DSL is purely textual, the Eclipse SDK provides a
corresponding graphical modeling tool and a runtime environment for ThingML-generated code.
The ThingML is built using the Eclipse Modeling framework, which allows flexibility in extending the system as
in [78], where the authors present an extension of the language to support things with data analytics features. To
support different IoT domains, ThingML can be considered as a generic tool, since it provides a set of built-in features
and constructs that can be used to define the behavior of IoT components, regardless of the specific domain they are
being used in. The tool is not restricted to fixed hardware or network specifications.
ThingML has been validated in multiple use cases with different platforms, but remains a fairly technical DSML
intended for users with technical background and IoT architecture knowledge to fully make profit of the code generator.

4.3.2 Midgar. Midgar [38, 39] is an IoT platform offering several services, including a DSL and a graphical editor to
interconnect web services and create applications for heterogeneous devices. Midgar aims to support interoperability
by interconnecting objects through a Midgar server with REST services without getting to manage the technical
sophistication specific to each object. The platform consists of 4 layers: Process definition, service generation, data
processing, and object management. Only the process layer is intended for user interaction. The latter defines connection
Manuscript submitted to ACM
A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 13

processes on objects via MOISL, the DSL developed with the HTML5 canvas and JavaScript generating serialized XML
models. Service generation achieves model transformation into the target application language. The platform offers code
generation into Java for desktop or mobile application and C for arduino/android devices. Things or objects implement
the messaging interfaces with the Midgar server (REST service).
The platform evolved by offering several model-based programming languages. The primary contribution includes
Midgar Object Interconnection Specific Language (MOISL), a language with graphical notations enabling the definition
of heterogeneous and ubiquitous object interconnections. It allows the user to describe how each object behaves with its
network and the Midgar server and considers security aspects. A textual DSL with the same purpose has been defined
later, as Midgar Use Case Specification Language (MUCSL) [40], which provides development support of automation
routines expression using a natural language (English-like) syntax. This layer does not support the automatic generation
of IoT applications and requires the explicit definition of the logic of the objects by the users. In recent work [39], the
same authors define Midgar Object Case Specification Language (MOCSL) with a graphical interface to facilitate the
creation of smart objects and the generation of data-processing applications by users with a little technical background.
A drag and drop interface allow to define communications between different connected objects.

Example 4.1. Consider the use case defined in Section 2. Three objects can be connected to the Midgar platform:
• a temperature sensor, registered under the ID tempSensorXXXX01 (numerical values);
• a carbon dioxide sensor, registered with the ID carbonDioxideYYYY01 (numerical values);
• an actuator for automatic window openning, with the ID windowAutoZZZZ01 (0 for close and 1 for open).
The application logic can be defined using the graphical notation of the platform or the textual DSL (MUCSL), where a
conjunction of conditions can be expressed and verified (here, temperature above 25 degrees and CO2 levels above 350 ppm)
to trigger an action on the connected device (window actuator).

When [ the ] tempSensorXXXX01 [ is ] greater than 25

or [ the ] carbonDioxideYYYY01 [ is ] greater than 350
then [ the ] windowAutoZZZZ01 [ to ] 1
Listing 1. Example of MUCSL rule definition

4.3.3 FRASAD. FRAmework for Sensor Application Development [79] is a development framework allowing users
to create IoT applications by defining a multi-layered node-centric model. It focuses on in-board sensor computation
providing a simple alternative to program sensor events reading, alerts and actions. Communication within a sensor
network is handled through two communication protocol support: unicast and broadcast protocols. FRASAD enables
developing applications while hiding hardware technical specifications related to the nodes. This abstraction is possible
thanks to the definition of two layers: the application abstraction layer (APL) and the operating-system abstraction
layer (OAL). Accordingly, the platform uses model-driven architecture principles at three distinct layers, supported by a
DSL definition. At the application layer, the visual model operates on rule-based programming patterns to describe the
sensor nodes and their local behaviours independently from their technical specifications. The model is stored as an
XML file. A code generation tool automatically transforms the user-defined models to generate platform-independent
applications at the OAL. The latter is then mapped and compiled by OS-specific C compiler into binary code. The rule
DSL language allows for a three parts rule definition: Select-Clause, Processing Clause and ActionClause. As code
generation is a two-step process, device-specific code might deviate from the user-defined model. This gap can be
explained by the pipeline of mappings applied to get a platform-specific code. Additionally, the platform focuses on a
Manuscript submitted to ACM
14 Hannou et al.

fixed number of devices and operating systems (Contiki OS, TinyOS) and protocols, limiting the applicability. To the
best of our knowledge, the platform development has not been perused, and no code repository has been maintained.

4.3.4 WoX. Web of Topics (WoX) [13, 70, 71] is a multi-layer IoT platform first introduced in 2015, that aims at
simplifying the design of user-centric applications by adopting a model-driven approach. It extends the Web of Things
(WoT) by focusing on the functional aspects of the system and this despite the object’s hardware complexities and their
diverse communication protocols. To overcome the technical complexity of the WoT, WoX introduces an abstraction
layer hiding heterogeneous technical details of things in a conceptual model. The WoX model is built around the
“topic” concept: a topic describes the feature values (perceivable, measurable characteristics) of entities of interest.
It is a representation of a physical or virtual sensor/actuator. The topic is identified by a URI designating it and its
location. An IoT entity is defined by the couple (topic, role), given that a role expresses the entity’s technological
and collaborative status. Unlike many IoT tools addressing the development within a single IoT architecture layer,
WoX defines three variants, one for each layer: WoX cloud, WoX local (L-WoX) for mobile use, and eMbedded WoX
(M-WOX), for constrained objects embedded. Corresponding adapted APIs are presented: Java/Python/.NET APIs,
Android/iOS or C/C++ for constrained objects. To homogenize modelling, WoX middleware (Hardware Abstraction
Layer) exhibits an exchange format based on the publish-subscribe model and provides a set of adapters for physical
and virtual communication protocols. Besides, the tool is structured to manage the flow of events issued by physical or
virtual environments through adapters connected to a REST service to several web technologies and a Linked Open
Data (LOD) API for the semantic transformation of topics into a semantic data model.
The platform has been demonstrated via prototypes such as the airport short-stay parking service or City4Age,
an application for the e-monitoring of elderly people’s behaviors [34]. In a recent work [72], WoX authors introduce
WoX+, extending the original model by integrating machine learning for automatic automation rules discovery. Rules
are created by mining users’ habits in smart environments.

4.3.5 UML-Based Tools. Other works adapt the use of the UML language to build visual interfaces enabling users
to express the structure and behavior of IoT systems. Eterovic et al. [30] propose a visual programming modeling
language based on UML. The base elements of the model refer to “things” (sensors/actuators, physical or virtual), and
their communication interfaces describe data flows. The things compose hierarchical subsystems with input/output
notations. Even if the language is designed for non-technical users, the authors propose an extension using advanced
UML notations for developers to achieve more complex tasks. UML4iot [100] borrows some UML constructs to create
customized profiles that address IoT systems’ challenges, namely heterogeneity and distribution. The profile is used
within a wrapper to define an IoT-compliant layer, providing cyber-physical manufacturing-system components with
capabilities to integrate IoT architectures and thus take advantage of IoT protocols (LWM2M).

4.4 Mashup Tools

In the IoT era, the need to compose services and expose them in a uniform user-centric fashion has arisen, and the
mashup principle has gained extensive attention. New challenges appeared regarding mashups’ use for the IoT, given
the heterogeneity of devices and resources to integrate. The Web of Things (discussed in Section 3.1) tackles these
challenges by allowing users to create applications based on a uniform semantic data model for heterogeneous sources
(things) integration and combine the use of web services and standard technologies (connecting functional islands).
Such a platform is possible thanks to the availability of communication protocols and REST APIs. Mashup tools are
helpful to speed-up application prototyping and are suitable for non-technical users or domain experts to quickly
Manuscript submitted to ACM
A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 15

create and deploy new IoT applications. They often leverage visual interfaces to encode rule-based and flow-based
programming patterns, describing message flows between components as resources producing data or web services.
Some examples of widespread IoT mashup tools are discussed in the following.

4.4.1 Node-RED. Node-RED5 is a mashup tool created by IBM for IoT applications’ development with the aim to wire
together IoT components. In 2016, Node-RED was transformed into an open-source JS Foundation project. The tool
offers a browser-based drag-and-drop graphical UI for building and editing event flows through nodes, reducing the
size of code writing for users. A Node.js runtime supports the application deployment of node-centric event-driven
programs, taking advantage of the built-in event model and native support for JavaScript. A node characterizes a
hardware device, a software API, or a service. The network of nodes is managed by a node package manager (npm)
with an extensible set of components, where each behavior is described in JavaScript and its structure in HTML.
The extensible palette of nodes includes function nodes (trigger, execute), network nodes (MQTT, HTTP, etc.), parser
nodes (for CSV, XML, HTML, and so on), etc. The interaction between nodes is constructed through links, capturing
events transformation, and each process is a black box, autonomously and asynchronously transforming data from
the input nodes to some output result for the target node. The created flows can be stored for reuse in JSON format.
When a user deploys a Node-RED flow, the runtime generates and executes the underlying JavaScript code based on
the connections and configurations explicited in the visual flowchart.
Node-RED is platform-agnostic tool written in JavaScript; it can be deployed on small devices due to the lightweight
nature of Node.js, supporting edge-computing scenarios as well as cloud devices, which guarantees a full-IoT system-
development process. Another advantage of Node-RED is the possibility to integrate different technology libraries
(databases, MQTT communication protocol, etc.), strengthening interoperability and extensibility. When a user deploys
a Node-RED flow, the runtime generates and executes the underlying JavaScript code based on the connections and
configurations made in the visual flowchart. One drawback of the open possibilities in flow definition (unique or
multiple flows with different node settings) is the difficulty of fault detection and system behavior fixing.
Many works extend Node-RED with additional features such as voice command interface [85] or adapt it to specific
uses cases [106]. Glue.things [61] is built on top of Node-RED, providing user-friendly predefined trigger and action
nodes. In glue.things, a flow editor is associated with a master device that controls all the nodes in a local network. The
master device can be deployed on the cloud allowing service compositing at this level. Node-RED is built to run on a
single device. Distributed Node-RED [9, 41] proposes a distributed version to run in fog-based architectures.
Ji et al. [53] propose an extension of Node-RED with a module running as a WoT servient. It combines REST APIs
and IoT devices as web things. The Thingweb node-wot6 is used as a runtime environment on the Scripting API. A top
layer implementing WoT Thing Description (TD) allows Web things (sensors/actuators) to interoperate, exposing their
properties, actions, and events. Sensing data are streamed in a chat channel, and activated triggers are reported to users
as WoT events. Authors claim that Node-RED enriched with specific WoT semantic description and servient-behavior
integration represent a good candidate for a standard WoT implementation.

Example 4.2. Node-RED can be used for both automation scenarios in building and agriculture, presented in Section 2.
To showcase an automation program for smart irrigation, we assume a minimalist hardware setting with a moisture sensor
and a water valve, both connected to an Arduino microcontroller. An Arduino-node can be installed into the palette manager
as follows:
5 Node-RED, https://nodered.org/. Accessed: 2024-06-27.
6 Thingweb node-wot, https://github.com/eclipse/thingweb.node-wot. Accessed: 2024-06-27.
Manuscript submitted to ACM
16 Hannou et al.

npm install node - red - node - arduino

Listing 2. The installation command for NPM arduino node

This node enables communication with the Arduino through the serial-in node for data reading and the serial-out node for
command sending. Moisture data received is processed (through function nodes) to check whether the moisture level is below
crop-watering recommendations. An Arduino-node can be installed into the palette manager to enable communication with
the Arduino through the serial-in node, for data reading, and the serial-out node, for command sending. Moisture data
received is processed (through function nodes) to check whether the moisture level is below crop-watering recommendations.
The flow can also integrate available web services for weather data, such as the OpenWeather API, accessible via HTTP
requests. To this aim, an inject node allows triggering API requests at a certain defined frequency, while the HTTP node is
set to GET weather data. A function node filters data (JSON) for rainfall forecasts. The data obtained from the API can be
combined with moisture-sensor data to prevent valve actuation if rainfall is expected.

4.4.2 Dynamic Dashboard. Vanden Hautte et al. [102] provide a dash-boarding tool enabling the visualization of
RESTful web things (sensors) and available data-aggregations services, abstracting sensor settings. The tool uses
semantic reasoning on things metadata to suggest a suitable visual interface composed of single-service widgets. The
dashboard interface is dynamically customized given the events picked by the user. The dynamic dashboard provides
real-time data and is supported by three core services: (1) It subscribes to a data streamer (Kafka Stream) to enable
access to data and apply filters to get relevant event-related values. The output is then transmitted to widgets for
visualization. (2) It interacts with a broker, which stores and provides the user interface state. It hosts the semantic
reasoner in charge of suggesting appropriate widgets given things semantic metadata. (3) WoT compliant gateway API
discovers things, and the semantic annotations explain things capabilities.

4.4.3 WoTKit. is a web-centric lightweight Java platform for managing IoT things and their real-time events. Things
can be grouped into systems (and subsystems), identified as modules that communicate through wires in a flow-based
fashion. The combination of modules and wires creates pipes inspired by Yahoo! Pipes [33]. WoTKit web application
has both visual and textual user interfaces. The main visual user interface is a JavaScript dashboard combining widgets
that enable pipe creation, start, stop and editing features, as well as navigating through different user pipes. Besides,
users can extend the built-in features by defining new modules’ scripts in Python to integrate into pipes. A central
sensor gallery allows reusing created sensors or discovering other public users’ shared sensors added to the system.
The gallery also stores meta-data describing the sensors, their location, and data output. WoTKit serves as a sensor-data
aggregator for processing, with the generation of control messages to actuators and visualization features. Additional
sensors can be registered to the platform through gateways definition. New sensor information are posted through the
REST API by providing a description file in supported formats (JSON, CSV, KML, HTML). An advantage of the WoTKit
architecture is the separation between wires and modules; modules can have many input wires enriching program
patterns. The processor can handle many flows for a single user.

4.4.4 A-Mage. A-Mage, an Atomic Mashup Generator [63], is a tool enabling Atomic mashup generation based on
Thing Descriptions files and a possible set of constraints and filtering conditions expressed by an end-user. All candidate
atomic mashups are automatically generated, enabling user evaluation through a sequence diagram. The user picks the
best fit atomic mashup (or adjusts constraints to get a new one), achieving the desired system behavior, and generates
an executable code based on the WoT Scripting API. The end user constraints are expressed in natural language and
Manuscript submitted to ACM
A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 17

then processed and used to generate semantic filters restricting the number of things involved in the WoT system, their
types, contexts, TD annotation, or annotation availability. The tool has been tested against agriculture, industrial and
smart home scenarios, with reasonable generation time and good response to user’s constraints.

4.5 End-User Development Tools

The following sections overview some examples of widespread EUP platforms. Detailed comparative studies of IoT
end-user development tools are reported in [66, 81, 92].

4.5.1 Trigger-Action Based Approaches. This programming approach uses event-condition-action (ECA) rules [19],
with visual user interfaces. The user specifies an expected system behavior through if-then statements, to automate
actions following some trigger occurrence.

IFTTT. IF This Then That7 is a widely-used IoT platform launched in 2011, and represents the most frequently used
tool of event-action programming [76, 101]. IFTTT presents a web-based interface (and a mobile app), enabling users
to define programs through automation scripts called applets or recipes that connect services, websites, and physical
devices. Each applet encodes the automation logic, i.e., a trigger-action rule “on trigger do action”, such as turning off
the light when someone leaves the room or sharing stats data on Twitter following a smartwatch notification. A trigger
is an event produced by a connected service (ingredients data) as the sensing data output, while actions can be executed
by physical devices or web applications.
IFTTT enjoys a large community thanks to its user-friendly interface and support for trending use cases such as home
automation [76]. This led to many research works and products extending the platform with support for voice assistant
commands [65], home automation extension [103], or secure authentication mechanisms [7]. The platform owes its
popularity to the simple means for creating automation rules, which in contrast makes for a significant expressiveness
limitation. Tasks only include rules with a single action per trigger, preventing the composition of rules and, therefore,
the expression of complex scenarios. IFTTT also provides a tool called “Platform API” that allows developers to create
more complex integrations. The GraphQL API allows developers to query and mutate data in the IFTTT ecosystem. The
platform supports a wide range of device integrations but do not allow the use of virtual devices. A recent development
of IFTTT supports the composition of actions through a “Maker” platform enabling developers to add multiple triggered
actions. Similar platforms such as Zapier, Microsoft Power Automate, or recently Mozart [64] address this issue by
enabling broader rule automation patterns.

Example 4.3. A popular use scenario of IFTTT is home automation. Consider the air-quality monitoring scenario defined
in Section 2. A minimalist hardware setting includes an ESP32 microcontroller hosting a CO2 sensor and a window actuator.
An IFTTT applet defines a trigger on any available MQTT service that can get data from the microcontroller. A filter code
option enables defining custom data transformation to check whether the CO2 level is above normal. A window-opening
command through the MQTT service constitutes the action statement. To combine a trigger recorded by a web service, such
as temperature via a weather API, a query statement must be defined (only avalable for IFTTT Pro users).

Zapier. Zapier8 is a web-based workflow automation platform primarily interested in business project management.
The zaps (equivalent to recipes) allow more composition rules than IFTTT [84] since one trigger can lead to a sequence
7 IFTTT: Every thing works better together, https://ifttt.com/. Accessed: 2022-07-13.
8 Zapier, https://zapier.com/. Accessed: 2023-07-10.
Manuscript submitted to ACM
18 Hannou et al.

of actions. The subsequent tasks are more expressive since they include filtering and data transformation on trigger data.
Zapier also provides developers with support for customized service integration.Zapier exposes a REST API enabling
developers to create zaps custom templates.

Microsoft Power Automate. Previously called, Microsoft Flow,9 provides advanced conditions and looping constructs for
more expressivity. It is a workflow-management platform with web and mobile tools, offering an interface for connecting
two or more cloud services to create business workflows, such as automating file synchronization, alerting, and data
organization. It is oriented towards supporting Microsoft business tools integration for business task-automation
scenarios.

4.5.2 Programming by Demonstration.

Epidosite. Enabling Programming of IoT Devices On Smartphone Interfaces for The End-users (Epidosite) [66] is a
mobile platform for home automation leveraging a programming-by-demonstration style. A user performs operations
on a real use case example to define expected system behavior. Epidosite reasons about the underlying logic to infer a
generalization program pattern that can be applied to new scenarios and features later. The programming is performed
through mobile, using the Android accessibility API to record user behavior when using IoT applications. The recorded
scenario is then used to generate a script for further use automatically. So, the created automation tasks are sequential
action-triggered rules and do not handle composition.

Improv. This system [18] exploits the programming-by-example approach, enabling users to compose software
operating across different devices to define a common interoperable system-interaction behavior. The user mimics
the interaction desired for the set of devices, and the tool transforms these parameters to extend the input-device
application by connecting it to additional devices.

4.5.3 Visual Mobile Applications.

Puzzle. Puzzle [22] is a desktop/mobile platform enabling the development of IoT applications. It uses the jigsaw
puzzle metaphor, where each system component is perceived as a puzzle piece exhibiting some functionality, and
connections provide necessary data inputs/outputs. The puzzle diagram corresponds to a sequential automation logic,
and Looping on particular triggers or actions is possible. The color code and the shape of the pieces suggest to the
user what puzzles can be connected based on data types and transformation for functionality composition. The tool
allows the integration of multiple hardware things and query web services, but its expressivity of the tool is limited to a
predefined puzzle set.

4.5.4 Tools using Natural Language . In natural language programming, the user expresses the requirements a system
should fulfill or enumerates automation rules using natural language. The constructs can sometimes be constrained
with templates, and UIs are either textual or voice-based. Recently, advances in natural language processing (NLP)
opened up avenues to a less constrained user-interaction mode, especially the transformation of voice assistants output.

AppsGate. AppsGate [21] is a rule-based web platform for home automation using a pseudo-natural language syntax
for user interaction. A dependency graph and timeline depict home devices and associated services, enabling users to
specify control patterns in a syntax editor with simple predefined constructs. Visual notations and color codes assist
9 Microsoft Power Automate, https://powerautomate.microsoft.com/. Accessed: 2023-07-10.
Manuscript submitted to ACM
A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 19

the user in identifying allowed syntax, checking rule completeness extent, and understanding the system’s state. The
rules define how automation actions are associated with the environment state or occurring events. The simplified
syntax does not allow for rule composition or operating changes on the graph devices or the timeline of events.

4.5.5 Voice Assistants. Voice-activated devices are increasingly integrated into various automation fields, thanks
to their growing hardware capabilities and the advances in artificial intelligence. Voice assistants are increasingly
smaller, cheaper, and equipped with broader skills. Leading manufacturers are marketing powerful assistants: Alexa,
Siri, Cortana, Google Assistant. Beyond acting as high-level interfaces for getting weather data, the progress of natural
language processing and the richness of human-interaction logs offer a learning base for programming control behaviors
through IoT systems. Most of the applications of this programming style have been applied to smart home scenarios,
which remains one of the most end-user-centric IoT applications, with a need to simplify access to programming.
Early uses of voice assistants extend visual programming platforms such as Node-RED or IFTTT with voice user
interaction, enabling humans to get natural-language answers. Rajalakshmi and Shahnasser [85] combine the use of
Alexa and Node-RED to offer complex automation-rules definition for home-environment control through the platform
and the use of Alexa to simplify the user awareness of the house state. However, in the cases mentioned above, the
voice-activated device does not operate to trigger or configure rules but is limited to query answering.
Other propositions allow users to trigger predefined rules in IFTTT via voice [58, 60]. The tool expressivity is
limited to the IFTTT applets, and the voice can be used only to activate the rules. A similar prototype has been defined
by [62], which integrates Google Assistant to an Android application using MQTT, Node-RED, IFTTT and Mongoose
OS. The event-action rules are first defined in Node-RED and can be triggered through Google Assistant. TAREME
(Trigger-Action Rule Editing, Monitoring) [74] allows triggering and defining rules through Alexa.
Almond [14] is an open-source platform10 that defines a textual domain-specific language named Thing Talk, for
connecting IoT devices, abstracting their technical specifications and enabling a pseudo-natural language for rules
definition. A knowledge-base Thingpedia includes natural language interfaces and open APIs for IoT devices and
services used for system building. The Almond Virtual Assistant is a Java/JavaScript-based mobile application running
a web service for voice-to-text transformation enabling users to formulate Thing Talk constructs vocally.

5 DOMAIN-DEDICATED IOT PLATFORMS

In this section, we discuss IoT platform providing domain-specific functionnalities: building automation (Subsection 5.1)
and smart agriculture (Subsection 5.2).

5.1 Building Automation

The earliest form of building automation goes back to the 1960s [26] with the use of digital computers to automate
heating and ventilation in large commercial buildings. With the evolution of control systems to handle additional
automation aspects such as lighting, security, or electrical equipment, the concept of Building Automation Systems
(BAS) has emerged. A BAS is a distributed system integrating all building automation services, aiming for energy
optimization and user comfort. The rise of IoT technology has accelerated the development of BAS by enriching the
lower perception layer with new sensors, actuators, and connectivity protocols, enabling the definition of autonomously
triggered routines and opening up the spectrum of use cases. An increasing number of building management system

10 Stanford Almond, https://github.com/stanford-oval/almond-gnome. Accessed: 2023-04-30.

Manuscript submitted to ACM
20 Hannou et al.

deployments integrate IoT devices to create so-called IoT-enabled building management systems. They enable efficient
and remote building monitoring features with cost optimization [10, 16].
IoT platforms in smart buildings support the centralization of management systems and offer multiple features such
as data collection and visualization, data analytics, and third-party systems and web services integration. There exist a
large panel of home automation platforms with varying technical characteristics [37], from device and protocol support
to user interfaces and the application layer. The following discusses platforms dedicated to home automation.

5.1.1 Open-source platforms. We survey the most important open-source solutions below.

OpenHAB. Open Home Automation Bus is an open-source home automation platform designed to integrate a large
panel of home devices and different systems services. The project was launched in 2010 and became an official Eclipse
Foundation project in 2013. OpenHab is a cloud-agnostic platform written in Java that operates on various operating
systems and can be deployed on either classical computers or embedded boards such as Rasberry Pi, Beaglebone Black,
Intel Galileo, or any device running Java Virtual Machine (JVM). Compared to other open-source solutions, it has been
tested on a large number of ARM-based single board computers. The platform is built as a modular software architecture
following the OSGi framework,11 where modules called “bundles” are implemented separately and communicate via a
publish/subscribe architecture.
The physical layer of the OpenHAB system, named Things, manages over 400 bindings (plugins), integrating more
than 3000 entities (things). A “thing” corresponds to a physical device identified and described by a thing-configuration
file detailing its items and channels. The latter represents the thing’s exposed capabilities. An “item” is the virtual
representation of a thing whose state can be modified by the application commands. There exist 14 possible items that
can be linked to a range of channels for event handling. The set of supported things is extensible: device or system
integration can be achieved via binding definition, extending the thing handler Java library.
In addition to physical things, a set of add-on bundles increase the core services with external systems or services.
The cloud connector enables connecting the local OpenHab runtime to a cloud instance to use advanced features,
including secure remote access, push notifications, or access to web services requiring OAuth,12 such as IFTTT or
Google Assistant. Additional system-integration add-ons cover HomeKit, Philips Hue, NEEO, ImperiHome. The platform
also integrates a REST API and enables event monitoring and historical data management through bindings integrating
InfluxDB and Grafana open-source time-series databases and visualization tools.
Different user interfaces are available on both mobile and web for programming automation routines. OpenHAB
defines a rule DSL, based on Xtend, that allows using a simplified textual syntax for rule definition. Since rules follow
an event-condition-action (ECA) programming style, actions are automatically triggered by time or sensor-based
events. DSL-based rules can be edited via a graphical rule editor and are ultimately parsed into actuators’ commands.
Technically trained users can access full configuration and automation routines’ options thanks to the supported
scripting languages: Python, JavaScript, Groovy, and Ruby.
Version 3 of OpenHAB, published in 2020, brings significant changes to the platform. A semantic model enriches
automation rules with semantic actions definition. The model relies on a modular ontology (location, equipment, point,
property) that users can employ for modelling their physical environment. In addition, the user interface is reorganized
with page definitions, including user-defined widgets. Finally, a blockly13 rule engine has been integrated, easing rule

11 Open Service Gateway Initiative, https://www.osgi.org/. Accessed 2023-07-10.

12 Open Authorization, https://oauth.net/2/
13 Google Blockly, https://developers.google.com/blockly. Accessed: 2023-07-10.

Manuscript submitted to ACM

A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 21

definition for non-technical programmers through a fully visual UI. OpenHAB enjoys increasing popularity and has
gathered an active community,14 which supports its adoption along the different versions.
Note that while OpenHAB is open source, it operates under the Eclipse Public License (EPL), which requires users to
attribute its use in commercial products.

Home Assistant. 15 is a home-automation platform developed in Python that enjoys worldwide popularity; it supports
interoperability with a wide range of plugins allowing the integration of various devices and protocols (currently
over 2200). Home Assistant is a free software backed by a strong community, assisting users with multiple topics and
providing extensive documentation. The platform makes privacy and user control a priority; it does not depend on cloud
services to operate. However, cloud-service integration with reinforced authentication is provided to ensure remote
access and support voice assistant interfaces such as Alexa. As for OpenHAB, the core component of the architecture
is an event bus handling event-based components’ interactions. End-users program automation routines with ECA
rules via a graphical dashboard generating YAML files. Developers can create advanced services using Python scripting
integration or REST and WebSocket APIs. The configuration of the dashboard, automation rules, devices and concepts
is mainly achieved through YAML configuration files, which may turn out to be heavy for beginners.

Jeedom. 16 is a home-automation platform developed in 2014, written in PHP and operating on various Linux distri-
butions. The platform is standalone, providing a user-friendly and flexible interface thanks to numerous customization
options via widgets. The platform supports several devices integration, protocols and services via official plugins or
third-party plugins. The Jeedom market counts around 600 plugins, but some are not free. The definition of new plugins
is possible in PHP, based on provided templates and JSON configuration files. In addition to the visual dashboard,
automation rules can be expressed via scripted plugins written on Python, PHP, Shell or Ruby. The documentation of
the platform is provided in different languages. One drawback hindering the expansion of the platform is its focus on
French users, since the community forums are mainly written in French.

IOBrocker. 17 is a node.js-based home-automation platform freely available and running on multiple operating
systems. The platform has a modular architecture and currently provides 450 adapters implementing devices, protocols
and services integration. IOBroker Pro is a paying cloud service proposed by the platform to support remote access or
interfacing voice assistant services such as Alexa or Google Home. Developers can create custom JavaScript code for
home automation using VSCode18 or Webstorm19 IDEs.

DomoticZ. 20 is a lightweight home-automation system first released in 2012, written in C++. It runs on different
operating systems and is adapted to low-resource devices. All things connected to the platform interact through MQTT.
The ECA rules can be defined using Blockly or through scripts. Supported languages are Lua, Python, shell and a
DomoticZ DSL called DzVents. DomoticZ has an E-vehicle framework enabling the integration of electrical vehicle
systems from, e.g., Tesla, Mercedes or KIA to read sensor data and automate in-car temperature or door locks.

5.1.2 Proprietary solutions.

14 OpenHAB community, https://community.openhab.org/. Accessed: 2023-04-18.
15 Home Assistant, https://www.home-assistant.io/. Accessed: 2023-04-24.
16 Jeedom, https://www.jeedom.com/. Accessed: 2023-04-18.
17 IOBrocker, https://www.iobroker.net/. Accessed: 2023-04-24.
18 Visual Studio Code, https://code.visualstudio.com/. Accessed: 2023-07-10.
19WebStorm, https://www.jetbrains.com/fr-fr/webstorm/. Accessed: 2023-07-10.
20 DomoticZ, https://www.domoticz.com/. Accessed: 2023-04-24

Manuscript submitted to ACM

22 Hannou et al.

Hubitat Home Hub. 21 is an automation system introduced by the Hubitat Elevation company in 2018. It is designed
with a strong focus on data privacy and security by promoting user control of data and devices. It runs locally without
requiring any data transfer and uses industry-compliant encryption protocols to secure communication between home
devices and Hubitat Hub. Hubitat applications are written in the Groovy scripting language, running on top of the
JVM. JavaScript support is available, enabling custom automation and device integration. Event-driven automation
is achieved through a rule machine, a powerful built-in tool offering complex automation scenarios. Events handling
considers events issued by devices, hubs, networks or that are time-related. Creating new rules is available for advanced
use through the rule machine API or HTTP requests. The rule machine enables complex rule definitions, combining
multiple conditions and triggering complex device actions. Beginner end users can set simple actions using the simple
automation rule, which provides an user-friendly interface with predefined rules that users can easily configure. On the
physical layer, supported devices includes z-wave, ZigBEE-enabled and LAN-based connected devices, and virtual or
cloud devices. It does not support Bluetooth-connected devices.

HomeSeer. 22 is a home-automation platform marketed by Home Seer Technologies since 1999. The company also
sells controllers and hubs compatible with its software solution, with variable capabilities and prices, which allow
automation routines to run across multiple devices. In addition to its hardware offer, including sensors and actuators,
the platform is popular for its extensive panel of plugins (currently around 400), free or not, allowing interoperability
with several cloud systems and services and third-party devices and protocols. The Home Seer products are z-wave-plus
certified, focusing on lighting automation, door-locking systems, and water management through valves and controllers.
In addition, Home Seer stands out for its integration of video surveillance systems and anti-intrusion functionality.
The platform works locally and autonomously, although it also provides a cloud solution to interface the use of voice
assistants and IFTTT services. Pricing plans vary with the number of devices and plugins required for the use case.

Apple HomeKit. Apple HomeKit23 is a home-automation system that allows users to automate their homes by
controlling compatible devices, virtually defined as accessories. The system is available through an application called
Home, running exclusively on Apple operating systems (IOS, iPadOS, macOS). Accessories can be integrated into
the smart-home instance by automatically discovering network-connected devices (Wifi, Bluetooth). In addition to
single-device control, the platform allows the definition of complex automation rules, defined as scenes where combined
actions on multiple accessories can be triggered if a specific event condition is fulfilled. A set of accessories can be
declared as physically belonging to the same room in the home layout. Events are either time-based or sensor-output
data. The platform provides a multi-control option where multiple users can share the automation of the home, defining
distinct preferences. User’s geolocation data are then used to adapt home scenes according to the resident’s presence.
To guarantee remote access, an Apple device (Apple TV, home pod, iPad,..) must be configured as a HomeKit hub.
The hub also enables integrating additional accessories such as matter-compatible devices [2] or cloud-based services
such as the Siri assistant for voice commands. To enlarge the range of accessories compatible with the platform, the
open-source project homebridge24 is a node.js-based solution that emulates the iOS HomeKit API. It defines a set of
plugins to interface third-party device APIs with the HomeKit platform. Developers aiming to integrate new accessories

21 HubitatHome Automation, https://hubitat.com/. Accessed: 2023-04-24.

22 HomeSeer Home Automation, https://homeseer.com/. Accessed: 2023-04-24.
23 Apple HomeKit Home Automation, https://developer.apple.com/apple-home/. Accessed: 2023-04-24.
24 Home bridge, https://github.com/homebridge/homebridge. Accessed: 2023-04-30.

Manuscript submitted to ACM

A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 23

or communicate with HomeKit in their applications might consider the HomeKit Accessory Development Kit (ADK)
framework,25 using the supported programming languages Objective-C and Swift.

Other solutions. The following solutions are provided by large technology companies, with scalability features to
handle large commercial buildings deployments:
• Samsung Smart Things, which supports a wider range of protocols (ZigBEE, Z-Wave, Wi-Fi), making it suitable
for complex and diverse IoT ecosystems in large commercial buildings;26
• Amazon AWS IoT, which offers extensive scalability and integration with other AWS services, providing robust
cloud-based solutions for large-scale industrial and commercial IoT deployments;27
• Google IoT, which provides powerful data analytics and machine-learning-based services;
• and Microsoft Azure IoT, tailored for enterprise solutions, offering advanced security, scalability, and integration
with a wide range of enterprise applications.28
Note, however, that these solutions might be less suited for new IoT users with limited budget and targeting small
deployments.

5.2 Smart Agriculture

Agriculture represents one of the application fields where the integration of IoT technologies records the most significant
growth. According to [83], the IoT market in agriculture has been valued at USD 12.5 billion in 2021 and is expected
to reach 28.56 billion by 2030. The evolution of the world population demands an increase in agricultural production
while paying attention to the ongoing climate and energy crises. These challenges require optimization strategies for
improving crop yield and monitoring resources such as water and energy. IoT provides effective solutions to support
the automation of several agriculture tasks [59] such as precision agriculture (e.g., for irrigation, fertilizer products,
greenhouses), environmental management (e.g., for pollution, water reserves, weather conditions), crop monitoring
(e.g., for animal management, product quality, soil health), horticulture via soil control or machinery.
The introduction of dedicated IoT platforms for agriculture is still recent [57] compared to other application domains
such as smart cities. Emerging projects aim to handle the complexity of the outdoor configuration, deliver (multi)
task-oriented decision support tools where farmers can define automation routines, collect data and get analytics to
make informed decisions towards performance improvement. We briefly describe below the most relevant propositions.

5.2.1 Proprietary solutions.

CropX. CropX29 is an agronomic farm management platform that leverages mashup principles to enable farm data
analytics and decision making. It includes a web UI and a mobile application to allow farmers access to a personalized
dashboard. The dashboard displays field and environment data recorded by CropX sensors or online cloud services.
Data insights cover underground indicators on the soil state, such as temperature or moisture, and additional data
analytics on satellite images, topological maps, or meteorological forecasts. Further farm management operational
statuses are integrated thanks to machinery APIs, or farmer’s feedback. In addition to data visualization, the farmer
can apply machine learning models to her data to obtain custom recommendations about irrigation planning, crop
25 Apple HomeKit Accessory Development Kit, https://github.com/apple/HomeKitADK. Accessed: 2023-04-30
26 Samsung developer, https://developer.samsung.com/smartthings/blog/en/2021/10/21/accelerating-home-automation-at-smartthings-with-rule-engine
27 AWS IoT, https://aws.amazon.com/fr/iot/. Accessed: 2024-06-27.
28 Azure IoT, https://azure.microsoft.com/fr-fr/solutions/iot. Accessed: 2024-06-27.
29 CropX, https://cropx.com/. Accessed: 2023-03-28.

Manuscript submitted to ACM

24 Hannou et al.

protection against diseases, effluence irrigation, and fertilization task. The pre-trained models support a large set of
crops and are designed to increase the crop yield while ensuring water and energy saving. While supporting various
crops and soil types, the platform does not allow end users to customize model definitions or service integration.
As the platform is proprietary, its use leads to various underlying costs, the first of which comes from acquiring the
hardware set compatible with the software solution. The sensors the company markets transmit real-time soil indicators,
including soil moisture, temperature, and electrical conductivity, at variable depths. To target farms with an existing
hardware installation and interoperate with additional connected devices as weather stations or rain gauges, CropX
sells a telemetry device to provide connectivity to the platform. In addition, access to cloud services and ML models
requires a monthly or annual subscription, and additional fees can be charged for in-person technical support services.

John Deere Operations Center. John Deere Operations Center30 is a cloud-based platform provided by the John Deere
company, which specialises in the manufacturing of agriculture equipment. The platform offers a set of tools to support
farm management, including data collection and integration, data analysis and visualization, and decision support
through recommendations and notifications. The platform is also available through a mobile application enabling remote
management on several tasks, primarily machine-based: machine operating and maintenance status, data analysis and
recommendations for yield improvement, and collaboration features with agronomists or support teams. The platform
does not allow for automatic control of machinery or field actuators, except for remote settings updates on the machines.
Although the platform can integrate other brands’ equipment, most features are limited to its ecosystem, restricting its
interoperability.

AgriWebb. AgriWebb31 is a cloud-based platform with web and mobile interfaces dedicated to farm management
with a primary focus on livestock management, including cattle and sheep. Livestock management covers animal
activity, health and insurance records, chemical and feed inventory (animal treatment, water stocks), and grazing
activity management. The platform enables activity planning based on financial forecasts by integrating financial
market data to ensure profitability and efficiency. AgriWebb has a GraphQL open API and supports multiple data import
and export options and formats. Sensing activity is limited to vendor-specific items through Bluetooth and wifi. The
solution is designed for livestock management and offers limited features regarding crop management (only grazing
activity).

5.2.2 Open-source solutions.

The Smart Water Management Platform (SWAMP) project. SWAMP32 develops an IoT-based solution for smart
irrigation to improve water saving [24, 56]. It pays particular attention to security challenges raised around farmers’
data management. The project has four pilots in three countries sharing the same technical architecture but covering
different crops and soil characteristics, with the purpose of reinforcing the irrigation and water distribution models.The
platform is designed as a modular framework, including several components interacting according to the microservice
architectural style. The modules are organized vertically following the IoT Computing Continuum [110] in five
layers, each corresponding to a processing step. The bottom layer consists of devices’ integration and ensuring
communications, while the top layer hosts application services, providing two use scenarios accessible through mobile
and web applications. Farmers benefit from data insights to make informed decisions regarding their irrigation system,
30 JohnDeere Operations Center, https://operationscenter.deere.com/, accessed 2023-04-14.
31 AgriWebb,https://www.agriwebb.com/. Accessed: 2023-04-14.
32 Smart Water Management Platform, http://swamp-project.org/. Accessed: 2023-04-11.

Manuscript submitted to ACM

A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 25

while water distribution actors get recommendations on distribution planning following real-time and forecast farmers’
needs. All soil indicators such as moisture or temperature can be visualized in real time, and farmers can trigger
irrigation by controlling probes through the mobile application.
The SWAMP framework is open-source33 and is built around the FIWARE framework,34 from which it integrates
the services of the data-management layer. It also reuses the IoT FIWARE security module within its data-acquisition
layer, ensuring safe data transmission and storage with reinforced authentication and data-encryption protocols. All
processing modules expose RESTful APIs for communication interfacing with the application layer. SWAMP pays
particular attention to semantic interoperability, by deploying within the data management layer an RDF triplestore and
a SPARQL Event Processing Architecture (SEPA) [90], enabling users to store and query knowledge graphs efficiently.
The graphs are defined on top of a SWAMP ontology defined to fit the platform’s use cases.SWAMP stands out by
offering the ability to request drone flight missions using the mobile application and visualize the path in real time.
Drone missions are autonomously launched by the platform. The platform is dedicated to irrigation-related tasks, which
prevents other use scenarios such as crop-disease control.
FIWARE is also the base platform of many other smart agriculture solutions, thanks to its open-source license
and the diversity of the supported open standards and tools it offers for IoT application development. The FIWARE
project is funded by the European Commission under Horizon 2020 program and considers interoperability within IoT
applications as a primary focus. Frequently compared to W3C WoT, a WOT-FIWARE connector has been proposed and
illustrated on smart agriculture scenarios in [109]. In [89], a review of smart agriculture solutions built around FIWARE
is provided. The following list is enriched with recent contributions.

Farm Management System (FMS). FMS [55] is a cloud-based platform built around FIWARE General Enablers in
a multilayer architecture. A local FMS collects data from sensors and machinery to integrate environment and soil
indicators and operating status. The collected data are transferred to a cloud FMS for management, processing and
application ends, including reporting and visualization. A case study on greenhouse management has been implemented
to showcase the collaboration and use scenario. The platform targets multiple end-user groups allowing for collaboration
among agriculture-related business domains (farmers, agriculturists, agronomists, ICT experts).

Cropinfra. Cropinfra [82] is a project carried out by MTT Agrifood Research Finland with the purpose of supporting
farmers in the management of demanding farm operations. The platform allows end users to interconnect data and
services of fields, machinery and buildings to create a custom operation-management environment. The resulting
application enables farmers to get real-time insights on their farming activities and receive warnings of potential risks.
Other similar platforms include Testbed [75], SME Widhoc [68], and Agricolus [42].

6 DISCUSSION AND INSIGHTS

The presentation of the previously discussed IoT platforms showcases the diversity of their technical characteristics
and use modalities. Table 1 provides a summary of IoT platforms characteristics as identified and defined in Section 3.
In this section we discuss some of the insights that one can draw from this survey.

33 SWAMP IoT Platform, https://git.rnp.br/swamp-essentials/iot-platform. Accessed: 2023-07-10.

34 FIWARE project, https://www.fiware.org/. Accessed: 2023-04-11.
Manuscript submitted to ACM
 26

Table 1. Summary of IoT programming platforms characteristics.

Tool Programming Interoperability Architecture Licence Domain

DSL UI Dev Approach Toolbox Supp Lang
Eclipse-based IDE
Java
Network and Serialization plugins
ThingML UML-like T MDD JavaScript D-C-Sx Peer-to-peer Open Source Generic
Port, Messages, Things APIs
C / C++
Eclipse SDK

Manuscript submitted to ACM

MOISL,
MOCSL, G Java
MIDGAR MDD APIs D-C-Sx Orchestrator Open source Generic
MUCSL T C / C++
DSLs
FRASAD Rule-DSL G MDD Eclipse IDE plugins C D-C Peer-to-peer NA Generic
REST APIs Java/Python
WOX – T MDD D-C-SX-S Blackboard Open Source Generic
Linked Open Data API Android or C/C++
Web visual editor
Node-RED - G Mashup Flow library, APIs JavaScript D-C-Sx-S Kernel Open-Source Generic
Node.JS SDKs
G REST APIs
WoTKIT - Mashup JavaScript, Python D-C-Sx Blackboard Proprietary Generic
T Sensor gateways
G
IFTTT - EUP integration API JavaScript D-C-Sx Orchestrator Freemium Generic
T
Epidosite – G EUP REST API (IFTTT) Java D-C Kernel Open Source Generic
Zapier - G EUP REST API JavaScript, Python D-C-Sx Orchestrator Proprietary Generic
Puzzle - G EUP – JavaScript D-C Blackboard NA Generic
G Java
Almond Thing Talk EUP API D-C-Sx-S Kernel Open Source Generic
V JavaScript
Device adapters
Appsgate Appsgate DSL T EUP Java D-C Blackboard Open Source Home Automation
P-Openhab middleware
Java
G REST APIs
OpenHAB Rule DSL EUP Python D-C-Sx-S Kernel Open Source Home automation
T Bindings
Groovy
Rest APIs
YAML-Based G Add-ons Python
Home Assistant EUP D-C-Sx Kernel Open Source Home automation
Scription T Web services integrations JavaScript
Webhooks
Rule machine API
Hub variable API
Hubitat – G EUP Groovy D-C-Sx Kernel Proprietary Home automation
Driver/Library/App bundles
Web services integrations
CropX - G Mashups NA NA D-C-Sx Kernel Freemium Agriculture
Agriculture
SWAMP - G EUP Rest APIs JavaScript D-C-SX-S Kernel Open Source
Irrigation
Programming: DSL: the exposed DSL language (see Appendix B on DSLs), or only a Visual Programming Interface (-); UI: textual (T) or graphical (G) notations; Dev Approch: the programming
approach (see Appendix B on DSLs). model-driven programming (MDD), mashups, or end-user programming (EUP). Toolbox: types of tools that support
Hannou et al.

developers’ activities; Supp Lang: the programming languages developers can access to develop applications, extend platforms functionalities and set
interoperability options. If the platform uses an internal DSL, indicates the target language for code generation. Interoperability: if extension point is
defined and documented for supporting more devices (D), protocols (C), exchange formats (Sx) or data models (S); Architectural Patterns: system and
components interaction paradigm (see Sec. 3.2); License: license of the platform (see Sec. 3.3; Domain: Distinguishes generic, domain-oriented, and
task-oriented platforms.
A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 27

6.1 K1: Expressivity and Technical Features

The first decision factor to consider when selecting any software solution is its adaptation to the envisaged use-case
requirements. For IoT platforms, adaptability relates to the capacity of the platform to support the tasks of the vertical
application domain, the use case and the compatibility with the technical configuration, if set by the client organization.
Exploring platform features enables one to identify to what extent it can be exploited or what adaptation degree
is necessary to maximize requirements coverage. In the smart irrigation use case, platforms exclusively dedicated to
building automation are likely outside the scope. Further, agriculture-oriented platforms might sometimes focus on
specific tasks such as livestock management with Agriwebb; more generic solutions such as Node-RED present a better
fit, considering the extensive extensibility features, documentation and support easing the development of custom
automation routines.
Similarly, data-management strategies are relevant to evaluate what insights or automation can be provided.Data-
analysis frequency and decision-making process pace do not always conform to the end user’s expectation nor the
device’s accuracy and data transmission rate. The decision to irrigate soil can be produced on a daily basis, which differs
from the ventilating decision for a room recording unhealthy CO2 peaks, which requires a faster system reactivity.
Technical deployment constraints are an additional aspect impacting the platform choice. Agricultural use cases
generally have outdoor deployments covering large areas, thus requiring wide-range communication protocols (WPLAN).
Outdoor systems expose devices to harsh environmental conditions, such as wind and snow, leading to unstable
connectivity and possible lack of data availability. Automation accuracy in these settings relies on the platform’s fault
tolerance capacity, including data synchronization mechanisms. In the building automation domain, indoor deployment
presents different challenges resulting from the density and complexity of the sensor network deployed in a narrow
area, requiring robust scalability.

6.2 K2: Learning Curve

From a user-developer perspective, the learning curve of a programming tool indicates the rate at which she acquires
proficiency in writing programs over time. Thus, time to proficiency impacts IoT platform choice. Several factors acting
on this curve are related to the platform itself: abstraction level and toolbox, frequency of updates, documentation
availability, customization degree and community strength (described later).

• Abstraction Level and Toolbox. As discussed in the DSL background ( Appendix B of supplementary material),
classifying a platform as belonging to a programming approach family is hard. Table 1 showcases that most
IoT programming platforms provide scripting APIs to enable low-level operations control, which increases
expressivity. Depending on use cases, the use of scripting APIs and, consequently, general-purpose languages
remain optional if the platform’s main programming interface fully covers the user’s requirements. This is also
valid for plugin definition APIs, service integration, templating or configuration file editing, which might require
more familiarization effort.
• System Architecture. The learning curve is generally lower for centric systems with one main programming
interface such as kernel systems. Peer-to-peer systems for example exhibit more heterogeneities to consider.
• Customization and Extensibility: Highly customizable platforms usually correlate with higher expressivity and
complexity, leading to steep learning curves. Identifying settings matching use-case requirements demands
more effort to understand possible scenarios, and the provided documentation does not cover all customizations.
Examples of similar platforms are NodeRED, for the extensive number of nodes in palette and flow-composition
Manuscript submitted to ACM
28 Hannou et al.

options, Home Assistant, relying on YAML-like configuration files, or ThingML, where the DSML supports high
customization degrees and relies on multi-language code generation. Trigger-action-based programming tools
offering compositions over rules appear to be complex while expressing advanced scenarios. The user might
need to compose numerous constructs (textual or visual) to encode a program, and quickly be confused by an
overwhelming flow of events and triggers.
• Frequency of updates: Whether the platform is proprietary or open-source, new versions are regularly released,
providing new features and enhancements addressing identified issues. This enrichment often affects users’
familiarization with the platform services and sometimes involves changes in the programming operation;
well-managed platforms carefully review new releases to ensure maximal stability and/or upward compatibility.
• Documentation and Tutorials: The availability of comprehensive learning resources is crucial for lowering the
learning curve. High-quality documentation is well structured, introducing platform features and characteristics
and supporting users in getting started. Tutorials consist of step-by-step programming examples covering the
most popular applications. Many platforms rely on GitHub to host the source code of application examples
guiding users through their learning experience.

Other factors impacting the learning curve derive from the complexity of the programs to write. Automation
routines involving trivial logical rules for turning off lights in an empty room can be implemented quite quickly.
However, scenarios such as window opening may present higher complexity due to the presence of several triggers to
be considered and the management of concurrent actions originated by parallel triggering events, duration control, or
user-preference integration. Furthermore, automation scenarios where objects communicate with different protocols in
an outdoor/indoor system, such as irrigation, require homogenization and data integration mechanisms with query
handling. Additional web-available data, such as crop-standard recommendations or timely weather forecasts should be
considered in the automation rules for irrigation. The learning curve is expected to follow complexity of use case. Finally,
the human factor relates to the user’s prerequisites, their skills, and the rate at which they might master the platform
programming interfaces. The user profile is of utmost importance when formulating platform recommendations.

6.3 K3: Community Strength

Multiple metrics can be used to evaluate the strength of the community, with a difference between proprietary and
open-source systems. Proprietary platforms communicate about their active user base, such as IFTTT, which indicates
20 million consumers (end of 2021). Open-source platforms usually make their projects available on collaborative
software-development platforms like Github. GitHub provides indicators about the project’s popularity by displaying the
number of stars, forks, watchers or contributing users. Table 2a gives statistics (at the time of writing, mid-2023) about
some open-source projects on GitHub. The number of mobile application downloads might be relevant, especially for
end-user programming platforms where mobile applications provide simplified automation routines. The IFTTT Android
application has been downloaded over 5 million times. Some systems lead to the development of mobile applications
as a secondary UI that does not provide all system features or might be created for remote access, visualization, and
alerting purposes. Some of them are fee-based, which may explain their low popularity compared to the platform’s
success, as for the NodeRED mobile application, namely RedMobile (1000 downloads).
The community strength is an important factor for time-to-master evaluation and the richness of the open-source
system features. IoT platforms with kernel architectures rely on multiple plugins (add-ons) to interface with het-
erogeneous devices and services, generally widely supported and developed by the community. Moreover, strong
Manuscript submitted to ACM
A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 29

communities and user bases provide examples of successful implementations of the platforms, which may present
better guarantees of applicability for new users. If proprietary solutions such as CropX communicate mostly about the
volume of deployments,35 exceeding there 10,000 fields, with statistics about their location and variety, implementation
stories are more detailed with open-source platforms such as openHAB36 or Home Assistant.37

6.4 K4: Interoperability

Interoperability is a crucial aspect when choosing an IoT platform for programming automation applications. First,
compliance with the technical constraints of the use case and the expected deployment are decisive factors for the
project’s viability. The system might also be regularly enriched with new devices operating via different communication
protocols. Furthermore, IoT applications are frequently associated and meant to interoperate with other domain-related
software solutions such as physical-security management systems, or room-reservation solutions in building automation,
or inventory management and accounting solutions in agriculture.
Model-Driven programming platforms usually generate executable codes in general-purpose languages that can be
executed on various environments and, in a general fashion, guarantee easier interoperability through protocols or
devices code injection, either at the higher level, using modelling notations, or by directly acting on code generation.
Mashups or EUP Platforms often come with a primary core of targeted hardware or software specifications and generally
include a set of plugins or gateways to expand the extent of supported devices and protocols or integrate external
web services to enrich delivered functionalities. Proprietary platforms sometimes require contacting the company for
additional service integration or plugin definition, as for the John Deere operation centre or CropX. Apple HomeKit
supports interoperability through a proprietary communication protocol, namely HomeKit Accessory Protocol (HAP),
which enables making devices compatible with the software solution by acquiring and implementing the protocol. In
the case of open-source platforms, the developer community enriches these software solutions using provided templates
and tools. Examples of such platforms include Node-RED, which provides JavaScript templates to support custom node
creation. The availability of this support is an indicator of interoperability concerns, enabling autonomous platform
adaptation to other technologies. However, the number of plugins or gateways is only partially relevant, considering
that several plugins are defined for the same device or protocol, leading to redundancy and impacting support coverage.
Another aspect of interoperability involves interfaces allowing the integration of web services such as IFTTT or
Zapier, which define templates for new service integrations through service APIs. However, these last two examples are
intended for the service provider, so that this solution is integrated into the platform. Some platforms natively include
external IoT systems integrations, such as Hubitat includes IFTTT or Google Home services, or Epidosite API for IFTTT
integration. Scripting APIs allow users to program scripts adapting the platform’s features or extending them through
GPLs, usually Java (ThingML, OpenHAb), Python (Home Assistant, WoX, WoTkiT) or JavaScript (Node-RED, IFTTT),
but also C/C++ (FRASAD, MIDGAR), Swift (Apple HomeKit) or Groovy (Hubitat). Some examples are in Table 2b.

6.5 K5: Cost and Licensing

The selection of an IoT platform is impacted by its associated costs. Upfront costs of acquiring the platform significantly
vary from one vendor to another, depending on their pricing models. In addition, the use of some solutions is constrained
by the acquisition of platform-compatible devices. John Deere Operation Center designs its agriculture solutions to fit

35 Reinke + CropX Farm Management – A Bold New Era, https://aboldnewera.com/ Accessed: 2024-06-27.
36 Projects using openHAB Companies, https://github.com/openhab/openhab1-addons/wiki/Projects-using-openHAB---Companies. Accessed 2024-06-27.
37 Awesome Home Assistant, https://github.com/frenck/awesome-home-assistant. Accessed: 2024-06-27.
Manuscript submitted to ACM
30 Hannou et al.

Plugins/
Platform Connect API Extension support
Integrations
Connect API
IFTTT 700 OpenAPI definition
(JavaScript)
Platform Repository Stars Forks
Editor API (Nodes)
Home Assistant */home-assistant/core 61 000 24 000 Module API
Node-RED 4400 Library store
(JavaScript)
Node-RED */node-red/node-red 17 000 4 000 Hooks
ThingML */TelluIoT/ThingML 100 30 Core bindings API
REST API
OpenHAB 400 Scripting APIs
Openhab */openhab/openhab-core 800 400 (Java)
(Java, Jython, Groovy)
Jeedom */jeedom/core 374 312 Module API
HomeKit 900 Home Bridge project
(a) Overview of some IoT platforms popularity metrics (Swift)
on Github (*/ = https://github.com/) (b) Overview of some IoT platforms offered APIs and plugins

Table 2. Overview of IoT platforms developper support metrics

the John Deere machines, and although interoperability features are proposed, they considerably restrict the scope of
applications. The required hardware settings are also often related to hubs acquisition as for Hubitat elevation, which
entirely relies on local computations for privacy. For home automation, Apple HomeKit is free for users owning an
Apple device that can be employed as a hub (Ipad, homePad or Apple TV), but limited to compatible IoT devices. Devices
with the label “works with Apple HomeKit” are considerably more expensive.
The financial aspects extend to the ongoing operating, support or maintenance costs. These include the costs for
extending the platform use cases to additional devices or services. Hub-based platforms are limited to a number of
devices, 100 for Apple HomeKit, for example. Scaling up to larger settings could require additional expenses. Freemium
platforms offer users a set of basic functionalities and request them to subscribe to monthly or annual billing plans for
additional services supporting complex automation, such as IFTTT. As discussed for interoperability, another aspect
that might contribute to ongoing fees relates to purchasing plugins or add-ons to enlarge the extent of supported
devices and protocols. JEEDOM open-source platform offers a plugin marketplace that provides free and chargeable
components. Many hub-based platforms offer cloud-access options for data storage, web-based service integration or
remote access, which leads to additional costs. Examples include the Home Assistant cloud. Maintenance and support
costs, essential for maintaining platform efficiency and resolving technical issues, are potential ongoing costs. Most
IoT platforms, whether open-source or commercial, provide extensive documentation and publicly available tutorials.
However, some offer paid training sessions or certification programs such as Azure Farmbeats or CropX. It is worth
mentioning that open-source platforms come with different licensing terms that should be considered when selecting
the appropriate IoT platform. Some licenses, such as the Eclipse Public License, require crediting the platform when
reusing its features in commercial applications, which may introduce constraints for large-scale industrial projects.

7 CONCLUSION
As for other complex systems,building, using, and maintaining IoT systems faces increasing challenges, primarily due
to the technological diversity and complexity of system components. On the other hand, the use scenarios involving
the Internet of Things and supporting task automation have never been this broad. Several high-level tools are striving
to offer simplified user-interaction interfaces for seamless access to these technologies, preventing users from being
overwhelmed with technical stacks wrapping edge, cloud, mobile, or constrained device management, communicating via
multiple adapted protocols. On another dimension, the popularity and success of IoT applications also transformed users’
profiles, who have recently evolved from simple consumers to developers creating applications through user-friendly
Manuscript submitted to ACM
A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 31

interfaces. IoT platforms nowadays attempt to expose interfaces with new languages (Domain-Specific Languages),
thought and designed to bridge the gap between the physical layers (cloud infrastructures and protocols, mobile-
constrained objects, etc.) and the high-level services supporting the communication between networked objects.
In IoT systems, general-purpose languages can be too sophisticated, requiring skilled users and much coding time,
and include patterns that might be unnecessary for some given domain requirements. They are still used across various
platforms but are generally wrapped into intermediate layers or exposed for device-programming utilities. Tools tending
to enlarge their user profiles prefer simplified interactions supported by domain-specific languages. In the realm of
IoT domain-centric tools, three primary paradigms—model-driven, mashup tools, and end-user programming—mirror
established programming models. Model-driven languages primarily cater to business experts possessing field knowledge,
facilitating the creation of applications via UML-like models or other VSDML visual languages. These languages are
beneficial for IoT systems that intertwine technical system building with vertical domains. The use of simplified
modelling tools encourages the involvement of domain experts, enhancing the system’s alignment with domain
requirements and facilitating autonomy for domain experts who prefer modelling for encoding system behaviour
and components. Mashup tools, on the other hand, harness the plethora of available IoT web services to enable data
and service composition. Unlike MDD tools, which focus on systems components, mashup tools are designed to
focus on flow messages between components. While the preexistence of services eases system development, it also
limits its applicability to available features. The tools enable the composition of various web-available services at
the user-interface level, but the extent to which users act on logical behaviours is restricted. End-user programming
as a concept is common to the programming community beyond IoT. It has evolved with technological advances to
facilitate higher abstraction levels, leveraging increasingly broader techniques. Historically, model-driven programming
and mashup tools were considered EUP tools as they encapsulate technical specifications in high-level component
representations. Recently, natural-language processing, programming by example or through games or voice-based
interactions are employed through various platforms, including computers and mobiles, for simplified automation
encoding. The platform programming approach usually affects its expressivity and the expected learning curve for new
users. The IoT platform selection process is thus dependent on various factors, including technical characteristics.
An extensive interest has been dedicated to interoperability within IoT systems in the last few years. Making complex
systems interconnect and operate together becomes more challenging with each proposed standard, tool, device, or
language. Interoperability support is tooled with plugins, adapters, gateways and APIs, enabling effective collaboration
and broader hardware support. As for complex systems, the architectural patterns also affect the deployment of IoT
solutions and their non-functional requirements, such as scalability, performance efficiency or security. The number
of system components and the type of interactions provide valuable insights about the system’s operating mode,
robustness, security or scalability. Platforms are increasingly putting effort into documentation and user communities
to increase their popularity and ensure comprehensive and effective use of their platforms.
In summary, the fast-evolving landscape of IoT technologies, in its vast diversity and complexity, calls for an ongoing
effort to empower end-users with the knowledge and selection criteria that support them to make informed decisions,
thereby making steps towards democratizing technological progress in every domain. We believe this paper is a step in
this direction, providing a broad survey of all these issues in a manner accessible to any technically inclined professional
interested in entering the IoT field from a business-domain perspective. We provide up to date knowledge and references
that should help fast-track the necessary selection, design and implementation steps that IoT deployment requires.
Future work may consider extending this survey to other application domains such as Industry 4.0 or healthcare, to
discuss more domain specific platforms.
Manuscript submitted to ACM
32 Hannou et al.

REFERENCES
[1] Ala Al-Fuqaha, Mohsen Guizani, Mehdi Mohammadi, Mohammed Aledhari, and Moussa Ayyash. 2015. Internet of Things: A Survey on Enabling
Technologies, Protocols, and Applications. IEEE communications surveys & tutorials 17, 4 (2015), 2347–2376.
[2] Connectivity Standards Alliance. 2011. Matter Specification Version 1.0. Technical Report. Connectivity Standards Alliance, San Jose, CA, USA. 11
pages. https://csa-iot.org/wp-content/uploads/2022/11/22-27349-001_Matter-1.0-Core-Specification.pdf
[3] Kevin Ashton. 2009. That ‘Internet of Things’ thing. RFID journal 22, 7 (2009), 97–114.
[4] Luigi Atzori, Antonio Iera, and Giacomo Morabito. 2010. The Internet of Things: A survey. Computer networks 54, 15 (2010), 2787–2805.
[5] Debasis Bandyopadhyay and Jaydip Sen. 2011. Internet of Things: Applications and Challenges in Technology and Standardization. Wireless
personal communications 58, 1 (2011), 49–69.
[6] Sourav Banerjee, Chinmay Chakraborty, and Sudipta Paul. 2019. Programming Paradigm and the Internet of Things. In Handbook of IoT and Big
Data. CRC Press, 145–163.
[7] Barnana Baruah and Subhasish Dhal. 2018. A two-factor authentication scheme against FDM attack in IFTTT based Smart Home System. Computers
& Security 77 (2018), 21–35.
[8] Len Bass, Paul Clements, and Rick Kazman. 2003. Software architecture in practice. Addison-Wesley Professional.
[9] Michael Blackstock and Rodger Lea. 2014. Toward a Distributed Data Flow Platform for the Web of Things (Distributed Node-RED)). In Proceedings
of the 5th International Workshop on Web of Things. 34–39.
[10] Evandro Eduardo Broday and Manuel Carlos Gameiro da Silva. 2023. The role of internet of things (IoT) in the assessment and communication of
indoor environmental quality (IEQ) in buildings: a review. Smart and Sustainable Built Environment 12, 3 (2023), 584–606.
[11] Arne Bröring, Stefan Schmid, Corina-Kim Schindhelm, Abdelmajid Khelil, Sebastian Käbisch, Denis Kramer, Danh Le Phuoc, Jelena Mitic, Darko
Anicic, and Ernest Teniente. 2017. Enabling IoT ecosystems through platform interoperability. IEEE software 34, 1 (2017), 54–61.
[12] Paul Brous, Marijn Janssen, and Paulien Herder. 2020. The dual effects of the Internet of Things (IoT): A systematic review of the benefits and risks
of IoT adoption by organizations. International Journal of Information Management 51 (2020), 101952.
[13] Adriana Caione, Alessandro Fiore, Luca Mainetti, Luigi Manco, and Roberto Vergallo. 2017. WoX: Model-Driven Development of Web of Things
Applications. In Managing the Web of Things. Elsevier, 357–387.
[14] Giovanni Campagna, Rakesh Ramesh, Silei Xu, Michael Fischer, and Monica S. Lam. 2017. Almond: The architecture of an open, crowdsourced,
privacy-preserving, programmable virtual assistant. In Proceedings of the 26th International Conference on World Wide Web. 341–350.
[15] Humberto Cervantes and Rick Kazman. 2016. Designing software architectures: a practical approach. Addison-Wesley Professional.
[16] Raymond Chan, Wye Kaye Yan, Jung Man Ma, Kai Mun Loh, Tan Yu, Malcolm Yoke Hean Low, Kar Peo Yar, Habib Rehman, and Thong Chee Phua.
2023. IoT devices deployment challenges and studies in building management system. Frontiers in The Internet of Things 2 (2023), 1254160.
[17] Victor Charpenay, Maxime Lefrançois, María Poveda-Villalón, and Sebastian Käbisch. 2023. Thing Description (TD) ontology. W3C internal
document. World Wide Web Consortium. https://www.w3.org/2019/wot/td
[18] Xiang ‘Anthony’ Chen and Yang Li. 2017. Improv: an input framework for improvising cross-device interaction by demonstration. ACM Transactions
on Computer-Human Interaction (TOCHI) 24, 2 (2017), 1–21.
[19] Bo Cheng, Da Zhu, Shuai Zhao, and Junliang Chen. 2016. Situation-aware IoT service coordination using the event-driven SOA paradigm. IEEE
Transactions on Network and Service Management 13, 2 (2016), 349–361.
[20] Lawrence Chung and Julio César Sampaio do Prado Leite. 2009. On Non-Functional Requirements in Software Engineering. (2009), 363–379.
[21] Joëlle Coutaz and James L. Crowley. 2016. A first-person experience with end-user development for smart homes. IEEE Pervasive Computing 15, 2
(2016), 26–39.
[22] Jose Danado and Fabio Paternò. 2012. Puzzle: a visual-based environment for end user development in touch-based mobile phones. In International
Conference on Human-Centred Software Engineering. Springer, 199–216.
[23] Laura Daniele, Raúl García-Castro, Maxime Lefrançois, and María Poveda-Villalón. 2020. SAREF: the Smart Applications REFerence ontology.
Technical Report TS 103 264, v3.1.1. ETSI. https://saref.etsi.org/core/v3.1.1/
[24] Ramide Augusto Sales Dantas, Milton Vasconcelos da Gama Neto, Ivan Dimitry Zyrianoff, and Carlos Alberto Kamienski. 2020. The swamp farmer
app for iot-based smart water status monitoring and irrigation control. In 2020 IEEE International Workshop on Metrology for Agriculture and
Forestry (MetroAgriFor). IEEE, 109–113.
[25] Jasenka Dizdarević, Francisco Carpio, Admela Jukan, and Xavi Masip-Bruin. 2019. A Survey of Communication Protocols for Internet of Things
and Related Challenges of Fog and Cloud Computing Integration. ACM Computing Surveys (CSUR) 51, 6 (2019), 1–29.
[26] Pedro Domingues, Paulo Carreira, Renato Vieira, and Wolfgang Kastner. 2016. Building automation systems: Concepts and technology review.
Computer Standards & Interfaces 45 (2016), 1–12.
[27] David L. Donoho. 2006. Compressed Sensing. IEEE Transactions on Information Theory 52, 4 (April 2006), 1289–1306.
[28] Inc Eclipse Foundation. 2019. IoT Developer Survey 2019. Technical Report. Eclipse Foundation, Inc.
[29] Fatima Essaadi, Yann Ben Maissa, and Mohammed Dahchour. 2016. MDE-based languages for wireless sensor networks modeling: A systematic
mapping study. In International Symposium on Ubiquitous Networking. Springer, 331–346.
[30] Teo Eterovic, Enio Kaljic, Dzenana Donko, Adnan Salihbegovic, and Samir Ribic. 2015. An Internet of Things visual domain specific modeling
language based on UML. In 2015 XXV International Conference on Information, Communication and Automation Technologies (ICAT). IEEE, 1–5.

Manuscript submitted to ACM

A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 33

[31] Dave Evans. 2011. The Internet of Things: How the Next Evolution of the Internet Is Changing Everything. Technical Report. Cisco Internet Business
Solutions Group (IBSG), Cisco Systems, Inc., San Jose, CA, USA. http://www.cisco.com/web/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf
[32] Dave Evans. 2012. Overview of the Internet of Things. Technical Report. International Telecommunication Union. 22 pages. https://www.itu.int/
rec/dologin_pub.asp?lang=e&id=T-REC-Y.2060-201206-I!!PDF-E&type=items
[33] Jody Condit Fagan. 2007. Mashing up Multiple Web Feeds Using Yahoo! Pipes. Computers in Libraries 27, 10 (2007), 10–17.
[34] Alessandro Fiore, Adriana Caione, Luca Mainetti, Luigi Manco, and Roberto Vergallo. 2018. Top-Down Delivery of IoT-based Applications for
Seniors Behavior Change Capturing Exploiting a Model-Driven Approach. Journal of Communications Software and Systems 14, 1 (2018), 60–67.
[35] Giancarlo Fortino, Claudio Savaglio, Giandomenico Spezzano, and MengChu Zhou. 2020. Internet of Things as System of Systems: A Review of
Methodologies, Frameworks, Platforms, and Tools. IEEE Transactions on Systems, Man, and Cybernetics: Systems 51, 1 (2020), 223–236.
[36] Martin Fowler. 2012. Patterns of Enterprise Application Architecture: Pattern Enterpr Applica Arch. Addison-Wesley.
[37] Iván Froiz-Míguez, Tiago M Fernández-Caramés, Paula Fraga-Lamas, and Luis Castedo. 2018. Design, implementation and practical evaluation of
an IoT home automation system for fog computing applications based on MQTT and ZigBee-WiFi sensor nodes. Sensors 18, 8 (2018), 2660.
[38] Cristian González García, B Cristina Pelayo G-Bustelo, Jordán Pascual Espada, and Guillermo Cueva-Fernandez. 2014. Midgar: Generation of
heterogeneous objects interconnecting applications. A Domain Specific Language proposal for Internet of Things scenarios. Computer Networks 64
(2014), 143–158.
[39] Cristian González García, Daniel Meana-Llorián, Vicente García-Díaz, Andrés Camilo Jiménez, and John Petearson Anzola. 2020. Midgar: Creation
of a Graphic Domain-Specific Language to Generate Smart Objects for Internet of Things Scenarios Using Model-Driven Engineering. IEEE Access
8 (2020), 141872–141894.
[40] Cristian González García, Liping Zhao, and Vicente García-Díaz. 2019. A user-oriented language for specifying interconnections between
heterogeneous objects in the Internet of Things. IEEE Internet of Things Journal 6, 2 (2019), 3806–3819.
[41] Nam Ky Giang, Michael Blackstock, Rodger Lea, and Victor C.M. Leung. 2015. Developing IoT Applications in the Fog: a Distributed Dataflow
Approach. In 2015 5th International Conference on the Internet of Things (IOT). IEEE, 155–162.
[42] Diego Guidotti, Susanna Marchi, Sara Antognelli, and Andrea Cruciani. 2019. Water management: agricolus tools integration. In 2019 Global IoT
Summit (GIoTS). IEEE, 1–5.
[43] Dominique Guinard, Vlad Trifa, Friedemann Mattern, and Erik Wilde. 2011. From the Internet of Things to the Web of Things: Resource-oriented
Architecture and Best Practices. In Architecting the Internet of Things. Springer, 97–129.
[44] Sandeep Gupta. 2022. Non-functional requirements elicitation for edge computing. Internet of Things 18 (2022), 100503.
[45] Armin Haller, Krzysztof Janowicz, Simon Cox, Danh Le Phuoc, Jamie Taylor, and Maxime Lefrançois. 2017. Semantic Sensor Network Ontology,
W3C Recommendation. W3C Recommendation. World Wide Web Consortium. https://www.w3.org/TR/2017/REC-vocab-ssn-20171019/
[46] Nicolas Harrand, Franck Fleurey, Brice Morin, and Knut Eilif Husa. 2016. ThingML: a language and code generation framework for heterogeneous
targets. In Proceedings of the ACM/IEEE 19th international conference on model driven engineering languages and systems. 125–135.
[47] Jorge E Ibarra-Esquer, Félix F González-Navarro, Brenda L Flores-Rios, Larysa Burtseva, and María A Astorga-Vargas. 2017. Tracking the evolution
of the Internet of Things concept across different application domains. Sensors 17, 6 (2017), 1379.
[48] IoT Analytics. 2020. IoT Platforms Landscape. https://iot-analytics.com/product/iot-platforms-landscape-database-2020. Accessed: 2022-06-09.
[49] SM Riazul Islam, Daehan Kwak, MD Humaun Kabir, Mahmud Hossain, and Kyung-Sup Kwak. 2015. The internet of things for health care: a
comprehensive survey. IEEE access 3 (2015), 678–708.
[50] ISO/IEC 25010:2011 2011. Systems and software Quality Requirements and Evaluation (SQuaRE) . Standard. International Organization for
Standardization, Geneva, CH.
[51] ISO/TC 211. 2011. Geographic information — Encoding. Standard. International Organization for Standardization, Geneva, CH.
[52] Krzysztof Janowicz, Armin Haller, Simon JD Cox, Danh Le Phuoc, and Maxime Lefrançois. 2019. SOSA: A lightweight ontology for sensors,
observations, samples, and actuators. Journal of Web Semantics 56 (2019), 1–10.
[53] Youngmin Ji, Kisu Ok, and Woo Suk Choi. 2018. Web of things based IoT standard interworking test case: Demo abstract. In Proceedings of the 5th
Conference on Systems for Built Environments. 182–183.
[54] Mengda Jia, Ali Komeily, Yueren Wang, and Ravi S Srinivasan. 2019. Adopting Internet of Things for the development of smart buildings: A review
of enabling technologies and applications. Automation in Construction 101 (2019), 111–126.
[55] Alexandros Kaloxylos, Aggelos Groumas, Vassilis Sarris, Lampros Katsikas, Panagis Magdalinos, Eleni Antoniou, Zoi Politopoulou, Sjaak Wolfert,
Christopher Brewster, Robert Eigenmann, et al. 2014. A cloud-based Farm Management System: Architecture and implementation. Computers and
electronics in agriculture 100 (2014), 168–179.
[56] Carlos Kamienski, Juha-Pekka Soininen, Markus Taumberger, Ramide Dantas, Attilio Toscano, Tullio Salmon Cinotti, Rodrigo Filev Maia, and
André Torre Neto. 2019. Smart water management platform: IoT-based precision irrigation for agriculture. Sensors 19, 2 (2019), 276.
[57] Andreas Kamilaris, Feng Gao, Francesc X Prenafeta-Boldu, and Muhammad Intizar Ali. 2016. Agri-IoT: A semantic framework for Internet of
Things-enabled smart farming applications. In 2016 IEEE 3rd World Forum on Internet of Things (WF-IoT). IEEE, 442–447.
[58] M. Karthikeyan, T.S. Subashini, and M.S. Prashanth. 2020. Implementation of Home Automation Using Voice Commands. In Data Engineering and
Communication Technology. Springer, 155–162.
[59] Sabrine Khriji, Dhouha El Houssaini, Ines Kammoun, and Olfa Kanoun. 2021. Precision irrigation: an IoT-enabled wireless sensor network for
smart irrigation systems. In Women in precision agriculture. Springer, 107–129.
Manuscript submitted to ACM
34 Hannou et al.

[60] Tae-Kook Kim. 2020. Short research on voice control system based on artificial intelligence assistant. In 2020 International Conference on Electronics,
Information, and Communication (ICEIC). IEEE, 1–2.
[61] Robert Kleinfeld, Stephan Steglich, Lukasz Radziwonowicz, and Charalampos Doukas. 2014. glue.things: a Mashup Platform for wiring the Internet
of Things with the Internet of Services. In Proceedings of the 5th International Workshop on Web of Things. 16–21.
[62] Ravi Kishore Kodali, Sasweth C Rajanarayanan, Lakshmi Boppana, Samradh Sharma, and Ankit Kumar. 2019. Low cost smart home automation
system using smart phone. In 2019 IEEE R10 Humanitarian Technology Conference (R10-HTC)(47129). IEEE, 120–125.
[63] Ege Korkan, Fady Salama, Sebastian Kaebisch, and Sebastian Steinhorst. 2021. A-MaGe: Atomic Mashup Generator for the Web of Things. In Web
Engineering - 21st International Conference, ICWE 2021, Biarritz, France, May 18-21, 2021, Proceedings. Springer, 320–327. https://doi.org/10.1007/978-
3-030-74296-6_24
[64] Ajay Krishna, Michel Le Pallec, Alejandro Martinez, Radu Mateescu, and Gwen Salaün. 2020. MOZART: design and deployment of advanced IoT
applications. In Companion proceedings of the web conference 2020. 163–166.
[65] S.V. Aswin Kumer, P. Kanakaraja, A. Punya Teja, T. Harini Sree, and T. Tejaswni. 2021. Smart home automation using IFTTT and google assistant.
Materials Today: Proceedings 46 (2021), 4070–4076.
[66] Toby Jia-Jun Li, Yuanchun Li, Fanglin Chen, and Brad A. Myers. 2017. Programming IoT devices by demonstration using mobile apps. In International
Symposium on End User Development. Springer, 3–17.
[67] Steve Liang, Chih-Yuan Huang, and Tania Khalafbeigi. 2016. OGC SensorThings API Part 1: Sensing, Version 1.0. Standard OGC 15-078r6. Open
Geospatial Consortium. http://dx.doi.org/10.25607/OBP-455
[68] JA López-Riquelme, N Pavón-Pulido, H Navarro-Hellín, F Soto-Valles, and R Torres-Sánchez. 2017. A software architecture based on FIWARE cloud
for Precision Agriculture. Agricultural water management 183 (2017), 123–135.
[69] Mahmoud Shuker Mahmoud and Auday AH Mohamad. 2016. A study of efficient power consumption wireless communication techniques/modules
for internet of things (IoT) applications. Advances in Internet of Things 6, 2 (2016), 19–29.
[70] Luca Mainetti, Luigi Manco, Luigi Patrono, Andrea Secco, Ilaria Sergi, and Roberto Vergallo. 2016. An ambient assisted living system for elderly
assistance applications. In 2016 IEEE 27th Annual International Symposium on Personal, Indoor, and Mobile Radio Communications. IEEE, 1–6.
[71] Luca Mainetti, Luigi Manco, Luigi Patrono, Ilaria Sergi, and Roberto Vergallo. 2015. Web of Topics: An IoT-aware model-driven designing approach.
In 2015 IEEE 2nd World Forum on Internet of Things (WF-IoT). IEEE, 46–51.
[72] Luca Mainetti, Paolo Panarese, and Roberto Vergallo. 2022. WoX+: A Meta-Model-Driven Approach to Mine User Habits and Provide Continuous
Authentication in the Smart City. Sensors 22, 18 (2022), 6980.
[73] Ivano Malavolta and Henry Muccini. 2014. A study on MDE approaches for engineering wireless sensor networks. In 2014 40th EUROMICRO
Conference on Software Engineering and Advanced Applications. IEEE, 149–157.
[74] Marco Manca, Parvaneh Parvin, Fabio Paternò, and Carmen Santoro. 2020. Integrating Alexa in a Rule-based Personalization Platform. In
Proceedings of the 6th EAI International Conference on Smart Objects and Technologies for Social Good. 108–113.
[75] Ramón Martínez, Juan Ángel Pastor, Bárbara Álvarez, and Andrés Iborra. 2016. A testbed to evaluate the fiware-based IoT platform in the domain
of precision agriculture. Sensors 16, 11 (2016), 1979.
[76] Xianghang Mi, Feng Qian, Ying Zhang, and XiaoFeng Wang. 2017. An empirical characterization of IFTTT: ecosystem, usage, and performance. In
Proceedings of the 2017 Internet Measurement Conference. 398–404.
[77] José P Miguel, David Mauricio, and Glen Rodríguez. 2014. A review of software quality models for the evaluation of software products. 5, 6 (2014),
31–53.
[78] Armin Moin, Stephan Rössler, Marouane Sayih, and Stephan Günnemann. 2020. From things’ modeling language (ThingML) to things’ machine
learning (ThingML2). In Proceedings of the 23rd ACM/IEEE Int. Conf. on Model Driven Engineering Languages and Systems: Companion Proc. 1–2.
[79] Xuan Thang Nguyen, Huu Tam Tran, Harun Baraki, and Kurt Geihs. 2015. FRASAD: A framework for model-driven IoT Application Development.
In 2015 IEEE 2nd world forum on internet of things (WF-IoT). IEEE, 387–392.
[80] Mahda Noura, Mohammed Atiquzzaman, and Martin Gaedke. 2019. Interoperability in Internet of Things: Taxonomies and Open Challenges.
Mobile networks and applications 24, 3 (2019), 796–809.
[81] Fabio Paternò and Carmen Santoro. 2017. A Design Space for End User Development in the Time of the Internet of Things. In New perspectives in
end-user development. Springer, 43–59.
[82] Liisa A Pesonen, Frederick K-W Teye, Ari K Ronkainen, Markku O Koistinen, Jere J Kaivosoja, Pasi F Suomi, and Raimo O Linkolehto. 2014.
Cropinfra–An Internet-based service infrastructure to support crop production in future farms. Biosystems engineering 120 (2014), 92–101.
[83] Precedence Research. 2022. Internet of Things (IoT) in Agriculture Market. https://www.precedenceresearch.com/iot-in-agriculture-market.
Accessed: 2023-03-28.
[84] Amir Rahmati, Earlence Fernandes, Jaeyeon Jung, and Atul Prakash. 2017. IFTTT vs. Zapier: A comparative study of trigger-action programming
frameworks. arXiv:1709.02788 [cs.CR]
[85] Anoja Rajalakshmi and Hamid Shahnasser. 2017. Internet of Things using Node-Red and Alexa. In 2017 17th International Symposium on
Communications and Information Technologies (ISCIT). IEEE, 1–4.
[86] Partha Pratim Ray. 2017. Internet of things for smart agriculture: Technologies, practices and future direction. Journal of Ambient Intelligence and
Smart Environments 9, 4 (2017), 395–420.
[87] Partha Pratim Ray. 2018. A survey on Internet of Things architectures. J. of King Saud U.-Computer and Information Sciences 30, 3 (2018), 291–319.
Manuscript submitted to ACM
A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective 35

[88] Larissa C Rocha, Rossana MC Andrade, Andreia L Sampaio, and Valéria Lelli. 2017. Heuristics to evaluate the usability of ubiquitous systems.
In Distributed, Ambient and Pervasive Interactions: 5th International Conference, DAPI 2017, Held as Part of HCI International 2017, Vancouver, BC,
Canada, July 9–14, 2017, Proceedings 5. Springer, 120–141.
[89] Maria Angeles Rodriguez, Llanos Cuenca, and Angel Ortiz. 2018. FIWARE open source standard platform in smart farming-a review. In Collaborative
Networks of Cognitive Systems: 19th IFIP WG 5.5 Working Conf.on Virtual Enterprises, Cardiff, UK, September 17-19, 2018, Proc. 19. Springer, 581–589.
[90] Luca Roffia, Paolo Azzoni, Cristiano Aguzzi, Fabio Viola, Francesco Antoniazzi, and Tullio Salmon Cinotti. 2018. Dynamic linked data: A SPARQL
event processing architecture. Future Internet 10, 4 (2018), 36.
[91] Challouf Sabri, Lobna Kriaa, and Saidane Leila Azzouz. 2017. Comparison of IoT constrained devices operating systems: A survey. In 2017 IEEE/ACS
14th International Conference on Computer Systems and Applications (AICCSA). IEEE, 369–375.
[92] Audrey Sanctorum, Suzanne Kieffer, and Beat Signer. 2020. User-driven Design Guidelines for the Authoring of Cross-Device and Internet of
Things Applications. In Proceedings of the 11th Nordic Conference on Human-Computer Interaction: Shaping Experiences, Shaping Society. 1–12.
[93] Sajjad Hussain Shah and Ilyas Yaqoob. 2016. A survey: Internet of Things (IOT) technologies, applications and challenges. In 2016 IEEE Smart
Energy Grid Engineering (SEGE). IEEE, 381–385.
[94] Kiran Jot Singh and Divneet Singh Kapoor. 2017. Create your own Internet of Things: A survey of IoT platforms. IEEE Consumer Electronics
Magazine 6, 2 (2017), 57–68.
[95] William Stallings. 1987. Handbook of computer-communications standards; Vol. 1: the open systems interconnection (OSI) model and OSI-related
standards. Macmillan Publishing Co., Inc.
[96] Rudi Studer, V. Richard Benjamins, and Dieter Fensel. 1998. Knowledge Engineering: Principles and Methods. Data and Knowledge Eng. 25, 1-2
(1998), 161–197.
[97] Xiang Su, Hao Zhang, Jukka Riekki, Ari Keränen, Jukka K. Nurminen, and Libin Du. 2014. Connecting IoT sensors to knowledge-based systems by
transforming SenML to RDF. Procedia Computer Science 32 (2014), 215–222.
[98] Antero Taivalsaari and Tommi Mikkonen. 2018. On the development of IoT systems. In 2018 Third Int. Conf. on Fog and Mobile Edge Computing
(FMEC). IEEE, 13–19.
[99] Richard N. Taylor, Nenad Medvidovic, and Dashofy Eric M. 2010. Software Architecture: Foundations, Theory, and Practice. John Wiley & Sons, Inc.
[100] Kleanthis Thramboulidis and Foivos Christoulakis. 2016. UML4IoT—A UML-based approach to exploit IoT in cyber-physical manufacturing systems.
Computers in Industry 82 (2016), 259–272.
[101] Blase Ur, Melwyn Pak Yong Ho, Stephen Brawner, Jiyun Lee, Sarah Mennicken, Noah Picard, Diane Schulze, and Michael L. Littman. 2016.
Trigger-Action Programming in the Wild: An Analysis of 200,000 IFTTT Recipes. In Proceedings of the 2016 CHI Conference on Human Factors in
Computing Systems. 3227–3231.
[102] Sander Vanden Hautte, Pieter Moens, Joachim Van Herwegen, Dieter De Paepe, Bram Steenwinckel, Stijn Verstichel, Femke Ongenae, and Sofie
Van Hoecke. 2020. A dynamic dashboarding application for fleet monitoring using semantic web of things technologies. Sensors 20, 4 (2020), 1152.
[103] Supachai Vorapojpisut. 2015. A Lightweight Framework of Home Automation Systems Based on the IFTTT Model. J. Softw. 10, 12 (2015).
[104] Peter Wegner. 1996. Interoperability. ACM Computing Surveys (CSUR) 28, 1 (1996), 285–287.
[105] Hansong Xu, Wei Yu, David Griffith, and Nada Golmie. 2018. A survey on industrial Internet of Things: A cyber-physical systems perspective. Ieee
access 6 (2018), 78238–78259.
[106] Hikmat Yar, Ali Shariq Imran, Zulfiqar Ahmad Khan, Muhammad Sajjad, and Zenun Kastrati. 2021. Towards smart home automation using
IoT-enabled edge-computing paradigm. Sensors 21, 14 (2021), 4932.
[107] Jennifer Yick, Biswanath Mukherjee, and Dipak Ghosal. 2008. Wireless sensor network survey. Computer networks 52, 12 (2008), 2292–2330.
[108] Wei-Zhe Zhang, Ibrahim A. Elgendy, Mohamed Hammad, Abdullah M. Iliyasu, Xiaojiang Du, Mohsen Guizani, and Ahmed A. Abd El-Latif. 2020.
Secure and optimized load balancing for multitier IoT and edge-cloud computing systems. IEEE Internet of Things Journal 8, 10 (2020), 8119–8132.
[109] Ivan Zyrianoff, Alexandre Heideker, Luca Sciullo, Carlos Kamienski, and Marco Di Felice. 2021. Interoperability in open IoT platforms: WoT-FIWARE
comparison and integration. In 2021 IEEE International Conference on Smart Computing (SMARTCOMP). IEEE, 169–174.
[110] Ivan Zyrianoff, Alexandre Heideker, Dener Silva, João Kleinschmidt, Juha-Pekka Soininen, Tullio Salmon Cinotti, and Carlos Kamienski. 2019.
Architecting and deploying IoT smart applications: A performance–oriented approach. Sensors 20, 1 (2019), 84.

Received 12 July 2023; accepted 2 September 2024

Manuscript submitted to ACM