Nous portons à votre attention un article de Vladislav Zaitsev ( vvzvlad ), un invité invité de notre blog. Vladislav s'intéresse depuis longtemps au thème des «maisons intelligentes» et, résumant son expérience, il propose les principes de base suivants pour la conception de tels systèmes.Aujourd'hui, je veux vous parler des maisons intelligentes en particulier et des appareils IoT en général. Mais ce ne sera pas un article ordinaire: il n'y aura pas de glandes, de liens vers les fabricants, de morceaux de code et de référentiels sur le github. Aujourd'hui, nous discuterons de quelque chose de plus élevé - les
principes selon lesquels les systèmes «intelligents» sont organisés.
En continuant à lire l'article, vous acceptez d'être satisfait de la clause de non-responsabilité suivante.
Exonération de responsabilité- Tous ces points concernent uniquement les systèmes IoT grand public (lire «maisons intelligentes»). Ceux qu'une personne peut acheter dans le magasin et installer sans la participation d'installateurs / intégrateurs spécialisés.
- Certains de ces principes ne s'appliquent pas aux systèmes industriels (il y a leurs propres exigences et principes), ainsi qu'aux systèmes où il y a des opérateurs séparés de l'utilisateur (par exemple, une maison intelligente installée et entretenue par des personnes spécialement formées).
De plus, certains des principes ne s'appliquent pas aux systèmes de niveau «jouet pour les geeks», aux systèmes maison et open source qui n'ont pas un seul propriétaire de produit. - Et, bien sûr, tout ce qui est écrit ci-dessous est uniquement mon opinion basée sur mes nombreuses années d'expérience. Vous avez le droit d'être en désaccord avec lui.
Une maison intelligente est un système qui prend en charge une partie des soucis quotidiens d’une personne. D'ici suit le premier principe et le plus fondamental:
1. Une maison intelligente devrait vous faciliter la vie.
Une maison intelligente est un système pour la vie, pas un jouet pour les geeks. Tout système plus difficile à utiliser
1 que les commutateurs conventionnels n'est pas une maison intelligente.
Tout nouveau produit doit être testé pour vérifier sa conformité à ce principe. Si cela ne rend pas la vie plus facile et que vous ne savez pas comment la rendre plus facile, elle n'a pas sa place dans une maison intelligente. Vous pouvez essayer de l'imaginer comme un système d'apprentissage.
Le deuxième principe le plus important concerne la façon dont l'utilisateur interagit avec le système:
2. Une bonne expérience utilisateur est plus importante que la fonctionnalité.
Sans valeur est un outil génial qui ne peut pas être utilisé normalement. Les appareils pratiques et fiables avec des fonctionnalités limitées ont plus de chances de réussir que les produits sophistiqués pour "toutes les occasions".
2.1. Les interfaces pratiques sont meilleures que la personnalisation.
Vous ne comprenez pas comment enregistrer un tas de fonctions et une interface simple? Vous appuyez sur toutes les fonctions d'affilée dans l'espoir que l'utilisateur trouvera ce dont il a besoin? Sortez de la profession!
Vous ne comprenez pas comment combiner la commodité et un tas de paramètres? Faites don des paramètres. Toute fonctionnalité sera plus froide qu'un interrupteur ordinaire, mais une complexité excessive forcera facilement l'utilisateur à revenir au commutateur.
Il en va de même pour la qualité du travail. Un bouton qui allume simplement la lumière est meilleur qu'un curseur de réglage de la luminosité, qui pépine parfois:
2.2. La qualité des fonctions implémentées est plus importante que leur quantité.
Une fonctionnalité peu fiable, mais éprouvée est meilleure que beaucoup, mais elle fonctionne d'une manière ou d'une autre.
L'un des mécanismes fixés dans la psyché humaine par l'évolution est une réaction plus active aux stimuli négatifs. Les facteurs négatifs sont plus importants que les facteurs positifs: sauter l'approche d'un dangereux prédateur est bien pire que de ne pas le remarquer et de ne pas manger un délicieux fruit sur un arbre. Si votre système n'a aucune fonction, ce n'est pas effrayant, c'est simplement l'absence d'incitation positive. Mais la fonction existante, mais qui fonctionne mal, est une incitation négative: on s'en souvient plus facilement et on s'en souvient plus longtemps.
2.3. La mise en œuvre du système ne doit pas réduire la vitesse de travail habituelle.
Les retards sont inacceptables car ils dégradent l'expérience utilisateur. Il s'agit également d'une incitation négative. Si une personne ne remarque pas de délai
2 entre le clic d'un interrupteur conventionnel et l'inclusion de lumière, elle ne doit pas le remarquer dans votre système.
Le fer moderne fonctionne à très grande vitesse. Il n'y a aucun problème à atteindre des fréquences de dizaines de mégahertz sur des microcontrôleurs et au moins des dizaines de kilobits par seconde, même en direct. Si vous ne pouvez pas créer un système dans ces conditions, l'utilisateur ne ressent aucun retard dans son fonctionnement, sortez du métier!
2.4. Le système ne doit pas briser les habitudes déjà formées de l'utilisateur.
Votre système n'est qu'un petit morceau de vie humaine. La durée de vie d'une personne dépasse la durée de vie du système au mieux de quelques fois, et au pire d'un ordre de grandeur. Votre système restera tel qu'il sera et la vie humaine continuera. Et dans cette vie, une personne a pris des habitudes concernant la luminosité préférée de la lumière, l'emplacement des interrupteurs, la façon dont il est commode d'allumer la lumière et de contrôler le climat à la maison.
Vous ne pouvez pas changer de force ces habitudes. Il est possible d'offrir. Forcer - c'est impossible.
Vous ne pouvez pas dire à l'utilisateur "vous allez maintenant allumer la lumière du téléphone - il est élégant, à la mode, jeune". Il s'agit d'une violation de ce principe et de plusieurs autres.
Alors que faire?
2.5. Le système doit apporter une nouvelle expérience et ne pas essayer de remplacer l'ancien.
Si vous pensez que votre façon de gérer les systèmes à domicile est meilleure que l'ancienne, offrez-la à l'utilisateur. Si c'est vraiment plus pratique, il en choisira une nouvelle (oui, différentes méthodes conviennent à différentes personnes). Tout ce que vous pouvez (et devriez) faire, c'est lui donner le choix.
Une place importante dans une maison intelligente est occupée par la logique du travail. Ce qui détermine par quelles règles cette maison intelligente fonctionnera. Et le principe important suivant est à peu près tout:
3. L' utilisateur ne peut être limité dans la logique qui lui est accessible.
Si l'utilisateur souhaite allumer la bouilloire
3 lorsque la température augmente dans la pièce, donnez-lui la possibilité de le faire. Une situation doit être exclue lorsqu'il n'y a pas de limitations physiques ou logicielles pour effectuer une certaine action, mais elle n'est pas disponible, car le développeur pensait que "personne n'en aura jamais besoin".
3.1. Aussi simple que possible: l'écriture de la logique ne devrait pas nécessiter de connaissances particulières sur le périphérique système
Si vous avez des appareils de versions différentes avec des protocoles différents, assurez-vous que l'utilisateur ne le sait que dans les cas vraiment nécessaires, lorsque vous ne pouvez pas vous en passer. Si vous pouvez empêcher l'utilisateur d'acquérir des connaissances particulières, mais au prix du temps des développeurs, faites-le. Le développeur passera deux jours et mille utilisateurs par heure. Quarante-huit heures contre mille? La réponse est évidente.
Comment dormez-vous, John est un programmeur en série?
3.2. Les appareils ayant les mêmes fonctions doivent être contrôlés de manière égale.
L'utilisateur n'a pas à savoir que la vanne d'eau est contrôlée par certaines commandes et le robinet par d'autres. Si les deux contrôlent l'eau dans le tuyau, alors ils doivent tous les deux avoir la même interface utilisateur: «eau ouverte» et «eau fermée».
Nous vivons tous dans le monde physique. Le corps humain et le cerveau sont formés pour interagir avec des objets physiques. D'où le principe:
4. Les dispositifs de contrôle physiques sont meilleurs que les dispositifs virtuels.
Tout, même les meilleures applications du téléphone avec des boutons de commande virtuels perdent au commutateur physique habituel au bon endroit.
Une autre chose est que le commutateur doit être situé au
bon endroit . D'où une autre règle importante:
5. La radio est meilleure que les fils.
Les systèmes câblés sont fiables, mais seule la communication radio vous permet d'installer un nouvel interrupteur ou relais pour la lampe sans avoir à le réparer à nouveau. Et transfert, si vous vous ennuyez de l'endroit précédent. Mais ce principe a ses exceptions:
5.1. Une mauvaise radio est pire que des fils.
Une bonne radio est celle qui vous permet de ne pas penser à quelle distance du contrôleur central les appareils doivent être placés. Une bonne radio est les protocoles de
réseau maillé : ZigBee, Z-Wave, 6LoWPAN et ainsi de suite.
Toutes les autres options sont une mauvaise radio. Le Wi-Fi est une mauvaise radio. Protocoles faits maison par des entreprises individuelles (ils sont connus sous le nom de self-made sous le nom de "433 MHz", bien qu'ils puissent être à d'autres fréquences et peuvent être très différents les uns des autres) - mauvaise radio.
Le Wi-Fi est mauvais car il est impossible de fabriquer des appareils «dormants» à part entière, et il est difficile de faire une configuration automatique, ainsi que des problèmes de compatibilité avec d'autres appareils Wi-Fi de la maison. Les protocoles simples faits maison sont mauvais car ils ne contiennent souvent pas de contrôle de livraison, de cryptage ou de spécifications disponibles. Aucun des deux n'a de routage maillé, ce qui entraîne souvent des problèmes comme «mais je ne peux pas mettre un commutateur dans ce coin - trop loin de l'émetteur».
Il est impossible de réaliser un système d'une fiabilité absolue et sans nécessiter de maintenance. Les appareils tombent en panne, des surtensions surviennent dans le réseau, l'eau coule de l'appartement des voisins, les piles se vident, les fissures en plastique, l'enfant verse de la soupe sur la lampe, etc. Mais:
6. La réparation, la mise à jour, la maintenance et les diagnostics doivent être simples.
Tout est clair en B2B: il y a un utilisateur, il y a un développeur et il y a un opérateur - une personne ou une organisation qui sait comment le système fonctionne et peut travailler avec lui à un niveau professionnel. Personne n'a besoin d'une connaissance comptable de la programmation sous 1C, c'est une personne spéciale. Et personne n'exige qu'une personne qui loue un bureau comprenne comment fonctionne la ventilation - son travail consiste à dire: "C'est étouffant dans notre bureau."
Une décision compétente pour acheter un système est basée sur le calcul du coût total de possession, qui est la somme du prix du système et du coût de son fonctionnement.
Dans les systèmes qu'une personne utilise à la maison, tout est plus compliqué. Là, l'opérateur et l'utilisateur sont une seule et même personne, et en plus souvent n'ont pas les connaissances nécessaires sur le système. Ce sont malheureusement les limites du marché de la consommation. D'où les principes suivants:
6.1. L'appareil doit fonctionner ou ne pas fonctionner. Il n'y en a pas de troisième.
La probabilité de travail, de travail partiel et de travail incorrect n'est pas autorisée. Vous ne devez pas autoriser les situations dans lesquelles votre appareil fonctionne une fois sur deux ou ne fonctionne pas une fois sur dix. Si vous pensez que votre appareil fonctionne mal, vous devez l'éteindre complètement - pour plus de sécurité et pour maintenir une expérience utilisateur positive. Le remplacement de l'appareil est désagréable, mais il vaut mieux forcer l'utilisateur à le remplacer que de se forger une opinion «fonctionne une fois» sur le système. Le système doit être dans un état strictement défini: s'il tombe en panne, alors il ne fonctionne pas, s'il ne tombe pas en panne, alors il fonctionne.
Si vous êtes fermement convaincu que la dégradation des fonctionnalités est acceptable, vous devez tout de même avertir l'utilisateur d'un message clair: «Une défaillance du deuxième canal de gradateur a été détectée. Il est nécessaire de remplacer le variateur. Continuer à utiliser le premier canal de gradateur? Oui / non
6.2. Le remplacement d'un appareil cassé devrait être facile.
Le système doit être modulaire. Si l'utilisateur casse le capteur, il devrait seulement avoir besoin de remplacer le capteur. Vous ne pouvez pas exiger de changer le relais avec le panneau de commande, car, voyez-vous, il y est attaché au stade de la production.
Vous ne pouvez même pas dire «seul notre spécialiste peut installer un nouveau capteur», car évidemment, avec le développement de votre système, il n'y aura pas assez de spécialistes pour des millions d'utilisateurs possibles, ce qui signifie que les problèmes commenceront à un moment donné. Bien entendu, l'utilisateur ne réparera pas lui-même l'appareil, mais en cas de panne il devra pouvoir les remplacer.
6.3. Messages clairs.
En cas de problème, l'utilisateur doit le savoir et savoir exactement ce qui s'est mal passé.
Il est impossible de dire à l'utilisateur «Erreur # 45», ce qui implique que seul l'employé du support technique comprendra ce message. Il doit dire: «L'appareil ne répond pas. Essayez de le redémarrer, de vous lier à nouveau ou de contacter le service. Erreur n ° 45. "
Il est impossible de détecter que l'appareil ne répond pas (si vous en avez la possibilité) et de ne pas en informer l'utilisateur. Ce n'est pas très agréable de recevoir un message sur des problèmes, mais c'est beaucoup plus désagréable de comprendre que l'appareil ne fonctionne pas depuis une semaine, au moment même où vous en avez un besoin urgent.
6.4. Manque d'informations inutiles dans les messages.
Mais en même temps, vous n'avez pas besoin de vider les vidages de débogage et les journaux multilignes sur l'utilisateur. Les informations sont nécessaires à l'utilisateur, comme dans le paragraphe précédent, car elles contiennent des informations sur ce qui s'est exactement passé, ou ne sont pas nécessaires si ces informations supplémentaires ne sont pas claires, car elles ne lui sont pas adressées.
Pas besoin de montrer à l'utilisateur une centaine de messages du même type: «la connexion avec l'appareil a été perdue», «la communication avec l'appareil a été rétablie». Décidez enfin: soit il s'agit d'un problème critique, et vous devez le signaler de la bonne manière - «Communication instable avec l'appareil», ou, comme il s'est avéré être restauré, ce ne sont pas des informations importantes et vous n'avez pas besoin de le montrer
4 .
6.5. La maintenance ne nécessite pas de connaissances et d'équipements spéciaux.
Donnez à l'utilisateur la possibilité de mettre à jour le firmware - laissez-le être mis à jour simplement en appuyant sur quelques boutons. Et cela se fera soit via l'interface standard (USB / BT / Wi-Fi), soit ne mentionne pas dans la documentation utilisateur la mise à jour du firmware à l'aide du programmateur SPI en général.
Vous ne pouvez pas obliger l'utilisateur à calculer des masques de bits pour une configuration de périphérique si cette configuration est requise en utilisation normale.
6.6. Le système ne devrait pas nécessiter de maintenance continue.
Si une fois par mois un lien vole vers l'unité exécutive, et que l'utilisateur doit monter vers le lustre et l'attacher à nouveau, c'est un mauvais système. Si l'interrupteur doit changer les piles une fois tous les deux mois - c'est un mauvais système. Même la période de maintenance moyenne de six mois pour chaque appareil est mauvaise: pour vingt appareils dans la maison, l'utilisateur devra prendre des mesures en moyenne tous les neuf jours.
6.7. Le système doit pouvoir être mis à jour ou étendu.
Le coût de l'expansion du système devrait augmenter linéairement. Un nouveau bloc devrait coûter le coût d'un nouveau bloc.
Il ne devrait pas y avoir de situation où vous devez acheter un nouveau contrôleur pour ajouter un nouveau capteur, car l'ancien ne prend pas en charge plus de six capteurs
5 .
Il ne devrait pas y avoir de situation où un nouveau micrologiciel de capteur ne peut fonctionner qu'avec une nouvelle version de l'unité de contrôle.
De telles restrictions ont un effet positif sur les bénéfices, forçant les utilisateurs à acheter de nouveaux appareils, mais c'est la voie de l'enfer - en perdant la confiance des utilisateurs en raison de ces astuces, vous perdrez beaucoup plus que vous ne pourriez gagner.
7. Autosuffisance: les réseaux externes sont une option et non une nécessité.
Un système dans lequel les équipes passent uniquement par un serveur externe est un mauvais système. Vous pouvez vous vanter des interfaces pratiques, des applications à la mode et des réseaux de neurones sympas autant que vous le souhaitez, mais peu importe si l'utilisateur, avec la chute d'Internet, a perdu la possibilité d'allumer la lumière dans les toilettes. Développeur, pensez-vous vraiment qu'un tel système est bon?
Mais sérieusement, je ne comprends pas vraiment pourquoi cet article n'est pas une évidence. En liant le système à un serveur externe, vous créez un point de défaillance avec la fiabilité d'un serveur normal, mais en même temps pour tous vos utilisateurs. Les services externes sont cool, ils vous permettent d'étendre les fonctionnalités, mais ne devraient pas être la seule option pour la gestion opérationnelle. Un canal de contrôle supplémentaire, un stockage de sauvegarde, une analyse des données - autant que vous le souhaitez.
8. Centralisation: l'absence d'un hub central limite la logique disponible.
Cependant, ne vous précipitez pas à l'autre extrême - essayez de rendre le système décentralisé et donc absolument fiable.
Un système décentralisé est lorsque l'interrupteur dit «allumer» l'ampoule et que le capteur de température allume le chauffage lorsque la température baisse. Un système distribué perd centralisé simplement parce qu'un tel système n'existe bien que dans le cadre du paradigme d'interaction entre appareils le plus simple - «l'appareil contrôle un autre appareil». À mesure que la complexité du système augmente, un tel système soulève plus de questions que de réponses. S'il y a plusieurs capteurs de température, le réchauffeur doit-il accepter les commandes de tout le monde? Ou devrait-il interroger lui-même les capteurs? Et si vous devez prendre une décision d'inclusion en fonction de la tendance, où stocker les données d'archives? Sur chaque radiateur? N'est-ce pas audacieux? Sur chaque appareil? Et générer du trafic à chaque demande? Et où stocker et comment changer la logique? Et si la logique inclut des éléments externes? Et comment stocker la logique sur des appareils "stupides"? Et comment le mettre à jour?
Tous ces problèmes disparaissent si vous vous réconciliez et reconnaissez la nécessité d'un hub central comme point d'interaction entre les données et les emplacements de stockage pour la logique utilisateur. Que tous les appareils soient «stupides», capables d'envoyer des données et de recevoir des commandes, et la tâche de stocker les données d'archives, de traiter ces données, de prendre des décisions et d'interagir avec des services externes incombera au contrôleur très central.
Soit dit en passant, la décentralisation peut être préservée, bien que partiellement: rien ne vous empêche d'envoyer une commande directement, car il existe un mode de sécurité intégrée, en l'absence de réponse du concentrateur. Il n'y aura pas de logique, mais il sera possible d'allumer la lumière.
9. Le système ne doit pas exécuter des actions potentiellement dangereuses sans confirmation ou notification à l'utilisateur.
Tant que nous ne vivons pas dans un monde où le programmeur est responsable des dommages causés par son programme (bien écrit sur ce sujet
ici ), il y aura de nombreuses erreurs dans les programmes. Ils seront dans le logiciel d'une maison intelligente. La seule possibilité dans laquelle ces erreurs n’entraînent pas de conséquences désastreuses est la limitation des actions indépendantes du système. Les actions potentiellement dangereuses doivent être effectuées au moins à la connaissance de l'utilisateur, et de préférence avec sa confirmation. Vous pouvez allumer la lumière automatiquement: un bug dans le programme provoquera le réveil de l'utilisateur la nuit ou recevra une facture pour une centaine de roubles supplémentaires à la fin du mois. Désagréable, mais peu dangereux. Par exemple, il est impossible d'allumer l'eau automatiquement, si aucun mécanisme n'est garanti pour l'éteindre lors d'une inondation. Mais fermez l'eau - vous le pouvez, car ce n'est pas une action dangereuse.
Ce principe n'indique pas qu'il est impératif d'interdire la commande automatique de tous les appareils de chauffage, chaudières, poêles, bouilloires et similaires. Il s'agit plutôt du fait que si vous fabriquez déjà un appareil potentiellement dangereux avec un contrôle de programme, assurez-vous que son danger n'atteint pas le niveau de l'utilisateur: la bouilloire contrôlée doit avoir des circuits de "fer" qui l'éteignent lors d'une surchauffe; le bain, qui est rempli par lui-même, doit avoir des capteurs d'inondation; le fer doit pouvoir s'éteindre, mais ne le rallumez que lorsque vous appuyez sur le bouton «fer», etc.
10. Le système doit être capable de se contrôler et de s'auto-diagnostiquer.
Un vrai développeur de systèmes intelligents devrait être un peu paranoïaque. Vous ne pouvez pas faire confiance à Internet, il peut disparaître. Vous ne pouvez pas faire confiance au code, il peut contenir des bogues. Peut-être qu'au moins le matériel peut être fiable? Non. Vous ne pouvez pas faire confiance à votre matériel. Le relais peut coller, les triacs s'ouvrent spontanément, les fusibles sautent. Enfin, l'utilisateur peut brancher la bouilloire de kilowatt sur une prise de 100 watts. Besoin de capteurs tension, courant, température. La température est-elle hors limites? Éteignez tout, envoyez un avertissement. Le courant est allé au-delà - coupez-le. Ils ont coupé le relais, mais y a-t-il encore de la tension à la sortie? Remarquez. Allumé, mais il n'y a pas de tension? Remarquez!
11. Le système doit pouvoir être contrôlé manuellement.
Et même avec toutes ces choses paranoïaques, il y aura toujours une situation où les vérifications ont échoué et quelque chose s'est cassé. Switch dans la chambre, routeur, hub central. Et l'utilisateur veut allumer la lumière dans les toilettes. Quelle conclusion?Il devrait toujours y avoir un bouton qui peut être utilisé pour faire "coucher le soleil manuellement". Qui peut allumer ou éteindre la lumière IMMÉDIATEMENT. Parce qu'ils apporteront un nouveau hub demain, vous pouvez acheter un interrupteur un peu plus tard, et vous souhaitez éteindre la lumière dans la chambre ce soir-là afin de dormir paisiblement.12. Les développeurs et les pirates sont aussi importants que les utilisateurs ordinaires.
Les utilisateurs ordinaires feront de vous un caissier et des pirates 6 - proposer de nouvelles fonctionnalités. Le fabricant ne sera pas en mesure et ne devrait pas développer tous les scénarios d'utilisation du système, car il n'a évidemment pas de connaissances dans tous les domaines et ne peut pas évaluer l'effet du développement de ces domaines. Il est possible que votre prise contrôlée se révèle être incroyablement pratique pour contrôler le thermostat du clair de lune, car il y a un régulateur PID dans la bibliothèque de solutions, et maintenant tous les clair de lune achètent vos systèmes en masse. Un exemple est quelque peu artificiel, mais le message principal est qu'au prix de certains efforts, il vaut la peine de créer un environnement confortable pour les pirates, car ils ajoutent une force motrice à votre système.13. Ouverture: le système doit avoir une API pour l'intégration avec d'autres systèmes.
Vous ne pouvez pas couvrir tous les besoins de vos clients avec vos appareils. Il y aura toujours des appareils que vous n'avez pas, mais d'autres fabricants en ont. Ou vous l'avez, mais d'autres fabricants sont meilleurs. Ou vous serez le fabricant dont l'unité unique est la meilleure. Une API ouverte et bien documentée est requise pour connecter votre système à d'autres. Si vous ne disposez pas d'une API, vous refusez aux utilisateurs la possibilité de créer des systèmes hétérogènes. Même les entreprises, les plus ardents défenseurs du matériel et des logiciels propriétaires, ne peuvent pas se le permettre.14. Documentation: la documentation est une partie aussi importante du système que le code et le matériel.
Quel que soit le matériel que vous possédez et le logiciel que vous écrivez, peu importe si l'utilisateur ne sait pas comment démarrer votre système et comment l'utiliser. Une bonne documentation en est une lorsque vous travaillez avec laquelle l'utilisateur n'a même pas pensé à contacter le support ou à évaluer négativement les capacités mentales du développeur. La rédaction d'une telle documentation est presque impossible, mais nous devons nous efforcer de le faire.Et enfin, le dernier principe (mais loin du dernier en termes d'importance):15. Autosuffisance et autosuffisance: le système devrait continuer de fonctionner, même si l'entreprise a cessé de fonctionner
Une personne vit de 70 à 90 ans, le système dans sa maison est de 5 à 10 ans (au mieux) et les entreprises sont souvent plus petites. Vous ne devez pas créer un système, la capacité de travailler avec laquelle vous vous traînez avec vous dans la tombe. Dommage les utilisateurs. Concevez le système de manière à pouvoir travailler avec lui, même si l'entreprise et les développeurs sont tombés dans l'oubli depuis longtemps.La liaison d'un nouvel appareil se produit-elle lors de la réception d'un jeton du serveur du développeur? Activez le bouton «Ignorer le jeton de réception». Lorsque vous allumez le système pour la première fois, devez-vous mettre à jour le micrologiciel à partir du site? Assurez-vous que le firmware par défaut est inondé lorsque le site n'est pas disponible. Et ainsi de suite.
Dans cet article, j'ai essayé de décrire toute l'expérience d'utilisation, de travail et de conception de tels systèmes, compressée en 15 principes de base. Certains d'entre eux peuvent sembler farfelus, certains peuvent être controversés (et c'est normal), et certains peuvent être banals (et cela est également normal).Mais si vous pensez à au moins l'un d'entre eux, cela signifie que l'article n'a pas été écrit en vain.Notes de bas de page et commentaires
1. Quand je dis «utiliser», je ne parle pas du processus de configuration, mais du processus d'interaction normale avec le système.2. Veuillez noter que je ne dis pas «le délai devrait être le même», mais «l'utilisateur ne devrait pas le remarquer». La pratique montre qu'une personne ne remarque pas de retard allant jusqu'à environ 300 ms.3. Il a peut-être grandi en Asie centrale et pense que le meilleur remède contre la chaleur est le thé vert chaud.4. Bien sûr, lorsque je dis «pas besoin de montrer des informations», cela signifie que vous ne devez pas envoyer de message à l'utilisateur à ce sujet à chaque fois. Il doit être affiché à la demande de l'utilisateur - en cliquant sur les boutons "afficher les journaux" ou "afficher les informations de débogage". Les utilisateurs ne doivent pas être considérés comme des idiots, mais leur temps doit être respecté.5. Bien sûr, il est impossible de concevoir un système prenant en charge un nombre infini d'appareils. Il y aura toujours des restrictions, mais la tâche du développeur est de s'assurer qu'il ne joue pas de rôle dans 99% des cas. Une limite de six capteurs est inacceptable. Cent deux cents appareils dans un réseau est un nombre suffisant pour la plupart des utilisateurs de maisons intelligentes.6. Je parle de hackers dans le sens originel du mot, selon la RFC1983 , et non de hackers.