Dudas sobre los datos


#41

Gracias por la ayuda, Jtring26. Al final he optado por adaptar parte del sketch que me has enviado, porqué me daba error en " if(!t){ " y no he dado con la solución. Decía que “t” no estaba declarado en el sketch.

Bueno, finalmente he ido cogiendo las instrucciones que he creído que hacían referencia a la hibernación y las he colocado en el sketch que funciona. De momento estoy probando, pero no imprime ningun dato. Deberé ir mirando la configuración del Thinger…

Un par de preguntas (más), en la última línea ESP.deepSleep(100000*60*5); //Duerme el procesador por 5 minutos, cómo debería hacer para que duerma 59.55 minutos, despierte durante 10 segundos, coincidiendo con la hora para garbar el dato, y vuelva a dormir hasta la próxima solicitud? Qué fórmula debería utilizar, supongo que en esta misma línea?

Y otra cosa, se ha dicho muchas veces que el delay en el loop, no es conveniente y la última instrucción lleva uno de 1000ms. Algun problema?

Gracias por la ayuda y la atención.

Salu2 cordiales.


#42

Hola @jaume,

Culpa mía, debí borrarlo al simplificar el sketch. Basta con incluirlo como variable global, es importante para evitar que se duerma sin haber enviado el mensaje. Ya lo he arreglado. Si no te manda datos a Thinger.io puede ser porque estás durmiendo la placa antes de que termine la comunicación, por eso yo tengo puesto un delay(1000) antes de la instrucción Sleep (quizá sería mejor poner un 2000).

En respuesta a tu pregunta, El cálculo incluido en el atributo es una manía mía, que simplifica las modificaciones, te explido: Multiplica 100.000 microsegundos (1s) por 60 (para hacer 1min) y esto multiplicado por 5 nos permite dormir la placa 5 minutos. Si quieres 59min cambia este 5 por un 59… jeje y para los 55s restantes suma 100.000*55… en total quedaría así:

ESP.deepSleep(100000*60*50+100000*55);

Ahora… si el momento del envío es súper-súper-crítico, me remito a lo que te aconsejó @ega anteriormente, al despertar que sincronice la hora con NTP para asegurarte de es la hora adecuada y manda el mensaje entonces… pero ¿tan crítico es eso?


#43

Hola, Jtrinc26, vale entendido. He llegado a la misma conclusión, mediante otro camino:

void loop()  
{ 
    thing.handle();
   // printValues();  //Descomentar per veure valors a serial
 
//   if(!thing.add_wifi)
//   {                  //si la connexió ha estat creada i el recurs s’ha enviat correctament, t == 1
     thing.write_bucket("climaStick2", "environment");    //Trucant al bucket
    // delay(1000);   //per estar segur que el missatge ha estat enviat completament 
     ESP.deepSleep (3540000);  //Dorm 59 minuts //(100000*60*5);  //Dormint el processador durant 5 minuts
//   }

}

60 minutos son: 3.600.000ms

60 minutos menos 1 (que está enviando datos): 3.540.000ms

Por lo tanto, duerme durante 59 segundos y despierta 1 minuto para mostrar datos. Total, 1h exacta.

Bueno, desde ayer está imprimiendo correctamente los datos. Te explico.

Ahora tengo el sistema como sigue:

1.-“Normal”: Tengo un sensor BME280 conectado a una ESP8266, nueva, conectada a Thinger. Es el sistema con el que he venido trabajando hasta ahora. Me a dado algun problema de horario al imprimir los datos. Va haciendo saltos, no tan seguidos como antes, pero los hace. Está alimentado por red de 220V.

2.- Hibernación: Tengo otro BME280 conectado a otra ESP8266 y también a Thinger, con el mismo conexionado, excepto que tiene una conexión adicional (un puente de D0 a RST, para, según parece, activar automáticamente el despertar del sistema. Este segundo sistema está alimentado, desde hace 24h, mediante dos pilas de 1.5V, total 3V. Debe funcionar correctamente, ya que 24h después la carga que marca es de 2.80V nada que ver con el sistema sin hibernación.

Bueno, los dos sistemas han estado imprimiendo los datos cada xx:00h religiosamente, peeeeero, hoy, a las 19h, AMBOS han marcado 19:04h, es decir que han hecho la impresión 4 minutos más tarde. Lo que me mosquea es que los dos, conectados a la misma plataforma, han cometido EXACTAMENTE el mismo error. Por ello, y en un principio, debo descartar algun fallo en los componentes y alimentación, y debería responsabilizar a la plataforma Thinger, en la gestión que hace del tiempo. Es esto posible?

De momento voy a dejarlo como está, sin tocar nada y ver cómo evoluciona.

PD: Eliminé la instrucción “t++” y “if(!t)”, por qué me daba error de compilación del tipo que “t” no estaba declarado en el sketch, y también el delay (1000); del loop, por los avisos de hipotéticos fallos por la parada del sistema.

Pero funciona tal cómo te he indicado más arriba.

Y bien, que opinas?

Muchas gracias por la atención y la ayuda.

Salu2 cordiales.


#44

La instruccion esp.deepsleep es en microsegundos, se debe multiplicar por 10^6 para obtener segundos, ojo con esto

https://www.esp8266.com/wiki/doku.php?id=esp8266_power_usage

Otra explicacion para la falla con ambos dispositivos es una intermitencia con el acceso a internet (si van por el mismo medio), que se hayan conectado a las :04 y justo en ese instante la plataforma los detecta e interroga instantáneamente, si esto es asi, de que la plataforma interroga apenas se conecta el dispositivo y despues cada hora, explica el comportamiento errático que había antes.

Saludos,


#45

Hola de nuevo, Ega, vamos a ver, seguro que me equivoco al interpretarte, pero los microsegundos que tengo en el sketch (ESP.deepSleep (3540000);), directamente son:

3540000 milisegundos = 59 minutos, + 60000 milis (1 minuto) = 3.600.000 milis = 60 minutos.

Si multiplico 3540000·10 ·6 = 212.400.000 milis = 3.540 minutos = 59 horas.

Me equivoco? No lo he entendido?

Sobre el fallo de los dos dispositivos, me mosquea mucho que se produzcan exactamente los mismos fallos en las dos lecturas siempre. Me he decidido a separarlos. He dejado el original tal cual y he abierto otra cuenta, con otro correo, he copiado el sketch del primero, que funciona más o menos bien, le he cambiado los parámetros del device y credenciales y estoy a la espera de ver si funciona…

pero el problema con los datos sigue igual… arfffffffffffffffff, ya no se que hacer!!! Empieza a asaltarme el desespero y ronda el desanimo…

Imatge1

Salu2 cordiales, y gracias por la ayuda…


#46

Esta instrucción va a hacer que el dispositivo se duerma por 3.54 segundos, porque el parámetro de entrada de la función según la documentación, es en microsegundos.

Haz la estimación en segundos y multiplicas por 10^6 (1000000), en la instrucción lo tienes en milisegundos, en ese caso deberías multiplicar por 10^3 para tenerlo en microsegundos, me explico?


#47

Gracias por la aclaración, EGA, ni me había fijado en el “detallito” de los micro y los milis… Si lo pongo directamente en milis no sirve? O Thinger y el sketch funcionan con microsegundos?

De momento está puesto, a ver que pasa… Ya te digo algo.

Gracias por la ayuda. Salu2 cordiales.


#48

Lo que le pongas como parámetro en ese comando lo va a interpretar en microsegundos, no tiene nada que ver con thinger ni con las otras instrucciones.

Por ejemplo, hay una instruccion que es delayMicroseconds(); que es equivalente al delay que conocemos (que funciona con milisegundos), pero esta funciona con microsegundos, no tienen nada que ver con el resto de instrucciones ni con la plataforma.


#49

Buenos días de nuevo. He dejado pasar tiempo por varias razones que no vienen al caso, pero no he dejado de trabajar en mi proyecto.

En primer lugar, he aparcado el tema de hibernación, ya que no ha habido manera de hacerlo funcionar, y he vuelto al tema del salto horario que, en lugar de imprimir cada hora los datos, empieza bien, pero después de un tiempo, a veces 2-3 días, a veces al cabo de 2h, se vuelve loco e imprime cada cuando le da la gana:

Debe ser algo de Thinger, ya que tengo otro proyecto, igual, pero con otros datos, y me hace lo mismo, salta el horario cuando quiere, y en diferentes horas. Ya no se que mirar…

No se si alguien tiene el mismo problema o soy yo el raro…


#50

Hola @jaume,

Cuando desarrollamos algo crítico solemos introducir variables de debug de la conexión, así si ocurre alguna pérdida de datos sabemos el motivo: En el recurso de salida un millis(); y un WiFi.RSSI(); a ver si en esos casos el dispositivo ha estado en el limbo, o si tiene perdidas de señal… también sería útil que introdujeras en tu código esta estructura (Check Cloud Connection on Arduino) que permite detectar el estado de la conexión y registrar ese tipo de problemas o incuso resetear la conexión si se queda congelada, que a veces pasa.

En la próxima versión del servidor también se incluirá la posibilidad de recuperar un OK de la escritura del bucket, así si hay cualquier tipo de problema con la conexión podemos hacer que siga intentándolo hasta conseguirlo.

Pero me resulta extraño que no te funcionara bien lo de hibernar la placa, la mayoría de las placas que hacen este tipo de lecturas tienen esa configuración y no hay problemas de pérdidas.

un saludo

un saludo


#51

Si es necesario que el dato se almacene cada hora exactamente, yo controlaría el tiempo en el que se hace cada escritura con el microcontrolador.

Puedes ejecutar la rutina cada hora y encender el micro al momento que quieras que se haga la primera lectura, o implementar un cliente NTP y capturar la hora de internet con el micro, y dar la instruccion de que sea cada hora especifica que escriba en el bucket.

Ah y no seria la plataforma que interrogue al dispositivo, seria el microcontrolador que escriba directamente en la plataforma :wink:

Saludos


#52

Gracias por la ayuda, Jtrinc. He mirado el enlace, pero me temo que no comprendo. Donde coloco estas instrucciones? Deben sustituir a alguna existente? Las coloco justo debajo del #define DISABLE_TLS, al principio, pero no me compila… Ufffffffffffff…

Salu2


#53

Gracias por la ayuda, Ega, esta era la idea para evitar tener conectada la alimentación al exterior y también serviría para este caso, pero lo estuve probando con todo lo que me comentasteis, y no hubo manera de hacerlo funcionar. En su momento abandoné provisionalmente la idea, aburrido de fracasar. Si logro solucionar este tema del salto, volveré sobre el tema…

Salu2


#54

Hola jtrinc26, bueno, he retomado tu sugerencia de dormir el ESP8266 y ahora compila, pero no aparecen datos en el bucket. Supongo que será problema de configuración de Thinger. Como debería configurarlo para que funcionara?

Creo entender que Thinger estaría todo el tiempo abierto a que se le enviaran los datos y es el ESP el que los envia, los recoge Thinger y los imprime, no es así? O Thinger va a buscarlos como hasta ahora, a una hora predeterminada, en que ESP esté enviando datos y los imprime? Si es así, como se sincroniza el envio de datos y la recogida e impresión en Thinger, para ahorrar el máximo de energía? Lo he entendido o no? No se si se entiende la duda…

Gracias por la ayuda.

Salu2.


#55

Y otra cosa, después de cargar el sketch, se deben puentear RST y D0, para que después de hivernar se vuelva a poner en marcha?

Salu2


#56

Si, eso es un detalle importante!! en D0 está el pin del RTC interno, es el que manda la señal “wake up”.


#57

Gracias, Jtrinc26, pero como debo configurar el bucket para este sistema?


#58

Cuando creas el bucket en el “Data source” seleccionas “By device call”.

y en el dispositivo la instrucción:

thing.write_bucket("Bucket_Name", "environment");

Va a escribir en el bucket el contenido de las variables definidas en “environment”.

Debes ser cuidadoso con la frecuencia que llames la instrucción, un error puede hacer que el micro intente escribir sin control en el bucket.

Saludos,


#59

Gracias por la ayuda, Ega. Esto no funciona. Imprime los valores en serial, pero no en el bucket.

Veamos si entiendo el funcionamiento de todo el proceso:

1.- En thinger tengo esta configuración:

Es la correcta? Hay que modificar algun otro parámetro?

2.- Al cargar el sketch, desconecto el puente entre RST y D0, si no no compila. Cuando está cargado vuelvo a puentear los pines.

3.- Entiendo que Thinger está abierto a cualquier dato que le envíe ESP? Está pendiente de que ESP le envíe los datos, que son los que imprimirá? Es así?

4.- Sobre el sketch: He añadido las instrucciones que sugería jtrinc26 y, si la configuración de Thinger és correcta, en las siguientes instrucciones creo que está el quid de la cuestión:

a.- if(!t) //Si la conexión se ha creado y el recurso se ha enviado correctamente, t == 1
{
b.- thing.write_bucket(“Bucket_Name”, “environment”); //thing.write_bucket(“climaStick2”, “environment”); //llama al bucket
c.- delay (2000); //Para estar seguro que el mensaje se ha enviado completo
d.- ESP.deepSleep (100000 * 60); //(100000 * 60 * 5); //Dormir el procesador durante 1 minuto

a.- Que significa esta instrucción?

b.- En esta situació, es el ESP8266 el que llama al bucket y le da los datos? O Es el bucket que intenta recoger datos permanentemente y solo pilla los que por un breve lapso de tiempo le facilita el ESP8266?

c.- Este lapso de tiempo (2000 microsegundos = 0.002 segundos), es el que ESP está abierto enviando los datos? Es decir, está despierto? Si es así, no puede funcionar en la vida, ya que desde que despierta y se rearma, hasta que imprime un tren de datos (al menos en el serial), pasan unos 6-7 segundos), con lo que estos 0.002 segundos, son evidentemente insuficientes para enviar nada. Estoy equivocado? Lo he entendido o no?

d.- Creo que lo he hecho bien. Le doy un tiempo de 1 minuto dormido, en lugar de los 5 minutos originales, para poder acelerar el control.

Es así como funciona o estoy equivocado?

Por favor, si logras proporcionarme esta información, creo que me aclararé y podré seguir adelante.

Muchas gracias por la ayuda.

Salu2 cordiales.


#60

Buen día, respondo las dudas que puedo

El bucket esta a la escucha, cualquier dispositivo podría escribir datos allí, no intenta recoger los datos de ningún dispositivo, fíjate que al configurar no estableces con que dispositivo va a funcionar, es absurdo pensar que va a interrogar todos los dispositivos de tu cuenta a ver en cual instante alguno quiere escribir información en base de datos.

La instruccion delay(); es en milisegundos, delayMicroseconds(); en microsegundos ojo con eso, y va a dar un breve periodo de tiempo para la completar la comunicación, el microcontrolador ejecuta una instrucción a la vez, mientras esta imprimiendo datos en el puerto serial no puede estar ejecutando la instrucción de delay.

Según la documentación, el argumento de esta función es en microsegundos, revisa las matemáticas.