Aujourd'hui, je voudrais parler des maisons intelligentes et des appareils IoT. Mais ce n'est pas un article ordinaire. Vous ne trouverez pas de description du matériel, des liens vers les fabricants, des lots de code ou des référentiels. Aujourd'hui, nous aborderons quelque chose d'un niveau supérieur - les principes qui sont utilisés pour organiser les systèmes «intelligents».

La maison intelligente est un système qui peut faire certaines routines quotidiennes au lieu d'une personne. Cela nous amène au premier et au principe principal:
1. La maison intelligente doit faciliter la vie.
La maison intelligente est un système de vie, ce n'est pas un jouet pour les geeks. Les systèmes qui sont plus compliqués à utiliser
1 qu'un commutateur ne sont pas des maisons intelligentes.
Toute nouvelle chose doit être testée par rapport à ce principe. Si cela ne vous facilite pas la vie et que vous ne savez pas comment l'améliorer pour vous faciliter la vie, ce n'est pas pour Smart home.
Le deuxième principe d'importance est la façon dont un utilisateur interagit avec le système:
2. Une bonne expérience utilisateur est plus importante que la fonctionnalité.
Un outil cool et difficile à utiliser ne vaut pas un centime. Les appareils pratiques et fiables aux fonctions limitées ont de bien plus grandes chances de succès par rapport aux appareils compliqués pour toutes les utilisations et applications possibles.
2.1. Les interfaces pratiques sont meilleures que la personnalisation.
Si vous ne comprenez pas comment combiner de nombreuses fonctions et une interface simple et simplement stocker toutes les fonctions en espérant qu'un utilisateur puisse tout comprendre lui-même, vous devriez peut-être reconsidérer votre choix de carrière.
Si vous ne comprenez pas comment intégrer la commodité et de nombreuses fonctions, supprimez certains paramètres. N'importe quelle fonction est meilleure qu'un interrupteur ordinaire. Mais s'il est trop compliqué, un utilisateur reviendra à un commutateur.
On peut en dire autant de la qualité du travail. Un bouton qui éteint simplement la lumière est meilleur qu'un gradateur qui fonctionne parfois et parfois ne fonctionne pas:
2.2. La qualité des fonctions réalisées est plus importante que le nombre de fonctions
Il vaut mieux avoir peu de fonctions fiables que de nombreuses fonctions défectueuses.
L'un des mécanismes développés dans l'esprit de l'homme au cours de l'évolution est une réaction émotionnelle plus forte aux stimuli négatifs. Les facteurs négatifs sont plus importants que les facteurs positifs - il est beaucoup plus dangereux de ne pas remarquer un tigre qui s'approche que de manquer un fruit mûr sur un arbre. Si votre système n'a pas certaines fonctions, il n'y a rien de mal à cela. C'est simplement l'absence d'un stimulus positif. Mais si vous avez une fonction mais qu'elle fonctionne mal, c'est un stimulus négatif dont on se souvient facilement pendant longtemps.
2.3. L'utilisation du système ne doit pas diminuer la vitesse de travail habituelle
Les retards sont inadmissibles car ils nuisent à l'expérience utilisateur. C'est aussi un stimulus négatif. Si une personne ne remarque aucun délai entre un basculement de l'interrupteur et l'allumage de la lumière, elle ne doit pas le remarquer dans votre système.
Le matériel moderne fonctionne à grande vitesse. Il n'y a aucun problème pour atteindre des fréquences de dizaines de MHz sur les contrôleurs et au moins des dizaines de kilobits par seconde même via un canal radio. Si avec ce matériel votre utilisateur connaît toujours des retards de travail - vous devriez reconsidérer votre choix de carrière.
2.4. Le système ne doit pas briser les habitudes d'utilisateurs déjà formées.
Votre système n'est qu'une petite partie de la vie d'une personne. Habituellement, la durée de vie d'une personne dépasse la période d'exploitation d'un système. Ainsi, les systèmes vont et viennent et la vie d'une personne continue. Et cette vie est pleine d'habitudes formées concernant la luminosité de la lumière, les emplacements des commutateurs et la façon dont il ou elle trouve qu'il est pratique de contrôler la lumière et le climat.
Les habitudes ne peuvent pas changer par la force. De nouvelles choses peuvent être offertes mais pas forcées.
Vous ne pouvez pas dire à un utilisateur: «Maintenant, vous allez allumer la lumière d'un téléphone intelligent - c'est moderne, élégant et cool». Cela va à l'encontre de ce principe et de certains autres également.
Que faire?
2.5. Le système doit apporter une nouvelle expérience et ne pas remplacer l'ancienne.
Si vous pensez que votre façon de contrôler les systèmes domestiques est meilleure qu'une ancienne, offrez-la à un utilisateur. Si cela est vraiment pratique, il choisira le nouveau lui-même (oui, différentes personnes choisissent différentes manières). Tout ce que vous pouvez (et devez) faire, c'est lui donner le choix.
La logique du travail joue un rôle important dans la maison intelligente. Il définit la règle selon laquelle la maison intelligente fonctionne. Et cela nous amène au principe suivant:
3. Les logiques de l'utilisateur ne peuvent pas être limitées.
Si un utilisateur veut faire bouillir une bouilloire
3 lorsque la température dans une pièce augmente, laissez-le le faire. Vous devez également éviter une situation où une action requise peut être effectuée au niveau matériel ou logiciel, mais elle n'est pas disponible simplement parce qu'un développeur pensait que «personne n'en aura jamais besoin».
3.1. Le plus simple - le mieux: la création de logiques ne doit pas nécessiter une connaissance particulière de la structure du système.
Si vous avez des appareils de versions différentes et avec des protocoles différents, assurez-vous qu'un utilisateur ne le sait que dans les cas où cela est vraiment nécessaire et inévitable.
Si vous pouvez épargner à un utilisateur la difficulté d'acquérir des connaissances spéciales même au prix du temps des développeurs, faites-le. Un développeur y passera deux jours et cela prendra un millier d'utilisateurs par heure. Si on regarde 48 heures contre 1000 heures, la réponse est évidente.
Dormez-vous bien, John, un programmeur en série?
3.2. Les appareils ayant les mêmes fonctions doivent être contrôlés de la même manière.
Un utilisateur n'a pas besoin de savoir qu'une vanne d'eau est contrôlée par certaines commandes et un robinet est contrôlé par d'autres. Si les deux contrôlent l'eau dans une conduite, ils doivent avoir les mêmes interfaces au niveau de l'utilisateur: «eau libre», «eau fermée».
Nous vivons dans un monde physique. Le corps et le cerveau de l'homme sont formés pour interagir avec des objets physiques. Cela nous amène au principe suivant.
4. Les dispositifs de contrôle physique sont meilleurs que virtuels.
Toutes les applications sur un téléphone intelligent, même les meilleures, ne sont pas aussi bonnes qu'un interrupteur physique normal à un endroit requis.
C'est une autre question qu'un interrupteur doit être situé exactement au
bon endroit . Cela conduit à une autre règle:
5. Les systèmes sans fil sont meilleurs que ceux câblés.
Les systèmes câblés sont fiables, mais seuls les systèmes sans fil permettent de placer un nouvel interrupteur ou un relais sans rénover une pièce. Ils permettent également de déplacer un interrupteur si vous pensez qu'un nouvel endroit est plus pratique. Mais il y a certaines exceptions:
5.1. Les mauvais systèmes sans fil sont pires que ceux câblés.
Pour un bon système sans fil, peu importe la distance entre les appareils et le contrôleur central. Les bons systèmes sans fil sont des protocoles avec
un réseau maillé : ZigBee, Z-Wave, 6LoWPAN, etc.
Toutes les autres options, y compris le Wi-Fi, ne sont pas aussi bonnes. Les protocoles propriétaires tels que "433 MHz", bien qu'ils puissent fonctionner dans d'autres fréquences et différer les uns des autres, ne sont pas très bons non plus.
Les inconvénients du Wi-Fi sont que vous ne pouvez pas fabriquer des appareils «en veille» entièrement fonctionnels, le réglage automatique est compliqué, l'incompatibilité avec d'autres appareils Wi-Fi de la maison.
Les inconvénients des protocoles propriétaires sont que, dans la plupart des cas, ils n'ont aucun contrôle sur la livraison, le chiffrement et les spécifications disponibles. Ni le Wi-Fi ni les protocoles propriétaires n'ont de routage maillé qui entraîne la difficulté suivante - «Je ne peux pas mettre un commutateur dans ce coin, car il est trop loin du routeur».
Vous ne pouvez pas créer un système fiable à 100% qui ne doit pas être entretenu. Les appareils tombent en panne, il y a des surtensions sur la ligne électrique, les voisins peuvent vous inonder, les batteries se déchargent, un enfant peut renverser de la soupe sur une lampe, etc. Mais:
6. La réparation, la mise à jour, la maintenance et le diagnostic doivent être faciles.
Tout est clair en B2B. Il y a un utilisateur, un développeur et un opérateur, c'est une personne ou une organisation qui sait ce que le système lui plaît et comment travailler avec lui au niveau professionnel. Un comptable n'a pas besoin de connaître la programmation pour utiliser son logiciel professionnel. Une personne qui loue un bureau n'a pas besoin de savoir comment fonctionne la ventilation, il lui suffit de dire: «C'est étouffant au bureau».
Une solution judicieuse concernant l'achat d'un système se fait sur la base du calcul du coût total de possession qui se compose du prix du système et des dépenses de maintenance.
C'est un peu plus compliqué dans les systèmes utilisés dans les maisons. Un opérateur et un utilisateur sont une seule et même personne qui n'a pas la connaissance requise du système. Ce sont malheureusement les limites du marché de la consommation. Et cela conduit aux principes suivants.
6.1. Les appareils fonctionnent ou ne fonctionnent pas. Il n'y a pas de troisième option.
Les travaux probables, les travaux partiels ou les dysfonctionnements sont interdits. Évitez les situations où votre appareil ne fonctionne pas une fois sur deux. Si vous pensez que votre appareil fonctionne mal, éteignez-le pour des raisons de sécurité et pour conserver une expérience utilisateur positive. Remplacer un appareil n'est pas agréable, mais il vaut mieux obliger un utilisateur à remplacer un appareil que de se faire une opinion sur le fait que le système fonctionne «une fois sur deux». Il n'y a que deux états possibles d'un système: il est en panne ou il ne fonctionne pas, il est en ordre et cela fonctionne.
Si vous êtes certain qu'une dégradation du système est possible, informez-en un utilisateur à l'aide d'un message facile à comprendre: "Le deuxième canal de gradateur est hors service. Remplacez le gradateur. Continuer à utiliser le premier canal de gradateur? Oui / Non »
6.2. Le remplacement d'un appareil cassé doit être facile.
Le système doit être un module. Si un capteur tombe en panne, seul ce capteur doit être remplacé. Il n'est pas correct d'exiger le remplacement d'un relais par une télécommande avec un capteur, car ils sont appariés à l'étape de la fabrication.
Il n'est pas correct d'exiger qu '«un nouveau capteur ne puisse être installé que par notre spécialiste», car il est évident qu'avec le temps, vos spécialistes ne suffiront pas à servir des millions d'utilisateurs à mesure que la popularité de votre système augmente. Ainsi, à un certain moment, des problèmes apparaîtront. Bien sûr, un utilisateur ne réparera pas lui-même un appareil, mais lorsqu'il ne fonctionne plus, il doit avoir la possibilité de le remplacer lui-même.
6.3. Messages conviviaux.
Si quelque chose ne va pas, un utilisateur doit le savoir et savoir exactement ce qui s'est mal passé. Vous ne pouvez pas afficher le message "Erreur # 45" impliquant qu'il doit le comprendre. Un message comme celui-ci doit être montré à un utilisateur «L'appareil ne répond pas. Essayez de le recharger et de le réattribuer ou contactez le support technique. Erreur # 45 ”
Vous ne pouvez pas apprendre qu'un appareil ne répond pas (si vous pouvez le faire) et ne pas divulguer ces informations à un utilisateur. Ce n'est pas agréable de recevoir des messages sur un problème. Mais il est beaucoup plus désagréable d'apprendre qu'un appareil est en panne depuis une semaine au moment où vous avez finalement besoin de cet appareil.
6.4. Aucune information supplémentaire dans les messages.
Ne spammez pas un utilisateur avec des journaux. Un utilisateur a besoin d'informations comme dans le principe précédent, car il contient des informations sur ce qui s'est exactement passé. S'il ne comprend pas les informations ou s'il n'est pas le destinataire, il n'en a pas besoin.
N'affichez pas des centaines de messages typiques «la connexion à l'appareil est perdue», «la connexion à l'appareil est rétablie». Vous devez décider s'il s'agit d'informations critiques et un utilisateur doit en être informé. Ou si la connexion est rétablie, ces informations ne sont pas importantes, alors ne les affichez pas
4 .
6.5. Aucune connaissance ou équipement spécial ne doit être requis pour les travaux de maintenance.
Autorisez un utilisateur à mettre à jour le micrologiciel en cliquant sur quelques boutons. Cela peut être fait via une interface standard (USB / BT / Wi-Fi), ou ne mentionnez pas du tout la mise à jour via le programmateur SPI.
Vous ne pouvez pas vous attendre à ce qu'un utilisateur calcule des masques de bits pour configurer un périphérique.
6.6. Le système ne doit pas nécessiter d'entretien constant.
Si un gradateur perd la connexion chaque mois et qu'un utilisateur doit monter sur une échelle pour atteindre une lampe et connecter à nouveau l'actionneur - ce n'est pas pratique. Si les piles doivent être changées dans un interrupteur tous les deux mois - ce n'est pas pratique. Même si la durée moyenne de maintenance d'un appareil est de six mois - ce n'est pas pratique. S'il y a une vingtaine d'appareils dans la maison, un utilisateur doit faire quelque chose tous les neuf jours.
6.7. Le système doit avoir des possibilités de mise à jour et d'extension.
Les dépenses d'extension d'un système doivent croître en progression linéaire.
Évitez les situations où un utilisateur qui souhaite ajouter un capteur doit acheter un nouveau contrôleur, car l'ancien ne prend pas en charge plus de 6 capteurs
5 .
Évitez les situations où un nouveau micrologiciel de capteur ne peut fonctionner qu'avec une nouvelle version d'un contrôleur.
Ces limitations ont une influence positive sur le revenu, incitant les utilisateurs à acheter de nouveaux appareils. Mais c'est une route vers nulle part. Vous pouvez perdre la confiance de vos utilisateurs à cause de ces astuces et, par conséquent, vous perdrez beaucoup plus que ce que vous auriez pu gagner.
7. Autosuffisance: les filets externes sont une option et non une exigence.
Un système où les commandes doivent passer par un serveur externe n'est pas pratique. Vous pouvez parler pendant des heures d'interfaces pratiques, d'applications modernes, de réseaux de neurones sympas, mais ils ne signifient rien si un utilisateur ne peut pas allumer la lumière dans les toilettes lorsque Internet est en panne. Pensez-vous vraiment qu'un tel système peut être considéré comme bon?
Je ne comprends vraiment pas pourquoi ce principe n'est pas tenu pour acquis. Si vous incluez un serveur externe dans un projet, il devient un point d'échec possible. Les services externes sont cool, ils peuvent ajouter plus de fonctions, mais ils ne peuvent pas être la seule variante de contrôle. Bien qu'ils puissent être merveilleusement utilisés comme canal de contrôle supplémentaire, stockage de sauvegarde, outil d'analyse de données, etc.
8. Centralisation: l'absence d'un hub central limite les logiques disponibles.
Mais un système décentralisé n'est pas idéal non plus, bien qu'il soit fiable.
Un système décentralisé est un système dans lequel un interrupteur «dit» à une lampe de «s'éteindre» et un capteur de température allume un radiateur lorsque la température baisse. Un système décentralisé perd à un système centralisé, car il n'est bon que pour une interaction simple entre les périphériques lorsqu'un périphérique contrôle un autre périphérique. Si un système devient plus compliqué, de nombreuses questions apparaissent. S'il y a plusieurs capteurs, le réchauffeur acceptera-t-il la commande de chacun d'eux? Le réchauffeur demande-t-il les capteurs lui-même? Si une décision doit être prise sur l'analyse des données réelles, où stocker les archives? Où stocker et comment changer les logiques? Comment stocker des logiques sur des appareils «stupides»? Comment mettre à jour les logiques?
Toutes ces questions disparaissent s'il est tenu pour acquis qu'un concentrateur est requis comme point d'interaction des données et comme lieu de stockage des logiques d'un utilisateur. Les appareils peuvent être «stupides», c'est-à-dire qu'ils peuvent envoyer des données et obtenir des commandes, car la tâche de stocker des données, de traiter des données, de prendre des décisions et d'interagir avec des services externes incombe au contrôleur central.
La décentralisation peut être partiellement sauvegardée, car lorsqu'il n'y a pas de concentrateur, les commandes peuvent être envoyées directement en mode de sécurité intégrée. Il n'y a pas de logique, mais la lumière peut être allumée.
9. Le système ne doit pas effectuer des actions potentiellement dangereuses sans en informer un utilisateur ou obtenir une confirmation de sa part.
Tant que nous vivons dans un monde où un programmeur n'est pas responsable des dommages causés par son logiciel, il y aura des erreurs dans le logiciel, y compris le logiciel de la maison intelligente. La seule façon de ne pas permettre à une erreur d'avoir des conséquences graves est de limiter les actions indépendantes du système. Les actions potentiellement dangereuses ne doivent être effectuées que lorsqu'un utilisateur en est informé ou encore mieux après qu'un utilisateur les a confirmées. La lumière peut être allumée automatiquement, un bug dans le logiciel réveillera un utilisateur la nuit ou augmentera sa facture d'électricité. Ce n'est pas agréable, mais ce n'est pas dangereux. Mais les robinets d'eau ne peuvent pas s'ouvrir automatiquement s'il n'y a pas d'outils empêchant les inondations. Je pensais qu'il n'est pas dangereux de fermer automatiquement les robinets d'eau.
Cela ne signifie pas que le contrôle automatique des radiateurs, chaudières, cheminées, bouilloires, etc., est interdit. Cela signifie que si vous souhaitez rendre automatique une action potentiellement dangereuse, assurez-vous que le danger n'atteindra pas le niveau utilisateur. Assurez-vous qu'une bouilloire est automatiquement éteinte lorsqu'elle atteint une température définie, qu'un bain a des capteurs de fuite, etc.
10. Le système doit avoir des options d'autocontrôle et d'autodiagnostic.
Un développeur actuel de systèmes de maison intelligente doit être un peu paranoïaque. On ne peut pas faire confiance à Internet, il peut être en panne. Le code n'est pas fiable, il peut y avoir des bugs. Peut-on faire confiance au matériel? Non, le matériel ne peut pas être utilisé. Les relais peuvent coller, les triacs peuvent s'ouvrir, les fusibles peuvent brûler. Même un utilisateur peut connecter une bouilloire de 1 kW à une prise de 100 watts. Ainsi, un capteur de tension, un capteur de courant et un capteur de température sont nécessaires. Si la température dépasse les limites - éteignez tout et envoyez un avertissement. Si le courant dépasse les limites - éteignez tout. Si un relais est désactivé, mais qu'il y a encore de la tension - envoyez une notification. Si vous désactivez un relais et qu'il n'y a pas de tension - envoyez une notification.
11. Le système doit avoir un contrôle manuel.
Même si vous considérez toutes les choses paranoïaques, il y aura une situation où tous les contrôles auront échoué et quelque chose sera tombé en panne. Il peut s'agir d'un interrupteur, d'un routeur ou du concentrateur central, mais néanmoins un utilisateur souhaite allumer la lumière dans les toilettes. Que faire?
Il doit toujours y avoir un bouton qui peut faire coucher le soleil en mode manuel, un bouton qui peut allumer / éteindre la lumière à droite MAINTENANT. Comme il faudra un jour pour livrer un nouveau hub et un nouvel interrupteur peut être acheté plus tard, mais la lumière dans la chambre doit être éteinte ce soir.
12. Les pirates sont aussi importants que les utilisateurs réguliers.
Les utilisateurs réguliers vous apportent de l'argent, les pirates
6 peuvent penser à de nouvelles fonctions. Une fabrication ne peut pas et ne doit pas développer toutes les scènes d'utilisation du système, car il n'a pas de connaissances dans toutes les sphères et il ne peut pas calculer l'effet de telles choses. Il est tout à fait possible qu'une prise intelligente puisse être pratique à contrôler via le thermostat d'une brasserie mobile, car elle possède un régulateur PID. L'exemple est un peu tiré par les cheveux, mais l'idée est qu'il n'est pas mauvais de créer des conditions pratiques pour les pirates, car ils peuvent ajouter la puissance de déplacement à votre système.
13. Ouverture: le système doit avoir une API ouverte pour s'intégrer à d'autres systèmes.
Vous ne pouvez pas répondre à tous les besoins de vos clients avec vos propres appareils. Il y aura toujours des appareils que vous n'avez pas. Ou vous pouvez avoir les appareils, mais les appareils d'autres fabricants peuvent être meilleurs. Pour connecter votre système à d'autres, il est absolument nécessaire d'avoir une API ouverte et bien documentée. Si vous n'avez pas d'API, vos utilisateurs ne peuvent pas avoir de systèmes hétérogènes. Mais même les grandes entreprises de matériel et de logiciels propriétaires ne peuvent pas se le permettre.
14. Documentation: elle est aussi importante que le matériel et le code.
Peu importe à quel point votre matériel est cool ou à quel point votre logiciel est bon, si un utilisateur ne peut pas comprendre comment démarrer votre système et comment l'utiliser. Une bonne documentation est celle après la lecture à laquelle un utilisateur ne pense pas à contacter le support technique ou ne donne pas d'évaluation négative des capacités mentales du développeur. Il est impossible d'écrire une telle documentation, mais c'est quelque chose à rechercher.
Et le dernier mais non le moindre:
15. Autosuffisance et autosuffisance: le système doit continuer de fonctionner, même si l'entreprise n'existe plus.
Une personne vit environ 70-90 ans, un système installé chez lui fonctionne environ 5-10 ans (au mieux), les entreprises durent encore moins. Ne créez pas un système qui cessera de fonctionner si votre entreprise décède. Sentez-vous pour les utilisateurs. Planifiez le système de manière à ce qu'il puisse être utilisé même si l'entreprise et le développeur ne sont plus dans ce monde.
Si un appareil est affecté à l'obtention d'un jeton du serveur d'un développeur, créez un bouton «Ignorer l'obtention d'un jeton». Si le micrologiciel doit être mis à jour depuis le site Web lors du premier démarrage du système, autorisez le téléchargement du micrologiciel par défaut si le site Web n'est pas disponible. Et ainsi de suite.
Dans cet article, j'ai essayé de décrire l'expérience de l'utilisation, du développement de tels systèmes et de leur utilisation en 15 principes. Une partie d'entre eux peut sembler farfelue, d'autres sont discutables (c'est normal), et d'autres sont galvaudées (c'est aussi normal).
Mais si vous avez pris le temps de penser même à l'un d'eux, l'article n'a pas été écrit en vain.
Commentaires
1. Par «utiliser», j'entends le processus d'interaction régulière avec le système, mais pas la mise en place.
2. Je voudrais souligner que je dis «un utilisateur ne doit pas remarquer», mais pas «le délai doit être le même que». La pratique montre qu'un humain ne remarque pas un retard de 300 millisecondes.
3. Il a peut-être grandi en Asie et pense que le meilleur remède contre la chaleur est le thé vert chaud.
4. Lorsque je dis «ne pas afficher d'informations», cela signifie qu'un utilisateur ne doit pas recevoir de message à ce sujet à chaque fois. Il doit être affiché à la demande d'un utilisateur - par exemple, «afficher le journal» ou «afficher les informations de débogage» lorsqu'un bouton est enfoncé. Ne considérez pas les utilisateurs comme des idiots, respectez leur temps.
5. Il est bien sûr impossible de concevoir un système prenant en charge un nombre illimité d'appareils. Il y aura toujours des limites, mais c'est la tâche du développeur de les rendre non pertinentes dans 99% des cas. Limiter à 6 capteurs est inacceptable. Cent ou deux cents appareils dans un même réseau suffisent à la plupart des utilisateurs de maisons intelligentes.
6. J'utilise le mot «pirate» dans le sens essentiel de ce mot selon la RFC1983, et non pas le sens d'une personne qui utilise des ordinateurs pour obtenir un accès non autorisé aux données.
Ce texte a été aidé à traduire en anglais par iRidium Mobile , pour lequel je les remercie beaucoup.