Dudas sobre los datos


#21

Re-hola, Ega, en referencia al tema de la separación de la primera columna (año-mes-díaThora:segundos con decimales, convertirla en dos columnas (1: año-mes-día, i 2: hora:minutos:segundos), he localizado la manera bastante más fácil de hacerlo desde el mismo Excel.

Pongo el enlace de ayuda de Excel, por si le es útil a alguien más. A mi me ha fucionado de lujo. La única precaución que hay que tomar, es que antes de empezar hay que añadir una segunda columna a la derecha de la primera, si no las horas se colocaran en la columna de la humedad:

Bueno, pues nada más. El tema està funcionando sobre ruedas, después de ir puliendo el tema datos.

Muchas gracias de nuevo.

Salu2 cordiales


#22

Con thinger se tiene un comportamiento extraño cuando se usan delays (me ha pasado a mí), por ello es preferible usar otro tipo de estrategia cuando se requieren usar temporizadores, pero en tu código no es necesario, lo único que deberías hacer (si no lo has hecho ya) es comentar la instrucción para que no consulte y envíe por puerto serial, no tiene sentido estar consultando el sensor y publicando si no se usa la lectura pues.

Saludos,


#23

Hola de nuevo, Ega. Bueno ya he entendido el por qué no es necesario ni conveniente el delay, especialmente en el loop, pero teniendo este problema que tengo con las horas, utilizo la lectura para el serial, para comprobar que funciona correctamente. Pero bueno, voy a comentar este delay en el setup, a ver qué pasa.

El otro delay(delayTime); del loop, ya lo comenté y la cosa ha mejorado algo (bastante), pero sigue habiendo saltos raros:


Desde que recopilé esta serie, con este delay comentado, cómo puedes ver, va funcionando correctamente desde las 10:00h hasta las 18:00h y, sin tocar nada, se pone a imprimir de nuevo a las 18:34h. Mantiene esta cadencia hasta las 21:34h, y salta a imprimir a las 22:04h, manteniendo esta cadencia hasta ahora. En todo este tiempo, no he hecho ninguna modificación ni he trasteado nada, excepto el control del funcionamiento desde Thinger.

Ahora he comentado el delay del setup Solo comentado este delay, sin comentar las instrucciones referentes a la lectura por serial), a ver si cambia alguna cosa, he descargado de nuevo el sketch y voy a poner en hora la impresión en el bucket. Tendremos que dejar pasar un día más a ver como se comporta.

Por cierto, me comentaste que la configuración horaria del bucket y del dashboard, no influía entre sí, pero parece que sí que influye el horario seleccionado en el primero sobre el segundo. Al menos esto he creído percibir en la impresión de los datos vistos en los gráficos del segundo. Esto no tiene la más mínima importancia, ya que los gráficos son meramente informativos visualmente, pero creo que es así.

Vale, pues si no me indicas nada más, vamos a ver qué pasa al eliminar todos los delays del sketch.

Te digo algo.

Muchas gracias por tu ayuda.

Salu2 cordiales.


#24

El delay del setup no afecta mucho (por no decir nada), porque solo se ejecuta una sola vez (cuando se enciende o resetea el micro), los que afectan son los delay en el loop, o en las funciones que se ejecutan en el loop, ojo con esto también.

Por casualidad estas modificando las propiedades del bucket entre medidas? porque se me ocurre que quizá al actualizar el bucket, se toma un dato y el siguiente a los 60 minutos, estoy especulando, no sé específicamente como funcionan la adquisición de datos por el bucket.

Para probar si funciona, desconecta el puerto serial y hazle la interrogación con mas frecuencia, el bucket te permite hacerlo cada minuto, para debuggear es un buen método porque pruebas el dispositivo en condiciones reales de trabajo, en producción no debería estar pegado por consola serial, digo yo.

De nada, es grato ayudar a quien esta empezando en esta aventura, así como en alguna oportunidad recibí ayuda :wink:

Saludos,


#25

Re-hola, Ega, no, durante el período de toma de los datos anteriores, no toqué nada, por si acaso.

De acuerdo contigo con el delay del setup, pero por si acaso…

Por lo que he podido comprobar, y siempre que funcione correctamente, la adquisición de datos empieza en el momento que le dices al data bucket el período que quieres recibir los datos, no a una hora redonda. Es decir, si aceptas el período, por ejemplo a las 10:23h, imprimirá datos a las 11:23h, 12:23h, 13:23h… El truco está en esperar a una hora redonda, por ejemplo a las 11:00h y clicar sobre aceptar la cadencia del data bucket.

Y creo que HAS DADO EN EL CLAVO!!!. Ayer, sobre las 22h, desactivé todo lo referent a al Serial.print del sketch y, a las 22:02h puse en hora el data buckets… Hoy, a las 18:02h, sigue marcando las tomas de cada hora a las :02h en punto y sin saltarse ni una. Ahora sí que parece que funciona como un reloj (nunca mejor dicho…

Lo que no acabo de entender es el por qué afectan las lecturas del Serial.print a la petición de datos del data buckets. En principio no debería interferir uno en otro.
Los datos que imprimía en serial iban a una velocidad vertiginosa, de manera que se hacía difícil leerlos, por eso me cuesta entender que provocara estos desfases.

Bueno, pues seguiré controlando el tema unos días, a ver si sigue funcionando bien. Cuando esté seguro te lo comunico.

Y muchas gracias por la sugerencia. A mi no se me habría ocurrido nunca, pero ahora tendré en cuenta este dato por si me encuentro otros fallos en algun otro proyecto.

Venga, te digo algo.

Salu2 cordiales.


#26

Claro, lo que comentas es muy cierto, la velocidad de datos al puerto serial va a velocidad vertiginosa, pero si vemos la relación de los tiempos, consume mucho más tiempo en el ciclo de trabajo el puerto serial que el thinger.handle();, aunque igualmente me parece bastante sencillo el sketch para dar una irregularidad de este estilo pero bien que se solucionó (siempre se aprende algo nuevo), de igual forma el puerto serial regularmente se usa para debuggear y ya, no para reportar en entorno de producción :wink:

Saludos


#27

AY, Ega, que esto sigue fallado… Ayer ya hizo, de nuevo, el tonto, pero tal vez fue porqué estuve trasteando con el ordenador. Lo puse de nuevo en hora, y esta madrugada, evidentemente sin que se tocara absolutamente nada (a no ser que sonámbulo, trasteara algo, cosa poco probable), hasta las 0:00h, marcaba correcto, pero la siguiente lectura la ha dado a las 0:54h y así seguía.

Voy a probar dos cosas:

1.- En lugar de seleccionar la hora, más o menos, exacta (11:00h), lo seleccionaré a las 11:02h, a ver si va coincidiendo la impresión con mas/menos 2 minutos.

2.- Cambio la alimentación (con USB desconectado, como lo tenía ya), de la red de 220v, y le pongo una alimentación con pila de 9V, totalmente autónoma. No sea que algun fallo de corriente o ves a saber qué, le haga hacer el tonto.

Ya te iré informando de como va…

Salu2 cordiales.


#28

Hola Jaume,

¿Donde estás indicando el intervalo entre lecturas? quiero decir, ¿qué configuración tienes? El dispositivo envía el dato a thinger con un thing.stream() o es el servidor el que solicita el dato con un “sampling interval” especificado en el menú del bucket?

Si tienes algún delay en void loop() mejor quitalo para evitar problemas.

un saludo


#29

Hola, jtrinc26, el intervalo entre lecturas està definido desde el Data Buckets > Bucket Explorer > Bucket Settings:

Y he desactivado todos los delays y lo que hace referencia a la lectura por serial:

#define _DEBUG_  //Imprimeix, a serial, l'estat de la connexió WiFi
#define _DISABLE_TLS_  //Imprimeix, a serial, l'estat de la connexió WiFi

#include <ESP8266WiFi.h>       //Librería de conexión WiFi del módulo ESP8266
#include <ThingerESP8266.h>    //Librería de la plataforma thinger.io

#include <Wire.h>
#include <SPI.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BME280.h>

// Assignar pins ESP8266 a pins arduino
#define D1 5
#define D2 4
#define D4 2
#define D3 0

// Assignar SPI als pins
#define BME_SCK D1  //SCL BME280
#define BME_MOSI D2  //SDA BME280
#define BME_CS D3  //SCB BME280
#define BME_MISO D4 //SD0 BME280

#define SEALEVELPRESSURE_HPA (1013.25)  //Pressió aproximada. Es pot modificar

Adafruit_BME280 bme(BME_CS, BME_MOSI, BME_MISO, BME_SCK);  //Programari SPI

//unsigned long delayTime;

//Paràmetres del connexió thinger.io
#define username "jaume"  
#define deviceId "BME280"
#define deviceCredentials "jmnnfrr"

ThingerESP8266 thing (username, deviceId, deviceCredentials);
 
//Paràmetres de connexió WiFi
const char WiFi_ssid[] = "MI RED";  //Nom de xarxa 
const char WiFi_password[] = "MI CONTRASEÑA";  //Clau de xarxa WiFi

//Gestió de decimals a la impressió de Thinger
float round_to_dp( float in_value, int decimal_place )
{
  float multiplier = powf( 10.0f, decimal_place );
  in_value = roundf( in_value * multiplier ) / multiplier;
  return in_value;
}



void setup() 
{
    Serial.begin (115200);  //Obre connexió amb serial
    Serial.println (F ("BME280 test"));

    bool status;
    
 // Configuració per defecte
    status = bme.begin();
    if (!status) 
    {
    Serial.println ("No es troba el sensor BME280. Verificar cablejat!");
    while (1);
    }
    
    Serial.println ("-- Test predeterminat --");
//    delay (1000); //Velocitat a la que imprimeix a serial

    Serial.println();

 
  thing.add_wifi (WiFi_ssid, WiFi_password);  //Inicialització WiFi per comunicar-se amb l'API


thing["BME280"] >> [](pson& out)  //Inicializació de la lectura de dades des de l'API
{
out ["Temperatura"] = round_to_dp( bme.readTemperature(), 2);  //*4*
out ["Humitat"] = round_to_dp( bme.readHumidity(), 2); //*4*
out ["Pressió"] = round_to_dp( bme.readPressure() / 100, 2); //,2);  //*4* i *5*
};

}



void loop()  
{ 
    thing.handle();
}

Es como para volverse loco. Me parece muy extraño, pero para mi que hay alguna cosa en Thinger que provoca estos errores al solicitar e imprimir los datos, pero creo que lo tengo bien configurado. Va imprimiendo los datos bien durante un tiempo y, de pronto le da el punto y se adelanta o atrasa la lectura…


#30

WHAT
IS
THIS ?
.
.
.
.
.
.
IN ENGLISH PLEASEEE…

Are you guys wants to grow thinger localy in spain only? or goes widely used around the world?
I also found another posting in spain, but c’mon guys…
Sorry just my 2 cents.


#31

Esto no funciona. Tuve que volver a conectar el engendro a la red por falta de pilas… Estuvo marcando, desde las 22:00h bien, hasta las 03:00h. La siguiente lectura ha sido a las 03:41 y así sigue, imprimiendo a las XX:41h… :roll_eyes::roll_eyes::roll_eyes::roll_eyes::roll_eyes::weary::weary::weary:


#32

Hola Jaume,

Cuando se producen las pérdidas ¿qué salida tienes en el DEBUG de thinger? ¿es posible que no tenga buena señal WiFi y se produzca un timeout o una desconexión?

Se me ocurre que utilices una estructura completamente distinta, y fuerces la escritura desde el dispositivo al server cada X minutos. Yo tengo una estación meteorológica que se hiberna con ESP.deepSleep() y sólo se despierta para enviar el dato y volver a hibernar. Ha estado conectada los últimos tres años y no ha fallado nunca.

De todas formas voy a poner una placa con tu código para tratar de replicar el problema

un saludo!


#33

Hola, Jtrinc26, no se a que te refieres con “DEBUG de Thinger”…

La señal de WiFi es buena, tengo el módem a 50cm del engendro y no tengo ni idea de si se produce alguna interrupción. A estas horas de la madrugada no controlo el sistema.

Y como debería hacer para que ivernara? Es conveniente? Práctico? No es mejor tal y como está ahora?

Me desmoraliza, después de tanto tiempo de pelea, empieza a hartarme…

Salu2 y gracias


#34

Hola Jaume, prueba a poner en la primera línea del sketch de arduino lo siguiente:

#define _DEBUG_

así conectado por Serial, podrás ver una serie de información del dispositivo, quizás así podamos ver que pasa

un saludo!


#35

Me parece super extraño, esto debería funcionar sin problema interrogando desde la plataforma, no sé si influye el período de tiempo, porque me parece extraño que interrogue a las :41, no sé cómo funciona la plataforma, pero asumo que al interrogar a las :00 si no obtiene respuesta, la siguiente interrogación la hace a la siguiente hora, no creo que haya pasado 41 minutos interrogando y después de ese periodo es que la remota le haya dado respuesta.

Si necesitas que se publique a cierta hora especifica, yo implementaría un cliente NTP para que la remota maneje la hora actual y sea la que decide cuando escribir los datos en el bucket, cuando los minutos sean 00 (ojo porque debes garantizar publique una sola vez cada hora, no que publique todo lo que pueda mientras minutos = 00), con eso te olvidas de buscar sincronizar la plataforma con el periodo de interrogación :wink:

Por supuesto también debes cambiar la configuración del bucket

La opción que plantea @jtrinc26 también es buena, para temas de ahorro de energía, podrías poner a hibernar el micro por 59 minutos y que se despierte, sincronice el tiempo, publique cuando los minutos sean 00 y se duerma de nuevo luego de escribir en el bucket, porque de resto tienes el dispositivo ahí “prevenido al bate” por una hora mientras publica data nueva.

Saludos


#36

Gracias Jccf07 y Ega. A ver, jccj07, ya está esta instrucción en la primera línea, pero las instrucciones que hacen referencia al serial estan comentadas.
Los datos que imprime por serial, lo hacen a toda velocidad, siendo imposible determinar que ha pasado en un momento dado hace horas. No veo cómo controlarlo. De hecho, al eliminar todos los delays y desactivar la lectura por serial, los saltos horarios han disminuido espectacularmente. Ahora parece que salta muy de cuando en cuando.

Ega, estoy contigo en la primera parte, pero no entiendo el resto.

Y otra cosa, a ver si es normal en este proyecto “anormal”. A las 12h he sustituido la alimentació por red, por una pila de 9V, nueva y desprecintada por mi. A las 18h esta pila estaba agotada (3.5V). Tanto consume el engendro? Me extraña mucho un consumo tan elevado y me pregunto, si esto es así, cómo lo alimento cuando sea autónomo? Ni pensar en aplicarle unas placas solares y una batería… Puede ser este un motivo del fallo? A lo mejor está estropeado el ESP8266 o el sensor y alguno de los dos da pol saco?


#37

Hola a tod@s. Parece, y solo PARECE, a falta de seguir las impresiones unos días, que el problema se ha solucionado.

Me llamó la atención que al colocar la alimentación mediante una pila de 9V, esta se agotara en muy pocas horas. No es normal, no? Entonces se me ocurrió que tal vez el módulo ESP8266 estuviera funcionando mal. Lo cambié y des de las 20:01h de ayer, hasta las 20:01 de hoya ha estado imprimiendo los datos de forma precisa…

Y ahora vienen más preguntas. Es normal este consumo que no me parece normal? Si fuera así, tendría que tener la estación conectada a red, sí o sí. Estoy en lo cierto?

He conectado la placa sospechosa, con otro programa que envia datos a una web de un DTH22, mediante un power bank de 5.200mA, con salida de 5V y 2.4A, y en 24h ha consumido el 75% de su capacidad. No lo veo normal.

Y otra cosa, los datos que ha imprimido, son correctos, excepto los últimos, que ha impreso los datos de fecha y hora, pero no los meteorológicos. Puede ser que alguna vez se produzca un fallo similar? O es que mi sensor ha dejado de funcionar?
Imatge2
Ya os iré informando del desarrollo.

Salu2 cordiales


#38

Hola @jaume,

Las pilas de 9v alcalinas tienen unos 600mah de capacidad, y esta placa consume de media entre 70-100mah, así que… esa autonomía está perfecta, no te preocupes. Pero si vas a alimentar con baterías, la estructura que te comentábamos anteriormente cobra más sentido aún pues reduce significativamente el consumo de la placa, que pasará 59 minutos hibernada, con un consumo ridículo. De esta forma podrías alimentar la placa con esa pila de 9V durante meses.

Yo tengo un pequeño sensor de temperatura en el salon construido con un ESP8285 y alimentado con una li-po de 100mah enviando datos cada 15min y suele tener una autonomía de 50 días.

En cuanto a esas lecturas nulas… tiene toda la pinta de que algo ha hecho fallar la lectura, pero esto es muy raro porque si el cableado está mal, tienes que hacer un reset para volver a ejecutar la rutina que establece la comunicación por el i2c, ya que tu bme280.begin() se encuentra en el setup…


#39

Muchas gracias por la atención, Jtrinc26 y tengo que decirte que el tema ya está solucionado. Llevo dos días mirando las lecturas cada hora (cómo un paranoico), y las está imprimiendo perfectamente, a cada hora:00h. O sea que el fallo estaba producido por el ESP8266. Seguramente me lo he cargado debido a las múltiples pruebas y tute que le dado. Al substituirla por otra, ha funcionado perfectamente.

Gracias por la sugerencia de la hibernación, pero que instrucciones debería modificar/incluir y donde? Te agradecería que me ilustrases sobre ello o me indicaras donde puedo buscarlo.

Venga, gracias de nuevo y podemos dar por zanjado el tema de la impresión de datos.

Salu2 cordiales


#40

@jaume! me alegro mucho de que ya funcione todo!

En este ejemplo puedes verlo, básicamente lo que hace es: establecer la conexión con thinger, verificar que se ha enviado el dato y volver a dormir:

#include <ThingerESP8266.h>

#define USERNAME "your_user_name"
#define DEVICE_ID "your_device_id"
#define DEVICE_CREDENTIAL "your_device_credential"

#define SSID "your_wifi_ssid"
#define SSID_PASSWORD "your_wifi_ssid_password"

ThingerESP8266 thing(USERNAME, DEVICE_ID, DEVICE_CREDENTIAL);

int t=0;

void setup() {
   Serial.begin(115200);

   thing.add_wifi(SSID, SSID_PASSWORD);
   thing.init_sensors();
  
   pinMode(13,HIGH);  //the led will be on all the process 
    
   thing["environment"] >> [] (pson& out){
     
       out["temperature"]=  22;
       out["humidity"]=  60;
       out["pressure"]=  916;
       t++;
       digitalWrite(13,LOW);   //just at the end the led turns off
   };
}

void loop() {
   
   thing.handle();
   
   if(!t){                  //if the connection has been created and the resource was sent properly, t==1
     thing.write_bucket("climaStick2", "environment");    //calling the bucket
     delay(1000);          //to be sure that the message has been completely sent 
     ESP.deepSleep(100000*60*5);    //Sleeping the processor for 5 minutes
   }
}