Establishing a Stable Connection between a Mobile App and a Smart Thermostat: Project Story

Building an IoT solution where a mobile app talks to a device always means thinking ahead to ensure they will properly exchange data. For this, a stable app-to-device connection is required. Our team recently built a mobile application that operates a smart thermostat. We interviewed the developers to see what they did to solve the connection problem. 


An air conditioning manufacturer wanted to create a mobile app (iOS, Android) for their connected thermostat. The application would display current temperature settings and allow users to remotely adjust their home temperature. 

Technology-wise, our team had to:

  • Visualize the data from the thermostat sensors, which is collected and analyzed by the server
  • Signal the server to change temperature settings, which can be configured from inside the app 

The client had a system of distributed servers underpinning the thermostat’s logic, which meant heterogeneous sensor data were stored on different servers in a back end cloud.  


Thus, we needed to connect the app to multiple servers and make sense of the heterogeneous sensor data.


The Road Not Taken

We had the option to develop an app and connect it to the back end servers directly. However, this type of connection would have lacked flexibility—any changes in the data or server operation formats would have required changing both the Android and iOS apps on the code level.


Going down this road would not have been the expert route, as the code would have ended up being difficult to maintain and extend.

Andrew, Android Team Lead


What Did We Do?

We added an additional back end layer between the device and the servers that adjusts the connection with the back end.

As the data are homogeneous now, the connection between the app and thermostat is more stable. It is a lot easier to add new features, as we just have to update the back end and the app versions instead of updating both the Android and iOS apps.


Our back end functions as a middleware solution. It collects data from various servers, patterns it, and delivers it to the mobile app in the required format.Konstantin, Back-end Developer

Additional Features

We implemented two energy-saving modes:

  • Away. Users can create a geofence through the app to make sure they’re not heating unused spaces. When they leave a designated area, the system sends a signal to the server, and a command to change the temperature follows.
  • Schedule. This mode allows users to activate the thermostat at particular time intervals.

For these modes we needed to develop several visual components:


Scrolling Component

We needed to implement a custom UI to view weekly temperature schedules. As we didn’t find a ready-made basic scrolling component that helps users to toggle between the days of the week, we had to develop one from scratch.

We decided to create a multi-purpose widget to display any range of days on the screen that the customer required. This allowed us to customize the display settings as we saw fit.

Sergei, Senior Software Engineer

Looking for a development service provider to create a drone-based solution? Check out how Softeq helped SkyFutures develop a solution for UAV inspections that won a Silver Stevie® Award as innovation of the year.

Displaying Inactive Status

We created widgets that showed when Away and Schedule modes were deactivated so users would know what to expect and could plan accordingly.

  1. Our first step was to make it so that users couldn’t interact with the deactivated modes through clicks and taps.

    In the code logic, this simply meant that the system wouldn’t register any input from clicks and taps when the widgets were deactivated.
  2. Next, we needed a visual indication so users would intuitively understand if Away and Schedule modes were activated or deactivated. Deactivated widgets would be greyed out and full color modes would be activated. We had the option of actually changing every widget’s component, but luckily we came across a more efficient solution.

    After an investigation of Android view layer types, we found a hardware acceleration API that allowed us to apply a cosmetic black-white filter to change the color range of the whole widget.

    We found a hardware acceleration API that allowed us to apply a cosmetic black-white filter to change the color range of the whole widget.
  3. As a result, users have a natural way of knowing the status of their app and can better incorporate it into their lives.