Go Down

Topic: lecturas de humedad, temperatura y CO2 repetidas tras varias horas (Read 1 time) previous topic - next topic

josekiki

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:

https://forum.arduino.cc/index.php?topic=539300.0

josekiki

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

Saludos.

krnlpanic

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.

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



surbyte

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.



krnlpanic

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.

surbyte

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

josekiki

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


Code: [Select]
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.

surbyte

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.

josekiki

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.

krnlpanic

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

josekiki

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():

https://forum.arduino.cc/index.php?topic=414341.0

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.

krnlpanic

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.

josekiki

Buenas de nuevo.

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

Quote
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.

nakuadak

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.

surbyte

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.


Go Up