Se ha producido algun problema con Thinger?

Buenas noches. Sigo peleándome con la estación méteo y Thinger y ha aparecido un nuevo problema. A partir del 6 de febrero, a las 10h, Thinger imprime los datos cada cuando le da la gana, puede ser cada minuto, durante 1h, o cada 5 minutos, o 30 minutos, pero de forma totalmente aleatoria:

Hasta esta fecha, imprimía los datos razonablemente bien (a veces enviaba dos datos en un hora, pero asumible). Pero a partir de esta fecha, ha enloquecido. He sustituido el ESP8266, por si se hubiera estropeado, le he vuelto a cargar el sketch, pero sigue el mismo problema sin cambios.

La pregunta es si este enloquecimiento puede ser debido a algun problema con Thinger o la plataforma funciona correctamente. Y si es así, alguien tiene alguna remota idea de donde puede venir el fallo?

Gracias por la atención y la ayuda.

Sal2 cordiales

Vale, entiendo. Si nadie responde quiere decir que no pasa nada con la plataforma… Pues nada, a por otra cosa.

Hola @jaume,

No pasa nada raro… de las 8 o 9 placas que tengo conectadas enviando datos cada 10-15min todas van como un reloj. Molaría ver qué código, HW y cableado estás usando.

Justo el sábado hubo que cambiar el certificado SSL de la plataforma, en placas ESP esto produce un warning pero permite que siga funcionando (de hecho yo no he actualizado aún ningun firmware y como te digo funcionan al 100%).

En cualquier caso, para evitar problemas te aconsejo que descargues la última versión de la librería que está colgada en el repositorio de github, esa ya incluye el nuevo fingerprint del server.

un saludo

He tenido una situación similar, tengo un micro enviando datos cada 5 minutos y a veces no se graba el dato en la nube, me parece muy particular que he hecho la prueba haciendo seguimiento en la consola serial y allí reporta que ha escrito “OK”, pero al ver el bucket, no es así.

Para mitigar el riesgo de pérdida de datos, lo que he hecho es comparar los Timestamps, es decir, cuando el micro hace la escritura de datos en el bucket, allí se le agrega la huella de tiempo, lo que he programado es que el micro consulte justo después de que se ha guardado el dato y verifique si la huella de tiempo ha cambiado, si no es así, intente escribir el dato nuevamente después de 1 minuto, porque a pesar de que no se escribe el dato en la nube, al intentar escribirlo de nuevo inmediatamente, ahí si se recibe el mensaje de “FAIL” cuando se hace la escritura, presumo que es la limitación de frecuencia de escritura en la nube que causa este error.

El bucket lo tengo configurado para que sea escrito por el dispositivo, así que es este último el que lleva el control de cuando se actualiza los datos en la nube.

He estado indagando acerca de implementar un cliente NTP en el micro para que sea a ciertas horas que se haga alguna medición o rutina, no es para nada complicado hacerlo, eso quizá sirva de mucho si requieres medir a alguna hora específica.

Saludos,

Hola de nuevo, jtrinc26 y ega. Me he seguido peleando con el tema todo este tiempo, pero no hay manera. Tengo 2 méteos conectadas a Thinger. Una imprimiendo datos cada hora, la que funcionaba más o menos bien, pero solo era de prueba, ya que es inviable, por el consumo, instalarla en el exterior de forma autónoma.
La segunda méteo, con la que me peleaba, la tengo de manera que hiberne e imprima datos cada hora, pero tiene un problema que no se solucionar. A cada hora imprime los datos, pero lo hace con 3 minutos, bastante exactos, de retraso con respecto a la impresión anterior. Por ejemplo: impresión 1 = 10:35; Impresión 2 = 10:20; Impresión 3 =10:05…
La primera méteo, la alimentada por red, funcionaba razonablemente bien, pero ha sido a partir del 6 de febrero, que ha empezado a hacer el loco, desmanguillandose totalmente.
Tal y como indica jtrinc26, he actualizado la librería de la Wemos D1 pro, pero no parece que sirva para nada.
ERga, crees que un cliente NTP solucionaría todo este cúmulo de problemas? Como sería el tema? Donde puedo localizar un tutorial fiable sobre el tema?

Gracias por la atención y la ayuda.

Salu2 cordiales.

Lo único que necesitas es que reporte precisamente a cada hora?

En estos días estoy algo libre de tiempo y podría probar con un micro a ver que tal :wink:

Gracias, por la respuesta. Sí, es una estación meteorológica que pretendo montarla de forma autónoma y necesito que imprima los datos cada hora y, mientras, duerma y no consuma…

Hola Jaume,

¿qué tipo de configuración tienes en el bucket? puedes pasarnos el código?

Todo esto se debería solucionar cuando actualicemos a la nueva versión del server que incluye un parámetro de verificación de escritura en los buckets, de esta forma podemos repetir el envío si falla.

las instancias maker gratuitas incluyen ya esta opción… de todas formas le echaremos un vistazo para ver que puede estar pasando

un saludo!

Gracias por la atención, jtrinc26, tengo dos méteos, Méteo 1 que estaba funcionando razonablemente bien y, de golpe y sin hacer nada de nada, ha empezado a imprimir datos un montón cada hora. La configuración del data Bucker de la Méteo 1 y una muestra de la impresión loca és:

(Si necesitas que te envíe el sketch, tendrás que recordarme cómo se coloca, que no recuerdo ni encuentro la manera de hacerlo).

El void Loop() es:

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

Esta Méteo 1 está alimentada por red, pero lo que quiero es hacer lo mismo pero alimentado de forma autónoma mediante placa solar. Para ello necesito que hiberne. De ahí la Méteo 2.

Y Méteo2. Es lo mismo que la Méteo 1, con esta configuración del Bucket:

Imatge2

y con alguna instrucción más en el void loop(), para que duerma durante 1h, despierte 5000 milisegundos y vuelva a dormir:

void loop()
{
  thing.handle();
  
    if(!t)
      {
      thing.write_bucket ("WEMOSV4","WEMOSV4");  
      delay (5000);  //Milisegundos
      ESP.deepSleep (3600000000, WAKE_RF_DEFAULT );  //Microsegundos
      }
}

Pero el problema que tiene la Méteo 2, es que funciona bastante bien, pero cada lectura que da la hace retrasando 3 minutos casi exactos. Y es acumulativo, o sea, que a primera lectura la hace a la 12:00h; la siguiente 1:57h; la siguiente a las 2:54h…

He cambiado las placas, los sensores, los cableados, etc, y no hay manera de dar con el fallo…

Alguna sugerencia? Qué estoy haciendo mal?

Gracias por la atención y la ayuda.

Sal2 cordiales.

@jaume

Vale, vamos por partes, en el primero la configuración y el código están bien pero ese comportamiento indica que el dispositivo se está desconectando y volviendo a conectar, cuando se establece la comunicación con el server se envía una trama que se guarda en e bucket. Esto me interesa conocerlo para buscar un posible fallo en el funcionamiento del servidor, así que necesito que compruebes el tiempo de conexión del dispositivo cuando esto ocurre. ¿puedes confirmarme que el tiempo de conexión del dispositivo coincida con la aparición del último dato no deseado en el bucket? Esta es una de las razones de que hayamos incluido nodeRED en las nuevas versiones de la plataforma, para poder detectar este tipo de anomalias y reportarlas via endpoint, está explicado aquí:

por otro lado, en el segundo, creo que podemos hacer una mejora de ése código sacando la instrucción sleep a otra rutina y poniendo un segundo cerrojo para que no se hiberne sin haber enviado el mensaje, pero para verlo necesito que me pases también la declaración del recurso.

los programas puedes colgarlos aquí enteros entre triples comillas simples, o pinchando en el botón upload del menú superior de edición del post

un saludo

Vale, estamos en Méteo1. Cómo puedo saber si se conecta o desconecta el dispositivo? El tiempo de conexión?

Donde pones que “…está explicado aquí”, no hay nada, ni enlace ni nada de nada. Tampoco se qué es ni en qué consiste nodeRED…

Referente a la Méteo2, la instrucción sleep es la que me indicasteis no se si tu o otro compañero. He estado trasteándola, pero no he conseguido nada. Que instrucción sería mejor? Y eso del segundo cerrojo, qué sería? En qué consistiria?

Bueno, finalmente lo he conseguido: pegar el programa + “Preformatted text”.

Este es el sketch de la Méteo1, la que anda loca:

#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); // hardware SPI
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[] = "XXXXXXXXXX";  //Nom real de xarxa: WIFI_5G_PtG4
const char WiFi_password[] = "XXXXXX";  //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 ("-- Sensor funcionant --");
    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 ["1 Temperatura"] = round_to_dp(bme.readTemperature() / 1.09, 2); //*4*
out ["2 Humitat"] = round_to_dp (bme.readHumidity() / 0.77, 2);  //*4*
out ["3 Pressio"] = round_to_dp (bme.readPressure() / 99.76, 2);  //*4* i *5*
out ["4 Index calor"] = round_to_dp (0.63 * (bme.readTemperature() + 61.0 + ((bme.readTemperature() - 68.0) * 1.32) + (bme.readHumidity() * 0.094)),2);  //*4* i *5*
out ["5 Punt rosada"] = round_to_dp((bme.readTemperature() - ((100-bme.readHumidity()) /5)),2);

};

}



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

Y este segundo es el de la Méteo2, la que duerme 1h, despierta, envía datos con 3 minutos de retaso cada vez. Pero a parte del retraso, este funciona correctamente:

#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;

int t = 0;  //Per regulació horaria

//Paràmetres del connexió thinger.io
#define username "loko"
#define deviceId "WEMOSV4"
#define deviceCredentials "jmnnfrr1955"

ThingerESP8266 thing (username, deviceId, deviceCredentials);
 
//Paràmetres de connexió WiFi
const char WiFi_ssid[] = "MIWIFI_2G_PtG4";  //Nom real de xarxa: WIFI_5G_PtG4
const char WiFi_password[] = "sh96xFX2";  //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 ("-- Sensor funcionant --");
    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["WEMOSV4"] >> [](pson & out)  //Inicializació de la lectura de dades des de l'API
  {
    out ["1 Temperatura"] = round_to_dp(bme.readTemperature() / 1.09, 2); //*4*
    out ["2 Humitat"] = round_to_dp (bme.readHumidity() / 0.77, 2);  //*4*
    out ["3 Pressio"] = round_to_dp (bme.readPressure() / 99.76, 2);  //*4* i *5*
    out ["4 Index calor"] = round_to_dp (0.63 * (bme.readTemperature() + 61.0 + ((bme.readTemperature() - 68.0) * 1.32) + (bme.readHumidity() * 0.094)), 2); //*4* i *5*
    out ["5 Punt rosada"] = round_to_dp((bme.readTemperature() - ((100 - bme.readHumidity()) / 5)), 2);

//    t++;  //Referent a instruccions hivernació

  };

}



void loop()
{
  thing.handle();
/*  
    if(!t) //Si la connexió s'ha creat i el recurs s'ha enviat correctament, t == 1
      {
      thing.write_bucket ("WEMOSV4","WEMOSV4");  //Trucant al bucket
      delay (5000);  //Mil·lisegons
      ESP.deepSleep (3600000000, WAKE_RF_DEFAULT );  //Microsegundos
      }
}

Ahora sí…

@jaume Por curiosidad, por qué la diferencia entre ambos códigos?

Lo que presumo que está sucediendo es que como Meteo1 se interroga desde la plataforma cada hora, al conectarse, se interroga y guarda el dato, se inicia el contador de tiempo en línea y espera a hacer la siguiente consulta a la siguiente hora, al desconectar y reconectar se repite el ciclo y por ello este comportamiento reflejado en los datos.

Si tienes Meteo1 siempre encendida, quizá sea más efectivo llevar el contador en el microcontrolador y que sea este el que escriba en el bucket cuando haya pasado el tiempo de espera (1 hora), sería básicamente el mismo principio que Meteo2, pero sin poner a dormir el dispositivo.

@JorgeTrincado A mí me ha pasado que he estado viendo el comportamiento de la remota por consola serial, y con la función de escribir en el bucket, da el mensaje que ha escrito OK, pero al verificar, no es así y sucede aleatoriamente (a veces sí escribe el dato sin problema), quieres más información de esta irregularidad en pro de solventar alguna situación con la plataforma?

Gracias por la atención, ega, la diferencia entre ambos códigos, es que la Méteo1 está permanentemente conectada a red. Por contra, la finalidad de la Méteo2 es la de colocarla de forma autónoma, alimentada mediante una placa solar. La placa WEMOS que utilizo, consume mucho y es inviable colocarla autónomamente con el código de Méteo1, ya que agota las baterías en muy poco tiempo. De ahí la necesidad que tengo de hacer dormir la placa de Méteo2, para que disminuya al máximo el consumo.

No se si hay algun sistema más efectivo para hacer que la WEMOS hiberne. Estos sketchs han sido construidos a partir de varias fuentes, aprovechando algunas cosa de uno e incrustando otras de otro. No he conseguido localizar ningun proyecto que incluya WEMOS + BME280 + Thinger y, que encima, hiberne. Si hubiera algun programa diferente que cumpliera estas premisas, me estaría perfecto. O, si fuera el caso y hay algun error o disfunción en los sketch, pues me lo decís y lo solucionamos…

Gracias por la atención y la ayuda.

Salu2 cordiales.

Hola Jaume,

echale un vistazo a esto: https://www.hackster.io/ThingerMakers/iot-meteorological-station-a69a03

el primer código está bien, los problemas tienen que estar producidos por desconexiones, quizá esté muy lejos del router o la conexión falle en algún punto intermedio. Como te decía la única forma de confirmarlo es que revises si los datos de más coinciden con desconexiones de las placa.

En cuanto al segundo código, imagino que el comando t++ no lo tendrás realmente comentado y que el /* del loop tampoco estará en el código… no?

asumiendo que es así, y que estás verificando que el recurso se lee al menos una vez, te garantizas que tienes conexión y entonces se puede hacer el write_bucket supuestamente sin problemas, pero en caso de que los haya, lo que podemos hacer es no hibernar la placa hasta que el valor de T sea == 2, me explico:

cuando thing.handle logra comunicar con el servidor, se ejecutan todos los recursos para que el servidor pueda suscribirse a ellos (t==1), posteriormente, cuando se ejecute weite_bucket el recurso se ejecuta por segunda vez y t==2.

podemos usar esto para evitar que se llame a la isntrucción deepSleep antes de tiempo:

void hibernar(){
      ESP.deepSleep (3600000000, WAKE_RF_DEFAULT );  //Microsegundos

}

void loop() {
  thing.handle();

if(!t){ //Si la connexió s'ha creat i el recurs s'ha enviat correctament, t == 1
      
      thing.write_bucket ("WEMOSV4","WEMOSV4");  //Trucant al bucket
      delay (5000);  //Mil·lisegons
       if(t>1) hibernar();  //hacemos un cambio de contexto para evitar problemas
  }
}

con esto, si hay más fallos ya se deberían a la red o a algún problema en el servidor.

un saludo

Hola, jtrinc26. Sobre el primer código, el router y la Méteo (1 y 2), estan a 50cm, o sea que por ahí nada.
La Méteo1, estan los componentes soldados en una PCB, por lo que el único cable que tiene, es el de alimentación.
Cómo puedo saber si los datos de más coinciden con hipotéticas desconexiones de la placa si, insisto, no se cómo controlarlo?

En cuanto al segundo código, tienes razón, estan descomentados y ha sido un fallo mio. Copié este mismo sketch para otra cosa y se me olvidó descomentarlos.

Referente a t == 2, tengo que cambiar algo? No veo haya ninguna instrucción t==1. No serà que debería modificar t++; verdad?

He modificado el resto que me indicas y ahora esperaré hasta mañana, a ver si se produce el retardo o no. Mañana te digo algo.

Saludos cordiales y gracias.

Bueno, ayer dejé funcionando la Méteo2 y solo dio la primera lectura, justo cuando acaba de cargar el programa. Ni una sola más…