Ever dreamed of a smart blind that is actually for your home? Not one you control with an app on your smartphone, but one that will learn how you use them and program itself?

Yes? Then this post is for you!

Habits and learning

As you might already know, at craft ai, we aim to use existing ways to control connected objects without developping new applications that only bring more complexity. In the case of a blind, we expect to need only the blind manufacturer application, the remote, or even better just the button on the wall to control it. As a developper, you only have to integrate our API into your own application or device, and without even noticing it, craft ai will learn when your user closes or opens her blinds and within a few days, craft ai will open and close them, for her.

Use case

Imagine you bought a set of connected blinds at your nearest convenience store and install it on Saturday. On Sunday you wake up at around 10 am, and you open up your blinds. In the evening, when the sun is almost down, you close them. On Monday, you wake up at 6 am, open up the blinds, and leave for work. In the evening, when the sun is almost down, the blinds already close automatically! On Tuesday morning, just as you wake up at 6 am, the blinds open up before you even touch them! In the evening, when night comes, the blinds close automatically. On the next weekend, the blind will open up at 10 am, as you wake up. For now on your blinds have learned your habits and you do not need to control them anymore.

What is When ?

Using the newest craft ai learning API is dead simple. It’s simply about continuously feeding the API with information about the context: you basically tell craft ai the same story we did in the previous section! craft ai then infers which context leads to the opening or closing of the blinds: craft ai learns a multi-dimensional planning for the blinds. What about defining what is part of the context and what is not? We believe the developer knows precisely the dimensions that matter based on his expertise of his market! In this case, he feed the API with the following context dimensions when the user closes or opens the blinds

• the current time (hour:minute)
• timezone, so we can handle daylight saving days
• the day of the week
• a computed value which models solar time ( from -1 at midnight to 0 at dawn to 1 at dusk to 2 at 11:59pm)

With just those four dimensions, the learning API can manage a lot of different cases:

• people who are working on weekend and have their day off during the week,
• people who are working at night (so they close their blinds during daytime),
• people who open/close their blinds following sunrise/sunset,
• people who open/close their blinds at a specific time,
• people who open/close their blinds multiple times a day,
• any combination of the above.

Technicals

In order to demonstrate how well craft ai works on this use case, we have built a simple simulation in a web application that plays a long period of time in accelerated time.

Profiles

The simulation can mimic different household profiles:

• a household that, on weekdays opens up his blinds at around 7am / closes them at around 7pm and on the weekends opens them up at around 10am and closes them at around 7pm
• a family with a baby that closes the blind between 2pm and 4pm on wednesdays at nap time, usually opens them at 6am on weekday and 10am on weekend, and closes them at sunset.

If during the simulation, the decision is not in line with the selected profile, we ‘simulate’ the user action on the blind to counter the learned decision, so we can see how many times a user has had to manually correct the AI decision and analyze when the user needs were not correctly anticipated.

We have tested two different ways to learn the schedule:

1. the learning is done during 2 consecutive weeks without any AI intervention
2. AI is plugged in as soon as day 2 (at least on the first day, nothing can not be infered)

Context diff & decision tree

Every day, at midnight, the application sends all context operations of the previous day and asks for the decision tree learned up to this day. This ensures a limited need for internet connectivity (as it can be expected for a real blind) while not impacting the quality of the decision, the daily period being natural to this use case. Then locally, the application uses the latest downloaded decision tree to builds a open/close planning for that day. During this process, the algorithm discards state changes for which there is a low confidence or that result in too many changes in a short period of time. We think (almost) nobody actually has the habit of opening/closing his blinds multiple times in less than 15 minutes. In any case, real blind motors would heat and go in security mode if you use them that often.

Results

The first version of the application was built with only the first profile (fixed time). With this in mind, the solar time value was removed from the model and the app just sent the context to our API when the user actually interacted with the blind. So basically just 2 context diffs per day. craft ai samples the time automatically, filling the day with interpolated samples, no need for the developper to feed context every minutes. In this case the app just specifies a 5 minute time quantum. So we have at max a 5 minute time window to change the state of the blind.

If the app learns for 2 weeks in a row before being plugged in, there is not one mistake done by the AI When the AI is plugged in from the beginning , there are some mistakes during the first 2 weeks, as the AI needs to learn the differences between weekends and weekdays

The decision tree after 2 weeks (either by learning only or with day by day corrections)

Result of 2 weeks learning (brown), then letting the AI drive the blind (blue)

Result of 1 day learning, then letting the AI drive the blind (blue), you can see human interactions (brown) on Saturday

The next one, was built with the second profile, so we feed the solarTime value in this version. Contrary to time values, where craft ai knows how it elapses, the solar time needs to be fed to the API as regular context operations. After some testing, we found we need to send an update to the solar time value every 30 minutes. As with the first profile, if we learn 2 weeks in a row, there is no mistake, if we learn as the time goes, then some mistakes are made when the previous day is not the same as the current one. As a side note, using the first profile (fixed time) can use the full context, the algorithm will just learn that the solarTime value has no impact in the decision making process!

The decision tree after 2 weeks (either by learning in a row or day after day)

Result of 2 weeks learning (brown), then letting the AI drive the blind (blue)

Conclusion

A real version can be built quite easily. Of course, we are not ‘blind’ specialists, so we may have forgotten to include some information in the context, but it will be easy to extend the model and try it! For example, a more complex context can use some weather information from any open API.

We hope you get the gist of how you can use craft ai to personalize a connected home with this post. Imagine all you can do with such simple AI service in you own application. Automate your application to suit each of your user, or even tailor it to them! If you want to experiment for yourself, just join our free beta!

Published originally on the craft ai blog, written by Stéphane Maruéjouls