En el panel de administracion se deberian poder dar de alta nuevos grd_id.

En los resultados se eliminan las columnas cero y escala.

Ordenarlos del mas nuevo al mas viejo

Che, recuerden que la aplicacion se corre en mediante passenger.
la mayoria de los links se refieren al root del dominio mientras que la app esta en pepe.net/dusttrak

eso me trae errores en el admin mas que nada.

saludos

Miren, esto es lo que trate de explicar en el otro post sobre como manejar los historicos:

Con el esquema de configuración que estamos usando, no hay memoria de los valores viejos. Si se cambia alguna configuración y alguien quiere ver datos previos al cambio, al menos el cálculo de concentración va a variar según la nueva configuración.. sospecho que podemos zafar del problema con paper_trail. Bah.. es un problema, o no importa que cambiemos el pasado?

who controls the past now, controls the future! ♬

Fijate los archivos que salen de la descarga, en la opcion TODOS te hace un volcado de la tabla de la db, y no de la tabla de resultados

en le admin falto el campo para determinar cual es el umbral

pasa el umbral a 0.070

Che, cuál es la consulta más frecuente que van a necesitar?

Por ejemplo: "10 veces al día me meto a ver los últimos 20 valores". No digo exactamente, pero la idea es minimizarles los clicks del día a día.

sacar todos los "Ej.: texto de prueba" de los campos del admin para agregar un nuevo aparato.

o cambiarlos por el que corresponda.

queda poco estetico

Bueno, después de darle todo el viernes al tema de preservar los valores de cero y escala históricamente, se me ocurre que podemos usar algo parecido al enfoque que ustedes armaron (lo de agregar las columnas zero y scale). Lo que sugiero es manejar la configuración como ahora, desde la aplicación, para actualizar los valores cero y escala, pero que cada vez que se registre un nuevo historical se calcule la concentración y se guarde ya calculada (con un trigger @fauno ?). Esto simplificaría y agilizaría las consultas, y el valor de la concentración es lo que nos interesa en el fondo, no la escala o el cero que haya habido configurado cuando se cargó el historical (de todas maneras esa información quedaría guardada en la tabla de parámetros que hice).

En resumen:

1. columna concentracion en la tabla historical
2. trigger que calcule la concentración con el value del nuevo registro y los cero y escala más nuevos de la tabla parametros para el grd_id del nuevo registro.
3. profit! Los backups y las consultas son directas

Los promedios se tienen que agrupar de la siguiente forma:

20 min

60 min

24 hor

• Cuando tratas de poner un valor para zero y/o escala te tira

404 Not Found
nginx/1.5.5

• La descarga de excel no hace nada, o sea no descarga
• EL promedio ayer funcionaba, aunque ahora me fije me tira internal server error, lo mismo con lo del umbral

tira error la descarga en xls.

Cosas que faltan

Panel de control:

• Cambiar $zero
• Cambiar $scale
• Cambiar el umbral
• Cambiar los rangos para los promedios cada 15/30/60 minutos.

Interfaz de usuario:

• En la aplicacion de filtro elegir cual grd_id procesar
• Como en el aqm, dividir los resultados en paginas
• IMPORTANTISIMO, poder descargar el resultado en una planilla de calculo, se que te va a molestar, pero tiene que ser en el formato privativo

Cosas que hay que cambiar

• 3 unidades despues de la coma
• Concentracion va "Concentracion mg/m3"

Estoy viendo que para hacer una consulta se traen de la base de datos los valores de configuracion un monton de veces...

Es porque la tabla de parametros se tiene que consultar por cada registro. Esto no escala, aguante SQL!

Relacionadas: #5 #13

Los promedios no esta coincidiendo con lo que hay en la db:

30 2013-08-30 13:30:00 -0300 4255 4030 3.2 -0.44 <--- eso no existe

el promedio que hay entre las 13.00 y 13.30 es 0.070

el equipo esta mandando datos cada minuto, pero tene en cuenta que pueden haber huecos, interrupciones en la medicion, o inclusive que haya datos en $value pero que esten en 0, ya que el dusttrak puede no estar midiendo nada y el exemys sigue mandando valores electricos que van a hacer muy pequeños o nulos por que no recibe nada del dusttrak

• En el modo promedios la forma de agrupar es

20 min
60 min
y 24 hs

• Se ordenan los datos del mas nuevo al mas viejo.
• En los resultados se eliminan las columnas cero y escala.

Cuando tratas de poner un valor para zero y/o escala te tira:

404 Not Found
nginx/1.5.5

nginx error.log

2013/09/11 14:40:20 [error] 16910#0: *3 open() "/home/siafa/http/ccys.siafa.com.ar/favicon.ico" failed (2: No such file or directory), client: 190.193.169.151, server: ccys.siafa.com.ar, request: "GET /favicon.ico HTTP/1.1", host: "ccys.siafa.com.ar"
2013/09/11 14:40:22 [error] 16910#0: *3 open() "/home/siafa/http/ccys.siafa.com.ar/admin" failed (2: No such file or directory), client: 190.193.169.151, server: ccys.siafa.com.ar, request: "POST /admin HTTP/1.1", host: "ccys.siafa.com.ar", referrer: "http://ccys.siafa.com.ar/dusttrak/admin"
2013/09/11 14:40:22 [error] 16910#0: *3 open() "/home/siafa/http/ccys.siafa.com.ar/favicon.ico" failed (2: No such file or directory), client: 190.193.169.151, server: ccys.siafa.com.ar, request: "GET /favicon.ico HTTP/1.1", host: "ccys.siafa.com.ar"

paralelamente levante la aplicacion mediante bundle exec padrino start -h 0.0.0.0 y modifque los parametros y no tuve incovenientes

http://pastie.org/8317607

Me quedo lo que planteo mpj y lo charle con el otro chabon de aca y llegamsos a lo siguiente:

El equipo no va a estar mucho tiempo, probablemente 3 semanas maximo y luego lo llevan a otro lado a laburar entre 1 y 2 semanas (informacion que no tenia, hasta hoy segun mi jefe era una estacion de monitoreo continuo sin limite de tiempo) o puede ser que el equipo se apague por un corte de luz, etc. Entonces lo que se me ocurrio es lo siguiente.

Si el equipo se detiene por alguna razon hay que volver a encenderlo, o en la medicion se nota que esta mandando alguna fruta hay que reiniciar el proceso, eso implica volver a calibrar el 0.
Ahi nos estaria afectando el pasado, posibles soluciones:

1- Segun el grd_id del equipo en cuestion, descargar en un archivo todo lo que haya en la tabla (haciendo cenversion), borrar todos los datos cargados y se vuelve a empezar.

2- Dentro de la misma DB, segun el grd_id, generar una nueva tabla con un nombre a eleccion del admin donde se almacene un historico (con valores convertidos), borrar todos los datos cargados y se vuelve a empezar. De esta forma el usuario podria tener varios historicos por ejemplo:

Esquina juncal y chamizo 01/03/13 al 10/03/13
obs: se detuvo el equipo, se reinicio medicion y calibracion de cero

Esquina juncal y chamizo 10/03/13 al 25/03/13
obs: Se finaliza sesion de 25 dias.

y se mantiene la forma de ver los resultados en los 3 modos posibles en los historicos.

Editado

3 - Tener perfiles, cargar un perfil con el grd_id al cual se le asocia un nombre unico, cuando entras a la pagina elegis cual perfil queres, y la operatoria de historico es como opcion 1 o 2, claramente un mismo grd_id puede tener varios perfiles, por eso es importante que cuando un perfil deje de ser usado el usuario mande todo lo que haya a historico y se borre para no mesclar datos tomados por otro perfil.
no se si se entiende.

Diganme que opinan.

PD: me inclino por la 2da opcion

Si $value >= $zero estamos bien.

Si $value < $zero estamos en un problema, estos pueden ser:

• El dusttrak dejo de medir, pero el exemys sigue mandando datos.
• El $zero se corrio (alguna falla electrica)

entonces en esos casos hay que advertir que algo no esta bien.

will_paginate intenta

SELECT COUNT(*) FROM `historical` HAVING concentracion > 0.4

que no es sql valido :c