Proof of concept (POC) projects are parts of our internal learning processes. During these, we implement tasks formulated on the basis of real business needs with slightly simplified requirements. In one of our most recent such projects, the participants connected learning about AWS services with the development of IoT systems. This is how an RFID card based electronic access control system and a temperature sensor monitoring system were implemented.
The post is more technical in nature, but it can also be useful for business people, as they can see how quickly and cheaply a complex system can be created in the cloud.
In our blog article, our development colleagues Bence Murányi and Erik Hajnal summarized their project, they also write about the results achieved, experiences, and the services used, so that those less familiar with these do not have to read up.
The task
Connected to the AWS IoT module, we want to transmit the events detected by the connected RFID card reader from an ESP8266 device to the control logic. There, based on whether it is an authorized card recorded in the database, we allow or prohibit the opening of the door. We store the entries in a database on AWS, which we also display in tabular form on an interface. Furthermore, on this interface, we enable the scanning device to be switched on and off.
The other function is to send the data of a temperature sensor device to the database, and to display the measurement data on a graph on the same interface. The interface is public on the Internet, but protected by authentication, so authorized persons can access and use it from anywhere.
Implementation
With the exception of the card reader, the system was implemented entirely using AWS services. Our devices (in the task, the temperature sensor ESP32 module and the ESP8266 connected to the RC522-MFRC card reader) are connected to the other services by the AWS IoT core module. Topics defined here based on the MQTT protocol ensure two-way communication. During the implementation, the goal was to not have to maintain a separate server, but to be able to implement all necessary tasks with serverless services.
Used AWS services
AWS IoT
The AWS IoT Core module provides two-way communication between the two devices and other AWS services. Communication is based on defining MQTT topics and sending and receiving messages in JSON format through them. Triggers for the processing of incoming messages are provided by message routing rules. As a result of the rules, it writes directly to the database when, for example, a card scanning event occurs, or when a Lambda is started in the case of a more complex process.
DynamoDB
The database behind the system was placed in DynamoDB. The card identifiers that are allowed in are stored here, as well as the accesses, device status and temperature sensor data in separate tables.
A relational database would be more suitable for a tabular, scrollable display, and DynamoDB was chosen mainly because of keeping POC costs low.
AWS S3
Amazon S3 is an AWS storage solution that also supports the hosting of static websites.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html
This solution is advantageous because we do not need a dedicated server to publish the administrative interface. S3, on the other hand, only provides access via the HTTP protocol, for HTTPS we also need CloudFront. The solution is to upload the already built frontend project to an S3 bucket and host it from there.
CloudFront
CloudFront is a CDN (Content Delivery Network) service. When connected in front of S3, the interface can be accessed via a separate URL dedicated to CloudFront, thus support for the HTTPS protocol is also ensured.
Cognito
Cognito is responsible for authentication and authorization. The interface is available to pre-registered users in the user pool stored in Cognito. The frontend requests the JWT tokens via the OATH2 provider provided by Cognito. You use these to check accessibility, and use them to call the API endpoints to which Cognito’s authorizer is also connected, so access to them is only available to logged-in users.
We can solve the administration of authentication in Cognito, you can only enter the interface with a pre-specified email address. When logging in for the first time, you can access the interface with a generated password, and after successful login, enter a new password. From now on, the password provided by the user will be valid.
Lambda
Lambdas are used in several places in the implementation. A Lambda is connected behind the API Gateway endpoints serving the frontend, which communicate with the database and also with the devices by sending messages with IoT topics. Message routing rule triggers from the devices during card reading also start a lambda. The logic here is that, based on the state of the database, it must be checked whether the given device is switched on, whether the card is authorized to enter, and accordingly a response message must be sent back regarding whether the door can be opened.
API Gateway
The API endpoints are offered with the AWS API Gateway service, we used the REST API type for implementation. The cognito authorizer is connected behind each endpoint. In this way, they are protected from unauthorized calls, and at some endpoints (e.g. for list queries for entry events [GET /employees/events]) the proxy integration switch is turned on, which is necessary because we also need data from the request in the processing lambda there is In the case of the previously mentioned endpoint, for example, the limit and offset attributes used for paging are passed as query parameters.
Card reader and temperature sensor
On the side of IoT devices, we used two controllers:
an ESP8266 microcontroller and a connected RC522-MFRC RFID reader are responsible for the access control system.
To generate the temperature sensor data, we use the built-in temperature sensor of the ESP32 module. Both devices connect to the AWS IoT module and communicate with messages using the MQTT protocol.
In terms of their operation, the Arduino framework runs on both, the boards used were the following:
ESP8266: Generic ESP8266 Module
ESP32: DOIT ESP32 DEVKIT V1
Some preliminary settings in the Arduino IDE are required for development. These are detailed below.
The board managers must include:
https://arduino.esp8266.com/stable/package_esp8266com_index.json
https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json
The libs used and to be installed:
- MQTT (2.5.1)
- PubSubClient (2.8)
- MFRC522 (1.4.10)
- ArduinoJson (6.21.3)
- TaskScheduler (3.7.0)
We used the ApexCharts tool to display the temperature data. The last maximum 100 measured values are displayed on a graph with adjustable scaling.
A few pictures of use
After logging in to the administrator interface, you can view previous logins:
Entry with authorized card:
Belépés visszautasítása:
The temperature data can also be viewed on the administrator interface:
Sensor log:
If we want to add a new device to the system, it must be added to the IoT Core interface in the management console under the Things menu item, and in the device-side code we must also ensure that it connects to the AWS IoT service using the generated certificates (the generated certificates are must be included in Secrets.h).
In Secrets.h, the data required for WIFI connection can also be set in the WIFI_SSID and WIFI_PASSWORD variables.
Summarizing the POC, it can be seen that certain more complex systems can be implemented relatively cheaply and quickly if we also use the cloud provider’s own services. These POC projects are also good so that if someone is just getting to know the cloud in their organization, they try them out, if they like it and it works, they put it into action, if not, they simply close the account. In the latter case, an unnecessarily acquired server will not be sitting on the shelf, but an AWS account that only ran for the duration of the test (in addition, for free due to the Free Tier, or partially free in the case of certain paid services).