This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

  • 4 voto(s) - 2.25 Media
  • 1
  • 2
  • 3
  • 4
  • 5
[SpainLabsIoT2018] Caso real: Nodos ESP8266
#21
(15-03-2018, 01:18 PM)Kurama escribió:
(15-03-2018, 11:40 AM)grafisoft escribió:
(15-03-2018, 09:35 AM)Kurama escribió: No se podria sacar una versión mas reducida con la que se pueda usar una lipo como la de los mini drones? Estoy en documentacion de mi proyecto para gestionar la temperatura/humedas de todas las estancia s de mi piso y habia visto la NodeMCU pero la de Grafisoft tiene muy buena pinta.

El problema de nodemcu es que no esta enfocado al bajo consumo, de ahi que yo tuviera que hacer este diseño,  porque mis pruebas iniciales eran en nodemcu.

La pcb  es del tamaño que las baterias 18650, no ocupa mas. Cuidado porque para conseguir autonomia, si no vas a tener el dispositivo conectado a la red o panel solar, no puedes usar una bateria pequeña.

El rediseño siempre es posible. La pcb esta no es mucho mas grande que la de nodemcu. Le puedes poner una bateria del tipo que quieras, no es necesaeio que sea tipo 18650, la pcb dispone de connector ptipo JST para una bateria externa.

Me queda alguna pcb, si te animas a soldar Guiño


Saludos

Me gusta la idea, se podria conserguir con todos los componentes para soldar?

Si que se podria.
  Responder
#22
Por intentar simplificar un poco nuestros códigos, esto podría seros útil.

Actualmente para construir toda la estructura necesaria para enviar datos mediante MQTT hacemos algo similar a esto:

Código:
//Bloque para el envio del valor temperatura.
   char valTemperature[5];
   dtostrf(bme.readTemperature(), 3, 1, valTemperature);
   String payload; //Variable para contener la info de la trama que se envia.
   //Creamos la trama. Sera del estilo: "sensors/NodeName/temp"
   TopicMQTT = "sensors/" + NodeName + "/temp";
   //Creamos el mensaje. Sera del estilo: "NodeName temperature=";
   payload = ""; //Limpiamos la variable.
   payload += NodeName;
   payload += " temperature=";
   payload += valTemperature;
   //Enviamos la trama via MQTT.
   client.publish((char*) TopicMQTT.c_str(), (char*) payload.c_str());
   delay(3000);

Y esto lo hacemos para cada tipo de dato que queremos enviar, es decir, este mismo fragmento (cambiando algún nombre de variable) lo tenemos que repetir para todos los datos que queremos enviar. Como pueden ser, temperatura, humedad, presión, etc etc.

Podemos simplificar un poco esto, y crear una función genérica que genere todo lo necesario para construir.

Estas lineas no las vamos a incluir, son para preparar el dato, y es algo que tendremos que dárselo ya hecho a la función:
   char valTemperature[5];
   dtostrf(bme.readTemperature(), 3, 1, valTemperature);

El resto lo que haremos sera crear la siguiente función en el archivo "funciones.h". Lo podemos colocar al final de todo el contenido. Añadiremos lo siguiente:


Código:
//Funcion generica para el envio de datos usando MQTT. Los parametros
//tienen que ser de tipo String.
//Siendo el parametro Dato el correspondiente al valor del sensor que queremos enviar.
//El resto de parametros corresponden a la creación del topic.
//El topic tendra la estructura: "BName/NName/TipoDato".
void enviarDato(String Dato, String BName, String NName, String TipoDato) {

     //Creamos el topic. Sera del estilo: "BName/NName/TipoDato"
     TopicMQTT = BName + "/" + NName + "/" + TipoDato;
     //Creamos el mensaje. Sera del estilo: "NName TipoDato=";
     String payload; //Variable para contener la info de la trama que se envia.
     payload = ""; //Limpiamos la variable.
     payload += NName;
     payload += " " + TipoDato + "=";
     payload += Dato;
     //Enviamos la trama via MQTT.
     client.publish((char*) TopicMQTT.c_str(), (char*) payload.c_str());
     delay(3000);

}

En nuestro archivo de código principal (main.cpp), enviaremos los datos de la siguiente manera:
Al principio de todo, justo debajo de la linea " #include "funciones.h" ", para facilitar la configuración del código según que queramos hacer con el nodo, colocaremos lo siguiente:


Código:
//----------------------- CONFIG PARAMETERS------------------------
//Con este parametro se construye todos los topics para el protocolo MQTT.
// Nombre del nodo.
//Estructura del Topic: "BaseName/NodeName/"
String BaseName = "sensors";
String NodeName = "Test4";
//El tiempo de sueño se especifica en el fichero funciones.h (sleeptime).
//-----------------------------------------------------------------

Así simplificamos y no tenemos que andar renombrando por el código los nombres de diversos parámetros según el tipo de sensor o dato que mandemos.

Para enviar los datos, ahora simplemente tendremos que usar esta función:

Código:
enviarDato(valDato, BaseName, NodeName, "TipoDato");

Donde en valDato es el parámetro que pasamos a la función con el valor del dato. Ya tiene que estar convertido a string.
El resto de parámetros que le pasamos es para construir el topic, que tendrá la estructura: "BName/NName/TipoDato".

En la siguiente versión que suba del firm para el curso, ya tendré implementada esta estructura. Os la comento aquí para los que vais pidiendo PCBs sueltas y que os resulte mas fácil programar. Espero os sea de utilidad.

Saludos
  Responder
#23
Alguien que controle de OTA en ESP8266, para ver como podríamos implementarlo en este proyecto? Seria muy interesante Sonrisa
  Responder
#24
(15-03-2018, 03:35 PM)grafisoft escribió:
(15-03-2018, 01:18 PM)Kurama escribió:
(15-03-2018, 11:40 AM)grafisoft escribió: El problema de nodemcu es que no esta enfocado al bajo consumo, de ahi que yo tuviera que hacer este diseño,  porque mis pruebas iniciales eran en nodemcu.

La pcb  es del tamaño que las baterias 18650, no ocupa mas. Cuidado porque para conseguir autonomia, si no vas a tener el dispositivo conectado a la red o panel solar, no puedes usar una bateria pequeña.

El rediseño siempre es posible. La pcb esta no es mucho mas grande que la de nodemcu. Le puedes poner una bateria del tipo que quieras, no es necesaeio que sea tipo 18650, la pcb dispone de connector ptipo JST para una bateria externa.

Me queda alguna pcb, si te animas a soldar Guiño


Saludos

Me gusta la idea, se podria conserguir con todos los componentes para soldar?

Si que se podria.
Me interesarían dos, envíame mp.

Saludos,
"Enseñar es aprender dos veces".
  Responder
#25
(07-04-2018, 04:08 PM)Kurama escribió:
(15-03-2018, 03:35 PM)grafisoft escribió:
(15-03-2018, 01:18 PM)Kurama escribió: Me gusta la idea, se podria conserguir con todos los componentes para soldar?

Si que se podria.
Me interesarían dos, envíame mp.

Saludos,

MP enviado!
  Responder
#26
Añadida info en el post principal sobre gestión de interrupciones tanto en la parte de software como en hardware.

Gestión de interrupciones: https://techtutorialsx.com/2016/12/11/es...nterrupts/
[Hardware] Posibles formas de implementar la parte de hardware en las interrupciones y deepsleep: https://github.com/esp8266/Arduino/issues/1488
Nota: Todos los pines pueden generar interrupciones excepto el GPIO16.
  Responder
#27
Primero felicitarte por tu gran trabajo,
no se si llego tarde pero te quedan pcb?
un saludo.
  Responder
#28
(13-04-2018, 04:41 PM)adev escribió: Primero felicitarte por tu gran trabajo,
no se si llego tarde pero te quedan pcb?
un saludo.

Gracias Sonrisa


Si, me quedan pcbs, componentes alguno suelto ya. Mandame MP.

Saludos
  Responder
#29
(10-04-2018, 10:21 PM)grafisoft escribió:
(07-04-2018, 04:08 PM)Kurama escribió:
(15-03-2018, 03:35 PM)grafisoft escribió: Si que se podria.
Me interesarían dos, envíame mp.

Saludos,

MP enviado!
Respondido.
"Enseñar es aprender dos veces".
  Responder
#30
(13-04-2018, 05:15 PM)grafisoft escribió:
(13-04-2018, 04:41 PM)adev escribió: Primero felicitarte por tu gran trabajo,
no se si llego tarde pero te quedan pcb?
un saludo.

Gracias Sonrisa


Si, me quedan pcbs, componentes alguno suelto ya. Mandame MP.

Saludos

MP enviado
  Responder
#31
Respondidos todos!

Saludos
  Responder
#32
Planteada la shield para poder conectar sensores. Control de alimentación para reducir consumos. Conectores I2C, UART, 1 ADC, elevador a 5v, 1 conector para pluviómetro y 1 conector directo al ESP para lo que sea (por ejemplo One Wire). No obstante se tiende mas a sensores digitales, que ya llevan toda la electrónica necesaria integrada, de forma que solo nos centramos en comunicación, gestión de interrupciones y alimentación. No hay salida SPI porque generalmente se suele disponer de comunicación SPI e I2C, así que es mejor tirar de I2C. Ahora a ver si cabe todo en la placa y no hay que empezar a recortar conectores Facepalm Creo que le abriré un post solo para la shield, y así quedara mas organizado y localizado el material.

[Imagen: oaRFxaKl.jpg]
  Responder
#33
Primeros pasos... será por conectores!

[Imagen: wrsSDzpl.png]
  Responder
#34
Para empezar, tremendo "mini" curso. Enhorabuena y muchas gracias por el esfuerzo.

Me gustaría hacerte unas preguntas:
- qué autonomía estás obteniendo con las dos pilas? Tengo entendido que la wifi consume bastante (sobre todo en la conexión). Es viable un nodo despierto continuamente? Y en el caso de dispositivos que sólo loguean datos (por ejemplo un sensor de temperatura reportando cada 10 minutos) qué autonomía se puede esperar con los ESP8266?
- estoy un poco pez en el asunto de pedir placas a sitios tipo dirtypcbs... las tienes compartidas en algún sitio de estos? No es por vagancia de subir yo mismo los gerber, más bien por minimizar la probabilidad de error Guiño
  Responder
#35
(19-07-2018, 03:27 PM)argalleiro escribió: Para empezar, tremendo "mini" curso. Enhorabuena y muchas gracias por el esfuerzo.

Me gustaría hacerte unas preguntas:
- qué autonomía estás obteniendo con las dos pilas? Tengo entendido que la wifi consume bastante (sobre todo en la conexión). Es viable un nodo despierto continuamente? Y en el caso de dispositivos que sólo loguean datos (por ejemplo un sensor de temperatura reportando cada 10 minutos) qué autonomía se puede esperar con los ESP8266?
- estoy un poco pez en el asunto de pedir placas a sitios tipo dirtypcbs... las tienes compartidas en algún sitio de estos? No es por vagancia de subir yo mismo los gerber, más bien por minimizar la probabilidad de error Guiño

Hola,

Los gerber estan subidos a github, tienes ahi los ficheros necesarios para enviar a fabricar. Si por lo que sea, algo no te cuadra, lo hablamos.

Sobre autonomias, como bien dices, depende de cada cuanto envies. Un bme cada 10(que realmente si es para medir en casa es muy poco tiempo, siendo 20 o 30min lo suyo, o hacer una programacion mas inteligente de forma que envie datos cuando la diferencia de temperatura con la anterior sea de por ejemplo medio grado). El caso es que con dos baterias puedes tener autonomia de 1 año sin problema.

Tambien puedes conectarle otra bateria diferente, lleva para conector JST y ahi ya pones la capacidad que quieras de Li-ion.

El nodo transmitiendo de continuo son unos 140mA si esta transmitiendo. Si no transmite pero esta encendido son 40-60 o menos. Depende. Si esta en sleep tienes 40uA redondeando.
  Responder
#36
(26-03-2018, 09:47 PM)grafisoft escribió: Alguien que controle de OTA en ESP8266, para ver como podríamos implementarlo en este proyecto? Seria muy interesante Sonrisa

"Controlar" es una palabra muy fuerte, pero yo puedo ayudar. Hay librerias OTA en platformio pero yo encuentro mucho mas sencillo usar la estandard ArduinoOTA.h. El ejemplo en https://github.com/esp8266/Arduino/blob/...sicOTA.ino funciona perfectamente (al menos en un Wemos) sin instalar ninguna librería adicional. Y además de ser más cómodo actualizar el firmware por OTA, va bastante más rápido que por el cable USB (ni idea de por qué) así que todo son ventajas Sonrisa

El OTA está escuchando en un puerto las posibles peticiones de subida de firmware, con lo cual no se puede poner tal cual en un nodo a batería que esté en deep_sleep la mayor parte del tiempo. Una manera que se me ha ocurrido es tener topics mqtt de petición de actualización. En el nodo nos subscribimos a, por ejemplo 'ota/<nombrenodo>', y cuando recibe ese mensaje cambia alguna variable de estado para que en vez de hacer "deep_sleep" esté un tiempo determinado en un bucle con ArduinoOTA.handle()

Como la primera vez que mandemos el mensaje 'ota/nombrenodo' el ESP estará durmiendo, tenemos que publicar ese mensaje con "retencion" (en mosquitto_pub se hace con la opcion -r'). Esto hace que el mensaje quede guardado en la base de datos de mosquitto y cuando un nuevo cliente se subscriba a ese topic, mosquitto le mandará el último mensaje.

El procedimiento para actualizar sería el siguiente:

1. Mando un mensaje al nodo que quiero actualizar, con mosquitto_pub -t 'ota/nombrenodo' -m 'ON' -r
2. Espero a que el nodo se despierte (o le pego un reset manual)
3. El nodo se despierta, recibe el mensaje retenido de que se solicita actualización y en el loop ejecuta ArduinoOTA.handle()
4. Subimos la nueva version.
5. Al estar el mensaje retenido en el mosquito, en cada reinicio el nodo seguirá poniendose en modo "ota"
6. Cuando estemos contentos con el resultado, borramos el mensaje de mosquitto con "mosquitto -t 'ota/nombrenodo' -n" (la -n significa null message) y en el siguiente reinicio del ESP se salta el modo OTA y vuelve a hacer su proceso y luego deep_sleep.

Es un poco rollo pero no se me ocurre otra manera de hacerlo a distancia... Cómo lo veis? Yo hice unas pruebas con un Wemos y parece que funciona bien.
  Responder
#37
Si, el proceso de MQTT es lo que tenia en mente. Lo unico que es el nodo quien lee un topic, y segun ese valor hace lo que este programado.
  Responder
#38
He estado probando unos días unos sensores y parece que están funcionando bien. En mi caso, estoy utiliando Wemos D1 con cargadores USB de móvil, lo cual no es muy eficiente energéticamente y estoy pendiente de hacer unas pruebas reales de consumo eléctrico (porque el cargador, aunque el micro esté en sleep, consume). Pero es que si no no conseguía empezar y mira, así siempre se aprende algo. Deberia funcionar con la placa de grafisoft teniendo en cuenta los pines, claro.

El sistema funciona asi:

Cuando se despierta el procesador (cada SLEEP_TIME microsegundos)
* se conecta a la wifi
* lee la temperatura y la envia como payload en un mensaje mqtt con topic TOPIC_TEMP (definible en platformio.ini)
* se subscribe al topic TOPIC_OTA_SET para ver si hay alguna petición de actualizacion por OTA
* si no hay peticion de actualizacion, vuelve a dormir
* si hay peticion:
   - envia un mensaje (con TOPIC_OTA_AVAILABLE) de que esta listo para el envio
   - espera por la actualizacion durante 5 minutos
   - y cuando recibe la actualizacion o pasan esos 5 minutos vuelve a reiniciarse, borrando los mensajes TOPIC_OTA_AVAILABLE y TOPIC_OTA_SET para que la siguiente vez entre en modo "normal" (leer la temperatura y dormir)
Creo que se entiende fácilmente y el código no es muy complicado.

Hay varias consideraciones:
* Lo del modo OTA, en un dispositivo Wifi a baterías, tal y como lo he pensado yo, no parece muy eficiente. Porque el dispositivo tiene que conectarse siempre a la wifi para comprobar si existe petición. Sin este requerimiento, el dispositivo podríá despertarse y sólo conectarse si la diferencia de temperatura con la reportada anteriormente pasa de un umbral. Se ahorraría bastante batería.
* Tuve bastantes problemas con el telegraf y grafana. El formato influx no me acaba de convencer porque requiere un montón de customización para integrarse con otros sistemas, no es nada estandard. Y fui incapaz de recoger temperatura en formato "float", sólo lo podía hacer en "string" y perdía bastantes funcionalidades en grafana, porque aunque los graficos los hacía bien (como si le enviara un número), los gauges no se representan bien... y... bueno. Por ahora prefiero hacerlo en modo estandard que se integra perfectamente con homeassistant y "mqtt dash" para android.
* En el código tengo varios delays que no tengo claro que sean necesarios... Como tengo los sensores enchufados no me preocupa pero para un dispositivo a batería está claro que hay que optimizar eso para tener el micro en suspensión el mayor tiempo posible.

Mando un zip con tres sensores, sólo para demostrar las posibilidaes de platformio de, con el mismo código, poder programar varios dispositivos distintos. Se definen variables en los distintos "environments" y se suben a cada dispositivo por ejemplo con:
Código:
$ platformio run --target upload --environment esp-sala

Esto subiría el programa a la IP definida en el entorno "esp-sala". Previamente tenemos que publicar un 'ota/esp-sala/set' ON, y esperar por el 'ota/esp-sala'. Evidentemente, la PRIMERA vez tendremos que subirlo añadiendo --upload-port /dev/ttyUSB0 (o el puerto correspondiente).

Seguramente se podrá optimizar definir tanta variable (sólo con el client-id sería suficiente) pero... lo fui dejando y el sensor de la sala me marca 25 grados... No puedo programar asi, jajajaja.


Archivos adjuntos
.zip   sensores_dallas.zip (Tamaño: 4.73 KB / Descargas: 46)
  Responder
#39
Buen aporte. Sobre lo de ota (no se si se podra hacer asi) una vez que el nodo ha leido el topic subscrito donde le indica si hacer update o no, el propio nodo tiene que ir a descargar el nuevo firm. No haria falta que este esperando.

Lo mismo que verificar si tiene que actualizar, se puede programar que lo haga una vez al día o que lo mire cuando suba rralmente un dato.

Pese a que en los ejemplos que subi yo, donde activo el wifi y establezco una conexión, no es del todo acertado. Lo suyo es hacer las medidas de los sensores y cuando este todo preparado para ser enviado, entonces hacer la conexión wifi y enviar, consultar si hacer ota o actualizar parametros y apagar wifi. Asi se reduce al maximo el tiempo en el que el nodo tiene un mayor consumo.

Lo de influx tiene que haber alguna forma.
  Responder
#40
Estoy dandole vueltas a entre hacer una tirada de esta placa con algunas mejoras o hacer una nueva. Quiero hacer un sistema de riego y necesito colocar unos sensores y controladores de la bomba y/o electroválvulas.

Si tenéis sugerencias de que le cambiarías o echáis de menos, es el momento de comentar.

Si queréis pcbs, decirlo para tener en cuenta Sonrisa
  Responder


Posibles temas similares…
Tema Autor Respuestas Vistas Último mensaje
  ESP8266 queda inaccesible juandavid8a 4 2,671 16-02-2023, 07:40 AM
Último mensaje: ruben2023
  CONSULTA Clones ESP32 y ESP8266 Anje 5 1,758 15-11-2020, 11:14 AM
Último mensaje: grafisoft
  [SOLUCIONADO]Raspberry Pi no ve mensaje ESP8266 silth 9 2,301 24-04-2020, 07:30 PM
Último mensaje: grafisoft
  ESP8266 callback + deepSleep silth 9 3,402 26-12-2019, 12:51 PM
Último mensaje: grafisoft
  [SpainLabsIoT2018] InfluxDB + Telegraf grafisoft 27 12,552 21-12-2019, 03:31 PM
Último mensaje: silth