How to make a home thermostat ‘smart’

How to make a home thermostat ‘smart’

Technology News |
By Rich Pell

This means that many manufacturers of control devices such as thermostats are now embracing the challenge of turning a conventional ‘dumb’ product into a smart, connected product (see figure 1). Adding connectivity entails the use of a standard RF technology such as Wi-Fi or Bluetooth Low Energy communication.

Of course, embedded device designers have no shortage of Wi-Fi and Bluetooth transceivers or modules to choose from, supplied by a wide range of semiconductor vendors. RF IC manufacturers also provide ready-made and free communications protocol stacks for Wi-Fi, Bluetooth and internet connectivity.

And if a thermostat design needs to be made ‘smarter’, microcontroller manufacturers always provide a migration path to upgrade the processing power, addressable memory and peripheral feature set of an existing thermostat’s MCU.

From a purely hardware point of view, then, the modification of an existing design to become a smart, connected product appears to be readily supported by a vibrant commercial off-the-shelf IC market. The real question for the embedded developer, however, is over the best way to combine the hardware, firmware and application software necessary to meet user expectations for functionality, and to provide for interoperability with platforms such as Apple’s HomeKit or Google’s Works with Nest technologies.

In reality, there is a great deal more to the realization of a successful smart thermostat design than wireless connectivity: the development of software will occupy the biggest part of the design team’s time. This is why the use of a fully integrated hardware/software development platform helps engineers to greatly reduce the time and difficulties involved in implementing new smart home device designs. This article describes the elements and operation of one such platform.

Fig. 1: next-generation home thermostats will support multiple one- and two-way communications interfaces.

Protocols supporting operation of connected devices
To support the types of remote- and voice-control functions and smart automation features available with platforms such as HomeKit or Works with Nest, a thermostat requires an internet connection, normally provided via a gateway such as a Wi-Fi router.

The device will also need to support application protocols such as HTTP, SMTP, NTP and MQTT to provide for communication with web and application servers over the internet. At the application layer, the thermostat may also run specific software elements such as Apple’s Homekit Accessory Protocol (HAP).

Security is an essential requirement for connected devices, to maintain user privacy and to protect against intrusion into the home network. Secure transactions and message exchanges between the device and the cloud may be made over Secure Sockets Layer (SSL) with Transport Layer Security (TLS) 1.2 or other secure protocols.

Underlying the complex operations of the application layer, the security layer and the communications layer, the system architecture will require an operating system (OS) to handle prioritization and memory allocation. In a resource-constrained device such as a thermostat, this will be a real-time OS with a tiny memory footprint.

Here, then, is the challenge for the thermostat designer: not only to provide for a robust Wi-Fi connection to a router, as well as in some cases a Bluetooth Low Energy connection to devices such as wireless sensors, but also to implement multiple protocols and the application software in an environment requiring rock-solid interoperability with third-party internet-connected devices and services.

It is a development task of considerable proportions and with many potentially unfamiliar technical difficulties to be mastered. It is for this reason that WICED, the Wireless Internet Connectivity for Embedded Devices technology from Cypress, was developed.

Unified platform for hardware and software development
The function of WICED is to provide a unified platform for the development of internet-connected devices that use Wi-Fi, Bluetooth or ZigBee communications. What does unified mean here? The WICED platform includes fully interoperable hardware and software elements, and is comprised of:

  • Cypress RF ICs and modules, some with an on-board MCU, providing connectivity via Wi-Fi, Wi-Fi + Bluetooth, Bluetooth + Bluetooth Low Energy, or Bluetooth + ZigBee.
  • A comprehensive software architecture providing for connectivity, security and applications (see Figure 2).
  • Native support for the ThreadX, NuttX and FreeRTOS RTOSs. Developers may also port other RTOSs to the WICED platform. ThreadX is distributed as sharable binaries within WICED with no royalties.
  • Native support for the NetX, NetXDuo and LwIP network stacks. Other TCP/IP stacks may easily be ported to WICED. NetX and NetXDuo are distributed as sharable binaries within WICED with no royalties.
  • A complete Software Development Kit (SDK) built on top of the open-source Eclipse Integrated Development Environment (IDE), enabling developers to use all the features provided in Eclipse for developing and debugging applications based on the Cypress RF products.
  • Arduino-compatible development baseboards to which users can connect sensor shields and other peripheral devices.
  • Reference designs provided by third-party WICED development partners.
  • Application example code demonstrating the implementation of all the commonly used communications, networking and application protocols.
  • Sample applications for communication with cloud-service providers such as Amazon Web Services, Microsoft’s Azure® and IBM’s Bluemix®.
  • A fail-safe process for Over-The-Air (OTA) updates.
  • Full documentation for APIs and the sample applications.
Fig. 2: the WICED software architecture.

All of the elements are rigorously tested and verified, so that users can be sure that, for instance, the WICED HAP code will function perfectly when running within a ThreadX software environment on a CYW43907, a Wi-Fi IC which includes an ARM Cortex-R4 core.

The WICED platform supports various hardware architectures, giving users the choice of whether to implement WICED in a dedicated module with on-board MCU, in a fully integrated RF microcontroller, or in an external host processor (see figure 3). Microcontrollers supported by the SDK include:

  • Cypress FM4 series
  • STMicroelectronics STM32F2 and STM32F4 series
  • Microchip AT91SAM4S16B
  • NXP Semiconductors Kinetis K61 and LPC17xx, LPC18xx series
Fig. 3: the hardware architectures supported by the WICED platform.

Smart thermostat: the WICED development process
A good starting point would be to connect a temperature sensor, relay and WICED module together. Figure 4 shows a set-up consisting of a temperature sensor with an I2C interface connected to the CYW43907AEVAL1F, an evaluation board featuring the Murata LBWA1UZ1GC-958 module based on the CYW43907 Wi-Fi system-on-chip, together with a small display to show the system status and temperature.

The driver written for the temperature sensor can be placed in the libraries folder of the WICED SDK, allowing other applications to use it. This same folder also contains the display driver supported in the SDK.

Fig. 4: initial hardware configuration for a new smart thermostat design project.

The snippet application folder includes a sample application showing how to use the I2C protocol to read the temperature sensor’s value. Basic API calls may then be used to read the room temperature.

The I/Os may be configured in the platform files. The platform.c file includes all the pin-out mappings and their respective configurations. When configuring the I2C pins, it is necessary to verify:

  • the I2C port to which the temperature sensor is connected
  • the SDA and SCL pins
  • the driver to be used

Another application code snippet integrates a 128px x 128px display into the design. By combining the two applications, it is possible to read the temperature of the room over the I2C interface and to show the value on the display.

To write this application, the flow is:

  1. Initialize WICED
  2. Initialize the I2C device
  3. Initialize the display
  4. Read the I2C value from the temperature sensor
  5. Via SPI or I2C, show the value on the mini display

Thus far, the system is simply implementing basic, dumb thermometer functions. The next step is to add intelligence: for instance, to compare the desired temperature to the present temperature and, if the room temperature is lower than the desired temperature, to switch on the heating via the relay.

After this, the developer will want to enable the thermometer to connect to a Wi-Fi network in range. Initializing the network stack offers the user a choice of operating modes:

  • STA interface – station-based, in which the thermostat is a client
  • Soft AP – in which the thermostat hosts a webserver
  • SoftAP and STA – known as APSTA mode, here the thermostat can operate in both server and client modes

APSTA is available in the WICED SDK as a sample application snippet. This means that the thermostat can host a webserver and allow other clients to connect to it; at the same time, as a client it can connect to the home access point for connection to the internet.

The WICED SDK makes it easy for the developer to host an http server on the thermostat to expose REST API calls to GET or POST the desired temperature. This powerful feature makes the thermostat accessible to other devices on the network.

For instance, a small peer application on a mobile device can be written to enable it to set the temperature using a sample POST request which would look something like this:

The app can also ask the thermostat to tell the mobile device which temperature it is currently set to, with a GET request such as:

The html page developed to host a webserver is placed under the resources folder along with the required javascript, css and image files. This needs to be included in the application Make Target as a resource object, allowing the server to render and display it when any client connects to the device.

There are two mechanisms for connecting the thermostat to a desired access point:

  • feed the SSID and password of the access point into the configuration file
  • ask any client such as a mobile phone connected to the softAP hosted by the thermostat to allow the user to enter the password for the chosen access point. The thermostat subsequently reboots and stores the access point credentials in a device configuration table.
  • The WICED SDK also provides for the option of WPS security for registering a new device to an access point.

Once connected to the internet, the thermostat can begin uploading temperature values to a cloud data service.

Of course, an internet connection opens the thermostat to incoming flows of data as well, such as weather reports, firmware updates, and the time and date via the NTP protocol. WICED also supports the SMTP protocol, which allows the user to configure an email account for sending notifications to the user’s email address.

SDK accelerates system development
The WICED hardware – the radios and RF microcontrollers available from Cypress – is the fundamental building block of a smart connected device. But as this example of a smart thermostat shows, the extra value of the WICED platform is in the integration of a complete software architecture supported by an SDK, and backed by an Eclipse IDE and a very wide range of application software examples.

It is this combination of hardware, software, examples and tools which makes development of smart devices much quicker and much easier than before.

About the author:
Vikram Ramanna is Senior Staff Applications Engineer at Cypress –

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News


Linked Articles