La alegría de los sistemas integrados correctamente diseñados

El antiguo sueño de la domótica nunca ha estado más cerca de la realidad. Crear un dispositivo de Internet de las cosas o incluso una colección de construcción de dispositivos integrados interconectados es "fácil" gracias a versiones baratas como el microcontrolador ESP8266 habilitado para WiFi. Sin embargo, para cualquier proyecto notable, realmente ayuda tener un plan antes de comenzar. Pero aún más importante, si su plan puede cambiar mientras trabajan juntos, es importante planificar la flexibilidad. En la práctica, esto significará que los títulos expansivos y las actualizaciones de firmware (OTA) son esenciales.

Me gustaría ilustrar esto con un proyecto en el que participé hace unos años llamado BMaC, que ha crecido en complejidad y alcance casi todos los meses. Esto nos obligó a esforzarnos para mantenernos al día con los cambios, enseñándonos lecciones valiosas sobre cómo ahorrar tiempo y dinero con una arquitectura de sistema adaptable.

Cómo diseñar un ecosistema integrado flexible

Un sistema flexible es aquel que puede adaptarse a nuevos requisitos e incorporar nuevos programas y dispositivos sin grandes dificultades. Dado que a menudo no es posible saber cómo se verá el conjunto final de requisitos, es mejor abrir las opciones en caso de que se necesiten más adelante. Las opciones significan características como conectores para módulos de expansión, una fuente de alimentación más flexible de la estrictamente necesaria y un medio conveniente para restablecer el firmware.

Cuando el proyecto se abrió después de unos meses, se expandió de simplemente recopilar datos de temperatura a monitorear y controlar las máquinas de café y los acondicionadores de aire con hardware personalizado, y responder a la lógica que se ejecuta a través de una serie de programas de back-end. servicios. Sin anticipar nada de esto, el proceso de desarrollo implicó mucha improvisación y muchas revisiones de hardware.

Como ahora se conoce el proyecto, el sistema de Construcción y Control (BMaC) comprende sensores de temperatura ambiente, presión del aire, humedad relativa, CO2, movimiento y humedad del suelo, con control de actuación para válvulas, cafeteras, ventiladores Fan Coil Unit (FCU). , así como bombas y similares. Si bien el alcance del proyecto no estuvo exento de dificultades, dejando abiertas las opciones, sin embargo permitió ampliar el sistema.

El hardware central consta de microcontroladores ESP8266 (módulos ESP-12E / F), que son económicos y están disponibles en abundancia, pero proporcionan una cantidad significativa de potencia de procesamiento con su único núcleo de 32 bits y fácil conectividad a través de WiFi. Esto nos permitió desarrollar rápidamente el hardware y probar las iteraciones sin tener que instalar cables Ethernet en todas partes.

Este diagrama cubre los controles y monitoreo ambientales, así como los servicios de respaldo que almacenan la configuración del nodo (Command & Control), brindan el intermediario MQTT (Mosquitto), almacenan datos de sensores (InfluxDB) y controlan las FCU (ACControl). La caja blanca en el centro es el nodo BMaC del techo, que contiene el microcontrolador ESP8266, así como una PCB personalizada.

Este PCB proporciona ubicaciones de montaje para los diversos sensores ambientales, un expansor I2C GPIO externo, cuatro canales de salida de voltaje de CC variable y rieles de alimentación para muchos dispositivos que operan a 3.3 V, 5 V y 12 V. El cortador en el PCB es para el movimiento sensor que se conectaría al encabezado de pin libre.

Y sí, la pista para el módulo DC-DC era incorrecta, por lo que el módulo terminó en la placa. El circuito para los voltajes de CC también se depuró ligeramente, ya que el sector seccional del transmisor no permitía que los voltajes cayeran a cero. Estos son más ejemplos de que un proyecto ha acelerado sin una validación completa.

Como se mencionó, el objetivo inicial era solo colocar algunos sensores alrededor del edificio y almacenar los datos reportados por MQTT. Posteriormente, se agregó la idea de leer la EEPROM de las máquinas de café, lo que requería hardware personalizado para interactuar con estas máquinas. Esto creció para controlar estas máquinas, seguido de la idea de monitorear el movimiento en las salas de reuniones y, finalmente, también controlar las unidades de aire acondicionado.

Obviamente usar el nudo tapado para las cafeteras no sería muy práctico, ya que todo lo que se necesitaba era una caja discreta para colocar detrás de las cafeteras, conectando a la puerta de serie detrás de la máquina (!), Que también proporcionaría el " nudo de café "con alimentación a través de la línea 5 V de la comunicación serie TTL.

Todos estos nodos fueron luego comunicados por el mismo corredor de MQTT, con los datos de los sensores integrados en los servicios de backend. Gracias al uso de MQTT, cualquier cliente MQTT pudo comunicarse con cualquier otro cliente, haciendo una red muy flexible. Con el uso de WiFi, significó que los nodos podrían instalarse en cualquier lugar del edificio, con sensores y aceleradores colocados casi a voluntad.

Dispositivos de ingeniería inversa para controlarlos

Y luego vino el alcance: los controladores de una máquina de café controlarían el aire acondicionado del edificio. Si bien la interfaz de una máquina de café era una especie de cosa, un aire acondicionado que funcionara mal sería muy perturbador y desagradable. Por otro lado, el incentivo original para reconstruir los controles alternativos también fue que el sistema actual no estaba funcionando correctamente, con partes de la habitación congeladas mientras que otras se hincharon, en gran parte debido a la falta de control y control de temperatura granular. Así que hubo muchas mejoras.

Estos requisitos significaban que solo teníamos que realizar ingeniería inversa en todo el sistema de aire acondicionado, encontrar un lugar para montar el nuevo hardware en cada habitación, interactuar con el sistema de aire acondicionado, escribir y expandir los servicios de backend para admitir la nueva función, actualizar el firmware en los nodos ESP8266 para hacer todas las cosas nuevas, desarrollar hardware personalizado donde sea necesario e integrar todo en un paquete que incluso el desarrollador promedio podría usar en términos de controles de uso final.

Dado que la PCB del nodo original no podía acomodar todos los controles de válvula con cuatro pines GPIO usados ​​para los cuatro controladores de ventilador FCU, se necesitaría la expansión GPIO para encender cuatro relés que controlarían las válvulas de expansión térmica de 24 VCA. Aquí, se guardó el encabezado de fuga I2C en el PCB del nodo. Para controlar las FCU, conectamos una PCB externa que combinaba la expansión GPP MCP23008 con ULN2003.

Para los interruptores que alternan las secciones de construcción entre refrigeración y calefacción, se tuvo que desarrollar otra placa basada en ESP8266 que pudiera seleccionar el modo deseado en función de los comandos del fondo. Dado que no necesitábamos cambiar tan a menudo, un relevo de agarre fue la solución perfecta. Mantiene el último estado incluso con una pérdida de energía, y con dos lados, el segundo lado podría usarse como una celda de memoria de un bit. Esto llevó a este hermoso prototipo.

Una característica divertida de esta placa es que se conecta directamente a una red eléctrica de 230 voltios a través de un módulo convertidor AC-DC. Luego, toda esta placa se enchufaría en el lugar donde se montó el interruptor original, con una línea de alimentación principal dirigida hacia él dentro de la pared.

La parte divertida de la ingeniería inversa es que nunca se sabe realmente lo que puede encontrar durante el proceso. Si primero hicimos la ingeniería inversa, luego hicimos un plan y lo implementamos, podríamos haber pasado por alto muchos de los furiosos cambios y la planificación. Por lo tanto, la moraleja de esta sección debe ser, obviamente, que vale la pena hacer la ingeniería inversa antes, quizás en lugar de hacerlo a la mitad del proceso de desarrollo. Pero cuando eso no sea posible, comience a crear tableros.

Qué funcionó y qué no

Con el hardware más o menos terminado, se instaló durante unas semanas en las tres primeras FCU y en el modo alterno de la sección. La instalación del hardware resultó complicada y errónea, con muchos puntos en los que la instalación podría simplificarse. Esto incluyó cosas como los terminales de tornillo en los PCB del techo con los que es difícil trabajar mientras está parado en la parte superior de una escalera.

Idealmente, las instalaciones basadas en el techo simplemente implicarían perforar un agujero en el techo suspendido, pasar un cable a través de él y enchufarlo en el nudo antes de unir este último al techo. Cuanto menos trabajo tenga que hacer durante la instalación del hardware, mejor. También es muy conveniente eliminar la opción de cambiar los cables durante la instalación. Esto significa conectores grandes y rugosos que se pueden instalar fácilmente sin herramientas.

Durante el desarrollo de la placa de nodo básica, cuando era un simple monitor de temperatura, decidí tener un cabezal I2C en la placa, por si acaso lo necesitábamos. Esto resultó ser un salvador. Permitió la fácil extensión de este hardware para controlar completamente las FCU incluso antes de que descubriéramos cómo funcionaban o qué necesitaríamos. Por lo tanto, es esencial disponer de interfaces de expansión fácilmente. Planifique para lo no planificado.

Adherirse a un solo proyecto de hardware para todos los nodos, excepto los de café, funcionó bastante bien, ya que se podían implementar rápidamente después de completar la fase de prototipo. Esto nos permite utilizar una única imagen consolidada, con módulos que se pueden encender y apagar para una operación específica. Esto mantuvo la base del código pequeña y organizada, y el proceso de construcción y actualización simple, sin necesidad de administrar qué imagen es adecuada para qué nodo.

Los nodos también se han configurado para actualizaciones inesperadas (OTA), con el cargador rBoot cambiando entre dos ranuras de memoria. Esto significa que probar nuevas imágenes firmes fue relativamente fácil, ya que no requirió que se quitaran los nodos del techo ni que los nodos se pescaran detrás de las máquinas de café siempre que hubiera una actualización disponible.

Sin embargo, probar nuevos cambios fue bastante complicado, ya que el firmware OTA tuvo que enviarse a un servidor HTTP, luego se envió el comando de activación MQTT, seguido de verificar y validar que el nodo se haya actualizado correctamente y que los cambios realmente tuvieron el efecto esperado.

La parte trasera del control de CA se basó en el servicio C&C, con un circuito de retroalimentación cerrado implementado para las FCU y los sensores de temperatura. Sin tiempo para escribir nada elegante, se usó un bucle directo, que luego se depuró durante semanas, lo que involucró innumerables actualizaciones de OTA y backend, provocando hardware mientras estaba en la parte superior de una escalera y varias otras diversiones que inducían dolor muscular.

A dónde ir desde aquí

Mirando hacia atrás en el proyecto, fue una buena experiencia de aprendizaje. ¿Pero si tuviera que hacerlo de nuevo, sabiendo lo que sé hoy? Sería un conjunto de objetivos claros, con una lista de dispositivos a desarrollar, junto con el firmware y los requisitos posteriores. También comenzaría la prueba de integración para el software, utilizando una plataforma de hardware virtual y compilación. Desde entonces, la versión actual de la plataforma BMaC ha ganado exactamente una prueba de este tipo, lo que debería facilitar cualquier desarrollo futuro. Unos años demasiado tarde para mí, ¡pero justo a tiempo para ti!

El proyecto BMaC todavía está en ejecución. Es de esperar que surja una nueva oportunidad para probar los cambios en un nuevo entorno de oficina o similar.

  • Craig Hollabaugh dice:

    Buen artículo, enhorabuena por el proyecto y su éxito. ¿Obtuviste ese recinto de plástico blanco?

    • chango dice:

      Yo también tenía curiosidad. Parecen enrutadores TP-Link sin ninguno de los recortes.

    • Maya Posch dice:

      Gracias 🙂

      Traje el recinto blanco, sí. Es el CamdenBoss CBRS01VWH, con las ranuras para ventiladores. También hay una versión sin esas ranuras. Puede encontrar más información sobre la PCB y su BOM aquí: https://github.com/MayaPosch/BMaC/tree/master/esp8266

      • Craig Hollabaugh dice:

        ¡Muchas gracias!

  • Antron Argaiv dice:

    Me pregunto sobre los detalles de controlar una máquina de café. Mi cafetera no tiene memoria. ¿Puede ser un poco más específico sobre cuál era la necesidad de control y qué se controló?

    El control ambiental suena razonable, simplemente no tengo claro cómo / por qué se agregaron a la lista las máquinas de café (debes tener muchas) ...

    • Maya Posch dice:

      Estas máquinas de café probablemente valen su propio artículo. Básicamente son esas máquinas grandes y rugosas que pueden moler frijoles, hacer espresso, agregar leche descremada y demás, automáticamente. Todos usan la misma electrónica dentro de Toptronics, que viene con un llamado "puerto de servicio" en la parte posterior que acepta una variedad de comandos.

      Usando estos comandos uno puede leer la EEPROM, escribir partes de ella, borrar la EEPROM (mala idea), activar cada acelerador o válvula en la máquina y mucho más. Es un juguete maravilloso para jugar, incluso si no bebes café 🙂

      • Elliot Williams dice:

        Me tenías en espresso + UART.

      • Antron Argaiv dice:

        Está bien, está bien, ¡gracias! Creo que uno de esos también funciona. Pero, ¿por qué la necesidad de un mando a distancia? ¿O es más como: “Una máquina en la Sala C está hecha de frijoles”?

        • Maya Posch dice:

          El control remoto fue en su mayoría como un reemplazo fácil para los "productos" preconfigurados. Cada tipo de café, café exprés, etc. es solo una colección de controles y duraciones de los mecanismos internos, desde el mecanismo del molinillo hasta el calentador, etc. Con el control remoto, por ejemplo, puede crear su propia receta para el café perfecto en lugar de depender de cosas como las configuraciones de "fuerza" y "ml" en la máquina.

          También permitiría calibrar la máquina, ya que notamos que las estimaciones de ml indicadas en cuatro diferentes de estas cafeteras de uraura desaparecieron furiosamente. Supongo que esta es una forma a largo plazo de decir que el firmware suministrado no es tan impresionante considerando el precio de la máquina 🙂

      • Lsjobom dice:

        ¡Me encantaría ver un artículo sobre eso!

  • Jon dice:

    Honestamente, estoy sorprendido de que sonoff o alguna otra organización similar no haya lanzado un multisensor basado en ESP8266 ... (o si lo tienen, no lo encontré)

    Estoy esperando a que lleguen mis piezas y armaré un juego para mi casa con algunos electrodomésticos insonorizados (y similares) existentes, así como un termostato inteligente y un asistente doméstico.

    • jagmills dice:

      El "Sonoff SC" existe. Yo mismo no tengo uno porque suelo usar Wemosses en todas partes.
      Si no lo sabe, eche un vistazo al firmware de Tasmota. La wiki de Github es una gran cantidad de información. 🙂

      • Ren dice:

        Wemosses?
        Wemosii?
        Wemii?
        M'weem Bway
        M'weem Bway
        M'weem Bway
        En la jungla, la poderosa jungla, ¡el León duerme esta noche!
        B ^)

        • radio dice:

          Ahora que fue divertido

      • Jon dice:

        Gracias por el jefe en el SC, no sabía de su existencia ... pero por el precio me quedaré con mis sensores caseros.

        Tengo docenas de + dispositivos con una tasmota y los nuevos sensores probablemente también lo encenderán ...
        eventualmente me gustaría obtener algunos de los sensores de energía de la batería, (debido a su ubicación) y eso requerirá una función de sueño profundo que una tasmota no parece tener ahora ... Tal vez sería más fácil insertarlo en lugar de construyendo algo desde cero ... ya veremos, cuando llegue a ese punto.

  • Greg A. dice:

    Estoy seguro de que todos son buenos puntos, pero las fotos realmente destacan lo mejor de un proyecto integrado: ¡un recinto decente! No puedo decirte cuántas cosas he creado al derretir en caliente un recorte de cartón en capas pegado, o un trozo de taza en rodajas con un palo de grillo a través de él, o simplemente colgarme desnudo con pegamento termofusible rociado de manera optimista sobre los contactos. por lo que puede que no se acorte a su entorno antes de lo que sobrevivirá a su uso. tanto pegamento termofusible. No conozco este gabinete, pero les digo que mis proyectos son mucho más fáciles de procesar desde que obtuve una impresora 3D. una verdadera revolución.

    • Ostraco dice:

      Suena digno de un artículo. "Cómo dibujar un recinto adecuado".

      • Elliot Williams dice:

        Las cajas de proyectos se encuentran sin duda entre los tres mejores programas de impresión 3D. Probablemente manejemos uno así al mes. ¡Quizás una semana!

        Así que sin sarcasmo ni malicia lo resumo en un enlace: https://duckduckgo.com/?q=site%3Ala-tecnologia.com+3d+printed+project+enclosure&ia=web

        Lo que no significa que el enfoque de Maya (buscar buenos recintos en el mercado, proyectar las placas adecuadas) sea malo. Solo requiere previsión o una segunda revisión. Soy demasiado vago para cualquiera de esos. 🙂

        ¡Mida al plan, corte a la medida, pinte para cubrir!

        • reg dice:

          El problema con las cajas de proyectos en la impresión 3D es que es poco eficiente y limita el tamaño del recinto. Lo que creo que es un enfoque mucho más agradable es utilizar uno o más recintos comerciales con apariencia impresa en 3D. Obtiene sólidos o cajas y un panel frontal / posterior personalizado, y un tiempo de impresión mucho más razonable.

  • Craig Hollabaugh dice:

    Terminé muchos proyectos pequeños de esp8266 y construí un proyecto de plantilla a lo largo de los años que contiene todas las "cosas" comunes. Úselo, https://github.com/holla2040/ESP8266Template. Solo estoy agregando compatibilidad con fauxmoESP3 para que Alexa pueda verificar los resultados. Muy agradable. Gracias por los comentarios adicionales a mi comentario original.

  • Ren dice:

    "Cómo diseñar un ecosistema integrado flexible"
    Flexible, integrado ...
    WRT el autor, parece un oxímoron.
    B ^)

    • d2 dice:

      conspiración: el próximo artículo trata sobre materiales adaptables y robótica blanda;)

      • Ostraco dice:

        http://news.brown.edu/articles/2019/03/hydrogel

  • Ren dice:

    "El proyecto BMaC sigue funcionando".
    Hacen un flujo lavable, ¿sabes?
    B ^)

  • hackadave dice:

    Proyecto maravillosamente hecho. Me interesó la referencia a la renovación de los sistemas de control de los dispositivos existentes. Tengo varios dispositivos menos comunes a los que quiero agregar control remoto y control de una manera mínimamente invasiva. Estos incluyen un sistema de purificación de agua UV, un sistema de piscina de agua salada y varios otros dispositivos que es poco probable que cuenten con el apoyo del fabricante para IoT como control remoto en el corto plazo. He trabajado en técnicas de ie que imitan sus interfaces de usuario locales existentes, pero el uso de técnicas de ie como multiplexación de control dificulta la construcción de interfaces. Los enfoques alternativos incluyen el uso de interfaces mecánicas para la entrada y sensores para los indicadores. Esto es un poco torpe e interpretar 7 segmentos y pantallas LCD es difícil. Por supuesto, siempre es posible reemplazar los controles existentes por otros nuevos, pero el objetivo es ser mínimamente invasivo. Sería fantástico si hubiera una forma de crear una biblioteca de técnicas para la interfaz y de soluciones para dispositivos específicos que pudieran compartirse. Quizás esto sea algo que La-Tecnologia podría patrocinar.

  • Pete Willard dice:

    Maya, esto es asombroso. ¡Realmente estás cumpliendo con tu apodo pirateado! Fue un placer leer y arreglar la patada en los pantalones que necesitaba para retomar mi propio proyecto similar y simplemente "terminarlo". ¡Bien hecho!

  • brula110 dice:

    Qué gran lectura. Actualmente estoy trabajando en mi propio control de compilación, pero sus Sonoffs 98% modificados (hardware y firmware) ... Estoy realmente tentado de usar tus proyectos para mi primera computadora casera ... es perfecto para mis necesidades ... ahora cuánto tiempo me costará configurarme para el trabajo smd: S

    • Maya Posch dice:

      Fui con componentes 0805 (y SOIC, SOT-23-3) para poder soldar todo manualmente. Con el diseño no optimizado, me tomó aproximadamente una hora terminar de llenar una tabla. Con la próxima revisión 2.0 de PCB, debería ser mucho más fácil de soldar, sin embargo, con una gran reducción en los componentes de los orificios irregulares.

  • rupinchheda dice:

    He estado usando el ESP8266 durante un tiempo, y el mayor problema, dado que no involucro el chip en un producto que eventualmente se instalará en una red corporativa, es la falta de soporte para PEAP / TLS, que tienden a la mayoría de los establecimientos WIFI corporativos. tener. ¿Alguien ha logrado hacerlo exitoso y autenticarse y, finalmente, tener acceso wifi en un entorno así?

  • Clemens dice:

    La frase más importante de este artículo es la siguiente: "Sería un conjunto de objetivos claros, con una lista de dispositivos a desarrollar, junto con los requisitos de firmware y backend".
    Con demasiada frecuencia, los proyectos fracasan porque los requisitos no están claros. Y los ingenieros son parte del problema, no requieren requisitos de producto adecuados y, por lo tanto, deben basar sus requisitos técnicos en sus pensamientos y decisiones. Obtuve los mejores resultados cuando me enfrenté a mi jefe, le dije que no y le expliqué por qué necesitábamos demandas. Y esto lleva tiempo, de 2 semanas a 3 meses, según la complejidad. Pero luego te apresuras porque sabes lo que necesitas.

  • PaulG dice:

    Encuentro esto fascinante.

    Como ex devoto, el título parece un enlace a la respuesta de "los males de la optimización prematura". http://wiki.c2.com/?PrematureOptimization
    Es extraño, pero a medida que aprendo más lentamente sobre la electrónica y mis versiones simples, me encuentro volviendo a preguntas de software como: ¿Cómo puedo depurarlo? ¿Dónde encontraré los registros? ¿Cómo puedo probar partes individuales de él?

    Como en este gran ejemplo, también debemos pensar en ¿Cómo puedo expandirlo? ¿Cómo intercambiaré partes de él?

    Dos cosas para recordar sobre esos días del programa:
    Haz una cosa y hazlo bien.
    - Use Frame - No sé exactamente cómo se traduce eso.

    Y una cosa de los textos recientes sobre IoT industrial.
    'Simplemente coloque tantos sensores como se atreva, simplemente no sabemos qué darán los datos.

  • Barry Buel dice:

    Hay MUCHAS consideraciones de proyectos y puede ser difícil identificar cuáles se aplican a un proyecto desde el principio. El "tamaño único" funciona solo si el rango de aplicaciones es limitado y muy bien definido. Cuanto más amplia sea la gama de usos esperada, es más probable que se necesite una familia de modelos. Incluso en proyectos grandes con decenas o cientos de ingenieros, es difícil encontrar la “combinación” adecuada; de hecho más difícil porque mucha gente tiene opiniones. Y las opiniones son solo eso; no son necesariamente ideas "mejores".

    Lo que los diseñadores deben comprender es que están tratando de resolver varios problemas al mismo tiempo. Tamaño, potencia, IO, CPU, comunicación y la confiabilidad menos comúnmente reconocida, ambiental, térmica, vibración ... Como diseñador, TÚ tienes que resolver todo esto. Cuanto más tenga razón al principio, mejor para usted, ya que se vuelve mucho más doloroso si los clientes identifican el problema y esperan que usted lo solucione. Entonces, cuanto más intente diseñar un buen sistema al principio, mejor para usted.

    Recuerde: tener 1 unidad trabajando en el banco NO constituye “terminado”.

Alejandro Vargas
Alejandro Vargas

Deja una respuesta

Tu dirección de correo electrónico no será publicada.