This article will outline two very important decisions in designing an IoT-controlled system of thermostats. Both of these considerations can be applied to other IoT-based systems.
We recommened reading our article What is IoT before reading this article.
Oftentimes, home temperature systems are set up to use customizable schedules based on days of the week. This provides users with the ability for very specific control. However, the time investment for the initial configuration of these schedules is large. This problem increases exponentially with a radiant system where a user may have 5-10 thermostats which would create 35-70 daily schedules to modify.
Design efforts must be focused on analyzing the underlying reasons why users want to modify the system in the first place in order to provide an interface relevant to the user's point of view (vs. a system / hardware point of view). Most often, a seven day schedule has two main components: working days and non-working days. Working days are typically Monday to Friday, while weekends are generally non-working days. A simplified interface could be provided by allowing the users to choose which days they work, and which they do not, to set the underlying system behaviour. However, this method cannot account for unexpected situations such as sick days or non-consistent schedules. Further refining the purpose of the two different modes, it can be shown that the reason a user informs the system of work and non-work days is so the system knows when they will not be occupying the premises.
A system which uses the homeowners' mobile devices (via geofencing) as an automatic indication of their presence may simplify the system and ultimately provide the users with a more ideal system: one that is comfortable when they are home and saves energy when they are not present. Rather then choosing days of the week or work day / non-work days, the system could automate the 'away' and 'home' process, allowing for a single day schedule per room.
In order to provide these ideal conditions, the app would have to ask the user whether they find comfort or energy savings more important. This would allow the system to make better decisions regarding room preheating duration and expected occupancy times, especially for when the system attempts to predict if the user will arrive home at non-standard times. For example, when a user has the "comfort" setting set, the system will try to ensure that the house is at the "comfort" temperature before the user comes home, erring on the side of making things comfortable for the user, even if that means the house is at the desired comfortable temperature for an hour before the user arrives.
On the other hand, with an "energy savings" setting, the system will ensure that the house is at the desired temperature exactly when it thinks the user will be home. Overall, the system would make more conservative choices on when to heat; if there is a low chance that a user will arrive home early on Monday night, the system will not preheat with that expectation. If the user does arrive early, the system might not be at a comfortable temperature yet. In this case, though, the users will be willing to accept this outcome since they chose to prioritize energy savings over comfort.
Systems with a large amount of control points frequently have the notion of 'zones' or 'scenes' in which multiple control points can be grouped together. This makes doing some changes quicker, but adds a large amount of complexity for both the user and the underlying control system. For example, if a user has a whole house group, room group, and individual room, how does the system decide which control point is most important? Which will the user expect to "win" when a conflicting schedule occurs? If the user modifies the group, should it override the individual room control point or should its control point be based on which was last modified? How do we inform the user of this control hierarchy?
These group controls often lead to confusion among users, which erodes their trust of the system. In order to avoid these issues, the user can be provided with a one-time ability to set up a consistent environment for the house. This provides the initial settings for each individual room control. From that point on, there is only one control point for each room with no group or whole-house capabilities. This provides the user with a single location to understand how a room is heated or cooled.
The case also exists where a user may want to affect multiple rooms at once. Generally, when a user wants to do this, some sort of unusual temporary event has occurred (a party, a vacation, etc.). An 'events' system could allow the user to configure multiple rooms for the same event, which could cause a temporary change to all these rooms at once. This in no way groups the rooms, but yet, still provides for a single change to affect multiple rooms simultaneously.
One of the problems with slow-changing control systems (such as those found in radiant heating systems), is that users may not understand why their actions do not fix the situation immediately. Rather, the problem is resolved in the future after the system has had time to progress to the desired state. This can lead to a number of further confusions. For one, the user might think that the system is broken, as they told it to get warmer but the system did not respond immediately. Also, the user may intentionally tell the system to overshoot its goal state (e.g. they keep pressing the warmer button past their ideal temperature), thinking they will arrive faster to the goal.
To prevent these issues, providing additional information to the user when setting the temperature in a room could be be useful. For example, showing the user how long it will take for the room to reach the desired temperature. This introspection into the system's workings can be provided by a textual reading indicating how long it will take the system to resolve the difference between the current and desired conditions.
Additionally, when the user is setting the temperature, they could be forced to move the temperature slider farther away from the current temperature. This growing physical separation on the screen between the current temperature and the set-point provides a clue to the user that it will take increasingly longer for that change to happen in the room.