No matter how many customers I talk to, I am still pleasantly surprised at the interesting products they develop and equally surprised at the creative ways that they incorporate InfluxData components into their solutions! One example of such creativity is with the product that our home automation customer, tado°, has built. tado° offers a Smart thermostat solution that anticipates your arrival to ensure a perfect home temperature that is considerate of the environment and your wallet. Not only does their product make the consumer efficient in energy consumption, but their approach to gathering the right metrics and events and serving the information up into their smartphone application is equally as efficient. This efficiency came at a bit of a cost as they did have to work at making the InfluxQL support their application, and the good news is that their work paid off in not only making their queries work, but they were able to gain a 200x speed increase in the queries that use the LAST() queries.

Read on to see what this journey looked like for our friends at tado°.

Background

tado° is a company based in Munich, Germany that has changed the way that energy is consumed at the home with the introduction of their Smart AC Control and Smart Thermostats. The company name, tado°, is a play on the Japanese word, “Tadaima” (ただいま) which is a greeting that you say when you return home. The person at home then recognizes your arrival and responds with “O kaeri nasai” (お帰りなさい). This friendly interaction is the core of how the tado° product works. Through the use of a geo-aware app, tado° automatically adjusts the temperature based on the residents’ locations, enabling households to save significantly on energy costs while reaching a higher level of comfort.

To support this interaction, the user needs to have a tado° Smart thermostat tied to the tado° smartphone app downloaded on the mobile phone of each resident. The user sets the temperature thresholds (at home, away, at home sleep time, etc.) and the  tado° Smart system collects the actual room temperatures and compares this with the threshold and the location of each of the residents. If all residents are away, then the temperature self-adjusts to the away temperature. And once a resident approaches their home, the system will adjust the temperature according to the set thresholds, so when the resident is finally home, the temperature is at the assigned level—no waiting required!

What Gets Collected & Used

So here is the base set of data that needs to be collected to support the automatic temperature adjustments and the user reports (graphs) in the smartphone app:

  • Household temperature thresholds
  • Each residents’ geo-location to determine home or away state/li>
  • Temperature of the home (we will assume only 1 zone)

Seems simple, right? So let me introduce the challenges and the solution that tado° articulated in their webinar:

  • The thermostats are battery-operated, and since they use rf to communicate to the gateway, which can easily drain the battery, they limit the inside temperature transmission frequency to every few seconds.
  • The devices only report inside temperature changes of >0.1° which could take a fairly long period of time to trigger.
  • User report requirements:
    • Peak request rate of 10 requests/sec (most of the requests are for the data of the current day)
    • Require a 500ms response time for these reports
    • 12 month retention of the data

What time series do tado° gather for the user report?

    • Continuous Data – Inside temperatures – these are continuously changing values and are plotted at 15-minute intervals on the user reports. For example:
      • 0:00: 64.5°
      • 0:15: 64.1°
      • 0:30: 63.9°
    • Discrete states – Home vs. Away – this doesn’t change often and the exact time the state change occurs is important. For example:
      • 0:00 – 7:43 – at home
      • 7:43 – 16:13 – away
      • 16:13 – 0:00 – at home
  • User Report Schema – where each unique customer has a homeID
    • Measurement: home
    • Tag: homeID
    • Fields: insideTemperature, tadoMode
    • Retention: 12 months

So here is the InfluxDB query for the inside temperature for the entire day (May 15, 2017). You can see that they are looking for the inside temperature for a customer with the ID of 42 for a 24-hour period and grouped by 15-minute intervals.

SELECT insideTemperature

FROM home

>WHERE “homeID” = ‘42’

   AND time => “2017-05-15T02:00:00.000Z” AND time < “2017-05-16T02:00:00.000Z”

GROUP BY time(900s) FILL(previous)

Since they offer a consumer service, they need to make sure they pull data that fits the customer’s time zone and not show data in UTC, and therefore the time used in the above query is set to 2am UTC.

In addition, there may be instances where the value at the start of the query interval is empty so they need to create an additional query to determine what the last temperature was and use it at the start of the query period. As you can see in the picture below, the first two intervals of the query are empty; however, you can use the last temperature taken prior to that period at 01:42 since temperatures are only recorded if there was a change from the prior time.

time interval

SELECT LAST(insideTemperature)

FROM home

WHERE “homeID” = ‘42’

AND time => “2017-01-03T11:52:13.354Z” AND time < “2017-05-15T02:00:00.000Z”

In the above query, they set the lower bound to the account creation date since they know there are no measurements taken before that, and the upper bound is set to the start of the query.

They use a similar set of queries to pull the data that helps the application know whether the customer is in home or away mode. This data is used to set the correct temperature of the home, and is also used to generate the reports in their smartphone app, and therefore it is important for tado° that the queries are performant.

Next Steps

I encourage you to watch the webinar where the team at tado° go into even more detail on their experiences with InfluxData, these queries and some other optimizations that help keep their application working smoothly. They also go over some challenges that they faced and how they were able to overcome them. In addition, there is a written case study where they review their data architecture as well as the journey they took from creating a MySQL prototype to building a production ready solution that supports over 100,000 customers using InfluxData.

tado° case studytado° webinartado° overview

Get your InfluxDB hoodie while they last!

Does your company have a cool app or product that uses InfluxData in production? We’d love to feature it on influxdata.com and give you a shout out on social media. As a “thank you” gift, we’ll send you an InfluxData hoodie and a pack of stickers. Just fill out this simple form and we’ll let you know when your entry is live and the hoodie is in the mail. Drop us a line at contact@influxdb.com if you have any questions. Thanks for the support!

Pin It on Pinterest

Contact Sales