# IoT Lab 3 Report

### Members
**Guo Ziniu 1004890
Meng Fanyi 1004889
Wang Zhuoran 1004867
Wang Shiyu 1004874**

### 1. Analyze working procedures (S3, Lambda, ESP together)
- UML
- Explaination
- The structure of aws_iot_demo_main() is similar to lab2
- Initialization of MQTT
- Establish a connection with the broker is exactly the same as Lab2.
- Enter subscribePublishLoop
- Inside the loop:
- Subscribe to "esp32/sub/url" (to get the presigned url)
- Subscribe to "esp32/pub/data" (to get the result of text recognition)
- Then we will enter a while loop to wait for button press
- **Once the button is pressed, Set buttonTrigger = True**
- **Call requestUrl(), send "url please" to the topic "esp32/sub/url"**.
- The broker will forward the message back since we have subscribed to the topic. The **callback function(handleIncomingPublish())** will be invoked, extract the payload and display some log info about the MQTT packet (payload for this packet is "url please")
- At the same time, one of the lambda funtcions will be triggered. It will **call s3.generate_presigned_url() to get the url** and craft a MQTT packet **(contains the filename and the presigned url)** and publish to the topic "esp32/sub/url".
- Again, the broker will forward the message to the subscriber(esp32). The callback function will be invoke, extract the payload to get the filename and url, and also display the log info.
- Once we have the url, we will call **upload_image_to_s3()** to upload the image we have captured and **set urlTrigger=True**
- Since urlTrigger is set as True, we will call **requestPicRecog() and send the filename extracted from the packet above to the topic "esp32/pub/data"**.
- Similarly, the broker will forward the message back and the callback function will be invoked, extract the payload and display some log info about the MQTT packet (payload for this packet is filename like "************.jpg")
- The other lambda function will be triggered, **it will find the image according to the filename in the payload and do text recognition on it.** Once the recoginition is done, **the lambda function will send the result back to the broker**(craft a MQTT packet whose payload is the result of text recognition).
- The broker will forward the message to the subscriber(esp32), the callback function will be invoked and **extract the result of text recoginition** from the packet, and an extra check will be done:
- **if "on" occurs in the result, esp32 will call turnOnLight()**
- **if "off" occurs in the result, esp32 will call turnOffLight()**

### 2. Demonstration
video 1: [Camera captures "turn on" text and turn on the camera.](https://drive.google.com/file/d/1iyTftbzJ5p7rhvagvlHdlTwW4IKXjQkZ/view?usp=drive_link)
video 2: [Upload a picture to S3, request a recognition in MQTT Client, and get the results](https://drive.google.com/file/d/1OT0S93s6R0bC_gp_scK2SMfaUyDQHNpz/view?usp=drive_link)

### 3. Problem encountered
In the third part of our project, we encountered an issue. Each time after the initial startup, the first recognition attempt was always successful, whether it was a "turn on" signal or a "turn off" signal. However, when we made changes for the second time, the device would crash and restart directly, with the error likely related to the C/C++ heap.

Initially, we thought it might be due to high image quality, but even after reducing the quality, the problem persisted. Then, we suspected an error in the code's business logic (such as entering an incorrect if condition or failing to publish data to the pub/data), but upon careful inspection, we found that the code was executing correctly. We also considered the possibility of memory not being freed, but after a thorough examination of the code, we found no issues. (Sorry we forot to take the screenshot of "idf.py monitor")

However, we tried another day. This time we did not encounter the problem mentioned above, we can turn on and turn off the light in one session without any error. Therefore, we concluded that the problem is not caused by the code itself, it may be caused by some external factors such as network condition given that the former was done in the afternoon and the latter one was condacted at night. (Probabily due to SUTD Wi-Fi is more stable at night time)