¿Cuál es el formato de los datos que soporta el calculador?, ¿se pueden soportar otros formatos?

[brolin]

El formato que soporta actualmente es de la siguiente forma, @danielbernalb nos puede explicar ¿por qué usar este formato? y ¿qué tan genérico es?

16:56:54.009 -> Start SenseAir S8 lecture 16:56:54.998 -> BEEP level: 1300 16:56:57.556 -> Deactivate Automatic Self-Calibration SenseAir 16:56:57.556 -> done 16:56:59.575 -> Read SenseAir S8: OK DATA 16:56:59.575 -> Air sensor detected AirSense S8 Modbus 16:57:02.091 -> SenseAir read OK 16:57:06.076 -> Preheat: 30 16:57:09.083 -> 28 16:57:11.095 -> 26 16:57:13.065 -> 24 16:57:15.069 -> 22 16:57:17.085 -> 20 16:57:19.089 -> 18 16:57:21.064 -> 16 16:57:23.068 -> 14 16:57:25.080 -> 12 16:57:27.063 -> 10 16:57:29.071 -> 8 16:57:31.069 -> 6 16:57:33.078 -> 4 16:57:35.081 -> 2 16:57:37.091 -> 0 16:57:38.080 -> Start measurements 16:57:43.086 -> Read SenseAir S8: OK DATA 16:57:43.086 -> CO2(ppm): 772 16:57:47.089 -> Read SenseAir S8: OK DATA 16:57:47.089 -> CO2(ppm): 771

Desde la línea 73 hasta la línea 84 es el procesamiento del archivo.

Para soportar un formato diferente se puede cambiar por ejemplo, de la forma 2021-04-07 05:34:00, 300.00 se puede cambiar esa sección del código devolviendo con una columna tiempo en segundos y una columna CO2 [ppm]

para leer este tipo datos se puede reemplazar esa sección con algo como: df <- read_csv(input$file1$datapath, col_names = F) colnames(df) <- c("tiempo","CO2 [ppm]") df

para el cálculo es necesario asegurarse que la unidad de diferencias de tiempo transcurrido entre el comienzo del decaimiento del CO2 y el final del decaimiento, sean SEGUNDOS

@son0p ¿Cómo hacer para soportar mútliples formatos de datos?, podríamos crear un branch para experimentar esa funcionalidad

[son0p]

Supongo que lo que @danielbernalb muestra son datos exportados por el sensor a un archivo. Para construir una trama de datos de transmisión serían innecesarios el encabezado y las líneas intermedias de ReadSenseAir S8: OK DATA.

Para soportar múltiples formatos se me ocurren dos caminos, perfilar diferentes sensores (como lo hace canair.io con los de pm25) o que el usuario indique la ubicación de los campos en su caso personal, algo parecido a lo que hace https://app.rawgraphs.io/

[danielbernalb]

Les cuento porqué ese formato, que también puedo cambiar en cualquier momento:

Con el cable OTG se puede programar el Arduino y luego accediendo por Monitor serial se puede hacer el debug serial de la info y saber si el sensor está bien y que errores puede haber. Luego se puede guardar el archivo del serial para que sea procesado luego con la página que crearon. Por eso coloco tanta info por el Serial. Podría quitarla para mayor facilidad, la hora publicada sale de activar la publicación de la hora en el Monitor Serial, se puede desde el celular o computador. El formato no tiene nada de genérico, me lo inventé yo como parte del código que fue saliendo. Lo interesante del ejercicio es que por ejemplo también se podría con los CanAirIO que tienen una trama como más genérica, aunque ahora por defecto no envía esa info por el serial. Si uds creen que lo mejor es quitar toda la info adicional y sólo dejar un modo limpio de este estilo puedo hacerlo activando como una opción sin debug:

16:00:00.000 619 16:00:02.000 619 16:00:04.000 620 16:00:06.000 621 16:00:08.000 621 16:00:10.000 621 16:00:12.000 623 16:00:14.000 626

La primera columna es la hora que coloca el compu y celular en el monitor serial, ese formato no se puede cambiar y la segunda el valor de CO2 y listo.

[brolin]

Cómo sería la trama de canairio? Y esta que se está usando en este momento que variaciones podría tener, por ejemplo cuando no sale OK DATA, si ocurre un error qué saldría?

Para tener en cuenta a la hora de parsear el archivo.

[danielbernalb]

El archivo CanAirIO tiene un formato .json con la app movil y un .csv en la pagina web. Es un tema más complejo que con LibreCO2 y todavía no está planeado porque estas tramas van a cambiar pronto con la seguridad que se está implementado en los datos. Cuando se genera un error en el LibreCO2 el dato cambia a: 11:45:45.621 -> Read SCD30: FAIL CO2 old: 614 11:45:45.621 -> FAIL CRC_CO2actual: 602 11:45:45.621 -> FAIL CRC CO2 Cuando aparece la trama CO2(ppm) es porque el dato es válido, ejemplo: CO2(ppm): 614

[brolin]

Hice mejoras al mecanisco para parsear los archivos en el siguiente commit https://github.com/daquina-io/calculo-tasa-ventilacion/commit/df886f03740916a61402f71afdd52f5c003c7e7a. En teoría debe interpretar correctamente archivos que contengan en la primera columna un timestamp en la forma hh:mm:ss.sss y como segunda columna interpreta donde aparezcan valores de la forma CO2(ppm): 614. Las demás líneas que no contengan valores de CO2 son ignoradas.