*Version 1.51* 29/0/2026

- En esta version hemos incluido la sincronizacion de movimientos cerrados no sincronizados en el mommento de producirse. Estos movimientos quedan registrados
en la BD y marcados como no sincronizados, es decir no ha sido subidos al servidor central o mejor dicho este supervisor
no ha recibido respuesta "OK" luego de haber enviado el movimiento. Dado que para componer la trama json del movimiento se necesita leer todas las imagenes asociadas al movimiento, las cuales pueden estar presentes o no (depende de la configuracion al momento de producir el movimiento) Hemos realizado un nuevo nodo
que prepara todos los nombres de las imagenes que se deben leer y otro nodo que confirma que las imagenes necesarias para este movimiento han sido ya leidas y se encuentran almacenadas en men memoria. En ese momentopodemos armar la trama json con todos sus elementos y entonces enviarla nuevamente por http via un API. Una vez concluido el envio, procedemos al realizar la misma operacion con el proximo movimiento a sincronizar. Cada vez que enviamos una trama esperamos respuesta del servidor y en caso afirmativo se procede a maracar el movimiento como ya sincronizado.

*Version 1.5* 25/0/2026
- En esta version se agrega la gestion de la imagen de contexto tanto durante el movimiento inicial como durante el movimiento final
Para ello se han introducido modificaciones en el nodo "Comandos via Websockets" a nivel del case de movimiento inicial. Luego tambien
se han introducido cambios en el nodo "movimiento cerrado" para incluir el nombre y las imagenes de contexto en los envios al Servidor.
Adicionalmente se han hecho cambios en las tablas de "movimientos" y "movimientos cerrados" para incluir los campos de los nombres de dichas imagenes
En el RPi se ha hecho una nueva carpeta (/home/trypton/.nodered/contexto) para incluir las imagenes de contexto que deben permanecer almacenadas.
*Version 1.5*  de Gestion de semaforos Esta version tiene la particularidad de que dispone de tres modos de gestion de la prioridad
1.TOUR. Supongamos que tenemos los tres lazos ocupados. Este modo se refiere a que si en esa situacion el sistema
le va a dar paso al Lazo mas prioritario las veces que de forma continua sigan apareciendo vehiculos en dicho lazo
si no ha llegado al maximo numero de vehiculo continuos permitidos. En caso de que le queden aun vehiculos en la cuenta pero ya no tiene mas vehiculos presentes entonces se le da paso al siguiente lazo menos prioritario el numero maximo de vehiculos
que tenga asignados y si sucede lo mismo es decir no llegan mas vehiculo entonces pasamos al siguiente menos prioritario
y cuando no haya mas vehiculos en ese lazo en ese momento inicializamos o recargamos todos los contadores de
vehiculos permitidos de forma continua. En el caso descrito si estamos dando paso al segundo menos prioritario y ahora llega
un vehiculo al mas prioritario entonces tiene que esperar hasta que el sistema termine la vuelta completa
El nombre TOUR tiene que ver con el sistema que se hace de dar una vuelta completa
antes de actualizar el contador de vehiculos.

uibuilder/control_manual/tsconfig.json

@@ -0,0 +1,14 @@
+{
+  "compilerOptions": {
+    "allowJs": true,
+    "checkJs": true,
+    "noEmit": true,
+    "strict": true,
+    "target": "ES2020",
+    "module": "ESNext",
+    "moduleResolution": "Node",
+    "baseUrl": "./src",
+    "typeRoots": ["./types"]
+  },
+  "include": ["types", "src/**/*.js"]
+}