Bueno, es que en cada foro es diferente y si no se avisa…
jajajaj a mí también me sangra la vista cuando veo el texto plano. Me he tomado la libertad de editarlo para la posteridad.
otra forma de poner el formato código es poniendo “```cpp” antes y sólo los tres acentos después.
Me alegra ver que conseguisteis resolver el problema! muchas gracias por el soporte @ega!!
Vaaaaaale, perdón por el error de colocación del texto, todo se aprende, no? Ya he eliminado el texto plano para que nadie se ofenda, jajajajajajaja… Y pido perdón.
Vale, pues queda el pié la pregunta de cómo solucionar la cadencia exacta de la recogida de datos en el bucket. Estos días, además de imprimir los datos de forma loca, como indico al principio, se permite el lujo de saltarse alguna hora que otra. No hay manera de afinar estos temas?
Gracias por la atención y la ayuda.
Salu2 cordiales
Jejejejeje si bueno, así provoca más ayudar que cuando lanzan el código y ya, recuerda que la programación es bastante artesanal y cualquier rutina que te inventes hacer algún procedimiento no necesariamente es intuitiva para todo el mundo, y si a eso le sumas que el texto cambia de formato y aleatoriamente… Por supuesto que es incómodo seguir la rutina del código.
Me parece muy extraño que no esté guardando los datos cada hora como debería interrogar la plataforma.
Lo único que no me convence es el delay que tienes. de cuánto es ese delay(delayTime);? No es recomendable usar este comando porque esto detiene absolutamente todo en el micro, y si coincide el momento que la plataforma interroga al dispositivo estando en esta instrucción, no va a recibir la solicitud.
Hola, Ega, muchas gracias por la ayuda, y pues claro que entiendo el tema del texto plano. Estuve buscando la manera pero, al principio, no di con el modo. Entiendo perfectamente el por qué de publicarlo así, ya que a mi también me molesta y lía ver el texto plano.
Y bueno, volviendo al tema, puede que tengas razón. Ya que lo comentas, me viene a la cabeza que leí, no se si con referencia a Thinger o a alguna otra plataforma, que había que evitar colocar delays dentro del void loop(). En un principio no entendí el por qué del aviso, pero ahora lo veo claro. Y es muy posible que estos fallos sean debidos a esta pausa. Si coincide con alguna pausa el momento de lanzar los datos, Thinger no los recibe. Por eso (y es solo una conjetura), había horas de lectura inexistentes. Lo que está por ver, una vez eliminado el delay es si sigue imprimiendo datos entre horas. Tendré que dejar pasar unos días a ver cómo se comporta.
Bueno, pues de momento estaremos a la espera de ver el comportamiento.
Muchas gracias y te digo algo en cuanto tenga unas horas almacenadas.
Venga, hasta ahora. Salu2 cordiales.
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
1 Like
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,
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.
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 
Saludos,
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.
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
Saludos
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.
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
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…
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.
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… 
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!
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
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!
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
Por supuesto también debes cambiar la configuración del bucket
La opción que plantea @JorgeTrincado 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