[SOLUCIONADO] lecturas de humedad, temperatura y CO2 repetidas tras varias horas

Hola a tod@s de nuevo. Después de varios meses de modificaciones y la ayuda de surbyte he llegado al código final que muestro a continuación y que partía de otro post antiguo cuyo enlace añadiré también. Este código lee los datos de temperatura y humedad de 9 sensores dht22 y un sensor de co2 que lee via serie. Procesa los datos y actúa en consecuencia activando una electrovalvula y unos extractores mediante varios relés de estado solido. Además envío los datos medios medidos a un modulo nodemcu a través de comunicación serie para subirlos a una plataforma IoT. En el envío de datos a nodemcu y la subida de éstos a la plataforma IoT no hay problema, el problema está del lado de arduino y lo expongo a continuación:

Cuando el sistema lleva varias horas funcionando, en los últimos días me he dado cuenta que si no apago todo y enciendo arduino puede estar horas o dias enteros enviando a nodemcu el mismo valor de temperatura, humedad y CO2. Pensé que podrían haberse roto los sensores pero es muy casual que se rompan todos a la vez y en ese caso no volverían a funcionar correctamente a cortar la alimentación y volver a reponerla.

He llegado a la conclusión de que el fallo está en Arduino Mega o el código porque reseteo el nodemcu y se dejan de enviar datos a la plataforma IoT por lo que intuyo que le están llegando valores nulos, en cuyo caso tengo programado en nodemcu que no envíe nada a la plataforma IoT.

Además cuando aparece este problema de valores repetidos, si reseteo Arduino los valores medios de temperatura y humedad y el valor de CO2 son nulos, es como si la función que he creado llamada lecturas() no se ejecutase.

Todo esto me lleva a pensar que cuando las lecturas en el lado de arduino no se realizan correctamente o simplemente no se realizan por la razón que desconozco, lo que se envía constantemente a nodemcu son los últimos valores de temperatura y humedad media y CO2 que se leyeron antes de que comenzase a fallar.

Además tengo programado que cada 4 horas se active la electroválvula y me envíe un valor 1 a la plataforma IoT y una vez enviada la pongo de nuevo a 0, pues bien cuando aparece el problema en cuestión se mandan constantemente los valores mencionados repetidamente pero esta variable sí se envía correctamente, cero cuando es cero y uno cuando es uno.

Me tiene totalmente loco y no sé cómo solucionar el problema porque ha estado funcionando todo durante meses correctamente. He ido modificando el código y no sé si es que en alguna modificación la he liado pero no logro encontrar dónde. Si no me caben los códigos aquí los agrego en otro mensaje. Sigo dándole vueltas, mientras tanto espero a ver si alguien me puede ayudar. Muchas gracias siempre.

Saludos.

ENLACE:

He intentado añadir los códigos pero son muy extensos y se exceden los caracteres. Los adjunto.

Saludos.

codigo_arduino_vf2_sin_serialprint.ino (27.4 KB)

codigo_nodemcuvf1.ino (10.6 KB)

No he mirado tu codigo porque supongo le pasa como a mis DHT22, cuando les da la gana se "cuelgan" y solo recibo NAN (Not a number), por lo que tengo que ir comprobando si la lectura es buena y si tras un minuto no he recibido ninguna le hago un reset de alimentación.

tempIn = dht1.readTemperature();
   if (tempIn != dht1.readTemperature()) { //detecto fallo lectura del sensor
     tempIn = ultimatempInCorrecta; //la cambio por la ultima buena conocida

Bueno creo que el tema del DHT22 lo estamos sufriendo todos y me parece que la solución propuesta por krnlpanic es mas que simple y que debería funcionar, supongo que a el le funciona por lo que yo haré lo mismo. A mi también me tiene loco el tema del DHT22. Tengo muchos en mi casa y fallas aleatoriamente. Tengo que ir y reiniciar el arduino o el ESP01/nodemcu/ESP32 donde estan conectados.
Pensé que era un fallo del código y miré la librería pero al hacerlo instantáneamente funciona bien, lo que te deja mas perplejo porque estas fallas de varios dias son dificiles de resolver.

Tuve mi proyecto sobre protoboard 3 meses y nunca recibí una lectura errónea, fue montarlos en su sitio y empezar a fallar, incluso puse cable de 1mm con el mismo fallo.
Lecturas erroneas tengo bastantes, pero cuando son de mas de 1 minuto si no reseteas alimentación no recupera.
Suelo tener 1-2 resets al dia, el mas alejado es el que mas errores tengo.

Voy a probar tu técnica y también generaré un log para que me diga cuando lo resetea.

Gracias por vuestra ayuda. Le tengo puesto al codigo que cuando la lectura del dht22 sea NAn vuelva a leerlo. Es de esta manera:

If (isnan(t) || isnan(h))
{return;
}

Por lo que entiendo que mientras la lectura sea Not a Number vuelve a leer, corregidme si me equivoco en cómo actúa el código, pero lo curioso es que se ejecuta el loop entero porque las lecturas se envían cada minuto como le tengo programado. La cosa es que ejecuta todo el código que hay en el loop realizando el resto de acciones correctamente. Y lo que también me llama la atención es que el sensor de co2 también se pone a enviar el mismo valor constantemente. Me tiene loco y sí es verdad que cuando reinicio se soluciona. He revisado el código miles de veces y es tan simple que no encuentro problema porque además ha estado funcionando correctamente durante 4 meses.

Llegado a este punto, cómo puedo hacer el reset de alimentación? Me interesaría poderlo hacer mediante software porque la instalación la tengo a una hora de viaje de casa.

Gracias nuevamente, saludos.

Bueno yo he descubierto algo (no lo sabía o lo había leído pero no registrado en mi mente) y es que hay pines del nodemcu que no debemos usar para algunos casos por ejemplo GPIO0 que se usa para flashear el nodemcu.

Los pines en verde esta OK para su uso.
Los pines en amarillo, estan OK para su uso pero se debe prestar atención porque pueden tener un coportamiento no esperado durante el booteo, ejemplo cuando tenemos un relé conectado ahi.
Los pines en rojo no se recomiendan para el uso como entradas o salidas.

Como ven las restricciones son importantes.
GPIO6 to GPIO11 estan conectadas al chip FLASH asi que no usarlos.

Pines usados durante el booteo
El ESP8266 puede no bootear si algunos pines son puestos en LOW o HIGH. La lista muestra cuales son y sus situaciones.

GPIO16: esta en HIGH durante el BOOT
GPIO0: no bootea si esta a LOW
GPIO2: esta en HIGH durante el BOOT, falla el boot si es puesto a LOW
GPIO15: no bootea si esta en HIGH
GPIO3: pin esta en HIGH en el BOOT
GPIO1: esta en HIGH durante el BOOT, falla el boot si es puesto a LOW
GPIO10: pin esta en HIGH en el BOOT
GPIO9: pin esta en HIGH en el BOOT

CONCLUSION

No usar GPIO0 mi caso
No usar GPIO15

Estos dos son los que generan restricciones.

Yo para la comunicación entrw arduino y nodemcu utilizo el pin GPIO 13(D7) por lo que el problema apunta, en este caso, a arduino o los dht22. Algo tiene que pasar a Arduino porque también se repite la lectura del sensor de CO2.

Un saludo.

Yo el reset lo hago por rele, dudo que pueda hacerse por software si no me esta dando ni lecturas.

Buenas de nuevo a todos,

en primer lugar, respecto al buen aporte de surbyte, decir que uso como decía el GPIO13 para la Rx del puerto serie virtual creado en NOdemcu para la comunicación con arduino. Para Tx uso el GPIO15 aunque realmente no transmito nada a arduino, la comunicación es unidireccional (Arduino ---> Nodemcu). Como veo en el pinout que el GPIO15 está en amarillo voy a cambiarlo por el 12 para curarme en salud.

En cuanto al problema y tema de este post, he estado revisando la documentación del foro y he visto el post del siguiente enlace sobre uso de delay y millis():

En el código que tengo cargado en arduino mega uso varios delay de 60 y 90 segundos además de otros de 1 segundo entre lectura y lectura de los 9 dht22 que tengo instalados. ¿Puede ser que esos delay´s me estén dando los problemas de lecturas repetidas?

Lo que me llama la atención es que la lectura de co2 también se repita cuando es un sensor independiente que leo por uno de los puertos serie del arduino mega. Se me plantean dos posibilidades que cuando empiezan a repetirse los datos no puedo comprobar porque para conectar por usb el arduino mega al PC, antes tengo que desconectar su alimentador y por lo tanto al conectarlo por usb se reinicia:

  • puede ser que llegue un momento en el que los dht22 se cuelguen y las lecturas de temperatura, humedad y co2 sean nulas, por lo que nodemcu sube a la nube de manera constante el último valor leido por puerto serie y almacenado en sus respectivas variables, ya que estas no las pongo a cero tras cada envío a thingspeak.

  • que los dht22 se cuelguen como comentáis y pasen a leer constantemente el mismo valor. Lo que me choca porque el que se cuelguen no debería afectar a la lectura del sensor de co2 que se realiza de manera independiente. Tengo que aclarar , que hay veces que reinicio arduino y constantemente las lecturas de temperatura, humedad y co2 son nulas. Cuando corto toda la alimentación durante 1 minuto y vuelvo a alimentar todo el sistema empiezan funcionar todo correctamente de nuevo.

El delay detiene todo el código, por lo que durante este no podrás hacer nada mas que esperar, mejor que lo pases a millis.

También he tenido problemas de comunicación serie cuando actualizo código del MEGA, muchas veces tengo que acabar reiniciando nodeMCU pese a no estar colgado solo que no funciona el serial ni haciendo un .end y un .begin, lo superviso enviando un "ping" y esperando la respuesta, aunque como digo es reiniciando solo el MEGA.

Cuando se cuelga el DHT22 no se recibe ningún valor.

Buenas de nuevo.

Tomo nota de tus dos primeros párrafos krnlpanic. Respecto a:

Cuando se cuelga el DHT22 no se recibe ningún valor.

Entiendo que al no recibir ningún valor de los dht22 por eso envíe siempre el último valor de temperatura y humedad almacenados en las variables tmed y hmed, estos son los que recibe nodemcu y sube a la nube(este sigue trabajando con normalidad porque si no, no subiría ningún valor). Lo que llama la atención es que según mi código si lees uno de los dht22 y no devuelven ningun valor por estar colgados, el código del loop debería quedar parado ahí en la función lecturas hasta que los dht22 envíen algún valor, sin embargo he comprobado que el loop se ejecuta al completo y en los tiempos fijados. Pensé que cuando se quedan colgados devuelven el último valor leído, pero me llama la atención que también le ocurra al sensor de co2 como os comentaba en otra ocasión. Hoy sigue enviando los mismos valores todo el tiempo, así que esta tarde me desplazaré a donde los tengo instalados y le cargaré el código con el uso de millis en vez de delay´s a ver qué pasa porque no se me ocurre nada más. También buscaré a ver cómo hacer el reset con relé para cuando me ocurra este problema.

Saludos.

Hola, yo llevo ya bastante tiempo peleando con los DHT22, y sé que la alimentación es realmente importante. Yo les meto 5vcc, a parte de la alimentación que va al NODEMCU. Nunca trabajar con ellos si tienes el NODEMCU conectado al USB (al menos no para trabajar de forma estable)

Aquí podéis ver un montaje en protoboard y los problemas de falsos contactos que genera, aun así lo tengo 24 horas conectado y me envía datos a la nube de forma ininterrumpida sin problemas. Sí es verdad que las lecturas fallan bastante y hace necesario el isnan.

¿Has probado a sustituir los DHT22 por unos "nuevos?"

Por cierto, como bien dice @surbyte, y la imagen que aporta, el NODEMCU tiene ciertas limitaciones a la hora de trabajar con sus pines. Yo actualmente uso los siguientes y sin problemas:

DHT 1 --> GPIO3
DHT 2 --> GPIO13
DHT 3 --> GPIO14
DHT 4 --> GPIO5

RELE 1 --> GPIO12
RELE 2 --> GPIO15
RELE 3 --> GPIO9
RELE 4 --> GPIO4
RELE 5 --> GPIO16

A día de hoy me funciona sin problemas, si quito la alimentación y lo conecto de nuevo, reinicia perfectamente. Pero la alimentación, NODEMCU por un lado, DHT22 por otro lado.

Yo no armo nada en protoboards. Hace mucho los tiré a la basura.
Solo me traen incertidumbre donde ya tengo cosas que resolver, no puedo en un proyecto estar supeditado a si hace o no buen contacto.
El uso reiterado, las fallas de armado, la locura por vender cada dia mas barato. Todo conspira, y terminamos usando el multimetro para saber si hay continuidad donde debería haberla. Entonces simple, una placa de prototipos, y a soldar conexiones entre cada punto. Si quiero preservar un arduino, sueldo una hilera de pines y lo monto ahi. Todo queda prolijo, y seguro. Si falla es por mala conexion mía. Si no funciona, desueldo y corrijo el circuito como harían con el protoboard. Lo golpeo, sacudo y sigue funcionando. No tengo problemas de capacidades parasitas ni cosas raras.
Tal vez nos fuimos de tema o no, espero que estos comentarios le sirvan al lector oportuno.

Toda información o consejo es siempre bienvenida Surbyte aunque se salga un poco del tema.

En cuanto al tema en cuestión, comentarte nakuadak que los sensores los tengo conectados a Arduino y no a nodemcu. Nodemcu solo lo uso para subir los datos a la nube. Problema de alimentación no creo que sea porque arduino mega lo alimento con una fuente de 12 V 2 A, y los 9 sensores dht22, el de co2, 3 reles de estado sólido y el nodemcu lo alimento con una fuente de 5 V 3 A. Teniendo en cuenta que los dht22 consumen 15 mA, los 4 reles consumen en funcionamiento 160 mA en total, (como mucho solo hay dos encendidos a la vez), el de co2 150 mA aprox y el nodemcu no mas de 300-400 mA ,y creo que menos, lo que hace un total de 845 mA máximo seguiría teniendo 2 Amperios de sobra, por lo tanto no creo que el problema sea el que todo esté alimentado con la misma fuente.

Se me ha ocurrido desmontar uno de los sensores y probarlo de manera independiente en un arduino uno que tengo a ver si al cabo del tiempo empieza a repetir medidas.

Pero vuelvo a lo que más me llama la atención y que he comentado anteriormente, si los dht22 dan problema me parece lógico que fallen, den problemas de medición y se vaya repitiendo los valores de temperatura y humedad media, pero lo que no me entra en la cabeza es que el mhz-19B (sensor de co2) también comience a enviar el mismo dato de manera repetida. Solo sé lo siguiente:

Aunque llegue un momento en el que se empiezan a repetir los mismos valores, el loop de arduino se ejecuta completamente porque el resto de funciones que le tengo programadas se ejecutan correctamente.

Me viene lo siguiente, uso el serial2 de arduino mega para enviar datos a nodemcu, ¿puede ser que el problema esté en la comunicación serie? Es que me llama la atención que al reiniciar se solucione el problema.

En cuanto lo que comenta Surbyte sobre el montaje estoy totalmente de acuerdo, comentar que todos los componentes están soldados a placa y con laca de protección y el cableado también está soldado a los pines de todos los sensores y protegido mediante funda termoretráctil.

Sólo se me ocurre además de probar uno de los dht22 en otro arduino, el cambiar del serial2 a un puerto serie virtual, ya que el serial3 lo tengo usado con el sensor de co2 o por último intentar meterle al código un reset por software cuando pasado un cierto tiempo se resetee arduino ya que vivo a una hora de camino de la instalación.

Hay por el foro algo sobre el reset software? Es que he buscado en el índice de la documentación y no he visto nada. Simplemente saber que hay, ya lo buscaría yo.

P.D.: se me olvidó comentar que ya modifiqué todos los delay por millis y desde el domingo a las 21:30 a hoy a las 17:00 ha estado funcionando bien. A esa hora han empezado a repetirse. Por lo tanto tampoco es el problema.

Gracias de nuevo a todos y seguimos en contacto.

Saludos.

Yo te recomiendo que supervises el puerto serie enviando y esperando una respuesta, si no la hay tras varios intentos le puedes aplicar el reset via pin o puedes usar el watchdog forzandolo con un delay, el nodeMCU puedes hacerlo con ESP.reset()

Hola a tod@s, no tengo olvidado el post, solo estoy haciendo pruebas cuando tengo algún hueco para volver y comentaros los resultados. Un saludo.

También he estado con la misma situación con el DHT22/AM2302.
En principio mi problema se debía a otra razón que no traigo aquí porque no suma.
He logrado que los DHT22 funcionen bien. Tengo todos sin resistencia en el pin de datos y trabajan bien.
El único momento en que fallan es en el arranque pero luego de un tiempo comienzan a enviar datos.
No hay mucho que pueda hacer porque luego de enviar un dato, mi ESP01 se pone en SLEEP por 60 segundos y no es posible seguirlos hasta que se despierta.

Lo curioso es que sin R, funcionan con ESP01 colgados de GPIO0 o GPIO2.
Mis DHT22 estan trabajando a 3.3V, no superan 3.35V y han trabajado incluso a 2.9V cuando la LiPO se cae en tensión, según la hoja de datos del DHT22 requiere alimentación de 3.3 a 5.5V.

Hola a tod@s, después de probar miles de cosas(uso de puertos serie creados mediante softwareSerial, reseteando, probando uno de los dht22 en otra placa, etc.) el problema no se soluciona, cuando pasa unos dias reaparece el problema de lecturas repetidas tanto de temperatura y humedad como de CO2. He tardado tanto en contestar porque he probado cada posible solución durante 10-15 dias cada una y porque no me desplazo a las instalaciones todos los dias. Sí es cierto que últimamente ha habido ocasiones en las que han estado funcionando bien durante 7-9 dias pero al final volvía el problema.

El error de medidas a cero tras el reseteo no he conseguido evitarlo ni identificar porqué puede ser. Cada vez que reseteo los valores medidos de temperatura, humedad y co2 son nulos.

Me traje un dht22 a casa y está todo el día midiendo entre un 90-95% de humedad cuando aquí no tengo más de un 40-60%. Eso me tranquiliza por un lado porque al menos me dice que arduino mega no esta fallando.

He pensado definitivamente en conectarlo todo al Nodemcu (Si puedo) y a ver si así no falla, porque me da la sensación que al usar el seria2 y serial3 o varios serial virtuales en arduino uno puede venir el error. Voy a hacer cálculos porque necesito 9 entradas digitales para los sensores dht22, otra para el pin Rx para el sensor de C02 y 3 salidas digitales para 3 reles.

Viendo la última entrada de Surbyte voy a probar su solución en el dht22 que tengo aquí en casa a ver qué tal y os cuento.

Por ahora sigo en el fango, la última solución será cambiar todos los dht22 por otro sensor que también mida temperatura y humedad.

Seguimos en contacto. Saludos a tod@s.

P.D.: Surbyte, los sensores dht22 que tengo venían montados sobre placa e incorporan la resistencia entre Data y VCC. No se si coger el estañador y quitársela. Voy a agregar foto.