La mayoría de los artículos están escritos sobre el principio de "¡Lo hice / lo hicimos / y mira qué bien!". La misma publicación está dedicada a un proyecto fallido. Bienvenido al gato ...
Esta es una continuación de mi publicación: el desarrollo de dispositivos inteligentes en el ejemplo de un controlador de piso con calefacción en el ESP8266
Empecemos desde lejos
Vivo en una casa pequeña, construida según mi proyecto. Diseño: rejilla euro, pasillo, cocina-sala de estar en la planta baja, baño, habitación infantil y dormitorio en la segunda. De no estándar: paredes de arbolit, cimientos de UShP, calefacción exclusivamente TP. Al mismo tiempo, los pisos son de madera, en el segundo piso hay un piso flotante, TP, en la placa GVL. En el primer piso hay 3 bucles de tuberías de TP (en realidad una habitación), en el segundo, también tres, pero cada bucle es responsable de una habitación (dormitorio, baño, habitación de niños). La caldera de gas montada en la pared de 14 kW es responsable del calor. La caldera está controlada por un termostato inalámbrico programable semanal chino. Cada día de la semana tiene cuatro períodos, en cada período puede establecer la temperatura deseada. Cerebros en la batería, el relé está oculto. Funciona muy bien Pero a menudo necesito más de lo que tengo. Quería control de temperatura ambiente. Miré las soluciones propuestas, no me gustó nada. Y la palabra "Arduino" me llamó la atención. Y de profesión soy programador. Y lejos nos vamos ...
Hierro
No soy fuerte en hierro. Soldar una placa de desarrollo es la altura de mis habilidades. Pero Arduino es algo tan simple que me di cuenta: incluso con mi conocimiento de electrónica, puedo hacer un controlador de temperatura en la casa que me convenga.
Sensores de temperatura
No me gustan los cables en el interior. Intento excluirlos u ocultarlos, si no puedo excluirlos. Y de una manera un tanto sinuosa, llegué a usar sensores inalámbricos de estaciones meteorológicas chinas como sensores de temperatura ambiente. Los sensores funcionan con baterías durante mucho tiempo y transmiten a una frecuencia de 433 MHz. Es bastante agradable, puedes elegir diferentes colores, con y sin pantalla. Mirando hacia el futuro, diré que cada fabricante de una estación meteorológica inventa su propio protocolo para transmitir datos con un sensor. Durante los experimentos, analicé los protocolos de 5 tipos de sensores: todos tienen diferentes formatos de transferencia de datos. Desarrollé una biblioteca que recibe datos de 4 tipos de sensores. No contacté al quinto, su protocolo no es similar a los demás debido a la falta de límites de paquetes. La herramienta principal para el análisis de datos se ha convertido en un analizador lógico chino. Sin dicha herramienta, el análisis de protocolo es prácticamente imposible. Cuesta bastante, es fácil de usar. Recomiendo que lo lleves a todos los arduins.
Implementé la biblioteca sobre el principio de muestreo, frecuencia 10kHz. Este enfoque nos permitió nivelar el ruido en el aire y reducir la carga en el procesador, en comparación con el enfoque con interrupciones cuando cambia el nivel en el pin del receptor. Para la depuración, se utilizó un analizador lógico:
Señal de depuración
3 ... 6 canales: datos para la depuración
Daré ejemplos de sensores y sus características.
- Tipo 1: transferencia de datos cada 35 segundos. El período no cambia y esto es un problema cuando se usan 3 o más sensores: las horas en los sensores varían un poco, las señales a veces pueden superponerse y uno o dos sensores se caen durante una hora, dos o tres veces por semana o dos. 6 paquetes de datos en 0.8 segundos. La ID del sensor cambia cada vez que se enciende. No hay datos del estado de la batería.
Datos
Arriba: datos del receptor, las flechas indican interferencia
A continuación se muestran los datos del transmisor.
- Tipo 2: Período de transmisión de datos: 40 ... 80 segundos, según el canal. El mejor protocolo en mi opinión es 15 paquetes de datos en 0.6 segundos, hay una suma de verificación. La ID del sensor cambia cuando se enciende, hay una transmisión de datos del estado de la batería. El transmisor más débil: cuando coloca el receptor en una caja, la calidad de la recepción ha empeorado notablemente. Probablemente tratado con una antena externa para el receptor.
Datos
sin interferencia
- Tipo 3: período de transferencia de datos de 50 a 55 segundos, según el canal. 7 paquetes en 0.6seg. La identificación cambia cuando se enciende, hay una transmisión de datos del estado de la batería. Buena elección
DatosCasi idéntico al tipo 1
- Tipo 4: Período de transmisión de datos 56 ... 76 segundos, dependiendo del canal. No hay pantalla La identificación cambiable cuando está habilitada no se detecta. ¿Hay diferencias en la identificación entre diferentes instancias? No sé, tengo uno de esos sensores. Datos sobre el estado de la batería - es. Señal potente, la transmisión saltando casi nunca se observa.
- Tipo 5: no medí el período de transmisión, no hay cambio de canal, no analicé el protocolo en profundidad.
Como resultado, la unidad receptora se implementó en el Arduino Pro Mini con transferencia de datos a través del esclavo i2c.
Mega Arduino
Esta es la primera plataforma en la que hice el controlador. Mi controlador tenía una interfaz de comando, controlada por comandos ingresados a través de UART. En esa etapa, planeé hacer una interfaz WEB en ESP8266 y comunicarla con Mega en UART. Tengo una placa Robotdyn Mega combinada con una ESP8266 y estaba planeando construir este desarrollo en esta placa. Una ventaja particular de la placa es una gran cantidad de puertos externos. Pero en el proceso de conocer el ESP8266, me di cuenta de que este pequeño chip es bastante capaz de combinar las funciones del controlador y la interfaz.
ESP8266
Utilicé la opción de mini placa WeMos D1, tiene dimensiones pequeñas y una cantidad suficiente de pines para mí, teniendo en cuenta el uso de un expansor de puerto. Hay una gran cantidad de bibliotecas para esta placa. Por ejemplo, me-no-dev / ESPAsyncWebServer es una excelente biblioteca de servidores web con soporte para sockets web. Ensamblé el controlador en esta placa. Desarrollé una interfaz web. Todo funciona de maravilla. Pero por una razón incomprensible para mí, el tiempo de actividad no es más que un día. O hice algo torcidamente, o algunas de las bibliotecas utilizadas están torcidas. Además, hay un límite de 5 conexiones simultáneas. Si se excede, reinicie o incluso se congele (a pesar del watchdog existente. Luché con los bloqueos usando un watchdog externo). Teniendo en cuenta que mi interfaz web consta de casi una docena de archivos y que los navegadores cargan páginas en 5 secuencias paralelas, es fácil reiniciar. Decidí por mí mismo: esta placa solo se puede usar como cliente. Empecé a buscar otras soluciones.
Capturas de pantalla de la interfaz. ESP32
Es como el heredero del ESP8266. ESP32 tiene la mayor cantidad de frecuencia, memoria, patas, ... Pero el problema es que la biblioteca me-no-dev / ESPAsyncWebServer no funciona en términos de sockets web. Absolutamente Choques Algo relacionado con multihilo. No encontré otra biblioteca de servidor web con soporte para sockets web.
SOC
En esta etapa, decidí usar el tablero con Linux; no se me ocurrió nada más adecuado.
Mis requisitos de la junta. Parece que no hay muchos de ellos:
- No necesito una pantalla
- Debido a la falta de una pantalla para la configuración inicial, la placa debe poder funcionar en el modo de punto de acceso.
- Necesito un mínimo de funcionalidad del sistema operativo.
Orange Pi i96
Esta placa era adecuada en todos los aspectos: no hay salida de video, WiFi, memoria flash incorporada, ranura para tarjeta SD. Puede poner Ubuntu o DietPi en la memoria interna. Pero el problema con esta placa es su software. No puedes hacer un punto de acceso. Bueno, el mayor problema: cuando reinicia, la dirección MAC cambia y no se hizo nada al respecto. En el horno (Al momento de escribir, en w3bsit3-dns.com, en el hilo dedicado al análogo de esta placa (2g IOT), apareció un mensaje que decía que es posible vencer el cambio de MAC)
Cebolla Omega 2+
Documentación elegante. Con el firmware listo para usar, todo se inició, la pantalla no es necesaria, no se requiere UART. SSH está habilitado por defecto. Node.js se entregó (versión 4.x, pero no me importa). Se entregaron las bibliotecas sqlite e i2c para Node.js (usando una pandereta)
Aparte de i2c, ya no necesito ninguna interfaz de hardware. En comparación con mi variante de desarrollo, se agregó un controlador Arduino Pro Mini separado al ESP8266 para analizar los datos del receptor de datos del sensor de temperatura. El controlador del receptor está conectado al Omega como un esclavo i2c. Los sensores con cable con una interfaz 1wire se conectan a través de un puente i2c 1-ire <-> (DS2482-100). Hay una biblioteca para node.js para este puente, pero no funcionó para mí en términos de búsqueda de sensores. No entendí, porté a js esa biblioteca DS2482 que funcionaba en ESP8266.
Pero el problema es que el WiFi en Omega-2 no funciona de manera estable, no se vuelve a conectar después de reiniciar el enrutador. Este problema se resuelve con la versión de firmware 2, no está en estado de lanzamiento, pero funciona. Se ha vuelto mucho mejor. Pero el problema resultó: a veces la placa se cae del enrutador Zyxel y se vuelve a conectar después de reiniciar el enrutador o después de una hora, dos o tres sin reiniciar el enrutador. O comienza a aburrirse terriblemente: este problema desapareció después de cambiar el esquema de energía (a la placa realmente le gusta 3.3v o un poco más alto) y agregar una antena externa, el omega estaba muy contento. Por lo tanto, en principio, estoy satisfecho con la placa, el hecho de que a veces no hay acceso no me molesta mucho, como interfaz principal, utilicé un viejo teléfono inteligente en el muelle conectado al punto de acceso Omega. Y el acceso remoto será muy necesario: puedo reiniciar el enrutador de forma remota. Causa malentendidos: Omega-2 tiene dos pines RST: uno debe enviarse +, según tengo entendido, esto se procesa mediante programación. Qué archivar para el segundo y cómo conectar un perro guardián externo que se alimenta, aún no lo sé.
Lógica del controlador
Ya he descrito la arquitectura del software del controlador: no ha cambiado (es decir, administra los comandos de texto transmitidos a través de un socket web). La interfaz web ha migrado con el ESP8266 con cambios cosméticos. Muchos procedimientos / funciones del código del controlador simplemente se tradujeron de C ++ a JS. Otra cosa es que la presencia de Linux (OpenWRT) me dio la oportunidad de usar la base de datos SQL: sqlite. Por lo tanto, organicé toda la lógica en las consultas SQL. Esta es en realidad mi primera experiencia con sqlite. Me gustó especialmente la posibilidad de usar la base de datos en memoria: coloqué todos los datos temporales y actuales en esta base de datos (por ejemplo, datos del sensor, datos sobre la temperatura requerida actual, ...).
Código fuenteUsualmente comparto ideas, no códigos fuente. Me parece que esto estimula la actividad mental, mía y de los lectores. Desea obtener la fuente: escriba de forma personal.
Asamblea
Recogí todo en hierro, dispuesto en una caja. Además - pruebas de recursos. Después de una semana de tiempo de actividad, decidí que la prueba fue aprobada. Es posible instalar.
Instalación
Esta etapa fue muy exitosa. Colgué la caja al lado del colector, instalé y conecté los cabezales térmicos. Estaba muy satisfecho con mi idea de almacenar todos los datos, configuraciones y parámetros en una base de datos; sobre la marcha pude configurar los relés y las zonas de una manera no planificada, es decir, tres relés por zona y mover todos los demás relés (el original la idea era una zona, un relevo). El proyecto incluyó el uso de un conjunto de sensores de servicio DS18B20, para monitorear la temperatura del medio de calentamiento en el flujo, en el retorno de cada circuito del piso cálido, y la temperatura total del retorno; estos sensores también se conectaron y configuraron con éxito (todo el ajuste es para indicar el nombre comprensible del sensor).
Conecté el relé de la caldera.
Lanzamiento
El controlador funcionó según lo planeado.
Para la prueba, decidí aumentar ligeramente la temperatura en una de las habitaciones del segundo piso.
La caldera comenzó a sobrecalentarse y apagarse.
Y luego los sensores de servicio fueron útiles. ¡Resultó que la temperatura del agua a la salida del circuito de esta habitación es solo un par de décimas de grado menor que en la entrada! ¡El agua no se enfría! Esto significa que no cede calor. Y toda la casa está caliente a cualquier temperatura por la borda (el objetivo era bajar ligeramente la temperatura en el segundo piso). Entonces, el primer piso da todo el calor, y el TP en el segundo piso apenas calienta el piso. Como resultado, la regulación de calefacción habitación por habitación en tales condiciones no es posible.
Conclusión
Por lo tanto, la influencia de las características físicas y de diseño de mi casa puso fin a mi desarrollo. A pesar de que el controlador funciona perfectamente, no puedo usarlo en el sistema de calefacción de mi casa. Tal vez lo rebajaré para que controle el clima de la casa como un termostato chino, según un sensor, pero hasta ahora no veo el punto.
Sin embargo, el proyecto en su conjunto no tiene éxito, durante el proceso de desarrollo me familiaricé con muchas tecnologías con las que casi no estaba familiarizado antes:
- Programación del controlador
- Aprendí sobre los buses de datos 1wire, i2c, uart, ...
- Adquirió algunos conocimientos en el dispositivo del servidor web
- Parece ser una buena comprensión del desarrollo de la interfaz web: html, JavaScript, vue.js
- Él dominó el desarrollo de back-end web: node.js
Por lo tanto, gané mucha experiencia en un proyecto fallido, que puede ser útil en otros proyectos.
Quienes leyeron a este lugar pueden ver lo que sucedió .
(las últimas tres configuraciones están bloqueadas)
PS Tablero ideal para bricolaje
En el proceso de escribir el artículo, se descubrió otro problema con Omega-2: el módulo comenzó a congelarse. Duro, restablecer no ayuda, solo apague la alimentación. ¿Cuál es el problema? Todavía no lo sé. Tal vez no le gusta el aumento de potencia, ahora se alimenta con 3.8V. Intentaré reemplazar el módulo de alimentación. A pesar de que el proyecto no cumple sus funciones, por ahora lo dejaré en modo termómetro (como dicen, no haga nada en Arduino, obtendrá una estación meteorológica). Pero en cualquier caso, el tema es interesante para mí, quiero lograr un 100% de disponibilidad del sistema 24/7. Si reemplazar la fuente de alimentación no ayuda, probaré el sistema LinkIt Smart 7688. Parece ser idéntico al hardware de Omega. Puede ser más estable.
Además: después de reemplazar el estabilizador lineal 5-> 3.3v con un pulso, Onion Omega 2+ no tuvo problemas con el WiFi: funcionamiento estable durante una semana. Luego escribió este suplemento.
En base a esto, todavía no he encontrado la tabla de opciones ideal para productos caseros :(
Probablemente, como cerebro del próximo proyecto, intentaré usar un teléfono inteligente en Android; tendrá que conectarle sensores a través de wifi, pero prácticamente no hay problemas con la estabilidad de los teléfonos de marca. Y node.js parece estar puesto en el teléfono.
Le agradecería que compartiera su visión sobre la elección de un tablero para bricolaje.