JT808 absorbe YB-2020 / GDRTA-002: se elimina el protocolo separado y su puerto; las alarmas AI (ADAS, DSM, TPMS y BSD) se leen de los TLV 0x64-0x67 de 0x0200, el conteo de pasajeros se lee de 0x1005 y los canales AI usan 100/101/103. El filtro y la administracion quedan con N9M, JT808 y TTX; los registros antiguos yb2020 se normalizan a jt808.

Audio JT1078: se capturan los paquetes de audio G.711 A/U y AAC, se envian al visor en vivo y al historial, y el MP4 de descarga se mezcla con audio AAC. Validado en 202609110001: el vivo y el historial entregan tramas de audio y el MP4 tiene pista AAC 8 kHz.

Descarga JT1078: el MP4 del historial se genera a 25 fps (antes ffmpeg heredaba una cadencia incorrecta y el archivo duraba 2 s); se invalida el MP4 viejo con marca .v2. Validado en 202609110001: MP4 de 6,36 MB, 40 s, 1280x720 H.264.

Historial JT1078: corregido el cuerpo de 0x9201 segun JT/T 1078 (tipo audio/video, stream, almacenamiento, modo, multiplicador, inicio y fin). El equipo ya abre el canal de historial y el video se reproduce claro; validado en 202609110001 canal 1, 1280x720 H.264.

JT808/JT1078: no se vuelve a pedir 0x9101 si el canal ya esta transmitiendo (evita cortar los otros visores al abrir otro canal). Historial: los fragmentos 0x1205 se agrupan por equipo aunque el equipo cambie el serial en cada fragmento; la lista de archivos ya aparece.

Video en vivo: la rejilla de 5 canales queda 3 arriba y 2 abajo centrados; la de 6 canales queda 3 y 3. Los demas tamanos no cambian.

Administracion: nueva seccion Sistema con estado de version, sistema operativo, Java, tiempo encendido y un boton para reiniciar solo la plataforma (systemd en Linux o tarea programada en Windows), sin reiniciar el servidor ni el sistema operativo.

Instalador Linux: detecta la IP publica, genera claves y secreto ZLM, instala Java/nginx/certbot/ffmpeg, levanta ZLMediaKit con Docker, crea sitio.properties, systemd, proxy /zlm y firewall. Todo en un solo comando; si ZLM no arranca deja WebCodecs directo.

Video: primera fase ZLMediaKit. Nuevo descriptor /api/media/play con orden WebRTC/FLV/HLS/WebCodecs, puente JT1078->RTMP y paquete Linux/Docker de ZLM. La seleccion automatica en el reproductor web es la siguiente fase.

Administracion de unidades: boton Borrar en la lista para eliminar el registro de la unidad, sus grupos, permisos y etiquetas, con confirmacion y cierre de la sesion activa.

JT808: se aceptan cabeceras 2013 (telefono BCD[6]) y 2019 (BCD[10]) y se responde en la misma version; la unidad 202609110001 ya registra y envia posiciones. JT1078: identificador de 6 o 10 bytes y peticion de video solo (1), como Traccar. Si una unidad tiene TTX y JT808 a la vez, el panel prioriza la sesion JT808.

Servidores TTX: el reinicio automatico aplica al proveedor seleccionado (Tongli o Richmor) y solo se envia si la casilla esta marcada al aplicar el cambio.

Servidores TTX: casilla activada por defecto para reiniciar tras aplicar el cambio en Richmor; el reinicio se envia al recibir la respuesta C517 (tambien cuando viene dentro de V100) y solo despues de que el equipo responde.

Servidores TTX: el selector queda con Tongli seleccionado por defecto y Richmor como segunda opcion.

Servidores TTX: el selector muestra solo los proveedores N9M y Richmore, sin siglas ni nombres de comandos.

Servidores TTX: selector de proveedor (Tongli por defecto, Richmord) y envio del dialecto elegido sin probar el otro; la confirmacion se muestra solo con la respuesta del equipo.

Servidor TTX: deteccion automatica del dialecto. Tongli sigue con NETWORK_SET y Richmord usa Param_CenterNetWork; se espera la confirmacion del equipo antes de mostrar exito.

Historial TTX: deteccion automatica del canal por el sufijo -N.mp4 de Richmord y respaldo al byte base 0 de Tongli; se espera la respuesta completa del C701 antes de mostrar la lista.

Acciones de unidad: 'Ver en Google' y 'Ver Street View' en todos los protocolos, usando la ultima posicion GPS de la unidad.

Historial: la descarga personalizada cierra el video y muestra un panel de descarga animado con icono, titulo visible, detalle y progreso mientras se genera el MP4.

Historial: boton independiente 'Descargar personalizada' que aparece al cerrar Pin Inicio y Pin Fin; la descarga normal del tramo queda aparte.

Historial: Pin Inicio y Pin Fin sobre la reproduccion, descarga del rango con margen configurable en Administracion > Descarga (5 s por defecto) y boton de descarga que se activa al cerrar el rango.

Se restaura el selector de protocolo en el formulario de unidad; era lo que impedia guardar la edicion de icono y color.

Iconos de camion, autobus y moto reemplazados por formas mas reconocibles en el mapa y en la vista previa de administracion.

Unidad: color con selector nativo (sin checks), vista previa SVG del icono, edicion corregida y grupos por modal de casillas.

Administracion de unidades: icono y color despues de Salidas, paleta en una sola linea con mas colores, y modal de grupos con casillas para elegir uno o varios sin escribir IDs. Se corrige la edicion de la unidad.

Se retira el aro de estado del icono: el estado queda solo en la leyenda y en el rumbo; el icono conserva el tipo y color personalizados.

Iconos personalizados con aro de estado: el color del icono es el elegido por unidad y el aro mantiene verde/amarillo/azul/rojo/gris segun movimiento, ACC, alerta, GPS u offline.

Unidades: selector de icono (auto, camion, van, moto, bus, taxi, pickup, remolque, bicicleta, barco, persona, marcador) y paleta de color por unidad; se guardan en H2 y se usan en lista y mapa. Por defecto auto y azul.

Seguimiento de unidad: boton Seguir entre rumbo y camara en la lista y despues de Centrar en el popup; el mapa centra la unidad en cada posicion. Se desactiva con el mismo boton o al mover el mapa.

Historial: iconos nativos de fecha y hora en blanco (color-scheme oscuro, sin invertir el icono).

Historial: los iconos nativos de los campos de fecha y hora se muestran en blanco sobre el fondo oscuro.

Administracion: la tabla de unidades muestra Unidad y Alias en columnas separadas y agrega la fecha de alta.

Tabla de unidades de administracion ordenada por fecha de alta; lista de transmision ordenada ASC por alias/IMEI. C08C: EXECU FAILED se muestra como 'sin grabaciones', no como error.

Unidades sin grabaciones: EXECU FAILED ya no se muestra como error; el calendario y la lista quedan vacios con el motivo. La tabla de unidades guardadas se ordena ASC por alias/placa/IMEI.

Video del historial: se envia la respuesta en cuanto el equipo abre el enlace (sin esperar la primera imagen) y ffmpeg arranca sin analizar 5 s; baja el tiempo hasta que empieza a verse el video. Se mantiene una sola camara y el cierre limpio al terminar.

Historial nativo: cada consulta usa un SERIAL distinto y reintenta si el equipo responde OPERATE SO MUCH; el calendario y la lista de archivos ya se piden seguidos sin abrir el tunel.

Historial N9M como Ceiba: dias y archivos por STORM/GETCALENDAR y STORM/QUERYFILELIST en el canal de control, sin abrir el tunel ni gastar streams; ya no aparece 'tabla llena' al consultar el historial.

Historial: al detener, el boton rojo se convierte en un boton verde 'Reanudar' con icono de play y el centro del visor muestra un play verde grande para continuar.

Historial: el cartel de detenido conserva el tamano del video (antes el visor se encogia al ocultar el lienzo).

Historial: pausa/detener con iconos y velocidad compacta sobre el video; la linea de tiempo va dentro del visor y al detener aparece un fondo negro con el icono de stop.

Historial: al saltar en la linea de tiempo el video empieza en la hora elegida y la linea mantiene el tramo completo, para poder adelantar y retroceder varias veces.

Historial: result -1/-2 del equipo ya no es un error. Se muestra 'sin grabaciones' y, si no hay disco instalado (0 GB), se explica en el calendario y en la lista.

Historial: clic o arrastre en la linea de tiempo salta a ese punto; burbuja con la hora exacta al pasar o seleccionar.

Popup: enlace clic/actualizar queda inmediatamente a la derecha de 'Direccion / Calle' y la direccion se muestra debajo.

Popup: Direccion / Calle pasa al inicio y ocupa las dos columnas; el enlace clic/actualizar va en otra linea y con tipografia mas pequena.

Popup: la direccion se guarda por unidad y el enlace 'actualizar' vuelve a consultar la API de geocodificacion con la posicion actual.

Popup: Satelites al final; nueva fila Direccion / Calle con enlace 'clic' que consulta Nominatim/OpenStreetMap bajo demanda usando latitud y longitud.

Popup TTX: se muestra el numero de satelites reportado por el estado A00xx; N9M no muestra esa fila.

Popup de unidad: se quita Unidad y Fecha/hora; orden Placa, velocidad, latitud, longitud, altitud, rumbo, ultima transmision GPS y origen.

Administracion de unidades: filtro rapido por IMEI/unidad/placa/notas, protocolo y grupo, con boton para limpiar filtros.

Lista: la camara cambia a fondo ambar intenso al abrir el video y vuelve a su estado normal al cerrarlo.

Lista: camara blanca sobre ambar y estado activo persistente al abrir el video; conexiones como toast, sin entrar en alertas.

Lista: camara con icono blanco sobre fondo ambar y cambio de color al abrir el video; conexiones/desconexiones salen como toast verde/rojo y ya no se mezclan con las alertas.

Lista de unidades: el icono de rumbo toma el color del estado (verde, azul, amarillo, rojo, rosa o gris) y la camara usa un color ambar distinto.

Lista de unidades: icono de rumbo que gira con la unidad y boton de camara para abrir el video en vivo; se quita el boton Salir del panel de administracion.

Interfaz: todos los botones de cerrar con X en modales y ventanas quedan en rojo, con mejor padding, tamano y area de pulsacion.

Login: luna reubicada para que se vea completa dentro del encuadre, con su orbita y el campo de estrellas.

Login: luna mas visible en orbita y campo de estrellas mas denso; fondo espacial con menor reticula y mejor profundidad.

Login: fondo espacial mas profundo, campo de estrellas por capas, luna con textura y orbita, deriva suave de camara y atmosfera mas realista.

Popup: el campo Origen muestra el protocolo humano (N9M, TTX, JT808, YB-2020) en vez del origen interno de la posicion (telemetria/json).

Lista de unidades: formato exacto de dos lineas: 'alias - velocidad km/h' y debajo 'IMEI / UT segundos'; sin kilometraje visible ni la palabra hace.

La lista y el popup refrescan alias, placa y grupos al volver de administracion; formato final de lista con alias, kilometraje, IMEI y UT.

Lista: alias, kilometraje, IMEI y ultima transmision; alias de la base tiene prioridad sobre el nombre del protocolo. Popup: placa visible, alias primero, satelites si existen; se quitan puerto e IP. IMEI en la cabecera junto al protocolo.

Mensajes de error del panel usan IMEI en lugar de DSNO; se conserva el campo interno dsno por compatibilidad.

Identificador unico como IMEI en administracion y panel; globo terrestre con textura, satelites con paneles y enlaces de datos animados en el login; iconos en Administracion, Alertas, Salir, Filtros y Terminal; filtro del Terminal sin autocompletar admin.

Interfaz: iconos en Administracion, Alertas, Salir y Filtros; Terminal junto a Filtros; Centrar mapa como icono verde; filtro del Terminal sin autocompletar 'admin'; animacion 3D satelital en el login con Three.js.

Airview: se unifica el identificador de unidad como IMEI en administracion, panel, estructura y webhook (se conserva dsno por compatibilidad); boton Volver al panel mejorado; Terminal junto a Filtros con icono; Centrar mapa como icono verde.

Lista de unidades: formato de dos lineas: 'alias - velocidad km/h' y 'identificador / UT segundos'.

Lista de unidades: kilometraje con dos decimales para que los valores pequenos no se redondeen a 0.0.

Lista de unidades: IMEI/identificador, velocidad, kilometraje y segundos desde la ultima transmision; se quita la palabra 'hace'.

Lista de unidades: se quitan latitud/longitud y el puerto/protocolo; queda el nombre, DSNO, velocidad y tiempo desde la ultima transmision.

Panel: filtros unificados de protocolo y grupo en un solo modal; lista agrupada por grupos, unidades sin grupo/directas y todas las unidades visibles, incluidas las desconectadas en gris. El admin ve todos los grupos; cada usuario solo los suyos. Una unidad en varios grupos se lista en cada uno.

Panel: el filtro de protocolos sale de la lista de unidades y pasa a un boton que abre un modal compacto; libera espacio y mantiene la seleccion multiple con aplicacion inmediata.

Panel: al cerrar el modal de alertas o al recargar la pagina se limpian tambien las alertas del servidor, no solo la vista. La hora de ultima transmision sigue actualizandose por SSE y por respaldo de sondeo.

Panel: la hora de ultima transmision se actualiza sin F5 aunque el SSE se quede callado (respaldo por sondeo y reconexion); las alertas no se borran al abrir el modal, muestran contador rojo, tabla oscura y se dan por vistas al cerrar o al recargar.

Unidades: autorizacion en tres estados (pendiente/activo/inactivo), autoregistro desactivable, rechazo de conexiones pendientes/inactivas, webhook por unidad y visibilidad por usuario con asignaciones suspendidas en gris. Migracion de las unidades existentes a activo.

Airview: base local H2 (usuarios, grupos, unidades, sensores, webhooks y auditoria), login por usuario/rol, permisos por grupo/unidad, panel de administracion, webhook global de telemetria y eventos con firma HMAC, interruptor maestro, limpieza de auditoria por fechas con peso visible. Paquete Linux con start.sh/build.sh y H2 en lib/.

Mapa: colores CMSV6 verificados (verde movimiento, azul detenido ACC, amarillo parqueado, rojo alerta, rosa sin GPS, gris offline)

Mapa: colores por estado (azul movimiento, amarillo parqueado, rojo alerta/offline, rosa sin GPS)

Popup: rumbo con flecha y punto cardinal (Norte, Noreste, etc.)

TTX IO: avisar tambien la primera lectura activa del sensor

Panico/sensores N9M con nombre y sensores TTX IO1..IO8 en alertas

TTX: publicar como alerta cualquier trama V2xx no reconocida

Alertas N9M: nombre para Video Loss/HDD y campos completos de la alarma

Alertas visuales de conexion/desconexion y ACC en el panel; sin persistencia

TTX: satelites desde el estado A00xx del propio reporte; se elimina la dependencia de CMSV6

TTX: satelites de CMSV6 (solo lectura) en el popup; N9M no muestra la fila

TERMINAL: la telemetria N9M y las posiciones JT808 se muestran decodificadas y legibles (GPS, velocidad, rumbo, altitud, hora y fix) en vez de solo hexadecimal. El hexadecimal queda como dato secundario en el titulo de cada fila.

TERMINAL DE TRAMAS: nuevo boton Terminal en el panel, visible solo con sesion iniciada. Muestra en vivo las tramas crudas de N9M, JT808/JT1078 y TTX (RX y TX) con hora, protocolo, ID, tipo, tamano, texto y hexadecimal. Filtro por ID/email/placa/IP o cualquier contenido de la trama, selector de protocolo y direccion, pausa, limpieza y auto-scroll. El buffer circular guarda 4000 eventos (2 KB por trama) y se consulta con token por /api/terminal.

LOGIN: fondo grafico con reticula, brillo azul y onda de datos; tarjeta mas visible y moderna. Reinicio del servidor para que todas las unidades se reconecten con la nueva version.

HISTORIAL N9M: la reproduccion se sanea con ffmpeg en el servidor (igual que TTX). Si el equipo manda un cuadro malo, ffmpeg lo corrige y el navegador ya no se cae con �Decoding error� ni pide �Nueva peticion� cada 20 s.

HISTORIAL TTX: la lista muestra una fila por archivo completo (como CMSV6), con su inicio y fin reales, en vez de trozos de 5 min que luego reproducan desde el inicio del archivo. El C703 pide el tamano completo del archivo y el campo de canal del archivo. Esto elimina la confusion de hora/archivo y apunta a la grabacion real que se selecciona.

LOGIN: fondo grafico SVG con brillo azul, reticula y puntos; tarjeta con vidrio esmerilado, borde luminoso, campos y boton de entrada de mayor contraste. HISTORIAL TTX: se copia el campo de canal del C703 que usa CMSV6 (tercer campo, base 0; canal 4 = 3); antes iba en 0 y el equipo entregaba siempre el canal 1. La version sube para confirmar que el panel desplegado es el nuevo.

HISTORIAL TTX: se procesa el prefijo inicial del .ifv igual que TtxIfv antes de publicar los cuadros. Antes se perdian los bytes sueltos del primer cuadro y la imagen salia partida/pixelada (mitad inferior en verde o blanco). El historial se transcodifica a H.264 con mejor calidad (CRF 21). DESCARGAS TTX: solo la descarga publica en su hub; antes una reproduccion podia entregar su archivo parcial y el boton Descargar bajaba un trozo o nada. La descarga espera hasta 5 min para tramos grandes.

HISTORIAL TTX PROGRESIVO: el C703 se decodifica conforme llega, con el mismo visor WebCodecs y la linea de tiempo del historial N9M; se acaba la espera a convertir todo el archivo a MP4. HEVC se convierte a H.264 al vuelo para navegadores sin HEVC. CANALES TTX: se corrige el campo de canal del C701 (viene en base 0) y el canal solicitado se pasa al C703; antes todos los tramos salian como canal 1. VIVO TTX/N9M: doble clic aisla una camara con el tamano de la vista de un canal y doble clic restaura la rejilla.

MODAL DE VIDEO: 15% mas estrecho y ajustado al ancho real de la rejilla (sin franjas laterales); tiles 16:9 con la misma altura y sin scroll para 1-4 camaras. TTX: el barrido C508 mantiene un minimo de 4 canales para arrancar el encoder. SNAPSHOT TTX: se elimina el fallback al lienzo oculto 300x150 (imagen negra); se serializa por unidad, se separa por canal y si el C510 no responde se usa el ultimo cuadro del visor de ESE canal, avisando en el mensaje.

VISTA MULTIPLE: botones Ver todas y Detener todas; controles INDEPENDIENTES por camara (foto, audio, parar/reanudar y pantalla completa; fullscreen a la derecha y stop justo antes). Bajar el numero de camaras solo oculta tiles, sin recargar peticiones; subirlo crea solo las nuevas. Los tiles conservan 16:9 y la misma altura; la ventana usa scroll y la fila de controles queda fija. El stop de una camara cierra solo su canal; en TTX el stop por canal manda su C508 stop y al reanudar un C508 individual, sin barrido x4.

VISTA MULTIPLE: 1-8 camaras a la vez en N9M y TTX (4 por defecto), con una rejilla en la ventana de video mas ancha; cada camara tiene su decodificador/ffmpeg y su stop. N9M admite varios EnVivo por unidad y serializa un REQUESTALIVEVIDEO por equipo. TTX cierra el modal y manda el C508 stop de inmediato (endpoint /api/ttx/stop), con respaldo automatico de 3 s. La documentacion deja preparado el conteo dinamico de camaras por equipo desde base de datos.

TTX vivo H.265: si el navegador no soporta HEVC (18270719177), el servidor convierte el video a MJPEG 960x540 y el panel lo muestra sin WebCodecs; historial TTX .ifv/WKP convertido a MP4 H.264 720p

TTX vivo: el ensamblador de paquetes WKP sube de 8 KB a 128 KB; las unidades con ID largo (18270719177/18270719325) mandan cuadros clave de 9-14 KB que se descartaban y el visor nunca recibia IDR

Foto TTX: quita las cabeceras WKP de 16 B que el equipo inserta cada 4096 B del JPEG; antes el visor solo decodificaba la franja superior y el resto salia verde

Foto TTX propia: C510 + V107/JPEG en 11007; API unica /api/ttx/snapshot; vivo independiente en 2163

Se retira el snapshot experimental (el equipo no entrega el principal por 11007); vivo estable en sub, snapshot del lienzo e historial principal

TTX vivo estable en sub H.264; snapshot desde lienzo; historial principal 1920x1080; puertos en el select y ley unica

TTX: vivo y snapshot en stream principal HEVC 1920x1080; limpia cache del sub H.264; puertos en el select y ley unica

TTX snapshot desde lienzo a resolucion nativa; panel: puertos en el select de protocolos, ley unica y estado del media oculto

TTX vivo: espera el cuadro clave sin cerrar la conexion (el cierre reiniciaba el GOP y nunca llegaba)

TTX vivo: no cerrar los canales del barrido mientras haya un visor (su stop congelaba el video)

TTX vivo: diagnostico de publicacion/entrega de cuadro clave

TTX vivo: pide los 4 C508 de golpe como CMSV6 para que el equipo arranque el encoder y mande el cuadro clave

TTX vivo: 8 s entre stop y nueva peticion (como CMSV6) para que el equipo entregue el cuadro clave

TTX vivo: C508 de stop al cerrar el visor (como CMSV6), para que el equipo libere el stream y el siguiente pida cuadro clave

TTX vivo: log de NAL del primer 0x11 (diagnostico)

TTX vivo: diagnostico de NAL del primer paquete 0x11

TTX vivo: identificador de stream nuevo en cada C508 (con uno fijo el equipo solo manda deltas sin cuadro clave)

TTX: no se consulta el estado de salidas N9M en el panel (evita el 409 en consola)

TTX vivo: si en 4 s no llega cuadro clave, cierra y pide otra conexion (hasta 4 intentos) para forzar el IDR

TTX historial: por defecto todo el dia hasta la hora actual (el rango completo a 23:59 a veces no devuelve lista)

TTX vivo: diagnostico de tipos WKP (buscar paquete de cuadro clave)

TTX vivo: registro del primer NAL para confirmar codec real (H.264/HEVC)

TTX historial: lista en tramos del tamano de clip (5 min por defecto) con fecha/hora de inicio y fin

TTX vivo: autorizacion WKP (tipo 0/2/4) al aceptar la conexion, como CMSV6, antes del V102

TTX vivo: 30 s de margen para que el equipo arranque el encoder tras el V102 (antes se cerraba a los 10 s)

TTX historial: rango de horas editable (inicio y fin) con todo el dia por defecto

TTX vivo: reutiliza el cuadro clave cacheado y solo pide C508 cuando no hay clave (sin cerrar la conexion activa)

TTX vivo: 1,5 s entre cerrar la conexion de medios y pedir la nueva (el equipo ignora C508 si la anterior sigue viva)

TTX vivo: cierre por instancia de la conexion de medios (evita que el flag mate a la conexion nueva)

TTX vivo: al abrir un visor se cierra la conexion de medios anterior para forzar SPS/PPS/IDR iniciales

TTX vivo: cada visor pide un C508 nuevo para recibir el cuadro clave inicial (el equipo no manda IDR periodicos)

TTX reproduccion: no cerrar por falta de visores y guardar el original para diagnostico

TTX historial: Ver descarga el tramo al 2162 y lo abre como MP4 (el equipo no manda video en vivo del historial)

TTX: cuadro clave por NAL (H.264/HEVC) para que el visor arranque, rango de horas en el historial y nombre de archivo decodificado en la reproduccion

TTX historial: usa solo el C701 3,98 (el que devuelve los tramos); la variante 4,0 bloqueaba la buena

TTX historial: espera a la variante del C701 que trae los tramos aunque la otra responda vacia

TTX: cabecera PLT1 hevc cuando el video es H.265, lista de historial publicada en cuanto llega y controles de hora ocultos para TTX

TTX descarga: el .grec original se convierte en MP4 (video HEVC + audio AAC) y el panel ofrece Descargar por tramo

TTX historial: reproduccion de un tramo con C703 (mismo comando que CMSV6), puerto 2162, visor PLT1 y boton Ver en la lista

TTX video: arranque instantaneo del visor con SPS/PPS+IDR cacheados, ffmpeg solo si se pide MJPEG y sin C508 duplicados mientras hay un vivo activo

TTX historial: oculta Ver tramo/Descargar mientras no haya reproduccion TTX (evita botones que no aplican)

TTX historial: pide C701 con las dos variantes (4,0 y 3,98), registra respuesta vacia y evita mezclar dias

TTX historial en el panel: la ventana de historial pide la lista por C701 al equipo TTX (fecha + Listar) y muestra canal, inicio, duracion, tamano y archivo

TTX historial: consulta por fecha (fecha/dia) en /api/ttx/history y cierre rapido de la sesion de historial

TTX medios: diagnostico del keep-alive y del cierre del flujo (contador y total)

TTX medios: libera el canal de vivo cuando no quedan visores (20 s), para no dejar el stream tomado ni gastar datos

TTX medios: handshake nativo completo en el canal de video (WKP tipo 0, 2 y 4 al autorizar; keep-alive tipo 3 con marcas de tiempo en microsegundos cada 1,8 s), copiado de la captura de CMSV6

TTX medios: autoriza el canal (WKP tipo 0 + keep-alive) despues del V102 del equipo, como CMSV6, en lugar de al abrir la conexion

TTX medios: keep-alive WKP en el canal de vivo (40 40 03 60 + 24 ceros cada 1,2 s, como CMSV6) para que el equipo no corte el video al minuto; HTTP de medios con pool de hilos y corte si no llegan datos

TTX medios: cierra la conexion de vivo que queda muda (equipo que manda V102 y no arranca) para que el siguiente C508 no se quede bloqueado

TTX: C100 de V140 con hora UTC en el ultimo campo (como CMSV6), evita atrasar 6 h el reloj del equipo al completar el login

TTX: recalcula la cabecera dcNNNN de cada trama (longitud-9). Con serial de 4 digitos el C100 fijo dc0058 no cuadraba y el equipo ignoraba la respuesta y las ordenes, quedando en conexion corta

TTX: C100 con hora posterior a la del equipo cuando va adelantado (evita que la unidad caiga en conexion corta solo-V101)

Revierte pruebas experimentales y deja el flujo TTX estable

Evita NPE en alarmas N9M sin ALARMNAME

Limpieza de depuracion y entrega de ordenes TTX mas robusta

Entrega robusta de ordenes TTX: cola por unidad, sin envios duplicados, C501 por V109, C508 solo en sesiones persistentes

Responde C501 a los keep-alive V109 (serial dinamico), evitando que la unidad TTX caiga en conexion corta

UI: audio en visor con toggle y volumen

UI: audio homologado en visor, toggle real y volumen

TTX: keep-alive TCP y nota de heartbeat

UI: homologar boton de audio N9M/TTX e inactivo por defecto

TTX: mas tiempo de espera para video y ordenes en V114

TTX: version C588 sin respuesta cruda ni campos desconocidos

TTX: ICCID desde ultimo campo no vacio de C588

TTX: version C588 con canales y discos legibles

TTX: version C588 con campos legibles

TTX: boton Ver version en Acciones

TTX: corregir campos de C588

TTX: version del equipo con C588

TTX: envio de ordenes/video en V114 y diagnostico de cabecera C505

TTX: C505 con cabecera correcta y medicion real de V114

TTX: GPS con SYSTEMPARAM_SET y GET real validado

TTX: ajustar longitud de SYSTEMPARAM_GET a 201

TTX: GET SYSTEMPARAM con formato exacto de CMSV6

TTX: GET de parametros GPS y alta con placeholder 30

TTX: GPS con C505 segun API CMSV6 ajaxSetGpsReportInterval

TTX: SET de GPS con C517 SYSTEMPARAM_SET

TTX: transmision GPS C505 con intervalo configurable

Salidas: quitar texto estado desconocido

Salidas: Encendido/Apagado y ocultar Leer estado en TTX

TTX: orden de salidas OFF/ON por canal

TTX: salidas/motor C150 1-4 equivalentes a N9M

TTX: C150 reboot con serial de CMSV6 y cola

TTX: C517 y C150 en cola aunque no haya socket abierto

TTX: encolar C150 reboot si el socket de conexion corta esta cerrado

TTX: boton Reiniciar equipo (C150 5)

Panel: mostrar texto de error del video TTX en vez de intentar JSON

TTX: video H.264 nativo PLT1 y audio G.711A en el mismo flujo

TTX: audio G.711A desde paquetes WKP y boton de audio

TTX: conservar sesion 30s para unidades de conexion corta

Panel: corrige parpadeo login/panel al invalidarse el token

TTX: cambio de canal automatico y boton de audio

TTX: canal 0 valido y mapeo Canal 1 del panel a CH0

TTX: canales de video independientes por C508 y audio pendiente

Panel: corrige cadena JS del formulario de servidores TTX

TTX: boton Servidores del equipo con dominio y puerto; N9M solo lectura

Panel: filtro por protocolo como select multiple

Panel: filtro por protocolo con casillas (N9M, JT808, TTX, YB-2020)

TTX: video en vivo MJPEG integrado en el panel por HTTPS

TTX: endpoint de historial C701 y descarga C703

TTX: captura cruda de historial/descarga para ingenieria inversa

TTX: C517 pendiente se envia con C100 en conexion corta

TTX: C508 directo si hay sesion y reintento en conexion corta

TTX: una sola peticion C508 por solicitud de video

TTX: canal 1 estable; soporte de conexion corta validado con 0060480

TTX: canal 1 estable; 0060480 validado

TTX: probar canal 2 en C508

TTX: usar el canal solicitado en C508 (canal 1)

TTX: probar C508 antes de C100 en conexion corta

TTX: C100 y C508 en el mismo envio para unidades de conexion corta

TTX: soporte de conexion corta para pedir C508 en la ventana de V101

TTX fase 2: media en 2163 y HTTP en 2164, fuera del rango FTP de CMSV6

TTX fase 2: primer C508 con serial 76

TTX fase 2: video en vivo H.264 desde WKP

TTX fase 2: ffmpeg por ruta absoluta para video en vivo

TTX fase 2: media en 2122, serial C508 y video MJPEG

TTX fase 2: API raw para diagnosticar C508

TTX fase 2: API de diagnostico C508 para video

TTX: C508 con cuerpo directo sin prefijo 0,longitud

TTX fase 2: C508, parser de medios, H.265 a MJPEG y HTTP de video

TTX fase 1: puertos y servidores de medios 11007, 11008 y 11009

TTX: NETWORK_SET con formato exacto de CMSV6 para redirigir 0060480

TTX: servidor 11005, heartbeat, posiciones, C100 y NETWORK_SET; primer equipo TTX real

Keepalive JT808 con heartbeat activo, timeout 240 s y tunel N9M a 15 min

JT808: perfiles por equipo, captura cruda y canal base configurable por unidad

JT808: puerto 11004 dedicado para historial y documentacion de descarga original

JT808: pausa y velocidad, lista 0x1205 segmentada, MP4 del historial y panel movil

JT808: lista de archivos 0x9205 y calendario del historial con 0x1205

Corrige el error al abrir Acciones y evita repintar la ficha en cada telemetria

Corrige el menu de Acciones vacio en N9M y el parpadeo por repintado cada segundo

Google Maps configurable por sitio (googleMapsKey; vacio = Esri + OSM) y marca en la ventana de versiones

JT808/JT1078: video en vivo e historial completos (SPS/PPS, cierre limpio, perfiles H.264) y panel adaptado por protocolo

JT808: comandos (version, reboot, params, ubicacion) con espera de respuesta

JT808: alerta de alarma con mask en campo codigo/extra

Corrige parpadeo del login (verifica token antes de mostrar app)

Corrige parpadeo del login (oculta login hasta que JS decida)

Quita debug de login (falsa alarma de credenciales)

Mapa: anade capas Google Satelite y Google Calles (clave de prueba)

JT808: puerto configurable (11002 por defecto) via sitio.properties

Popup muestra el protocolo del equipo (N9M/JT808)

JT808: servidor TCP 7611, framing, registro, auth, heartbeat, localizacion 0x0200

JT808: servidor TCP 7611, framing, registro, auth, heartbeat, localizacion (0x0200) con GPS y alarmas

Alertas: campos separados (tipo, detalle, codigo, canal, extra)

SSE: respaldo HTTP si no llega el stream

Alertas de sensores: S1..S8 on/off (usa solo el identificador)

Alertas: usa el nombre del sensor reportado por el equipo (Panico, etc.)

Panel: migracion a SSE (push de sesiones y alertas)

Panel: alertas y eventos (alarmas EVEM, sensores) con vista y aviso

Oculta el boton Configuracion del menu Acciones (codigo conservado)

Transmision: el campo muestra el TM real del equipo seleccionado

Transmision: el campo muestra el TM real del equipo al abrir

Transmision: limpia espacios y boton Cerrar a ancho completo

Transmision: solo tiempo TM, modal proporcional; documenta CONFIGMODEL/GET

Servidores del equipo: ventana propia, sacado de Transmision

Transmision: quita activo/inactivo (siempre activo), solo tiempo TM; Servidores del equipo pasa al menu Acciones

Transmision: solo tiempo de reporte (TM), GPS siempre activo, campo numerico 5-3600 s

F1: tronco renombrado a plataforma_replica; paquetes com.plataforma; JAR plataforma.jar; tarea Plataforma-Replica; claves plataforma.*

El panel ya no muestra N9M como nombre del producto: titulo de la pestana, cabecera del login, cabecera principal y ventana de version pasan a Plataforma / Plataforma Replica. Las menciones al canal N9M se mantienen porque son el nombre del protocolo.

El panel pasa a publicarse en /app/ (antes /n9m/): sitio.properties con prefijo /app y nginx con location /app mas redireccion 301 desde /n9m para no romper enlaces ni marcadores. Documentacion actualizada con la URL nueva.

PRE-VUELO: documentado el estado aplicado y las claves de sitio.properties que escribe el instalador (platip, platport, publicip, prefijo, usuario, clave, bind, datos, ssl). start.bat remite a sitio.properties y deja de repetir los valores de este servidor.

PRE-VUELO: datos de instalacion en sitio.properties (dominio, IP publica, prefijo, usuario, clave, bind y carpeta de datos) leidos por la clase Sitio; se eliminan airviewme.club y 74.208.235.122 del codigo y los textos del panel usan la IP configurada. El panel escucha solo en 127.0.0.1 por defecto, con limite de intentos de login por IP y cookie Secure cuando hay HTTPS. ffmpeg se busca tambien como ffmpeg sin .exe y en el PATH, y clips, cache y accesos aceptan -Dn9m.datos. La clave ya no se imprime en el arranque.

ANALISIS: revision pre-vuelo para Linux. Cinco fallos concretos: ffmpeg.exe en vez de ffmpeg, datos escritos un nivel por encima del JAR, panel escuchando en 0.0.0.0, airviewme.club y 74.208.235.122 por defecto y prefijo /n9m. Anadidas comprobaciones de servidor (zona horaria, Java 21, ffmpeg, puertos del proveedor, Cloudflare, tunel) y endurecimiento (limite de login, cookie Secure, clave fuera del log). Nuevo modo --comprobar del instalador y docs/PRE-VUELO-LINUX.md.

ANALISIS: alias de protocolos. Identificador interno yb2020 con nombre visible YB-2020 y completo GDRTA-002 / YB-2020; tabla de alias en docs/PROTOCOLOS-ALIAS.md para resolver como se nombra cada uno en conversacion, en la configuracion y en la API. Se anota que el tercero es una variante de proveedor con inteligencia artificial, sin documentacion publica, y que se integrara con especificacion del proveedor y capturas reales.

ANALISIS: el tercer protocolo queda identificado como GDRTA-002 / YB-2020, norma provincial de Guangdong, con identificador corto gdrta002 y documento PROTOCOLO-GDRTA-002.md. Se anota que habra que confirmar su relacion con JT/T 808 y JT/T 1078 para reaprovechar el registro comun.

ANALISIS: cuatro modos de publicacion (dominio principal, dominio mas directorio, subdominio, subdominio mas directorio) con el primero por defecto; el instalador pregunta cual y en los modos con directorio no toca la web existente del cliente, reutiliza su certificado y revierte si falla. Se anade desinstalacion completa por manifiesto, con conservacion opcional de datos y certificado. Internet abierto en todos los servidores; CentOS 7 queda como modo demostracion. Docs/INSTALADOR-AUTOMATICO.md.

ANALISIS: decisiones del instalador. Se documenta la matriz de sistemas (Ubuntu 24.04 y 26.04, Debian 12 y 13 completos; CentOS 7 en modo compatibilidad con JRE incluido y acme.sh por estar sin soporte desde 2024), correo fijo eltrebolpubli@gmail.com, prefijo raiz por defecto, clave del panel preguntada al instalar con 121212 si se deja vacia y usuario siempre admin. Se aclara el punto del acceso a internet y se advierte del NAT y de Cloudflare en los puertos de equipos.

ANALISIS: instalador automatico de entrega. Al exportar se piden marca, dominio, IP y correo; el paquete incluye el JAR con la marca, instalar.sh (systemd, nginx, certbot, ufw), sitio.properties y LEEME.md con los puertos a abrir. Incluye actualizacion que conserva configuracion y certificado, y endurecimiento: panel solo en 127.0.0.1 y clave por instalacion. Documentado en docs/INSTALADOR-AUTOMATICO.md. Nada aplicado.

ANALISIS: modelo en cuatro capas (motor, marca, sitio, protocolo). Tronco plataforma_replica; marcas Airview y 247GPS en perfiles; el dominio y la IP publica pasan a sitio.properties y dejan de compilarse. Detectados dos valores que ataban cualquier instalacion a este servidor: airviewme.club en IndexPage y 74.208.235.122 en TunnelService, con plan para quitarlos. Protocolos confirmados N9M y JT808; el tercero queda pendiente de nombre. Nada aplicado.

ANALISIS: modelo de nombre por marca. Un solo tronco de codigo con nombre neutro (plataforma); el nombre comercial (Airview, 247GPS o el que se pida) se elige al exportar y queda grabado en el JAR y en la pagina. Docs/NOMBRE-Y-MARCAS.md describe perfiles de marca, exportar.ps1, estructura de carpetas y plan F1-F6. La propuesta Rview queda descartada; N9M sigue siendo solo el protocolo. Nada aplicado.

ANALISIS: cambio de nombre de la plataforma a Rview, con N9M como nombre del protocolo y duplicado 247GPS. Documentado en docs/RENOMBRADO-RVIEW.md: inventario medido (17 ficheros Java, 150 menciones), tabla de equivalencias, 14 riesgos, plan en fases F0-F7 y criterios de aceptacion. Se anade tools/audit-nombres.ps1 (solo lectura) para medir el alcance y auditar restos. Nada aplicado todavia.

PANEL: la tarjeta flotante se ensancha a 340 px, los textos de los datos suben de tamano (13->15 px), el boton Acciones lleva icono y el DSNO ya no queda debajo de la aspa de cerrar (la cabecera deja hueco a la derecha).

PANEL: el menu de Acciones (que ahora sale desde el pie de la tarjeta) se cortaba si la unidad estaba en la parte baja del mapa: al abrirlo, el mapa se sube lo justo para que quepa entero.

PANEL: los cuatro botones (Centrar, Video, Historial y Acciones) se quedan juntos en una fila al pie de la tarjeta, con el desplegable de Acciones como cuarto. Ademas, la aspa de cerrar del popup ahora se ve (28 px, con fondo y color de aviso) porque antes apenas se notaba.

PANEL: Centrar, Ver video en vivo e Historial salen del desplegable Acciones y se quedan como tres botones con icono y color propio, repartidos a partes iguales y ARRIBA en la tarjeta: son lo primero que ve el operador al abrirla. El desplegable conserva el resto (Salidas / motor, Configuracion, Transmision, Ver version, Web del equipo, Forzar apertura y Reiniciar equipo). Si la unidad esta fuera de linea, de los tres botones solo queda Centrar y el desplegable se esconde.

PANEL: la lista de unidades ya no se reordena con cada actualizacion. Antes cogia el orden que llegaba del servidor, que cambiaba cuando una unidad movia su posicion: la lista se reconstruia entera, las filas se movian solas (mucho ruido) y se podia perder el clic. Ahora el orden es fijo: conectadas primero y, dentro de cada grupo, alfabetico por nombre. Ademas, el boton «Acciones» del popup ocupa el 100 % del ancho.

PANEL: la tarjeta flotante se compacta (texto del estado de sesion y el aviso de las acciones, que ocupaban media tarjeta; el detalle queda en el tooltip del boton).

PANEL: los datos de la unidad pasan a un POPUP flotante anclado a su marcador (como en las plataformas de monitorizacion). Antes estaban en una franja horizontal debajo del mapa: con 11 campos se repartian en varias filas, la franja crecia y el mapa se quedaba corto. Ahora el mapa ocupa todo el alto y la tarjeta sale al pulsar la unidad de la lista o su marcador, con los datos en 2 columnas y el desplegable de Acciones dentro. La franja de abajo desaparece.

PANEL: «Ver version» (la version del firmware del equipo) sale de la ventana de Transmision y se queda en el desplegable Acciones, entre Transmision y Web del equipo.

HISTORIAL: si se interrumpe el video (error de decodificacion, conexion de video cerrada o el equipo no manda imagenes) aparece el boton «Nueva peticion» y ademas se reconecta solo una vez. Si el clip termina, el boton queda a mano para volver a verlo. No se insisten solos mas de una vez: el equipo tiene un numero limitado de tareas de reproduccion.

HISTORIAL: el boton «Nueva peticion» tambien aparece cuando el decodificador falla con el contenido que llega (error de video: Decoding error), no solo cuando el equipo no manda imagenes. Con el decodificador roto el video se queda congelado y hay que volver a pedir el tramo.

PANEL: el boton rojo de cerrar de la ventana de video del historial se justifica a la derecha de la cabecera (lleva margin-left:auto, como las X normales de Bootstrap, y el titulo largo puede encogerse para no empujarlo).

PANEL: apilado real de ventanas emergentes. Bootstrap no apila modales (todos a z-index 1055 y sus fondos a 1050), asi que el fondo del segundo modal quedaba debajo del primero y los dos cuadros se veian pegados. Ahora cada modal recibe una numeracion por profundidad: modal N a 1060+N*10 y su fondo a 1055+N*10, de modo que el fondo de la capa N tapa al modal de la N-1 y queda bajo su propio modal. El fondo se va aclarando por capa (70 %, 60 %, 50 %) para que el apilado se note. Se elimina el caso especial del video y su desenfoque.

HISTORIAL: la ventana de video se abre encima del historial con el fondo casi opaco y un poco de desenfoque (antes los dos cuadros se empalmaban y no se veia cual estaba delante). La X de cerrar de esa ventana es ahora un boton rojo con icono. Si el equipo acepta la reproduccion pero no manda imagenes, sale un boton «Nueva peticion» al pie de la ventana que vuelve a pedir el mismo tramo (a la segunda suele salir).

PANEL: se corrige la confirmacion de reinicio (los saltos de linea se meten con String.fromCharCode porque un escape de salto en el fuente de Java rompe el JavaScript servido) y se arregla el check-web.ps1, que no detectaba esos escapes porque el operador coma de PowerShell liga mas fuerte que el mas.

PANEL: se reordena el desplegable Acciones por bloques (Centrar | video e historial | salidas, configuracion, transmision, web del equipo y forzar apertura | reiniciar). El boton Reiniciar equipo sale de la ventana de Configuracion y queda al final de la lista, en rojo y con confirmacion. La reconfiguracion de transmision (GPS, tiempo de transmision, servidores del equipo y version) sale de Configuracion a su propia ventana Transmision; en Configuracion quedan el acceso a la web del equipo y el diagnostico de media.

HISTORIAL: el listado del stream secundario cae al principal si la unidad no lo graba (su web desactiva ese selector cuando RM.product.IsNoSupportHDDSubStream). Antes, al elegir Sub stream en una unidad sin sub, la tabla salia vacia y parecia que no habia grabacion. El JS del equipo (HAPPLE/js/playback.js) lo confirma: el selector playback_stream_type se desactiva si la unidad no soporta sub stream en el disco.

HISTORIAL: REPLIEGO AUTOMATICO AL STREAM PRINCIPAL. Se ha medido que hay unidades que no graban el stream secundario: piden el secundario y contestan START PLAYBACK FAILED 52 (y la lista de archivos del sub sale vacia). Ahora, si el equipo rechaza el secundario, el panel reintenta solo con el principal y avisa con un aviso en pantalla y en la cabecera X-N9M-Aviso. Si se elige Sub stream y no hay archivos, se dice que esa unidad no lo graba.

HISTORIAL: SUB STREAM ARREGLADO. Al elegir «Sub stream» el panel listaba los archivos del stream secundario pero al reproducir se pedia siempre PBST 0 (principal), asi que el equipo no entregaba nada. Ahora PBST accompanye al flujo elegido (0 = main, 1 = sub) en la reproduccion y en el clip MP4. El selector se llama Main stream / Sub stream y explica que el secundario se ve y se descarga mas rapido.

HISTORIAL: si el equipo manda las grabaciones con la fecha dentro, el calendario se arma de esa lista sin preguntar dia a dia.

HISTORIAL: SE LEEN LOS DOS FORMATOS DE RESPUESTA DEL EQUIPO. Algunas unidades contestan al calendario con la tabla de dias (data) y otras con la lista de grabaciones (peroid), que es lo que hacia que el panel dijera que no habia nada. Ahora, si llega el segundo formato, se pregunta dia a dia del mes (en paralelo) para saber que dias tienen grabacion y en que canales. Ademas, result 0 es una respuesta correcta (antes se tomaba como error) y solo se considera error si result no es cero o code no es 0.

PANTALLA COMPLETA CORREGIDA: al entrar en pantalla completa el lienzo se estira a toda la pantalla y la imagen se centra dentro SIN deformarla (object-fit contain), y al salir se devuelve el tamaño original. El area del video en vivo ya ocupaba el 100% del ancho de la ventana (verificado: 766 de 766 px).

El historial ya no confunde un rechazo del equipo con no hay grabaciones: si el equipo contesta sin la seccion de datos, se dice que no contesto y se muestra su respuesta. Ademas el endpoint de diagnostico Servidores del equipo ya decodifica bien la ruta de la pagina que se le pide.

HISTORIAL H.265 ARREGLA. El historial detectaba el codec leyendo el byte del START CODE (siempre 0), asi que siempre decia «H.264»: las unidades que graban en H.265 (Encode Standard H265) llegaban al navegador etiquetadas como H.264 y no se veian (ni el panel ni ffmpeg las podian leer). Ahora se mira la cabecera del NAL, igual que en el video en vivo, y el servidor transcodifica a H.264 cuando el navegador no admite H.265.

HISTORIAL: AVISO DE FORMATO NO REPRODUCIBLE. Hay unidades (la 0099001410) que graban en H.264 con 'data partitioning': ni los navegadores ni ffmpeg lo implementan, asi que el video mudo no era un fallo del panel. El servidor lo detecta al abrir el archivo y lo dice claro en vez de dejar 0 tramas. El video en vivo de esas unidades si funciona.

Diagnostico: el log del historial anade la clase y los tipos de NAL de las primeras tramas de cada archivo (para ver el formato de las unidades que no decodifican).

El panel ya no tapa el aviso de error del decodificador con el contador de tramas (se ve el error real del navegador cuando un video no decodifica).

Diagnostico: el log de media anade la clase de la trama y los tipos de NAL de las primeras imagenes, para ver por que hay unidades cuyo video no decodifica el navegador.

VIDEO QUE NO SE CAE. El historial detectaba la imagen clave solo por la clase de la trama (0x32): en algunas unidades la clave llega con otra clase, se publicaba como delta y el navegador moria con «A key frame is required after configure()». Ahora se comprueba tambien el NAL (IDR en H.264, IRAP en H.265) y, en el navegador, se ignoran los deltas hasta que llega la primera clave y un trozo malo ya no tumba el stream entero.

La cache del historial se guarda junto al proyecto (n9m-replica/historial-cache.json) en vez de en el directorio de trabajo del servicio.

La cache del historial se guarda en disco (historial-cache.json): si la otra plataforma tiene el tunel del equipo, el panel sigue enseñando los dias y los archivos de la ultima lectura, aunque el servidor se reinicie.

HISTORIAL CON CACHE POR UNIDAD. Si el equipo esta ocupado (la otra plataforma tiene su tunel), el panel muestra la ultima lectura buena del calendario y de los archivos, con la antiguedad, en vez de un error: el operador ve los dias y las horas aunque ahora mismo no entre el tunel. El servidor sigue reintentando solo y en cuanto hay hueco se actualiza solo.

El boton «Servidores del equipo» avisa cuando el puerto de media de una unidad es el mismo que el de datos (11000): en ese caso el equipo no puede abrir un segundo stream y el video y el tunel fallan con «sin memoria». El aviso dice que hay que ponerlo en 11001.

El servidor espera el hueco del equipo SOLO: si el tunel falla porque otra plataforma tiene streams abiertos en esa unidad, se sigue reintentando en segundo plano (cada 25 s, hasta 20 min) y en cuanto el equipo deja hueco el tunel queda abierto. El aviso del historial lo dice y /api/tunnel/status expone 'esperandoHueco'. Con el puerto de media ya corregido (11001) el historial entra en 3-10 s en las unidades libres.

NUEVO: leer los SERVIDORES del equipo por N9M (sin tunel y sin gastar streams). Es la seccion MCMS de la configuracion del equipo: por cada servidor, IP, puerto de datos, puerto de media, puertos UDP y si esta activo; mas la lista de puertos (WEB Port). Nuevo endpoint GET /api/equipo/servidores?dsno= y boton «Servidores del equipo» en la ventana de Configuracion, para ver desde el panel a que apuntan las unidades (el servidor 1 suele ser Ceiba con 5556 y el 2 el nuestro con 11000). Tambien se ha descubierto que el equipo responde a CONFIGMODEL/GET de las secciones MCMS y PORT, lo que permite diagnosticar la configuracion sin depender del tunel.

Nuevo endpoint de diagnostico GET /api/equipo/pagina?dsno=&ruta= : lee una pagina de la web interna del equipo con la sesion ya iniciada (por ejemplo /WAP/getparameter.json, que es la configuracion nativa del equipo con sus servidores y puertos), para comparar unidades sin salir del panel.

El historial falla RAPIDO y claro cuando la unidad tiene sus streams ocupados: presupuesto de apertura de 12 s (2 intentos) en vez de 30, y el aviso explica que esa tabla la comparten Ceiba y la plataforma principal y que las reservas se liberan solas en unos minutos.

HISTORIAL MAS RAPIDO Y ESTABLE. El tunel del equipo pide ahora el stream con un nombre FIJO por equipo (en vez de uno aleatorio en cada apertura): el equipo REUTILIZA el stream que ya conoce, asi que nuestras peticiones ya no reservan entradas nuevas en su tabla (que es corta y la comparten Ceiba y la plataforma principal). Comprobado: con nombre aleatorio la unidad daba ALLOCATE MEMORY FAILED y con el nombre fijo respondia SUCCESS. Los reintentos tambien usan el mismo nombre, asi que no gastan streams de mas. Los mensajes de error explican que la tabla se comparte con las otras plataformas. Documentado en docs/HISTORIAL-RENDIMIENTO.md.

Video en vivo e historial: el video ya ocupa el 100% del ancho de su ventana (se quita el tope de 720/960 px, por eso se veía en un recuadro pequeño) y los botones de captura y pantalla completa son mas grandes, con mas margen arriba y a la derecha.

FOTOS: la API solo sirve fotos del VIDEO EN VIVO (si se pide modo=historial lo dice con un mensaje claro). En el HISTORIAL la captura es MANUAL: el boton de camara de la ventana de video saca la imagen de lo que se esta viendo en ese momento (PNG del lienzo), sin pasar por la API.

La foto (snapshot) por API ya pide el video al equipo (REQUESTALIVEVIDEO) antes de sacarla: antes solo se preparaba el stream y el equipo no abria su enlace de media, asi que nunca llegaba ninguna imagen.

La foto (snapshot) por API encuentra ahora el video que el equipo tiene abierto aunque el enlace de media se haya quedado con el flujo anterior (se busca en el propio enlace y no solo en el mapa de streams).

DESCARGAS CON PROGRESO Y BOTONES ARREGLADOS. La descarga del clip MP4 del historial ahora se lee por trozos y muestra una barra con el porcentaje y los MB, con aviso de descarga completada (antes se quedaba en «descargando...» para siempre, sin porcentaje ni mensaje de fin); también se puede cerrar la barra. Los botones de la ventana de video del historial (captura, pantalla completa, pausa y descargar MP4) VOLVEN A FUNCIONAR: el manejador general de acciones se comia cualquier boton que empiece por «hist-». Los botones de captura y pantalla completa se reencuentran bien colocados: la caja del video lleva ahora el ancho maximo y los botones quedan en la esquina superior derecha DEL VIDEO, no de la ventana.

Foto (snapshot) en video en vivo: si el video esta en «Fluido» (flujo secundario, resolucion reducida) el boton de captura cambia solo a «Calidad», espera el video y saca la foto a la resolucion de la camara (2 MP = 1920x1080, 1 MP = 1280x720).

FOTO A LA RESOLUCION DE LA CAMARA y PANTALLA COMPLETA. La foto (snapshot) se pide ahora en el flujo PRINCIPAL (calidad) en vez del secundario, asi que sale a la resolucion nativa de la camara (1920x1080 en 2 MP, 1280x720 en 1 MP); nuevo parametro calidad=1|2 en la API. El lienzo en pantalla completa se estira a toda la pantalla con object-fit:contain (antes se quedaba en su tamano intrinseco, que en el flujo «Fluido» es diminuto). El boton de captura avisa cuando el video esta en «Fluido».

Video en vivo: el area del video ya no se encoge ni queda chico en pantalla completa (la caja pasa a ser de bloque y el canvas conserva su ancho maximo; en fullscreen se fuerza el maximo con !important).

Foto (snapshot): mensaje de error mas claro cuando la unidad no tiene configurado el servidor de media (Media Server IP/Port), y la foto del historial se arma con la ultima imagen clave mas las siguientes, incluyendo los conjuntos de parametros (SPS/PPS/VPS) para que ffmpeg pueda decodificarla.

CONTROLES DE REPRODUCCION Y CAPTURA DE IMAGEN. En el historial: boton de pausa/reanudar, selector de velocidad (0,5x, 1x, 2x, 4x) y salto con un clic en el video (se vuelve a pedir el tramo desde ese punto, sin tener que ver los 5 minutos). Boton de captura (camara) arriba a la derecha del video, en vivo y en historial, y boton de pantalla completa (los botones siguen visibles en pantalla completa). NUEVA API REST DE FOTOS: GET /api/media/snapshot?dsno=&canal=&modo=vivo|historial devuelve un JPEG de la imagen de ese momento (si no hay video abierto, abre uno momentaneo al equipo y lo cierra). Y POST /api/media/playback/control para pausar, reanudar o acelerar la reproduccion desde fuera.

EL REINICIO DEL EQUIPO YA FUNCIONA: el comando que mandabamos estaba incompleto (el equipo contestaba SUCCESS y seguia conectado sin hacer nada). Ahora se envia el formato EXACTO que usa Ceiba, capturado de su trafico real del puerto 5556: DEVEMM/SETCONTROLDEVCMD con PARAMETER{CMDTYPE:0, CONTINUE:null, HDEV:2, SERIAL:<numero>} y SESSION vacia (la plataforma se dirige al equipo por el SERIAL, no por la sesion). Verificado en 0099001410: el equipo responde SUCCESS y cierra la conexion. El panel espera el ACK y comprueba que la conexion se cierre, en vez de anunciarlo sin comprobarlo.

La configuracion del equipo se divide: el cuadro de Configuracion ya no vuelca los datos (hacia crecer el modal) y los muestra en su propia ventana «Ver detalle de la configuracion», con el resumen arriba y todas las tablas (PGPS, PDSM, KEYS) plegadas debajo.

Configuracion del equipo: «Leer config» ya no toca ni guarda los campos (solo consulta); «Aplicar y confirmar» manda el SET completo (SERIAL, MODE, NUM y TM), espera el ACK y vuelve a LEER el equipo para confirmar el valor real en un aviso; «Ver version» abre de nuevo su ventana (usaba una clase que Bootstrap no muestra) y el reinicio ahora espera el ACK y comprueba que el equipo se desconecte, en vez de anunciarlo sin comprobarlo.

Descarga de clips: el proxy del panel conserva el tipo video/mp4 y el nombre del fichero (antes el MP4 se servia como application/json en los enlaces directos)

Tunel: si el equipo no mantiene el keep-alive se vuelve solo a Connection: close (sin repetir el fallo); el tunel se conserva 24 h y el proxy de la web cierra el tunel muerto antes de reintentar

Diagnostico del tunel: el registro confirma si el equipo mantiene abierto el tunel (keep-alive) despues de cada consulta del historial

Tunel del equipo con keep-alive: una sola reserva de stream por sesion (evita ALLOCATE MEMORY FAILED) y login automatico del historial con admin/admin, sin pedir credenciales

HISTORIAL CON VENTANA DE VIDEO Y BUSQUEDA POR HORA. El video ya no se pinta al final de la lista (habia que bajar hasta abajo): al pulsar Ver en un clip se abre una VENTANA APARTE con el reproductor, el estado y un boton «Descargar este tramo (MP4)». Arriba de la lista hay una BUSQUEDA POR TRAMO: se escribe la hora de inicio (HH:MM:SS), se le suma la duracion del selector Clip (5 minutos por defecto) y se reproduce o se descarga ese tramo del dia marcado en el calendario; la hora se propone sola con el primer tramo del dia. La descarga usa el mismo generador de MP4 en segundo plano (video H.264 y audio AAC G.711) y muestra el avance y el peso final. Al cerrar la ventana se corta la reproduccion y se suelta el equipo.

HISTORIAL: se quita el bloque antiguo que habia quedado FUERA del modal (botones de mes, canal, flujo, «Ver mes» y «Hoy», y una copia entera del calendario, la tabla y el lienzo); duplicaba ids y se veia suelto en la pagina. FICHA: las siete acciones pasan a un solo desplegable «Acciones» (video en vivo, historial, salidas/motor, configuracion, web del equipo, forzar apertura y centrar), cada una en su ventana; con la unidad fuera de linea solo queda «Centrar». VIDEO: al cambiar de canal o de calidad la transmision se reabre sola y el lienzo se borra antes de conectar, asi ya no queda pegado el ultimo fotograma de la camara anterior; cada apertura lleva un contador de sesion que descarta cualquier decodificador viejo. Al cerrar la ventana se corta la transmision, el decodificador y el audio, y se deja canal 1 y flujo Fluido para la siguiente unidad. El historial usa su propio decodificador, asi que cerrar una ventana no corta la otra.

AUDIO EN VIVO, EN EL HISTORIAL Y EN EL MP4 DESCARGABLE. El equipo manda el sonido G.711 (8 kHz, mono) en las tramas de clase 0x34, con la misma cabecera propietaria que el video; ahora se separa con una regla estricta (tramas de 384 bytes = 320 de sonido, o de 256 = 160) que descarta los falsos positivos de las continuaciones de video. El navegador recibe el sonido como una marca nueva (clave 2), lo decodifica (A-law o µ-law, selector en las ventanas de video e historial) y lo programa con Web Audio y un colchon de 150 ms. La reproduccion del historial se entrega ahora al ritmo real del archivo (antes iba a la velocidad del TCP, ~1,65x). El clip MP4 se monta en dos pasos (video y audio en bruto primero, ffmpeg al final) y la cadencia del video se mide con el reloj del audio (~10 fps en estas unidades, no 25): los clips ya salen con la duracion correcta y con sonido. Se retira el pendiente de descargar el archivo original.

Interfaz nueva con Bootstrap y ventanas emergentes (video en vivo, salidas/motor, configuracion, historial, versiones) y lista de pendientes visible en el panel. El historial parte los tramos largos en clips de 1 a 30 minutos (como la plataforma principal) y permite descargar el clip en MP4, que el servidor genera en segundo plano.

Historial de grabaciones: calendario del mes y lista de archivos por canal (leidos de la web del equipo por el tunel), y reproduccion del tramo grabado con REQUESTREMOTEPLAYBACK por el enlace de media (tramas 0x04 re-agrupadas en imagenes y transcodificadas si el navegador no soporta H.265). Nueva ventana de historial en el panel.

Diagnostico: /api/media/status indica si hay ffmpeg y el arranque registra su ruta; comentarios del flujo de video al dia.

Video H.265: quitar -probesize/-analyzeduration al transcodificar (ffmpeg perdia el I-frame y las referencias) y forzar marcas de tiempo crecientes en las tramas.

Video en vivo H.265: deteccion de codec por stream, cabecera N9M1 al navegador y transcodificacion local H.265->H.264 con ffmpeg propio (tools/ffmpeg.exe) cuando el navegador no soporta HEVC. Incluye el arreglo del troceado TCP de las respuestas de media (REGISTER MEDIA SERVER FAILED).

Video en vivo: deteccion automatica de H.264/H.265 y cabecera N9M1 al navegador (la unidad 009900309A emite H.265); respuesta de media en una sola escritura TCP (sin ella el equipo abortaba con REGISTER MEDIA SERVER FAILED).

Video en vivo (fase 2): el servidor pide REQUESTALIVEVIDEO con IPANDPORT 11001, responde CREATESTREAM y manda AVSM/GETIFRAME para que el equipo empiece a emitir H.264; nuevo /api/media/live que retransmite las tramas y reproductor WebCodecs en el panel (canal 1 y Fluido por defecto). Verificado con unidades reales.

Media: REQUESTALIVEVIDEO corregido segun captura real de Ceiba (incluye IPANDPORT; AUDIOVALID y CHANNEL como mascara; STREAMNAME tipo 5-N; STREAMTYPE 1/2). Nuevo campo 'module' en /api/command/media para enviar AVSM/GETIFRAME y arrancar el envio de video.

Media 11001: cada conexion deja en el log sus primeros 64 bytes en hex y ASCII, y el motivo del cierre, para identificar el encuadre real cuando una unidad apunte a Media Server Port 11001. El log de media lleva hora. Sin cambios de comportamiento hacia los equipos.

Video en vivo (fase 2): canal 1 por defecto y lista de canales 1-8; calidad FLUIDO (stream secundario, por defecto) o CALIDAD (primario). El video se pide solo, sin preguntar, en cuanto se pulsa Ver video en la ficha o en el bloque Video en vivo. Se envia REQUESTALIVEVIDEO por el enlace de media (11001) con STREAMNAME propio, STREAMTYPE 2/1, CHANNEL 1<<(canal-1). Si la unidad no esta registrada en el 11001, el panel lo avisa y recuerda el ajuste Media Server IP/Port del equipo. Nuevo via=media en /api/command/media.

Fase 2, paso 2: escucha de MEDIA en el puerto 11001 (mismo CERTIFICATE/CREATESTREAM que el tunel). El equipo se apunta ahi con su ajuste Media Server IP/Port; el servidor registra el stream por DSNO y anota las tramas que recibe (JSON 0x00 y datos 0x0d) para identificar el encuadre real de historial y video. Todavia no se envia ninguna orden al equipo. Nuevo /api/media/status y una linea de estado en la consola de MEDIA del panel.

Fase 2: la consola de MEDIA puede enviar las operaciones por el TUNEL de la unidad, no solo por el canal de control (comprobado que el equipo real ignora GETCALENDAR/QUERYFILELIST por control y las atiende por el canal de media). Si la unidad no tiene tunel abierto, avisa sin enviar nada.

Fase 2, paso 1 (historial y video): nueva consola de MEDIA en Configuracion. Envia al equipo cualquier operacion del modulo MEDIASTREAMMODEL (GETCALENDAR, QUERYFILELIST, REQUESTALIVEVIDEO, DOWNLOADVIDEO, REALPLAY, REMOTEPLAY, CONTROLSTREAM) con el PARAMETER editable, espera su RESPONSE hasta 8 s y lo muestra en crudo. Los botones Ver video en vivo e Historial abren la consola con la operacion correspondiente. Formato real de REQUESTALIVEVIDEO recuperado de napi.dll (STREAMNAME, STREAMTYPE, FRAMEMODE, CHANNEL, AUDIOVALID). Ninguna operacion de media se envia sola: siempre la dispara el operador.

En modo manual, si el servidor ya tiene abierta la sesion de un equipo (el operador ya escribio usuario y clave) la web del equipo entra directo a su panel en vez de volver a mostrarle el login; si la sesion ha caducado, es el propio equipo el que manda a su pagina de login. Se mantiene que sin sesion se abre login.rsp.

Acceso a la web del equipo: modo GENERAL ademas del ajuste por unidad. El general es MANUAL por defecto, asi que todas las unidades (y las que se anadan) muestran el login del propio equipo en vez de entrar solas con admin/admin; se puede cambiar a automatico o a automatico con credenciales. En la ficha hay Guardar en esta unidad, Usar el general (quita el ajuste propio) y Guardar general; el panel dice si la unidad usa su ajuste o el general. En modo credenciales, guardar sin reescribir la clave ya no la borra (se conserva la guardada), y al cambiar a otro modo las credenciales se descartan.

Arreglo del acceso MANUAL a la web del equipo: su pagina de login calcula la direccion de vuelta a partir de la ruta del navegador y da por hecho que el servicio esta en la raiz o bajo un prefijo de UN tramo (como el /nat<devid>/ de Ceiba). Con nuestro prefijo de tres tramos (/n9m/devweb/<dsno>) pedia "/n9m/WAP/..." y tras escribir usuario y clave terminaba en una pagina en blanco. Ahora ese primer tramo de mas se quita tanto en las redirecciones (Location) como en el parametro url= que recibe el equipo, asi que el login manual entra al panel del equipo.

Correccion del acceso a la web del equipo: al guardar el modo, el desplegable se quedaba pintado con el valor anterior ("automatico") hasta cambiar de unidad; ahora se pinta el valor real y, mientras se esta leyendo el ajuste guardado, no se muestra ninguno para no dar uno falso.

Web del equipo: acceso por equipo (automatico admin/admin, MANUAL -que el equipo pida usuario y clave- o automatico con credenciales propias), guardado en devweb-acceso.json y configurable en la ficha (Acceso a la web del equipo). El modo manual entra directo a login.rsp del equipo y guarda la sesion que abre el operador; al cambiar el acceso se tira la sesion anterior para que el cambio valga. Ademas: las rutas relativas con ".." de la web del equipo (p. ej. ../login.rsp al caducar la sesion) ya no se pierden, se atienden contra el equipo del ticket. La pagina del panel se trocea para no pasar el limite de 64 KB por constante.

Correccion: al olvidar (o caducar) una unidad caida, su marcador rojo se quita del mapa; antes se quedaba dibujado para siempre hasta recargar la pagina.

Lista y mapa: el carrito va VERDE si la unidad esta en linea y ROJO si esta fuera de linea. La lista ahora TAMBIEN muestra, en rojo, las unidades que se han caido (con su ultima posicion y "SIN CONEXION hace X"), asi se ve de un vistazo quien se ha perdido; al seleccionarlas se muestra su ultima ficha conocida (sin acciones, solo Centrar) y el marcador rojo se queda en el mapa. El contador del encabezado avisa de las que estan fuera de linea. Nuevo /api/caidas/forget para olvidar una caida.

Mapa: el icono de la unidad va VERDE cuando esta conectada y ROJO cuando se desconecta. Al caerse una unidad se queda dibujada en su ultima posicion conocida (etiqueta y burbuja en rojo, "SIN CONEXION" con el tiempo transcurrido) en vez de desaparecer del mapa; el servidor la recuerda 12 h (/api/sessions -> caidas) y la borra en cuanto la unidad vuelve. La lista y el contador siguen mostrando solo lo conectado.

Menos gasto de reservas en las unidades: comprobado en real que la reserva de un REQUESTTRANS no se libera al cortar la conexion y tarda mucho en caducar, asi que el tunel sin uso ya no se cierra a los 2 min sino a los 10 (se reutiliza durante toda la sesion de configuracion y se pide una sola reserva en vez de una por visita). Probado tambien que el equipo no permite liberar esa reserva por protocolo: MEDIATASKSTOP se ignora y CONTROLSTREAM CMD:0 responde NO TASK sobre los nombres del tunel.

Corregido un falso positivo: el panel anunciaba «sesion abierta» cuando la unidad conectaba al 13051, respondia ALLOCATE MEMORY FAILED (ERRORCODE 12) y cerraba en menos de un segundo (abrir la conexion no basta: ahora se espera 1,2 s y se exige que el equipo no haya respondido con error y que la sesion siga viva; ademas, al recibir un errorcode distinto de 0 el servidor cierra esa conexion condenada).

Servidor de la API (13001) y web del panel (13000) con pool de hilos: antes com.sun.net.httpserver atendia las peticiones de una en una, asi que una peticion larga (cargar la web del equipo, forzar apertura, leer la version) dejaba el panel entero congelado, incluido el refresco de la lista. Ahora cada peticion va por su cuenta y el panel sigue respondiendo mientras se espera a una unidad.

Apertura forzada: el presupuesto de espera ahora cuenta cada intento fallido como ~3 s (los rechazos los contesta la unidad al instante), asi que «Forzar apertura» (2 min) hace del orden de 20 intentos espaciados 5 s en vez de 4. Mensajes de error corregidos: comprobado que no habia video ni tunel de Ceiba abierto contra esas unidades, la reserva que queda es interna de la unidad.

Forzar apertura de la sesion del equipo: si la unidad responde ALLOCATE MEMORY FAILED (ERRORCODE 12), el servidor reintenta solo, espaciado 5 s (medio minuto al abrir la web del equipo; hasta 90 s con el boton «Forzar apertura» de la ficha) despues de cerrar su propia sesion. Se quita el boton «Cerrar sesion remota» de Configuracion: ahora el estado de la sesion y el boton de cerrar estan en la ficha, junto a «Web del equipo», y el boton de cerrar solo aparece cuando hay una sesion abierta. Los avisos de error explican las dos salidas: Forzar apertura y Reiniciar equipo.

La ventana de version del equipo se vacia al cerrarla: no queda ningun dato guardado en el panel (y una respuesta que llegue tarde ya no pinta nada).

Ver version del EQUIPO en ventana emergente: se pide al pulsar y ya no se guarda ni queda pintada en Configuracion (la respuesta viaja en la misma peticion HTTP). Nuevo boton Cerrar sesion remota: libera en el equipo el stream del tunel de este servidor (el servidor cierra su tunel anterior y espera 1,5 s antes de pedir otro, y los tuneles sin uso se cierran solos a los 2 min). El mapa se redibuja bien al entrar (varias pasadas de invalidateSize + al cambiar la ficha y la ventana), sin necesidad de pulsar F5.

Configuracion del equipo: al pulsar Aplicar (GPS/periodo) el panel VUELVE A LEER la configuracion sola, en vez de quedarse mostrando la lectura anterior (parecia que el cambio no se habia aplicado; comprobado en unidad real que el SET si entra). Ademas, mientras el equipo no contesta, el panel muestra "pidiendo al equipo..." con la hora de la ultima lectura, tanto en configuracion como en version.

Web del equipo: un solo intento de apertura de tunel. Comprobado en equipo real que cada REQUESTTRANS reserva un stream y los anteriores tardan en liberarse: insistir con varios nombres seguidos agota la memoria del equipo y provocaba el propio error ALLOCATE MEMORY FAILED. Se mantienen los avisos claros y el ticket de 5 minutos.

Web del equipo: el aviso de error explica que el equipo corto el tunel por estar ocupado o sin memoria (mismo ALLOCATE MEMORY FAILED) y que es cosa de la unidad, no de la PC desde la que se entra.

Panel: la lista de unidades y los botones de la ficha ya no se reconstruyen en cada actualizacion (se hacia cada segundo). Ahora las filas y los botones se crean una sola vez y solo cambia su texto, por lo que un clic ya no se pierde cuando el elemento se reemplazaba entre pulsar y soltar.

Web del equipo: la pestana se abre en el mismo clic (el navegador ya no la bloquea por perder el gesto del usuario; si la bloquea, queda un enlace en pantalla), el ticket dura 5 min y el tunel reintenta 3 veces cuando el equipo responde ALLOCATE MEMORY FAILED (ERRORCODE 12). El aviso de fallo ahora aclara que depende de la unidad y no de la PC desde la que se entra.

Tunel: STREAMNAME aleatorio (nunca repite nombres entre reinicios)

Web del equipo: la cookie de acceso dura 8 h (antes heredaba los 2 min del ticket)

Tunel: diagnostico del error del equipo (ALLOCATE MEMORY FAILED) y confirmacion de tunel vivo

Tunel: STREAMNAME unico por apertura (evita colision con streams de Ceiba)

Tunel: registro por DSNO y diagnostico de cierre/mensajes de control

Tunel: parseo de cabeceras HTTP con LF (cookies de sesion del equipo)

Web del equipo por tunel: proxy autenticado /devweb, login automatico admin/admin y reescritura de rutas

Tunel HTTP hacia la web interna del MDVR (REQUESTTRANS + CREATESTREAM, puerto 13051)

Panel: seccion 'Configuracion' con tablas de todos los valores leibles del equipo (GPS, PDSM, KEYS) y nota del limite del firmware. Boton 'Comandos' renombrado a 'Configuracion'.

Configuracion nativa: lee PGDSM+KEYS en una sola peticion (unica seccion valida en R33U30) y permite activar/desactivar el GPS y fijar el periodo por CONFIGMODEL/SET. Panel con selector y periodo sincronizados.

Nuevo boton 'Ver version': pide DEVEMM/GETDEVVERSIONINFO al equipo y muestra firmware (MANVERSION), aplicacion, kernel, GPS, MCU y version de protocolo. Solo lectura, verificado en equipo real (R33U30).

Confirmacion de salidas en el panel: se guarda lo que se pidio (la respuesta del equipo no repite el estado) y el panel muestra 'orden S1=BAJO confirmada por el equipo hace X s', o 'enviada, esperando confirmacion' mientras no llega.

Escritura de salidas ARREGLADA (causa raiz encontrada con captura del 5556 + pruebas A/B/C en equipo real): el equipo exige PARAMETER.SERIAL NUMERICO en CTRLIOOUTPUT; con el DSNO en texto ignoraba la orden en silencio, y por eso nunca accionaba nada. Ahora se envia con un serial numerico propio (sin depender de la plataforma), el equipo la confirma con SUCCESS en 1-2 s, y el panel muestra 'confirmada por el equipo'. Botones de salida renombrados ALTO/BAJO igual que en Ceiba.

Portabilidad: los unicos datos de esta instalacion que quedaban en el codigo (host y puerto que el panel muestra para configurar el MDVR) pasan a variables de entorno N9M_PLATIP / N9M_PLATPORT, y la URL publica de check-web.ps1 a N9M_PUBLIC_URL. El servicio queda sin ninguna referencia a la plataforma principal. Documentado en docs/AISLAMIENTO-Y-MIGRACION.md.

El panel muestra la configuracion que devuelve el equipo (CONFIGMODEL/GET): GPS activado/desactivado, periodo de reporte, modo y subida de datos. Solo lectura.

Leer config arreglado: la operacion correcta es CONFIGMODEL/GET con PARAMETER{MDVR:{PGDSM:?},SERIAL} (formato tomado del programa real del proveedor, docs/ejemplos/ceiba2-paro-motor.js). Antes se enviaba CONFIGMODEL/QUERY, que no existe y el equipo ignoraba.

Salidas: se descubre la semantica real del comando (documentacion oficial de la API: io = ESTADO de cada salida 0 abajo / 1 alto, cm = modo 0 continuo / 1 temporizado, ti = segundos). Los tres arrays son por canal (uno por salida), no por orden, por eso el comando anterior IO:[0] no hacia nada. Ahora se envia el estado completo de las salidas conservando las demas, y el panel relee el estado cada 5 s para reflejar cambios hechos desde otras plataformas.

Corrige unidades duplicadas: una sesion zombi (equipo que se reconecto sin cerrar la conexion anterior) hacia que la misma unidad apareciera dos veces y que los comandos fueran a la conexion muerta (por eso Leer estado no hacia nada). Ahora al registrarse un equipo se descarta su conexion anterior y un vigilante cierra las sesiones sin datos durante 3 min. El panel muestra siempre los botones ON/OFF de las salidas (S1/S2) y consulta el estado automaticamente al seleccionar la unidad.

Paneles de salidas correctos: el equipo reporta 2 salidas (reles), no 4. Se reemplaza la operacion inventada CONTROLOUTPUT por las reales GETIOOUTPUT (lectura, verificada) y CTRLIOOUTPUT (accionamiento, formato del servidor real). Se separan las 8 ENTRADAS S1..S8 (sensores de UPDATEIOSTATUS) de las salidas.

Corrige bucle de mensajes: el servidor respondia con ERRORCODE=0 a mensajes que ya eran respuestas del equipo (GETIOOUTPUT), provocando repeticion continua. Ahora no se contesta a un mensaje que ya trae RESPONSE.

Corrige el error de JavaScript en el aviso de reinicio que dejaba la pantalla de login sin funcionar (SyntaxError: Invalid or unexpected token). Anade check-web.ps1 para validar la web tras cada despliegue.

Reinicio real de equipos: DEVEMM/SETCONTROLDEVCMD con CMDTYPE=1 (verificado en equipo real, offline ~110 s y reconexion)

Version base estable. GPS en vivo leido de la trama de telemetria (0x16), mapa con capas Calles/Satelite, centrado de unidad con zoom 16, actualizacion cada 1 s con aviso 'en vivo', ficha de la unidad, y comandos: salidas S1-S4, leer config, periodo GPS y reinicio.

Confirmar la ley del audio (A-law o µ-law) con un micrófono activo en la unidad: ahora es A-law por defecto con selector en el panel y en el clip; si suena raro, cambiar a µ-law.

Controles de reproduccion: pausa, velocidad y salto (PALYBACKCMD, PLAYCTRL, REMOTEPLAYSEEK).

Audio y talk con el equipo (TALKSTART, ENCODER, AUDIOFORMAT, SAMPLINGRATE).

Vista multiple: ya se ven 1-8 camaras a la vez en el directo de N9M y TTX (4 por defecto). Falta que el panel lea de la base de datos cuantas camaras tiene cada equipo y ajuste el maximo, el defecto y las peticiones; el historial sigue de una en una.

Guardar copia de los videos en el servidor y buscar por fecha, matricula o GPS.

Zona horaria y reloj del equipo, y gestion de los usuarios de su web desde el panel.

Cargar la configuracion completa del equipo (el firmware solo expone GPS y claves por N9M).

Confirmar en mas unidades que «Aplicar y confirmar» deja el nuevo tiempo de transmision (ya verificado en 0099001410: 30 -> 60 -> 30, con la relectura del equipo).

Confirmar en produccion el H.265 real (unidad 009900309A) y el historial en mas unidades.