Manifiesto del desarrollador de casas inteligentes: 15 principios

Hoy me gustaría hablar sobre hogares inteligentes y dispositivos IoT. Pero no es un artículo ordinario. No encontrará una descripción del hardware, enlaces a fabricantes, lotes de código o repositorios. Hoy discutiremos algo de un nivel superior: principios que se utilizan para organizar sistemas "inteligentes".

imagen



Smart Home es un sistema que puede hacer algunas rutinas diarias en lugar de una persona. Nos lleva al primer y principal principio:

1. El hogar inteligente debe hacer la vida m√°s f√°cil.


La casa inteligente es un sistema para vivir, no es un juguete para geeks. Los sistemas que son m√°s complicados en el uso 1 que un interruptor no son Smart Home.

Cualquier cosa nueva tiene que ser probada contra este principio. Si no facilita la vida y no comprende cómo mejorarla para facilitar la vida, no es para el hogar inteligente.



El segundo principio importante es c√≥mo un usuario interact√ļa con el sistema:

2. La buena experiencia del usuario es m√°s importante que la funcionalidad.


Una herramienta genial que es difícil de usar no vale un centavo. Los dispositivos convenientes y confiables con funciones limitadas tienen muchas más posibilidades de éxito en comparación con los dispositivos complicados para todos los usos y aplicaciones posibles.

2.1. Las interfaces convenientes son mejores que la personalización.


Si no comprende cómo combinar numerosas funciones y una interfaz simple y simplemente almacena todas las funciones con la esperanza de que un usuario pueda resolverlo todo por sí mismo, tal vez debería reconsiderar su elección de carrera.

Si no comprende cómo integrar la conveniencia y numerosas funciones, elimine algunas configuraciones. Cualquier función es mejor que un interruptor normal. Pero si es demasiado complicado, un usuario volverá a un cambio.

Lo mismo puede decirse sobre la calidad del trabajo. Un botón que simplemente apaga la luz es mejor que un atenuador que a veces funciona y otras no:

2.2. La calidad de las funciones realizadas es m√°s importante que la cantidad de funciones


Es mejor tener pocas funciones confiables que numerosas que funcionan mal.

Uno de los mecanismos desarrollados en la mente del hombre en el curso de la evolución es una reacción más emocional a los estímulos negativos. Los factores negativos son más importantes que los positivos: es mucho más peligroso no notar un tigre que se acerca que perder una fruta madura en un árbol. Si su sistema no tiene ciertas funciones, no tiene nada de malo. Es simplemente la ausencia de un estímulo positivo. Pero si tiene una función pero funciona mal, es un estímulo negativo que se recuerda fácilmente durante mucho tiempo.

2.3. El uso del sistema no debe disminuir la velocidad de trabajo habitual


Los retrasos son inadmisibles ya que tienen un efecto negativo en la experiencia del usuario. Es un estímulo negativo también. Si una persona no nota ninguna demora entre un interruptor del interruptor y la luz encendida, no debe notarlo en su sistema.

El hardware moderno funciona a alta velocidad. No hay problema para alcanzar frecuencias de docenas de MHz en los controladores y al menos docenas de kilobits por segundo, incluso a trav√©s de un canal de radio. Si con este hardware su usuario a√ļn experimenta retrasos en el trabajo, deber√≠a reconsiderar su elecci√≥n de carrera.

2.4. El sistema no debe romper los h√°bitos de usuario ya formados.


Su sistema es una peque√Īa parte de la vida de una persona. Por lo general, la vida de una persona excede el per√≠odo de explotaci√≥n de un sistema. Por lo tanto, los sistemas ir√°n y vendr√°n y la vida de una persona continuar√°. Y esta vida est√° llena de h√°bitos formados sobre el brillo de la luz, las ubicaciones de los interruptores y la forma en que √©l o ella lo encuentra conveniente para controlar la luz y el clima.

Los h√°bitos no pueden ser cambiados por la fuerza. Se pueden ofrecer cosas nuevas pero no forzadas.
No puede decirle a un usuario: "Ahora encenderá la luz desde un teléfono inteligente: es moderno, elegante y moderno". Va en contra de este principio y algunos otros también.

Que hacer

2.5. El sistema debe aportar una nueva experiencia y no reemplazar la anterior.


Si cree que su forma de controlar los sistemas domésticos es mejor que una anterior, ofrézcala a un usuario. Si es realmente conveniente, él mismo elegirá el nuevo (sí, diferentes personas eligen diferentes formas). Todo lo que puedes (y debes) hacer es darle una opción.



La lógica del trabajo juega un papel importante en el hogar inteligente. Define la regla por la que trabaja Smart Home. Y nos lleva al siguiente principio:

3. La lógica del usuario no puede ser limitada.


Si un usuario quiere hervir un hervidor de agua 3 cuando la temperatura en una habitación aumenta, déjelo hacerlo. También debe evitar una situación en la que se pueda realizar una acción requerida en los niveles de hardware o software, pero no está disponible solo porque un desarrollador pensó que "Nadie la necesitará".

3.1. Cuanto más simple, mejor: la creación de lógicas no debe requerir un conocimiento especial de la estructura del sistema.


Si tiene dispositivos de diferentes versiones y con diferentes protocolos, aseg√ļrese de que el usuario lo sepa solo en los casos en que sea realmente necesario e inevitable.

Si puede ahorrarle a un usuario la molestia de obtener un conocimiento especial incluso a costa del tiempo de los desarrolladores, hágalo. Un desarrollador gastará dos días y le tomará mil usuarios por hora. Si miramos 48 horas contra 1000 horas, la respuesta es evidente.

¬ŅDuermes bien, John, un programador en serie?

3.2. Los dispositivos con las mismas funciones deben controlarse de la misma manera.


Un usuario no tiene que saber que una v√°lvula de agua est√° controlada por ciertos comandos y un grifo est√° controlado por otros. Si ambos controlan el agua en una tuber√≠a, deben tener las mismas interfaces a nivel de usuario: ‚Äúaguas abiertas‚ÄĚ, ‚Äúaguas cerradas‚ÄĚ.



Vivimos en el mundo fisico. El cuerpo y el cerebro del hombre están formados para interactuar con objetos físicos. Nos lleva al siguiente principio.

4. Los dispositivos de control físico son mejores que los virtuales.


Cualquier aplicación en un teléfono inteligente, incluso las mejores, no es tan buena como un interruptor físico normal en un lugar requerido.

Otra cuestión es que un interruptor debe ubicarse exactamente en el lugar correcto . Lleva a otra regla:

5. Los sistemas inal√°mbricos son mejores que los cableados.


Los sistemas con cable son confiables, pero solo los sistemas inalámbricos permiten colocar un nuevo interruptor o un relé sin renovar una habitación. También permiten mover un interruptor si crees que un nuevo lugar es más conveniente. Pero hay ciertas excepciones:

5.1. Los malos sistemas inal√°mbricos son peores que los cableados.


No importa para un buen sistema inalámbrico a qué distancia están los dispositivos del controlador central. Los buenos sistemas inalámbricos son protocolos con red de malla : ZigBee, Z-Wave, 6LoWPAN, etc.

Todas las demás opciones, incluida la conexión Wi-Fi, no son tan buenas. Los protocolos propietarios como "433 MHz", aunque pueden funcionar en otras frecuencias y difieren mucho entre sí, tampoco son tan buenos.

Las desventajas de la conexión Wi-Fi son que no puede crear dispositivos "durmientes" completamente funcionales, la configuración automática es complicada, incompatibilidad con otros dispositivos Wi-Fi en la casa.

Las desventajas de los protocolos patentados son que, en la mayoría de los casos, no tienen control de la entrega, el cifrado y las especificaciones disponibles. Ni el Wi-Fi ni los protocolos propietarios tienen enrutamiento de malla que resulta en la siguiente dificultad: "No puedo poner un interruptor en esa esquina, ya que está demasiado lejos del enrutador".



No puede hacer un sistema 100% confiable que no tenga que ser mantenido. Los dispositivos se salen de servicio, me producen ca√≠das de tensi√≥n en la l√≠nea el√©ctrica, los vecinos pueden inundarlo, las bater√≠as se descargan, un ni√Īo puede derramar sopa sobre una l√°mpara, etc. Pero:

6. La fijación, actualización, mantenimiento y diagnóstico deben ser fáciles.


Todo está claro en B2B. Hay un usuario, un desarrollador y un operador, es una persona u organización que sabe cómo es el sistema y cómo trabajar con él a nivel profesional. Un contador no tiene que saber programar para usar su software profesional. Una persona que alquila una oficina no tiene que saber cómo funciona la ventilación, todo lo que tiene que hacer es decir: "Está cargada en la oficina".

Una solución inteligente sobre la compra de un sistema se realiza sobre la base del cálculo de los costos totales de propiedad que se componen del precio del sistema y los gastos de mantenimiento.

Es un poco más complicado en los sistemas que se usan en los hogares. Un operador y un usuario son la misma persona que no tiene el conocimiento requerido del sistema. Lamentablemente, estos son los límites del mercado de consumo. Y lleva a los siguientes principios.

6.1. Los dispositivos funcionan o no funcionan. No hay una tercera opción.


El trabajo probable, el trabajo parcial o el mal funcionamiento son inadmisibles. Evite situaciones en las que su dispositivo no funcione cada dos veces una de cada diez veces. Si cree que su dispositivo no funciona correctamente, apáguelo por razones de seguridad y para mantener una experiencia de usuario positiva. Reemplazar un dispositivo no es agradable, pero es mejor hacer que un usuario reemplace un dispositivo que formarse una opinión de que el sistema funciona "en cualquier otro momento". Solo hay dos estados posibles de un sistema: está fuera de servicio o no funciona, está en orden y funciona.

Si est√° seguro de que es posible la degradaci√≥n del sistema, informe a un usuario al respecto con la ayuda de un mensaje que sea f√°cil de entender: "El segundo canal del atenuador est√° fuera de servicio. Reemplace el atenuador. ¬ŅContinuar usando el primer canal dimmer? S√≠ / no ¬Ľ

6.2. Reemplazar un dispositivo roto debe ser f√°cil.


El sistema debe tener un módulo uno. Si un sensor se sale de servicio, solo se debe reemplazar este sensor. No es correcto requerir el reemplazo de un relé con un control remoto con un sensor, porque están emparejados en la etapa de fabricación.

No es correcto exigir que "un nuevo sensor solo pueda ser instalado por nuestro especialista", porque es evidente que con el tiempo sus especialistas no serán suficientes para atender a millones de usuarios a medida que aumenta la popularidad de su sistema. Por lo tanto, en un momento determinado aparecerán problemas. Por supuesto, un usuario no arreglará un dispositivo por sí mismo, pero cuando se salga de servicio debe tener la oportunidad de reemplazarlo.

6.3. Mensajes f√°ciles de usar.


Si algo sale mal, un usuario debe saberlo y saber exactamente qué salió mal. No puede mostrar el mensaje "Error # 45" que implica que debe entenderlo. Un mensaje como este debe mostrarse al usuario "El dispositivo no responde. Intente volver a cargarlo y asignarlo nuevamente o póngase en contacto con el soporte técnico. Error # 45 "

No puede saber que un dispositivo no responde (si puede hacerlo) y retener esta información de un usuario. No es agradable recibir mensajes sobre un problema. Pero es mucho más desagradable saber que un dispositivo ha estado fuera de servicio durante una semana en el momento en que finalmente lo necesita.

6.4. No hay información adicional en los mensajes.


No envíe spam a un usuario con registros. Un usuario necesita información como en el principio anterior, porque contiene información que salió exactamente mal. Si no puede entender la información o no es el destinatario, no la necesita.

No muestre cientos de mensajes típicos "se ha perdido la conexión al dispositivo", "se ha restablecido la conexión al dispositivo". Debe decidir si se trata de información crítica y un usuario debe ser informado al respecto. O si se restablece la conexión, esta información no es importante, así que no la muestre 4 .

6.5. No se requieren conocimientos o equipos especiales para trabajos de mantenimiento.


Permita que un usuario actualice el firmware haciendo clic en un par de botones. Se puede hacer a través de una interfaz estándar (USB / BT / Wi-Fi), o no mencionar la actualización a través del programador SPI.

No puede esperar que un usuario calcule m√°scaras de bits para configurar un dispositivo.

6.6. El sistema no debe requerir un mantenimiento constante.


Si un atenuador pierde la conexión todos los meses y un usuario tiene que subir una escalera para alcanzar una lámpara y conectar el actuador nuevamente, no es conveniente. Si las baterías deben cambiarse en un interruptor cada dos meses, no es conveniente. Incluso si el período promedio de mantenimiento de un dispositivo es de seis meses, no es conveniente. Si hay unos veinte dispositivos en la casa, un usuario tiene que hacer algo cada nueve días.

6.7. El sistema debe tener oportunidades de actualización y ampliación.


Los gastos para extender un sistema deben crecer en progresión lineal.

Evite situaciones en las que un usuario que quiera agregar un sensor tenga que comprar un nuevo controlador, porque el antiguo no admite m√°s de 6 sensores 5 .

Evite situaciones en las que el nuevo firmware del sensor solo pueda funcionar con una nueva versión de un controlador.

Dichas limitaciones tienen una influencia positiva en los ingresos, lo que hace que los usuarios compren nuevos dispositivos. Pero es un camino a la nada. Puede perder la confianza de sus usuarios debido a tales trucos y, como resultado, perderá mucho más de lo que podría haber ganado.

7. Autosustentabilidad: las redes externas son una opción, no un requisito.


Un sistema donde los comandos tienen que pasar por un servidor externo no es conveniente. Puede hablar durante horas sobre interfaces convenientes, aplicaciones modernas, redes neuronales geniales, pero no significan nada si un usuario no puede encender la luz en el ba√Īo cuando Internet est√° ca√≠do. ¬ŅDe verdad crees que un sistema as√≠ puede considerarse bueno?

Realmente no entiendo por qu√© este principio no se da por sentado. Si incluye un servidor externo en un proyecto, se convierte en un posible punto de falla. Los servicios externos son geniales, pueden agregar m√°s funciones, pero no pueden ser la √ļnica variante de control. Aunque pueden usarse maravillosamente como un canal de control adicional, un almacenamiento de respaldo, una herramienta para el an√°lisis de datos, etc.

8. Centralización: la ausencia de un centro central limita las lógicas disponibles.


Pero un sistema descentralizado tampoco es ideal, aunque es confiable.

Un sistema descentralizado es un sistema donde un interruptor "le dice" a una l√°mpara que "se apague", y un sensor de temperatura enciende un calentador cuando la temperatura est√° bajando. Un sistema descentralizado pierde a uno centralizado, porque es bueno solo para la interacci√≥n simple entre dispositivos cuando un dispositivo controla otro dispositivo. Si un sistema se vuelve m√°s complicado, aparecen muchas preguntas. Si hay varios sensores, ¬Ņaceptar√° el calentador el comando de todos ellos? ¬ŅEl calentador debe solicitar sensores? Si se debe tomar una decisi√≥n sobre el an√°lisis de los datos reales, ¬Ņd√≥nde almacenar el archivo? ¬ŅD√≥nde almacenar y c√≥mo cambiar la l√≥gica? ¬ŅC√≥mo almacenar l√≥gicas en dispositivos "est√ļpidos"? ¬ŅC√≥mo actualizar las l√≥gicas?

Todas estas preguntas desaparecen si se da por sentado que se requiere un centro como un punto de interacci√≥n de datos y un lugar para almacenar las l√≥gicas de un usuario. Los dispositivos pueden ser "est√ļpidos", es decir, pueden enviar datos y obtener comandos, ya que la tarea de almacenar datos, procesar datos, tomar decisiones e interactuar con servicios externos est√° en el controlador central.

La descentralización se puede guardar en parte, ya que cuando no hay un concentrador, los comandos se pueden enviar directamente como modo a prueba de fallas. No hay lógicas, pero la luz se puede encender.



9. El sistema no debe realizar acciones potencialmente peligrosas sin informar a un usuario u obtener una confirmación de él.


Mientras vivamos en un mundo donde un programador no sea responsable por el da√Īo causado por su software, habr√° errores en el software, incluido el software de Smart Home. La √ļnica forma de no permitir que un error provoque graves consecuencias es limitar las acciones independientes del sistema. Las acciones potencialmente peligrosas deben realizarse solo cuando un usuario est√° informado acerca de ellas o incluso mejor despu√©s de que un usuario las confirma. La luz se puede encender autom√°ticamente, un error en el software despertar√° a un usuario por la noche o aumentar√° su factura de electricidad. No es agradable, pero no es peligroso. Pero los grifos de agua no se pueden abrir autom√°ticamente si no hay herramientas que eviten las inundaciones. Pens√© que no es peligroso cerrar los grifos autom√°ticamente.

No significa que est√© prohibido el control autom√°tico de calentadores, calderas, chimeneas, calderas, etc. Significa que si desea que una acci√≥n potencialmente peligrosa sea autom√°tica, aseg√ļrese de que el peligro no llegue al nivel del usuario. Aseg√ļrese de que una tetera se apaga autom√°ticamente cuando alcanza una temperatura definida, que un ba√Īo tiene sensores de fugas, etc.

10. El sistema debe tener opciones de autocontrol y autodiagnóstico.


Un desarrollador actual de sistemas dom√©sticos inteligentes debe ser un poco paranoico. No se puede confiar en Internet, puede estar inactivo. No se puede confiar en el c√≥digo, puede haber errores. ¬ŅSe puede confiar en el hardware? No, no se puede confiar en el hardware. Los rel√©s pueden pegarse, los triacs pueden abrirse, los fusibles pueden quemarse. Incluso un usuario puede conectar un hervidor de kilovatios a un enchufe de 100 vatios. Por lo tanto, se requieren un sensor de voltaje, un sensor de corriente y un sensor de temperatura. Si la temperatura excede los l√≠mites, apague todo y env√≠e una advertencia. Si la corriente excedi√≥ los l√≠mites, apague todo. Si un rel√© est√° apagado, pero todav√≠a hay voltaje, env√≠e una notificaci√≥n. Si apaga un rel√© y no hay voltaje, env√≠e una notificaci√≥n.

11. El sistema debe tener control manual.


Incluso si considera todas las cosas paranoicas, habr√° una situaci√≥n en la que todos los controles fallaron y algo se rompi√≥. Puede ser un interruptor, un enrutador o el concentrador central, pero, sin embargo, un usuario quiere encender la luz en el ba√Īo. Que hacer

Siempre debe haber un botón que pueda hacer que el sol se ponga en el modo manual, un botón que puede encender / apagar la luz AHORA MISMO. Como llevará un día entregar un nuevo centro y se puede comprar un nuevo interruptor más tarde, pero la luz en el dormitorio debe apagarse esta noche.

12. Los hackers son tan importantes como los usuarios habituales.


Los usuarios habituales te traen dinero, los hackers 6 pueden pensar en nuevas funciones. Un fabricante no puede y no debe desarrollar todas las escenas de uso del sistema, ya que no tiene conocimiento en todas las esferas y no puede calcular el efecto de tales cosas. Es muy posible que un enchufe inteligente pueda ser conveniente para controlar a través de un termostato de una cervecería móvil, ya que tiene un regulador PID. El ejemplo es un poco exagerado, pero la idea es que no está mal crear condiciones convenientes para los piratas informáticos, ya que pueden agregar la potencia de movimiento a su sistema.

13. Apertura: el sistema debe tener una API abierta para integrarse con otros sistemas.


No puede satisfacer todas las necesidades de sus clientes con sus propios dispositivos. Siempre habr√° dispositivos que no tienes. O puede tener los dispositivos, pero los dispositivos de otros fabricantes pueden ser mejores. Para conectar su sistema a otros, es absolutamente necesario tener una API abierta y bien documentada. Si no tiene API, sus usuarios no pueden tener sistemas heterog√©neos. Pero incluso las grandes compa√Ī√≠as de hardware y software patentados no pueden permit√≠rselo.

14. Documentación: es tan importante como el hardware y el código.


No importa cu√°n genial sea su hardware o cu√°n bueno sea su software, si un usuario no puede entender c√≥mo iniciar su sistema y c√≥mo trabajar con √©l. Una buena documentaci√≥n es la que, despu√©s de leer, el usuario no piensa en ponerse en contacto con el soporte t√©cnico o no eval√ļa negativamente las capacidades mentales del desarrollador. Es imposible escribir dicha documentaci√≥n, pero es algo por lo que luchar.

Y el √ļltimo pero no menos importante:

15. Autosustentabilidad y autosuficiencia: el sistema debe seguir funcionando, incluso si la empresa ya no existe.


Una persona vive entre 70 y 90 a√Īos, un sistema instalado en su hogar funciona entre 5 y 10 a√Īos (en el mejor de los casos), las empresas duran a√ļn menos. No cree un sistema que deje de funcionar si su empresa muere. Sentirse por los usuarios. Planifique el sistema de tal manera que pueda funcionar incluso si la empresa y el desarrollador ya no est√°n en este mundo.

Si se asigna un dispositivo para obtener un token del servidor de un desarrollador, haga un botón "Omitir obtener un token". Si el firmware debe actualizarse desde el sitio web cuando se inicia el sistema por primera vez, haga posible descargar el firmware predeterminado si el sitio web no está disponible. Y así sucesivamente.


En este artículo intenté describir la experiencia de usar, desarrollar dichos sistemas y trabajar con ellos en 15 principios. Parte de ellos puede parecer exagerado, otros son discutibles (es normal) y otros están tristes (también es normal).
Pero si te tomaste el tiempo para pensar incluso en uno de ellos, el artículo no fue escrito en vano.

Comentarios


1. Por "uso" me refiero al proceso de interacción regular con el sistema, pero no a la configuración.
2. Me gustaría enfatizar que digo "un usuario no debe darse cuenta", pero no "la demora debe ser la misma que". La práctica muestra que un humano no nota un retraso de 300 milisegundos.
3. Quizás creció en Asia y piensa que el mejor remedio para el calor es el té verde caliente.
4. Cuando digo "no mostrar información", significa que no se debe enviar un mensaje al usuario cada vez. Debe mostrarse a solicitud del usuario, por ejemplo, "mostrar el registro" o "mostrar información de depuración" cuando se presiona un botón. No consideres a los usuarios como idiotas, respeta su tiempo.
5. Por supuesto, es imposible dise√Īar un sistema que admita una cantidad ilimitada de dispositivos. Siempre habr√° l√≠mites, pero es tarea del desarrollador hacerlos irrelevantes en el 99% de los casos. El l√≠mite a 6 sensores es inaceptable. Cientos o doscientos dispositivos en una red son suficientes para la mayor√≠a de los usuarios de hogares inteligentes.
6. Uso la palabra "hacker" en el significado esencial de esta palabra de acuerdo con RFC1983, y no el significado de una persona que usa computadoras para obtener acceso no autorizado a los datos.

IRidium Mobile ayudó a traducir este texto al inglés, por lo que les agradezco mucho.

Source: https://habr.com/ru/post/439072/


All Articles