## 3 Materials and Methods
### Architecture of the Serverless Cloud Application  
An application was designed for the management and control of smart objects. The application is developed using AWS Lambda and the MQTT protocol to provide flexible interaction between the users and the extractor fan. Amazon Alexa is used to implement a vocal interface for the control of the smart object. State updates are also sent by the fan using the custom commands protocol and are processed by a dedicated Lambda function on the cloud to keep track of the state of each device. The application was developed on AWS, and the serverless platform of choice was Amazon Lambda. Two Lambda functions were implemented in NodeJS (JavaScript) using the AWS SDK: one to forward user commands to devices, either by an application or Alexa skill, and the other to handle state updates from the devices. JavaScript, being a high-level interpreted language, lends itself quite naturally to the development of serverless or FaaS applications and, alongside Python, is one of the most used languages for the development of serverless applications [3]. Lambda functions comprised one or more handlers that are used to manage triggers, which can be received by various outside services, including Amazon Alexa or AWS IoT core. Each handler was defined on the basis of the custom command protocol and of the intents that were implemented in the [PERSON] skill. This way, users are able to control and monitor all the admissible states of the devices. The project uses two AWS storage services: Amazon S3 and Amazon DynamoDB. DynamoDB is used to store devices states and devices and user identifiers. Similarly to the approach used in [61] to store Lambda code, in this project, Amazon S3 is used to store the device firmware. This way, each device can download any firmware version at any moment, greatly simplifying software updates and the deployment of new code. A software update can be initiated by sending the url of the S3 bucket containing the new firmware inside an MQTT command. The device will then download the file from the S3 bucket and execute the firmware update in autonomy. An Alexa skill has been developed to interact with the devices. The endpoint of the skill is Amazon Lambda. A Lambda function is triggered when a command is invoked by the user. The Alexa skill takes care of translating input vocal commands into text and then translates text into JSON inputs that can be parsed by Lambda functions. Each JSON input produced by the Alexa skill also contains a user identifier that is used by Lambda to retrieve (from DynamoDB) the device ID associated with the user that invoked the skill. This mechanism guarantees that Lambda functions are only able to control the fans corresponding to the user that invoked the Alexa skill from their personal account. Custom slots are used to define a series of extra identifiers to distinguish between different fans when a user owns or controls more than a single fan. Figure 3 illustrates the message flow of the application. Green boxes indicate vocal commands and responses, yellow boxes are messages in JSON format generated by the Alexa skill, and the pink box indicates the payload of the MQTT message generated by the AWS application and forwarded to the device. The complete description of the smart appliance system is illustrated in Figure 4. When a user invokes the Alexa skill with a valid intent, i.e., an Alexa skill intent for which a handler was defined, the skill triggers Lambda and passes a JSON message to it, containing both the UserID and a string identifying the handler required to manage that request. The Lambda function queries DynamoDB for the identifier(s) of the device(s) owned by that user. If the user owns more than one device, then a custom slot in the Alexa intent is used to distinguish between their multiple devices and retrieve the correct identifier from DynamoDB.