Today I’d like to speak about Smart homes and IoT devices. But it is no ordinary article. You won’t find description of hardware, links to manufacturers, batches of code or repositories. Today we’ll discuss something of a higher level — principles that are used to organize “smart” systems.
Smart home is a system that can do some everyday routines instead of a person. It leads us to the first and the main principle:
Smart home is a system for living, it’s not a toy for geeks. Systems that are more complicated in use1 than a switch are not Smart home.
Any new thing has to be tested against this principle. If it does not make life easier, and you do not understand how to improve it to make life easier, it is not for Smart home.
The second in importance principle is how a user interacts with the system:
A cool tool that is difficult to use is not worth a dime. Convenient and reliable devices with limited functions have much greater chances of success in comparison to complicated devices for all possible uses and applications.
If you do not understand how to combine numerous functions and a simple interface and simply stock all functions hoping that a user can figure it all out himself, perhaps you should reconsider your career choice.
If you do not understand how to integrate convenience and numerous functions, get rid of some settings. Any function is better than a regular switch. But if it is over-complicated a user will come back to a switch.
The same can be said about the quality of work. A button that simply turn off the light is better than a dimmer that sometimes works and sometimes does not work:
It’s better to have few reliable functions than numerous malfunctioning ones.
One of the mechanisms developed in Man’s mind in the course of evolution is more emotional reaction to negative stimuli. Negative factors are more important than positive ones — it’s much more dangerous not to notice an approaching tiger than to miss a ripe fruit on a tree. If your system does not have certain functions, there is nothing wrong about it. It’s simply absence of a positive stimulus. But if you have a function but it malfunctions, it’s a negative stimulus that is easily remembered for a long time.
Delays are inadmissible as they have a bad effect on a user experience. It’s a negative stimulus too. If a person does not notice2 any delay between a flip of the switch and light turning on, he must not notice it in your system.
Modern hardware works at a high speed. There is no problem to reach frequencies of dozens of MHz on controllers and at least dozens kilobit per second even via a radio channel. If with this hardware your user still experiences delays in work — you should reconsider your career choice.
Your system is a small part of a person’s life. Usually a person’s lifetime exceeds the exploitation period of a system. Thus, systems will come and go and a person’s life will continue. And this life is full of formed habits about the light brightness, switch locations and the way he or she finds it is convenient to control light and climate.
Habits can’t be changes by force. New things can be offered but not forced.
You can’t tell a user, “Now you will turn on light from a smart phone — it’s modern, stylish and cool”. It goes against this principle and some others as well.
What to do?
If you think that your way to control home systems is better than an old one, offer it to a user. If it is really convenient, he will choose the new one himself (yes, different people choose different ways). All you can (and must) do is to provide him a choice.
Logics of work plays an important role in Smart home. It defines the rule Smart home works by. And it leads us to the next principle:
If a user wants to boil a kettle3 when the temperature in a room rises, let him do it. You must also avoid a situation when a required action can be done on the hardware or a software levels, but it is unavailable just because a developer thought that “No one will ever need it”.
If you have devices of different versions and with different protocols, make sure that a user knows about it only in cases when it is really necessary and unavoidable.
If you can spare a user the trouble of getting special knowledge even at a cost of developers’ time, do it. A developer will spend on it two days and it will take a thousand users an hour. If we look at 48 hours against 1000 hours, the answer is evident.
Do you sleep well, John, a serial programmer?
A user does not have to know that a water valve is controlled by certain commands and a tap is controlled by other ones. If both of them control water in a pipe they must have the same interfaces on a user level: “open water”, “close water”.
We live in physical world. The body and the brain of Man are formed to interact with physical objects. It leads us to next principle.
Any apps on a smart phone even the best ones are not so good as a regular physical switch in a required place.
It’s another matter that a switch has to be located exactly in the right place. It leads to another rule:
Wired systems are reliable, but only wireless systems allow to place a new switch or a relay without renovating a room. The also allow to move a switch if you think that a new place is more convenient. But there are certain exceptions:
It does not matter for good wireless system how far devices are places from the central controller. Good wireless systems are protocols with mesh-network: ZigBee, Z-Wave, 6LoWPAN, etc.
All other variants, including Wi-Fi, are not so good. Proprietary protocols such as «433 MHz», though they can work in other frequencies and differ from one another greatly are not so good either.
The disadvantages of Wi-Fi are that you can’t make fully-functional “sleeping” devices, automatic setting is complicated, incompatibility with other Wi-Fi devices in the house.
The disadvantages of proprietary protocols are that in most cases they have no control of delivery, encrypting, available specifications. Neither Wi-Fi nor proprietary protocols have mesh-routing that results in the following difficulty — “I can’t put a switch in that corner, as it is too far from the router”.
You can’t make 100% reliable system that does not have to be maintained. Devices get out of order, there cane me power line surges, neighbors can flood you, batteries discharge, a child can spill soup on a lamp, etc. But:
Everything is clear in B2B. There is a user, a developer, and an operator, it’s a person or an organization that knows what the system it like and how to work with it on the professional level. An accountant does not have to know programming to use his professional software. A person who rents an office does not have to know how ventilation works, all he has to do is to say, “It’s stuffy in the office”.
A wise solution about buying a system is made on the basis of calculating the total costs of owning that is made up of the price of the system and maintenance expenses.
It’s a bit more complicated in systems that are used in homes. An operator and a user are one and the same person who doesn’t have the required knowledge of the system. Unfortunately, these are the limits of the consumer market. And it leads to the following principles.
Probable work, partial work or malfunction are inadmissible. Avoid situations when your device does not work every other time of one out of ten times. If you think that your device malfunctions, turn it off for security reasons and to keep positive user experience. Replacing a device is not pleasant, but it’s better to make a user replace a device than form an opinion that the system works “every other time”. There are only two possible states of a system: it’s out of order or it does not work, it’s in order and it works.
If you are definite that system degradation is possible, inform a user about it with the help of a message that is easy to understand: «The second dimmer channel is out of order. Replace the dimmer. Continue using the first dimmer channel? Yes/No»
The system must a module one. If a sensor gets out of order, only this sensor has to be replaced. It’s not correct to require replacing a relay with a remote control with a sensor, because they are paired on the manufacturing stage.
It’s not correct to demand that “a new sensor can be installed only by our specialist”, because it is evident that with time your specialists won’t be enough to service millions of users as the popularity of your system grows. Thus, at a certain moment problems will appear. Of course a user won’t fix a device himself, but when it gets out of order he must have an opportunity to replace them himself.
If anything goes wrong, a user must know about it and know what exactly went wrong. You can’t show “Error #45” message implying that he must understand it. A message like this must be shown to a user “Device does not answer. Try reloading it and assigning it again or contact tech support. Error #45”
You can’t learn that a device does not answer (if you can do it) and withhold this information from a user. It’s not pleasant to get messages about a problem. But it’s much more unpleasant to learn that a device has been out of order for a week at the moment when you ultimately need this device.
Do not spam a user with logs. A user needs information like in the previous principle, because it contains information what exactly went wrong. If he can’t understand information or he is not the addressee, he does not need it.
Do not show hundreds of typical messages “connection to device is lost”, “connection to device is restored”. You have to decide if it is critical information and a user has to be informed about it. Or if connection is restored, this information is not important, so do not show it4.
Allow a user to update firmware by clicking a couple of buttons. It can be done via a standard interface (USB/BT/Wi-Fi), or do not mention updating via SPI-programmer at all.
You can’t expect a user to calculate bit masks to configure a device.
If a dimmer loses connection every month and a user has to climb a ladder to reach a lamp and connect the actuator again – it’s not convenient. If batteries have to be changed in a switch every two months – it’s not convenient. Even if the average period of maintaining a device is six months – it’s not convenient. If there are about twenty devices in the house, a user has to do something every nine days.
Expenses on extending a system must grow in linear progression.
Avoid situations when a user who wants to add a sensor has to buy a new controller, because the old one does not support more than 6 sensors5.
Avoid situations when new sensor firmware can work only with a new version of a controller.
Such limitations have a positive influence on the income, making users buy new devices. But it’s a road to nowhere. You can lose your users trust because of such tricks and as a result you’ll lose much more than you could have earned.
A system where commands have to go through an external server is not convenient. You can speak for hours about convenient interfaces, modern app, cool neuro networks, but they mean nothing if a user can’t turn on the light in the lavatory when the Internet is down. Do you really think that such a system can be considered good?
I really fail to understand why this principle is not taken for granted. If you include an external server in a project, it becomes a possible point of failure. External services are cool, they can add more functions, but they can’t be the only variant of control. Though they can be wonderfully used as an additional control channel, a back-up storage, a tool for data analysis, etc.
But a decentralized system is not ideal either, though it is reliable.
A decentralized system is a system where a switch “tells” a lamp “to turn off”, and a temperature sensor turns on a heater when the temperature is falling. A decentralized system loses to a centralized one, because it is good only for simple interaction between devices when a device controls another device. If a system becomes more complicated, there appear a lot of questions. If there are several sensors will the heater accept command from all of them? Is the heater to request sensors itself? If a decision has to be made on the analysis of actual data, where to store the archive? Where to store and how to change logics? How to store logics on “stupid” devices? How to update logics?
All these questions disappear if it is taken for granted that a hub is required as a point of data interaction and a place to store a user’s logics. Devices can be “stupid”, i.e. they can send data and get commands, as the task to store data, to process data, to make decisions and to interact with external services is upon the central controller.
Decentralization can partly be saved, as when there is no hub, commands can be sent directly as fail-safe mode. There is no logics, but light can be turned on.
As long as we live in a world where a programmer is not responsible for the damage done by his/her software, there will be errors in software, including the software of Smart home. The only way not to allow an error cause serious consequences is to limit the independent actions of the system. Potentially dangerous actions must be done only when a user is informed about them or even better after a user confirms them. Light can be turned on automatically, a bug in the software will wake a user at night or will increase his electricity bill. It’s not pleasant, but it is not dangerous. But water taps can’t be opened automatically, if there are not tools preventing flooding. Thought it is not dangerous to close water taps automatically.
It does not mean that automatic control of heaters, boilers, fire-places, kettles, etc., is forbidden. It means that if you want to make a potentially dangerous action automatic, make sure that the danger won’t reach the user level. Make sure that a kettle is automatically turned off when it reaches a definite temperature, that a bath has leakage sensors, etc.
A present day developer of Smart home systems must be a little paranoiac. Internet can’t be trusted, it can be down. Code can't be trusted, there can be bugs. Can hardware be trusted? No, hardware can’t be relied on. Relays can stick, triacs can open, fuses can burn. Even a user can connect a kilowatt kettle to 100–watt socket. Thus, a voltage sensor, a current sensor and a temperature sensor are required. If the temperature exceeds the limits – turn everything off and send a warning. If the current exceeded the limits – turn everything off. If a relay is turned off, but there is still voltage – send a notification. If you turn of a relay and there is no voltage – send a notification.
Even if you consider all paranoiac stuff, there will be a situation when all controls failed and something broke down. It can be a switch, a router or the central hub, but nevertheless a user wants to turn on light in the lavatory. What to do?
There must always be a button that can make the sun set in the manual mode, a button that can turn on/off light right NOW. As it will take a day to deliver a new hub and a new switch can be bought later, but the light in the bedroom has to be turned off tonight.
Regular users bring you money, hackers6 can think of new functions. A manufacture cannot and must not develop all scenes of system use, as he does not have knowledge in all the spheres and he can’t calculate the effect of such things. It’s quite possible that a smart socket can be convenient to control via a thermostat of a mobile brewery, because it has a PID-regulator. The example is a bit far-fetched, but the idea is that it’s not bad to create convenient conditions for hackers as they can add the moving power to your system.
You can’t meet all your customers’ needs with your own devices. There will always be devices that you do not have. Or you may have the devices, but devices of other manufacturers can be better. To connect your system to other ones it is absolutely necessary to have open well-documented API. If you have no API, your users can’t have heterogenic systems. But even big companies of proprietary hardware and software cannot afford it.
It does not matter how cool your hardware is or how good your software is, if a user can’t understand how to start your system and how to work with it. Good documentation is the one after reading which a user does not think of contacting tech support or does not give negative evaluation to developer’s mental abilities. It’s impossible to write such documentation, but it’s something to strive for.
And the last but not least:
A person lives about 70-90 year, a system installed in his home works about 5-10 years (at best), companies last even less. Do not create a system that will stop working if your company dies. Feel for users. Plan the system in such a way that it can be worked with even is the company and the developer are no longer in this world.
If a device is assigned with getting a token from a developer’s server, make a button “Skip getting a token”. If the firmware has to be updated from the web-site when the system is started for the first time, make it possible to download default firmware if the web-site is not available. And so on.
In this article I tried to describe the experience of using, developing such systems and working with them in 15 principles. Part of them can seem far-fetched, others are debatable (it’s normal), and others are hackneyed (it’s also normal).
But if you took time to think even about one of them, the article was not written in vain.
1. By “use” I mean the process of regular interaction with the system, but not setting.
2. I’d like to emphasize that I say “a user must not notice”, but not “the delay must be the same as”. Practice shows that a human does not notice a delay of 300 milliseconds.
3. Perhaps he grew in Asia and he thinks that the best remedy for heat is hot green tea.
4. When I say “do not show information”, it means that a user must not be sent a message about it every time. It must be shown on a user’s request – for example, “show the log”, or “show debug information” when a button is pressed. Do not look upon users as idiots, respect their time.
5. It’s or course impossible to design a system that supports an unlimited number of devices. There will always be limits, but it’s a developer’s task to make them irrelevant in 99 % of all cases. Limit to 6 sensors is unacceptable. A hundred or two hundreds of devices in one net is enough to most users of smart homes.
6. I use the word “hacker” in the essential meaning of this word according to RFC1983, and not I the meaning of a person who uses computers to gain unauthorized access to data.
This text was helped to translate into English by iRidium Mobile, for which I thank them very much.
Smart home is a system that can do some everyday routines instead of a person. It leads us to the first and the main principle:
1. Smart home must make life easier.
Smart home is a system for living, it’s not a toy for geeks. Systems that are more complicated in use1 than a switch are not Smart home.
Any new thing has to be tested against this principle. If it does not make life easier, and you do not understand how to improve it to make life easier, it is not for Smart home.
The second in importance principle is how a user interacts with the system:
2. Good user experience is more important than functionality.
A cool tool that is difficult to use is not worth a dime. Convenient and reliable devices with limited functions have much greater chances of success in comparison to complicated devices for all possible uses and applications.
2.1. Convenient interfaces are better than customization.
If you do not understand how to combine numerous functions and a simple interface and simply stock all functions hoping that a user can figure it all out himself, perhaps you should reconsider your career choice.
If you do not understand how to integrate convenience and numerous functions, get rid of some settings. Any function is better than a regular switch. But if it is over-complicated a user will come back to a switch.
The same can be said about the quality of work. A button that simply turn off the light is better than a dimmer that sometimes works and sometimes does not work:
2.2. The quality of realized functions is more important than the number of functions
It’s better to have few reliable functions than numerous malfunctioning ones.
One of the mechanisms developed in Man’s mind in the course of evolution is more emotional reaction to negative stimuli. Negative factors are more important than positive ones — it’s much more dangerous not to notice an approaching tiger than to miss a ripe fruit on a tree. If your system does not have certain functions, there is nothing wrong about it. It’s simply absence of a positive stimulus. But if you have a function but it malfunctions, it’s a negative stimulus that is easily remembered for a long time.
2.3. System use must not decrease the usual speed of work
Delays are inadmissible as they have a bad effect on a user experience. It’s a negative stimulus too. If a person does not notice2 any delay between a flip of the switch and light turning on, he must not notice it in your system.
Modern hardware works at a high speed. There is no problem to reach frequencies of dozens of MHz on controllers and at least dozens kilobit per second even via a radio channel. If with this hardware your user still experiences delays in work — you should reconsider your career choice.
2.4. System must not break already formed user habits.
Your system is a small part of a person’s life. Usually a person’s lifetime exceeds the exploitation period of a system. Thus, systems will come and go and a person’s life will continue. And this life is full of formed habits about the light brightness, switch locations and the way he or she finds it is convenient to control light and climate.
Habits can’t be changes by force. New things can be offered but not forced.
You can’t tell a user, “Now you will turn on light from a smart phone — it’s modern, stylish and cool”. It goes against this principle and some others as well.
What to do?
2.5. System must bring new experience and not replace the old one.
If you think that your way to control home systems is better than an old one, offer it to a user. If it is really convenient, he will choose the new one himself (yes, different people choose different ways). All you can (and must) do is to provide him a choice.
Logics of work plays an important role in Smart home. It defines the rule Smart home works by. And it leads us to the next principle:
3. User’s logics can’t be limited.
If a user wants to boil a kettle3 when the temperature in a room rises, let him do it. You must also avoid a situation when a required action can be done on the hardware or a software levels, but it is unavailable just because a developer thought that “No one will ever need it”.
3.1. The simpler — the better: creating logics must not require special knowledge of the system structure.
If you have devices of different versions and with different protocols, make sure that a user knows about it only in cases when it is really necessary and unavoidable.
If you can spare a user the trouble of getting special knowledge even at a cost of developers’ time, do it. A developer will spend on it two days and it will take a thousand users an hour. If we look at 48 hours against 1000 hours, the answer is evident.
Do you sleep well, John, a serial programmer?
3.2. Devices with the same functions must be controlled the same way.
A user does not have to know that a water valve is controlled by certain commands and a tap is controlled by other ones. If both of them control water in a pipe they must have the same interfaces on a user level: “open water”, “close water”.
We live in physical world. The body and the brain of Man are formed to interact with physical objects. It leads us to next principle.
4. Physical control device are better than virtual.
Any apps on a smart phone even the best ones are not so good as a regular physical switch in a required place.
It’s another matter that a switch has to be located exactly in the right place. It leads to another rule:
5. Wireless systems are better than wired ones.
Wired systems are reliable, but only wireless systems allow to place a new switch or a relay without renovating a room. The also allow to move a switch if you think that a new place is more convenient. But there are certain exceptions:
5.1. Bad wireless systems are worse than wired ones.
It does not matter for good wireless system how far devices are places from the central controller. Good wireless systems are protocols with mesh-network: ZigBee, Z-Wave, 6LoWPAN, etc.
All other variants, including Wi-Fi, are not so good. Proprietary protocols such as «433 MHz», though they can work in other frequencies and differ from one another greatly are not so good either.
The disadvantages of Wi-Fi are that you can’t make fully-functional “sleeping” devices, automatic setting is complicated, incompatibility with other Wi-Fi devices in the house.
The disadvantages of proprietary protocols are that in most cases they have no control of delivery, encrypting, available specifications. Neither Wi-Fi nor proprietary protocols have mesh-routing that results in the following difficulty — “I can’t put a switch in that corner, as it is too far from the router”.
You can’t make 100% reliable system that does not have to be maintained. Devices get out of order, there cane me power line surges, neighbors can flood you, batteries discharge, a child can spill soup on a lamp, etc. But:
6. Fixing, updating, maintaining and diagnosing must be easy.
Everything is clear in B2B. There is a user, a developer, and an operator, it’s a person or an organization that knows what the system it like and how to work with it on the professional level. An accountant does not have to know programming to use his professional software. A person who rents an office does not have to know how ventilation works, all he has to do is to say, “It’s stuffy in the office”.
A wise solution about buying a system is made on the basis of calculating the total costs of owning that is made up of the price of the system and maintenance expenses.
It’s a bit more complicated in systems that are used in homes. An operator and a user are one and the same person who doesn’t have the required knowledge of the system. Unfortunately, these are the limits of the consumer market. And it leads to the following principles.
6.1. Devices either work or do not work. There is no third option.
Probable work, partial work or malfunction are inadmissible. Avoid situations when your device does not work every other time of one out of ten times. If you think that your device malfunctions, turn it off for security reasons and to keep positive user experience. Replacing a device is not pleasant, but it’s better to make a user replace a device than form an opinion that the system works “every other time”. There are only two possible states of a system: it’s out of order or it does not work, it’s in order and it works.
If you are definite that system degradation is possible, inform a user about it with the help of a message that is easy to understand: «The second dimmer channel is out of order. Replace the dimmer. Continue using the first dimmer channel? Yes/No»
6.2. Replacing a broken device must be easy.
The system must a module one. If a sensor gets out of order, only this sensor has to be replaced. It’s not correct to require replacing a relay with a remote control with a sensor, because they are paired on the manufacturing stage.
It’s not correct to demand that “a new sensor can be installed only by our specialist”, because it is evident that with time your specialists won’t be enough to service millions of users as the popularity of your system grows. Thus, at a certain moment problems will appear. Of course a user won’t fix a device himself, but when it gets out of order he must have an opportunity to replace them himself.
6.3. User-friendly messages.
If anything goes wrong, a user must know about it and know what exactly went wrong. You can’t show “Error #45” message implying that he must understand it. A message like this must be shown to a user “Device does not answer. Try reloading it and assigning it again or contact tech support. Error #45”
You can’t learn that a device does not answer (if you can do it) and withhold this information from a user. It’s not pleasant to get messages about a problem. But it’s much more unpleasant to learn that a device has been out of order for a week at the moment when you ultimately need this device.
6.4. No extra information in messages.
Do not spam a user with logs. A user needs information like in the previous principle, because it contains information what exactly went wrong. If he can’t understand information or he is not the addressee, he does not need it.
Do not show hundreds of typical messages “connection to device is lost”, “connection to device is restored”. You have to decide if it is critical information and a user has to be informed about it. Or if connection is restored, this information is not important, so do not show it4.
6.5. No special knowledge or equipment must be required for maintenance works.
Allow a user to update firmware by clicking a couple of buttons. It can be done via a standard interface (USB/BT/Wi-Fi), or do not mention updating via SPI-programmer at all.
You can’t expect a user to calculate bit masks to configure a device.
6.6. System must not require constant maintenance.
If a dimmer loses connection every month and a user has to climb a ladder to reach a lamp and connect the actuator again – it’s not convenient. If batteries have to be changed in a switch every two months – it’s not convenient. Even if the average period of maintaining a device is six months – it’s not convenient. If there are about twenty devices in the house, a user has to do something every nine days.
6.7. System must have opportunities for updating and extending.
Expenses on extending a system must grow in linear progression.
Avoid situations when a user who wants to add a sensor has to buy a new controller, because the old one does not support more than 6 sensors5.
Avoid situations when new sensor firmware can work only with a new version of a controller.
Such limitations have a positive influence on the income, making users buy new devices. But it’s a road to nowhere. You can lose your users trust because of such tricks and as a result you’ll lose much more than you could have earned.
7. Self-sustainability: external nets are an option, not a requirement.
A system where commands have to go through an external server is not convenient. You can speak for hours about convenient interfaces, modern app, cool neuro networks, but they mean nothing if a user can’t turn on the light in the lavatory when the Internet is down. Do you really think that such a system can be considered good?
I really fail to understand why this principle is not taken for granted. If you include an external server in a project, it becomes a possible point of failure. External services are cool, they can add more functions, but they can’t be the only variant of control. Though they can be wonderfully used as an additional control channel, a back-up storage, a tool for data analysis, etc.
8. Centralization: absence of a central hub limits available logics.
But a decentralized system is not ideal either, though it is reliable.
A decentralized system is a system where a switch “tells” a lamp “to turn off”, and a temperature sensor turns on a heater when the temperature is falling. A decentralized system loses to a centralized one, because it is good only for simple interaction between devices when a device controls another device. If a system becomes more complicated, there appear a lot of questions. If there are several sensors will the heater accept command from all of them? Is the heater to request sensors itself? If a decision has to be made on the analysis of actual data, where to store the archive? Where to store and how to change logics? How to store logics on “stupid” devices? How to update logics?
All these questions disappear if it is taken for granted that a hub is required as a point of data interaction and a place to store a user’s logics. Devices can be “stupid”, i.e. they can send data and get commands, as the task to store data, to process data, to make decisions and to interact with external services is upon the central controller.
Decentralization can partly be saved, as when there is no hub, commands can be sent directly as fail-safe mode. There is no logics, but light can be turned on.
9. System must not make potentially dangerous actions without informing a user or getting a confirmation from him.
As long as we live in a world where a programmer is not responsible for the damage done by his/her software, there will be errors in software, including the software of Smart home. The only way not to allow an error cause serious consequences is to limit the independent actions of the system. Potentially dangerous actions must be done only when a user is informed about them or even better after a user confirms them. Light can be turned on automatically, a bug in the software will wake a user at night or will increase his electricity bill. It’s not pleasant, but it is not dangerous. But water taps can’t be opened automatically, if there are not tools preventing flooding. Thought it is not dangerous to close water taps automatically.
It does not mean that automatic control of heaters, boilers, fire-places, kettles, etc., is forbidden. It means that if you want to make a potentially dangerous action automatic, make sure that the danger won’t reach the user level. Make sure that a kettle is automatically turned off when it reaches a definite temperature, that a bath has leakage sensors, etc.
10. System, must have options for self-control and self-diagnostics.
A present day developer of Smart home systems must be a little paranoiac. Internet can’t be trusted, it can be down. Code can't be trusted, there can be bugs. Can hardware be trusted? No, hardware can’t be relied on. Relays can stick, triacs can open, fuses can burn. Even a user can connect a kilowatt kettle to 100–watt socket. Thus, a voltage sensor, a current sensor and a temperature sensor are required. If the temperature exceeds the limits – turn everything off and send a warning. If the current exceeded the limits – turn everything off. If a relay is turned off, but there is still voltage – send a notification. If you turn of a relay and there is no voltage – send a notification.
11. System must have manual control.
Even if you consider all paranoiac stuff, there will be a situation when all controls failed and something broke down. It can be a switch, a router or the central hub, but nevertheless a user wants to turn on light in the lavatory. What to do?
There must always be a button that can make the sun set in the manual mode, a button that can turn on/off light right NOW. As it will take a day to deliver a new hub and a new switch can be bought later, but the light in the bedroom has to be turned off tonight.
12. Hackers are as important as regular users.
Regular users bring you money, hackers6 can think of new functions. A manufacture cannot and must not develop all scenes of system use, as he does not have knowledge in all the spheres and he can’t calculate the effect of such things. It’s quite possible that a smart socket can be convenient to control via a thermostat of a mobile brewery, because it has a PID-regulator. The example is a bit far-fetched, but the idea is that it’s not bad to create convenient conditions for hackers as they can add the moving power to your system.
13. Openness: system must have open API to integrate with other systems.
You can’t meet all your customers’ needs with your own devices. There will always be devices that you do not have. Or you may have the devices, but devices of other manufacturers can be better. To connect your system to other ones it is absolutely necessary to have open well-documented API. If you have no API, your users can’t have heterogenic systems. But even big companies of proprietary hardware and software cannot afford it.
14. Documentation: it is as important as hardware and code.
It does not matter how cool your hardware is or how good your software is, if a user can’t understand how to start your system and how to work with it. Good documentation is the one after reading which a user does not think of contacting tech support or does not give negative evaluation to developer’s mental abilities. It’s impossible to write such documentation, but it’s something to strive for.
And the last but not least:
15. Self-sustainability and self-supportability: system must go on working, even if the company no longer exists.
A person lives about 70-90 year, a system installed in his home works about 5-10 years (at best), companies last even less. Do not create a system that will stop working if your company dies. Feel for users. Plan the system in such a way that it can be worked with even is the company and the developer are no longer in this world.
If a device is assigned with getting a token from a developer’s server, make a button “Skip getting a token”. If the firmware has to be updated from the web-site when the system is started for the first time, make it possible to download default firmware if the web-site is not available. And so on.
In this article I tried to describe the experience of using, developing such systems and working with them in 15 principles. Part of them can seem far-fetched, others are debatable (it’s normal), and others are hackneyed (it’s also normal).
But if you took time to think even about one of them, the article was not written in vain.
Comments
1. By “use” I mean the process of regular interaction with the system, but not setting.
2. I’d like to emphasize that I say “a user must not notice”, but not “the delay must be the same as”. Practice shows that a human does not notice a delay of 300 milliseconds.
3. Perhaps he grew in Asia and he thinks that the best remedy for heat is hot green tea.
4. When I say “do not show information”, it means that a user must not be sent a message about it every time. It must be shown on a user’s request – for example, “show the log”, or “show debug information” when a button is pressed. Do not look upon users as idiots, respect their time.
5. It’s or course impossible to design a system that supports an unlimited number of devices. There will always be limits, but it’s a developer’s task to make them irrelevant in 99 % of all cases. Limit to 6 sensors is unacceptable. A hundred or two hundreds of devices in one net is enough to most users of smart homes.
6. I use the word “hacker” in the essential meaning of this word according to RFC1983, and not I the meaning of a person who uses computers to gain unauthorized access to data.
This text was helped to translate into English by iRidium Mobile, for which I thank them very much.
peacekeeper
I like this principles. I believe most of them fit not only for Smart Home but for a lot of other things…
I especially do like principle 2.5… alas… some really big and famous companies prefer to ignore it…
But… when I'll have a Smart Home… I really want it would be totally similar the principles…
Thank you!