G1 IoT Based AC Controller Unit - shalan/CSCE4301-WiKi GitHub Wiki

G1 Page - IoT Based AC Controller Unit

GitHub repo link: https://github.com/iTankurBank/IoT-Based-AC-Controller-Unit-System. This repo includes the CubeMX file for the F303K8, the F303K8 Keil Vision files, the .INO file for the ESP32 on Arduino IDE, and finally, the .HTML and .CSS files needed to be loaded into the ESP32 through Arduino IDE. Also, the link to our Google Slides presentation (checking the history of it, you will be able to traverse through different milestones).

Hardware Requirements

  • STM32 board (F303K8)
  • ESP32
  • Temp sensor (DS3231)
  • IR Receiver module (Veshay TSOP382)
  • IR Emitter module (TSAL6200)
  • An AC and its remote control (Carrier 42 QH12B-H)

Software Requirements

  • Arduino IDE
  • Web browser
  • Text editor (VSCode/Sublime Text) for HTML/CSS/JS
  • CubeMX
  • Keil uVision

Proposed Hardware Connections

Proposed Hardware Connections

Physical Connections

Physical Connections

General implementation

The main idea is to have a wireless connection from your devices (laptop or phone) to an interface (the web page) where you have control over the most important features a typical Air Conditioning remote has. To turn on/off the AC, change the temperature, and to change between the 4 fan modes. This sending is done by the IR Emitter connected to the microcontroller. To know the required IR codes to be sent, we got them by having a separate design with the IR Receiver, and we'd try out the commands and take note of them to save as constants in our main design/code.

  • Essentially, the ESP32 connects to WiFi (has to be the same as the computer it's connected to whilst programming) and hosts a Web Server with .HTML and .CSS pages loaded into the ESP32. It is connected to the STMF303K8 microcontroller through UART2, and that microcontroller is connected to a temperature sensor, Infrared Receiver, and Infrared Emitter modules.

  • The hosting of the Web Server is handled by the ESPAsyncWebServer library. By checking our repo, more specifically the .INO and .HTML files, you will be able to find how to communicate with this Web Server.

  • By connecting the temperature sensor to the i2C and successfully getting the readings onto the F303K8, HAL_UART_Transmit(huart2...) will send it from the F303K8. On the Arduino side, Serial2.readString() will read from UART2. Whilst sending we added an apostrophe at the end of each temp reading being sent, and we used the Serial2.readStringUntil(') to have the reading done better.

  • On the webserver, there is a control panel (the image is attached) that includes turning on or off the AC, selecting the temperature, and select the fan mode. This value is submitted to the webserver, which sends it to the ESP32, and the ESP32 (Serial2.println...) sends it over to the STMF303K8 microcontroller to know the IR code the IR emitter needs to emit to the AC. IoT - AC Control Panel Note that in the photo the current temperature is "TEMP". This is the default in our code before getting any temperature readings from the STM board.

General Limitations

  • Currently, there is no proper documentation, code-wise, on the IR Receiver and Emitter modules besides a library for Arduino IDE. There is a Russian GitHub repo that roughly translated this library from Arduino to HAL, but that's the only proper coding reference for Keil, we will link it below in our references. For Arduino and coding on the ESP32, the only reference is a library called IRremote (with multiple different versions, the version we used is IRremoteESP8266, also to be linked below). These libraries have further limitations discussed at the end of this section.

  • On that same note of lack of documentation... As expected, there is very little (virtually nothing) to get on in terms of the infrared codes required to control the ACs. This makes sense as manufacturers would want this secret to their own company, probably for security reasons, but that fact made it all the harder to try and know the needed parameters needed to send our specific commands to the AC.

  • This is mostly a COVID-19 limitation (as we are currently in a COVID-19 semester), meeting physically has come with huge difficulty and added anxiety, so our testing is limited to the AC model in one person's house. It also doesn't help that each AC has its own limiting temperature (which would have to affect the slider), and sometimes, even within the same brand of ACs, they would take in different IR codes that communicate with the AC. So, our implementation was only tested on a certain AC Model: Carrier 42QH12B-H.

  • The IR codes for ACs are massive (due to them holding every single bit of data: whether it's on or off, the current fan mode, the current temp mode, etc.). It needs to hold all this data in the IR codes because the remote doesn't get any feedback from the AC, so the AC remote updates the AC of all the values, every time it sends any command. Also, sometimes, the IR codes can sometimes require extra steps, for instance, possibly the remote needs to send twice in a row to the AC for the AC to accept the IR Code. With that in mind, there are two limitations here... Firstly, each AC model has a completely different method of operations (based on the two points we have just discussed in this paragraph), so only a select few models are supported in the libraries we used in our project. If they're not supported, then you'll have to use "raw" data (it's the literal data in the IR code), and there's even less documentation on how to properly send those. Secondly, the commands in that the Russian GitHub repo for the STM board explicitly wrote that sending "raw" IR codes aren't properly working with his repo, so we had to stick to the ESP32 libraries. There is a 20 dollar library (AnalysIR) that includes many tools to work with unsupported AC models in the ESP32 library, but sadly, we cannot personally confirm this (we did not test this due to the pricing constraint), however when researching through forums, this is the main library people were using, apparently.

Potential Complications

  • Do not try to use UART1 on the ESP32. It is not fully supported. The GPIO pins for it aren't properly accessible either, it requires tinkering with the software, but don't attempt it, it's best to stick with UART0 or UART2. UART0 and UART2 are supported and the pins are accessible (highlighted in the datasheet). UART0 is also communicated through the USB, so it helps with debugging onto Arduino IDE's serial monitor.

  • When writing from the ESP to the F303, DO NOT use the Serial2.write, use Serial2.print or Serial2.println (this will just add a \n) to the end of what's being sent). The .write only send bytes at a time through the interface, the .print will send the entire char array straight away.

  • Be careful of the difference between String and string. The "string" library is not supported in Arduino, it's only the "String" library. Yes, they are different. The problem mostly arises when getting commands off of the Web Page (it uses the "string" there). Using the function "toCharArray" ended up helping us here, but it's important to point out that these two libraries are very different.

  • Adequate HTML/CSS/JS knowledge is required to properly code the web page so that things can be properly communicated with the ESP32 that is hosting this web page. Thankfully, we generally did not have this shortcoming, but we suggest visiting w3schools (a website) as that helped bridge the gap between the little of the required knowledge we didn't have.

Final Output

All but the emitting works. We managed to get the IR codes through the IR receiver and got the codes (even made sure by running multiple tests), and the emitter was emitting (pointing your camera towards the emitter will pick up the IR emitting sending the IR codes), but the AC wasn't accepting the emitting IR code.

References