# IoT Helper: A Lightweight and Extensible Framework for Fast-Prototyping IoT Architectures
## 3 System Architecture
The basic operations executed on the inputs and output are as follows: (a) read an input value as the state of a sensor or actuator and (b) change the value of an output, i.e., execute an action on an actuator. **Generic Firmware** executes such operations. It implements the following commands:  
* **Read**--_read values of inputs \(I_{0}\dots I_{n}\)._ For example, read temperature and humidity values from the respective sensors. * **RepeatRead**--_read of inputs \(I_{0}\dots I_{n}\) each \(n\) milliseconds_. This is useful when we need continuous read operations with a fixed frequency. This command accepts a parameter \(t\) representing time in milliseconds. This command is used to regularly collect data from the Embedded System and allows one to minimize the number of requests sent to the system. * **Write**--_change values of output \(O_{0}\) to \(v_{0},\dots O_{n}\) to \(v_{n}\)_. For example, switch the LED on and set the speed of the fan to four. * **TimedWrite**--_change values of outputs after a fixed delay_. For example, switch off the fan in two hours. The overall flow-chart of Generic Firmware is shown in Figure 2. When the system starts, the Generic Firmware runs some initialization operations: (1) it reads the configuration file, (2) it configures input and output pins, (3) it starts the WiFi connection, (4) it initializes the connection with the Message Broker and (5) it starts a timer for timed commands. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Type** & **Typology** & **Name** & **Description** & **Pin** & **Values** \\ \hline Input & Digital & \(I1\) & Temperature Sensor & 1 & \\ \hline Output & Digital & \(O1\) & Initialization Complete LED & 10 & \{0,1\} \\ \hline Output & Analog & \(O2\) & Fan Speed & 12 & \{0–6\} \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Configuration example. \(I1\) is a digital sensor, \(O1\) is a digital actuator and \(O2\) is an analog actuator. Figure 2: Generic firmware flowchart. After initialization, Generic Firmware waits for commands and executes them. Each command is received as a request message and generates a response, as discussed in Section 3.1. Generic Firmware is developed in a C dialect and is released as open source. It is important to emphasize that the Firmware is designed to be completely generic, i.e., it is agnostic of the specific sensors and actuators and can be configured to work with any of these. Indeed, all application-specific logic is coded within the configuration and, of course, in client applications. Client apps, either Web or mobile, embed all custom logic and translate input and output values into the specific scenario. This has several advantages: it makes it easy and relatively inexpensive to turn non-embedded devices and machinery into IoT-enabled systems. At the same time, it enables quick prototyping of an end-to-end solution. In fact, in the early stages, the client app can be simulated by using generic clients, thus allowing users to easily test messages. Then, at later stages, once tests have been completed and a decision to consolidate the solution has been made, real client apps can be developed using high-level programming languages and platforms, such as, for example, Java in decoupled manner from the embedded system. In Section 3.2, we discuss the support library provided as part of the IoT Helper framework to simplify the development of client apps. The final model we discuss is the **Message Broker**. It handles the exchange of messages among client apps and the Embedded System, according to the formats described in Section 3.1. Several communication models can be used to connect nodes in a distributed environment. A simple one consists of a _point-to-point_ approach, where the Embedded System directly communicates with every external system. This model, however, presents several limitations that might have a negative impact on the overall performance of the architecture.