What is ShAir?

How many times have you had a disagreement with your coworkers about the air conditioner?
How many times did a signle person turn off the air conditioner for the entire lecture because he felt too cold?

The idiology behind our idea is democratic air conditioning - Every person in the room has a vote, every vote is equal, and the system decides the optimal temperature of the air conditioner based on the votes everyone cast, and the real temperature in the room.
Our solution is simple - an arduino device will be placed in each classroom/office/etc. and will be configured to work with the room's air conditioners.
Every person entering the room who has the ShAir mobile application, will be able to locate the bluetooth beacon connected to the device, allowing the user to register and vote on the room temperature.
Meanwhile, the arduino device will constantly query the server, checking if it needs to transmit a new command to the air conditioners - and if it does, will transmit the IR codes and change the temperature of the room!
The approach we took allows easy integration with existing air conditioners - installing the device is simple, only requires putting it in the room and configuring it through the administration site. No need to replace existing air conditioners or infrastructure.

Our project consists of three parts:

  • The Arduino device - measuring the temperature, sending telemetry and querying the server for instructions and sending the IR codes to control the AC. The device also has a bluetooth beacon assigned to it - which allows nearby users to locate and recognize it.
  • The Android app - detects the nearby bluetooth beacons, allowing the user to choose his classroom. When connected, allows viewing current air conditioner votes, real temperature, and for the user to vote on his own desired temperature.
  • The Server - Contains a database with all active devices, all user votes and to which device they belong, all the known air conditioners and how to operate them. The server decides for each device, upon request, which signal to transmit to the air conditioners, and communicates with the android app by handling requests and sending data.

Operation Scheme

The ESP8266 Adaruit HUZZAH Feather

At the Feather HUZZAH's heart is an ESP8266 WiFi microcontroller clocked at 80 MHz and at 3.3V logic. This microcontroller contains a Tensilica chip core as well as a full WiFi stack. You can program the microcontroller using the Arduino IDE for an easy-to-run Internet of Things core.


IR radiation is radiation in frequencies outside the visible spectrum. IR is transmitted by all bodies that radiate heat. When you use any IR remote, for example a TV remote, an IR LED is used to transmit information to your TV by modulating the information on a frequency in the IR spectrum, and sending it to the TV IR receiver.

A common modulation scheme for IR communication is something called 38kHz modulation. There are very few natural sources that have the regularity of a 38kHz signal, so an IR transmitter sending data at that frequency would stand out among the ambient IR. 38kHz modulated IR data is the most common, but other frequencies can be used.

When you hit a key on your remote, the transmitting IR LED will blink very quickly for a fraction of a second, transmitting encoded data to your appliance:

By controlling the spacing between the transmitted modulated signals, the waveform can be read by an input pin on a microcontroller and decoded as a serial bit stream.

By controlling the spacing between the transmitted modulated signals, the waveform can be read by an input pin on a microcontroller and decoded as a serial bit stream.

How air conditioners remotes work

Unlike TV remotes, which have a signal for each button, and maybe a "repeat" signal for long presses, AC's remotes hold state - for example, when pressing + on the fan speed, not only the button id is transmitted, but also the fact that the AC is on, whether it's in cooling or heating mode, fan speed, temperature, whether the swing is on or off, etc.

Therefore, it's not enough to record every button on the remote once- you either need to record all the possible combinations that you will want to transmit, or you will need to understand how the remote passes information and construct the signal yourself.

Our board

The temperature module, TMP_102 was connected according to it's manual specifications: to the SDA anc SCL connectors of the board.
The LED was connected to pin #16.

Writing the code

The arduino code consists of a few seperated modules:

  • http_handler - This part is in charge of connecting to the WIFI network, and communicating with the server.
  • IR_handler - This part handles the IR communication - transmitting the code the server sends back.
  • TemperatureHandler - This part is in charge of cummunicating with the temperature module and extracring the temperature

The following open source libraries were used while writing the code:

Each device stores it's own unique 'device key' which is a secret used to identify the device when communicating with the cloud, and used by the device admin to configure the device in the cloud(Location name, which AC it's connected to, etc.)
The IR codes are recorded separately and stored into the server database, so the end user device doesn't need to do that- only needs to choose the air conditioner model the device will use and nothing needs to change on the device itself - this is why the server sends the IR codes and they aren't stored locally on the device.

Android app documentation

Data managment

The application uses SharedPreferences for saving details about the state and the current connection, allowing us to save the session for fragments interaction. SharedPreferences are simply sets of data values that are stored persistently, which means data you stored in the SharedPreferences persists even if you stop the application or turn off the device.

API Interacion

The application interacts with REST API server on the cloud. The REST API exposes functions to connect and disconnect from the device, vote for desired temperature, get current room temperature, and get the location name of a device. The app sends HTTP requests encoded in json and updates the UI according to the response. Almost all the functions use POST request, for security purposes.


The application using open sources libraries:

For beautiful UI:

For bluetooth scanning:

For parsing JSON:

UI structure

The main activity manages three fragments:
  • About
  • Devices
  • Temperature

About fragment

Shows general information about the app, and links to the adminstrator site for device configuration: http://shairmanager.azurewebsites.net/

Devices fragment

The devices fragment scans for nearby bluetooth devices that applicable to ShAir(filtered by device name). The user can then view the location of the device(class name, organization, etc.) to decide which bluetooth device he wants to connect to, and consequently which AC he will vote on.

Temperatre fragment

After the user connected to the device, on the temperature fragment, he can view details like the current temperature and vote for his desirted temperature.

Using the slider the user may choose his desired temperature and it sends request when pressing the SET button.
At each stage the user can refresh to get the most recent temperature, or disconnect the device using the top appbar menu.
Automatic refresh is performed every minute on this fragment. Behind the Scenes, all the function interact with the API server on the cloud.


Our Climate Controller uses Azure's cloud resources as a way to proccess and pass information between users and Arduino devices. 

The technologies which we have used for building projects server side are:

• Azure App Service - runs our Climate Control server.
• Azure Sql Database and Server - hosts the project's DB.  
• Spring - Java framework which enbales the createion of Restful API's, supports SQL server and Multithreading.

Server Flow

After configuring a new Climate Control device the arduino sends the server information about the tempature at a specific location where it was configured. When the server recieves this information it sends back the IR codes which the arduino needs to transmit in order tho change the rooms temperature.
While Arduino devices are transmiting information users can connect to our Climate Control server, get the real tempature and place their own vote to affect the overall rooms temperature.

Security Features

All data passed to or from server is encrypted as it uses HTTPS (Azure configuration). Sql injection is prevented by the use of prepared statements with variable binding. Moreover, Azure Sql Server Firewall rejects all connections to the server and the databases except for connections from other Azure services.

Server Database

Our project uses Microsoft Sql Server which is a relational database management system.

Our DB structure:

  • •AC code table – Contains the codes and details for each ShAir configured AC.
  • •Device AC table – Contains the relations between devices and the AC’s they control.
  • •Location table – Contains all device/mac locations as configured by the device admin.
  • •Temperature table – Contains all temperature measurements for each device and the the measuring time.
  • •User table – Contains all the users connected to the ShAir Server and their temperature requests.

Server Endpoints

Gets all the AC’s configured supported by ShAir

Configures the device location and connected AC’S

Receives device data, processes it and send back users requests and AC codes

Connects a new user to ShAir Server and sends in response users location data

Handles users change temperature request

Sends user his current location by BT device ID

Send user temperature and location data

Enables user to disconnect from ShAir Server

Challanges We Faced During Development

We had to research how AC codes work, and how to construct and transmit them. As mentioned earlier, AC IR codes consist the entire state of the AC, making them more difficult to construct than simpler codes such as remote control of a TV.
Once we understood that, we had an issue with transmitting a code identical to the original AC remote. After many attempts of tackling the problem we figured out that the script we were using for recording wasn't build to handle ACs, and found a different skeleton that does.
Finally, we had decide where to store the AC codes and how to construct them. We decided on storing them on the server side and sending them back to the device on demand. This allows much easier customization - replacing the AC requires no code changes on the device, and we can change how we construct the code on the server side without any issue.
We've had multiple issues handling the server JSON responses in the arduino code, especially with the nested array.
The ArduinoJson library was overall a good solution, but finding the correct way to handle nested arrays was a challange of it's own, especially since our JSON is relatively long, and the buffer size we assigned to it was too small, which resulted in no errors but an empty results.
Once we figured that out, and found the as<JsonArray> method things went smoothly.
Getting the TI CC2650 board to work was no easy task. Trying to work our way through the official site, multiple possible IDEs, and no good examples was a tough effort.
To make it work we ended up using the guide in exercise 1 of the 2016 IOT course. Using the versions and tools mentioned there we managed to install "Project 0" on the board and making it work the way we needed.

About Us

This project was submitted by Daniel S., Inbal M. and Arthur V.
At the time of submission we are third year students in Tel Aviv Unitersity, studying for BsC in Computer Science.
September 4th, 2018.