Seguridad Agile: ESP32 con BMP280

En el marco del mínimo sistema IoT que he preparado para la futura materia Implementación de IoT, mientras se confeccionaba la lista de materiales para la carrera completa, hubo discusión acerca de si usar DHT11 o BMP280, ambos sensores de temperatura.

El DHT11 es más barato, usa un solo pin, pero es menos preciso.
El BMP280 usa I2C, dos pines y se deduce de la frase anterior que es más caro y preciso.

Lo que no se deduce es que el primero mide temperatura y humedad y el segundo además presión, salvo el modelo que he conseguido que no mide humedad.

Al DHT11, dependiendo de la presentación hace falta agregarle un resistencia de entre 5 a 10 K, le he puesto unas SMD rescatadas de unas viejas placas de una central telefónica hallada en un volquete en el centro cerca del trabajo.

DHT11 con resistencia SMD en los pines

Había implementado todo para DHT11 pero entre que las otras materias no lo iban a usar y que para ESP32c3 no funcionó, incorporé el BMP280 al ESP32c3 y luego al ESP32, llegando al punto de poder retirar al DHT11 de la lista de materiales, discusión resuelta. De todos modos quedó en el repo disponible.

Para la adaptación no hay ningún sufrimiento, hay que tomar la implementación con DHT11, borrar lo específico y reemplazarlo con el código de ejemplo de UncleRus, que es básicamente un include, elegir los pines, armar una estructura, inicializar y leer.

Respecto a los pines, a diferencia de DHT11 que usa un protocolo serial OneWire por software y se puede implementar en cualquier pin GPIO, BMP280 usa I2C por hardware, supuse que debía ser un subconjunto bastante menor.

Busqué en esp32-wroom-32_datasheet_en.pdf y nada. Por suerte luego hallé un tutorial https://randomnerdtutorials.com/esp32-i2c-communication-arduino-ide/ que decía que:

the SDA line may also be labeled as SDI and the SCL line as SCK.

y luego que se podían mapear a casi cualquier pin, supuse mal.

Alguna líneas interesantes del código, en estas se determina que chip es:

bool bme280p = dev.id == BME280_CHIP_ID;
ESP_LOGI(TAG, \
"BMP280: found %s\n", bme280p ? "BME280" : "BMP280");

Luego se manifiesta en los valores que se pueden completar:

if (bmp280_read_float( \
        &dev, \
          &temperature, \
          &pressure, \
          &humidity) != ESP_OK) {
ESP_LOGI(TAG, "Temp./press. reading failed\n");
} else {
ESP_LOGI(TAG, \
    "Press: %.2f Pa, Temp: %.2f C", pressure, temperature);

//if (bme280p) {
sprintf(send_buf, REQUEST_POST, temperature , humidity );
//} else {
// sprintf(send_buf, REQUEST_POST, temperature , 0);
//}
}

Lo dejé comantado pues la verdad es que me dá lo mismo mandar un cero hardcodeado que uno proveniente de la lectura, pero es incorrecto, debería no enviar el valor y/o agregar un campo con el tipo de sensor, para diferenciar el cero de cero humedad del cero de cero lectura.

Este sistema está todo hecho así, una reducción muy básica con múltiples oportunidades de completar y mejorar. Si te viene interesando, podés implementarlo siguiendo las instrucciones y luego: