Saltar a contenido

¿Por qué SUNAPI expone la zona y el driver/plugin de Milestone no?

Pregunta: si la cámara lo expone perfectamente, ¿por qué la integración oficial de Wisenet/Hanwha en Milestone no lo cubre?

La respuesta no es que a alguien se le pasó. Es estructural: el modelo de eventos de driver de Milestone no tiene dónde poner la zona. Todo lo que sigue está verificado contra la base Surveillance de este servidor.

Evidencia 1 — Lo que el driver tiene realmente cableado para esta cámara

Hardware.EventSettings de la Hanwha TNO-4050T, resolviendo los GUIDs contra EventTypes:

Binding Event ID Nombre
event:15\|0 4b1a4dbc-… IntrusionStart
event:8\|1 52e855c9-… Tripwire
event:4\|2 12385cd5-… Tampering

Tres eventos. Nada más. Es exactamente el síntoma descrito: intrusión, cruce de línea, y nada de zona.

Y cada binding tiene este setting:

<setting><name>EventIndex</name><value>1</value></setting>

O sea: el driver sí tiene un concepto de índice, pero está fijo en 1. Hay un solo slot. No hay un binding por zona.

Evidencia 2 — Los tipos de evento de driver no aceptan parámetros

SELECT CASE WHEN CAST(Definition AS nvarchar(max)) LIKE '%<Parameters/>%'
            THEN 'sin parametros' ELSE 'CON parametros' END, COUNT(*)
FROM EventTypes WHERE GeneratorType LIKE 'Driver%' GROUP BY ...

sin parametros | 203

203 de 203. Todos los tipos de evento de driver declaran <Parameters/> vacío. Un evento de driver en Milestone es un nombre y un dispositivo origen. No hay carga útil. La zona no tiene dónde viajar.

Definición completa de uno, para que se vea:

<EventType>
  <Name>CrosslineHuman</Name>
  <Parameters/>                          ← vacío
  <Generator><Type>DriverDevice</Type>…</Generator>
  <Sources><Source><Type>Camera</Type><Filters/></Source></Sources>
</EventType>

Evidencia 3 — Milestone sabe del problema y lo esquivó

En el catálogo de eventos de driver aparecen estos pares:

CrosslineHuman        /  CrosslineHumanNoAreaId
CrosslineVehicle      /  CrosslineVehicleNoAreaId
CrosslineBicycle      /  CrosslineBicycleNoAreaId
LoiteringHuman        /  LoiteringHumanNoAreaId
LoiteringVehicle      /  LoiteringVehicleNoAreaId
LoiteringBicycle      /  LoiteringBicycleNoAreaId

El sufijo "(no area ID)" prueba que Milestone modela explícitamente la distinción "la cámara reportó un area ID" vs "no lo reportó".

Pero al comparar las dos definiciones XML, son idénticas en estructura: ambas con <Parameters/> vacío y el mismo <Sources>.

Es decir: el area ID alcanza para elegir cuál de los dos eventos disparar, pero su valor se descarta. Milestone nunca creó variantes por índice (CrosslineHuman_1, _2, …). Llegaron hasta el borde del problema y se detuvieron ahí.

Por qué está diseñado así

  1. El catálogo de eventos es vendor-neutral. Esos 203 eventos los comparten los ~800 drivers del Device Pack. Si Hanwha metiera Intrusion_1..8, Axis querría los suyos, Bosch los suyos, y el catálogo explota. El precio de esa normalización es el mínimo común denominador.

  2. El driver apunta al mínimo común denominador de firmware. SchemaBased=True es de SUNAPI CGI 2.6.0 — esta cámara lo tiene, muchas Hanwha viejas en campo no. Un driver del Device Pack tiene que andar en todo el rango de modelos y firmwares, así que usa el evento plano, que existe siempre.

  3. Un solo slot de índice. EventIndex=1 en el binding: la arquitectura del driver contempla un índice, no N zonas simultáneas por tipo de evento.

  4. Los plugins MIP de Hanwha apuntan a otra cosa. Los instalados acá (HanwhaVisionIntercom, HanwhaVisionIPSpeaker, HanwhaVisionVehicleManagement, AISearch*) resuelven intercomunicador, audio, ANPR y búsqueda por IA. Las analíticas se consideran "ya cubiertas" por el driver, aunque sea de forma burda.

  5. Comercialmente, no es la batalla del fabricante. Enrutar zona por zona es una necesidad de integración de sistemas, no un feature de catálogo. Lo que se vende es la IA de detección, no el ruteo de a qué zona pertenece.

Por qué nosotros sí podemos

Milestone tiene que darle soporte a ~800 drivers al mismo tiempo. Nosotros tenemos que darle soporte a uno. Esa diferencia es todo el negocio.

No escribimos un driver de Device Pack: escribimos una integración a medida para esta marca, en este sitio. Eso nos deja hacer tres cosas que un driver genérico jamás se puede permitir:

  • Hablamos SUNAPI directo, sin filtros. Pedimos SchemaBased=True — el parámetro que el driver oficial nunca pide — y la cámara nos entrega la zona exacta donde ocurrió cada intrusión.
  • Definimos nuestros propios tipos de evento. Inyectamos por Analytics Events, con Hanwha Intrusion_1..5, uno por zona. El catálogo de Milestone no tiene ese lujo; el nuestro sí.
  • Nos adaptamos por cámara, no por catálogo. Si un firmware viejo no soporta SchemaBased, lo detectamos al conectar y degradamos solos a evento plano, avisando en el panel. Un driver de fábrica no puede negociar modelo por modelo — nosotros sí, porque es exactamente lo único que hacemos.

Ahí está el negocio, en una frase: el fabricante ya expone el dato hace años; el VMS genérico nunca tuvo dónde ponerlo. Ese hueco no lo cierra una actualización de Milestone — lo cierra una integración construida para llenarlo.

Y no arriesgás nada por el camino. Nuestro evento convive con el IntrusionStart del driver, no lo reemplaza — no hay que tocar ni una regla existente. Van a seguir llegando los dos: el de zona, para las reglas nuevas, y el del driver, de respaldo. Se suma valor, no se saca soporte.