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