- Hemos colocado un codigo de dos lineas para eliminar el boton del menu activo "COMPLETAR INFO" en caso que se presente una tarjeta o un codigo QR.
Esto lo hicimos en el nodo "Analisis del modo de Operacion" en la linea 70 donde chequeamos si estamos en movimiento inicial.
- Corregido un "error" que no permitia cerrar el movimiento inicial cuando se pasaba una tarjeta si teniamos el menu activo y la firma obligatoria.
Se agrego una condicion ("ID_verificado") en la condicion global para llamar a la firma. Esto es en el nodo "Analisis de Operacion" en las primeras lineas
if (flow.get("firma_obligatoria") && !flow.get("firma_flag") && !flow.get("firma_ok_flag") && !flow.get("supervisor") && (!flow.get("menu_activo") || (flow.get("menu_activo") && (flow.get("menu_seleccionado_flag") || ID_verificado))))
Con esto permite continuar con la firma en caso que tengamos menu_activo y firma obligatoria y entremos con tarjeta o con codigo QR.
**Version 1.3.1**
- Hemos colocado una opcion mas en el menu de configuración en "Pruebas del Sistema" -> "Probar Sensor". Esto permite visualizar la salida del valor
de la distancia que esta midiendo el sensor cada segundo. Para que el medidor no este continuamente inundando el configurador con el dato de distancia
hemos colocado un switch el cual solo deja pasar ese dato cuando se activa el menu, lo inhabilita cuando se sale del menu.
- Hemos puesto el flag flow.set("RFID_ok_flag", false) cuando leemos un QR y flow.set("QR_ok_flag", false) cuando leemos una tarjeta, esto permite
que se utilice un QR aunque primero hayamos metido una tarjeta invalida y viceversa. Se hizo en el nodo "envio QR/RFID".
y por lo tanto no deberiamos guardar en contexto flow o global ya que esos contextos estan previstos para objetos serializables (estados, valores, arrays, json...)
transporta. Esta notificacion se muestra una vez que hayan cumplido todos los requisitos de entrada y antes de poner el semaforo en verde.
Para esta funcionalidad hemos introducido un codigo en el nodo "Analisis del modo de Operacion" (lineas 76 a 112) y en el nodo "check json content"
en las lineas 44 a 50 bajo el titulo "RESPUESTA DE LA REVISION DE LA UBICACION INTERNA EN BD". Si recibimos respuesta positiva de la BD es decir que si
tiene ubicacion interna el residuo presentado entonces sacamos notificacion con lo que dice el campo de descripcion encontrado en la tabla, en caso contrario
el mensaje que aparece en pantalla es diciendo que no hay ubicacion para ese residuo.
hasta que el vehiculo abandone la bascula. Se agrego un nodo para mantener el aviso de salir de la bascula en caso de PMA, si el usuario pulsa OK.
Corregido en el nodo "check JSON content" la recepcion de la matricula asociada a una tarjeta. Hemos activado los flags correspondientes para que el nodo
"matricula 2" pueda hacer el chequeo de la matricula respecto a si esta o no en transito.
En el nodo "Analisis del modo de operacion" hemos puesto una condicion para no mostrar el boton de salida cuando el usuario utiliza una tarjerta valida.
enviando matricula si se recibe sin que haya vehiculo en bascula. Esto no evita que se reciban matriculas automaticas antes de entrar el vehiculo en la bascula.
Estas ultimas fotos se conservan en memoria hasta que el vehiculo entre en la bascula y pueden ser utilizadas como foto principal en caso de fallo en la solicitud.
Hemos eliminado en la linea 156 del nodo matricula2 la condicion de "qr_revisado" para eximirlo de disponer de matricula debido a que ahora el codigo qr puede estar asociado a varias matriculas.
y por lo tanto sera necesario disponer de una matricula a pesar de tener el codigo de autorizacio (solo indica residuo).
Hemos inicializado la matricula [flow.set("matricula", "Sin Matricula")] tambien en el momento en que el peso supera a pmin por primera vez (es decir entrando en la bascula).
Se agrego en la salida de la edicion de matricula [flow.set("matriculacheck_solicitada", false)] para permitir que se busque nuevamente la matricula en BD.
dos campos es para disponer de la identificaciob utilizada en salida en caso de hacerlo. Para ello en el nodo "Analisis del modo de Operacion" se evalua
si estamos en el movimiento inicial o final para ver cual campo es el que tenemos que rellenar. Est se hace el la linea nº 100
Se ha moviso la inicializacion flow.set("distance_flag_SET", false) al momento donde la bascula pasa de peso < pmin por primera vez.
Antes se inicializaba cada vez que el peso que llegaba era menor que pmin. Esto podia ocasionar un error ya que el nodo detector perdia el control
de este flag al ser inicializado cada vez que el peso < pmin.
En caso de que la matricula leida sea diferente a la matricula obtenida en la BD se toma la matricula leida de la BD
version 1.0. Este codigo de Bascula Autonoma sale a partir del Totem Autonomo. Todo el codigo relativo a la gestion de BAse de Datos se traslada al RPI Supervisor
En este RPi solo queda lo relativo a la gestion de sensores, camaras, lectores de Identioficacion, semaforo, barrera y la pantalla para que el usuario
pueda interactuar con el sistema como por ejemplo hacer seleccion del residuo a traves de un menu de seleccion.
En esta version se ha introducido el termino PMA(Peso Maximo Autorizado. Este es un valor que el Totem recibe cuando el Supervisor le envia la autorizacion
de la matricula junto con la tara- El Totem revisa el peso estable del vehiculo con el PMA recibidoy en caso de ser superior se envia un aviso en la pantalla
indicandole al conductor que debe retroceder ya que supera el peso admitido.
Otra función que contiene esta version es el chequeo de la Tara. Si el valor recibido de la Tara es superior a cero entonces el movimiento inicial recinbido por el supervisor
es enviado como movimiento cerrado al Servidor.Realmente para el Totem es transparente. La gestion de la Tara en efecto la hace el Supervisor una vez que recibe
el movimiento inicial que envia el Totem.
yamaray