\Glspl{Task} in the \gls{iTasks} system are modelled after real life workflow
tasks but the modelling is applied on a high level. Therefore, it is difficult
to connect \gls{iTasks}-\glspl{Task} to real world tasks and allow them
to interact. A lot of the actual tasks could very well be performed by
\gls{IoT} devices. Nevertheless, adding such devices to the current system is
difficult to say the least as it was not designed to cope with these devices.

In the current system such adapters connecting devices to \gls{iTasks} --- in
principle --- can be written in two ways.

First, an adapter for a specific device can be written as a
\glspl{SDS}\footnote{Similar as to resources such as time are available in the
current \gls{iTasks} implementation.}. \glspl{SDS} can interact with the world
and thus with hardware, allowing communication with any type of device.
However, this requires a tailor-made \gls{SDS} for every specific device and
functionality and does not allow logic to be changed. Once a device is
programmed to serve as an \gls{SDS}, it has to behave like that forever. Thus,
this solution is not suitable for systems that can send \glspl{Task} to
the device dynamically.

The second method uses the novel contribution to \gls{iTasks} by Oortgiese et
al. They lifted \gls{iTasks} from a single server model to a distributed server
architecture~\cite{oortgiese_distributed_2017}. As a proof of concept, an
android app has been created that runs an entire \gls{iTasks} core and is able
to receive \glspl{Task} from a different server and execute them. While android
often runs on small \gls{ARM} devices, they are a lot more powerful than the
average \gls{IoT} microcontroller. The system is suitable for dynamically
sending \glspl{Task} but running the entire \gls{iTasks} core on a
microcontroller is not feasible. Even if it would be possible, this technique
would still not be suitable because a lot of communication overhead is needed
to transfer the \glspl{Task}. \gls{IoT} devices are often connected to the
server through \emph{Low Power Low Bandwidth} which is unsuitable for
transferring a lot of data.

The novel system that has been devised bridges the gap between the
aforementioned solutions for adding \gls{IoT} to \gls{iTasks}. The system
consists of updates to the
\gls{mTask}-\gls{EDSL}~\cite{koopman_type-safe_nodate}, a new communication
protocol, device application and an \gls{iTasks} server application. The system
supports devices as small as \gls{Arduino}
microcontrollers~\cite{noauthor_arduino_nodate} and operates via the same
paradigms and patterns as regular \glspl{Task} in the \gls{TOP} paradigm.
Devices in the \gls{mTask}-system can run small imperative programs written in
the \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task} are sent to the
device at runtime, avoiding recompilation and thus write cycles on the program
memory. This solution extends the reach of \gls{iTasks} and allows closer
resemblance of \glspl{Task} to actual tasks. Moreover, it tries to solve some
integration problems in \gls{IoT} by allowing all components to be programmed
from one source.
