Come configurare l’Alarm Server su una videocamera VIGI

Configuration Guide

Last updated: luglio 29, 2026

Contenuti

Introduzione

La funzione Alarm Server è progettata per ricevere i messaggi evento inviati in modo proattivo da videocamere VIGI e NVR VIGI quando vengono attivati eventi di allarme.

Le informazioni incluse nel report verranno progressivamente arricchite con l’aggiornamento della versione software lato dispositivo e potranno includere tipo di evento, timestamp dell’evento, dettagli del dispositivo e, opzionalmente, un’immagine snapshot dell’evento.

Questa funzione consente un’integrazione fluida tra dispositivi VIGI e sistemi di terze parti per la gestione degli allarmi e l’elaborazione dei processi operativi.

Oltre a descrivere come configurare la funzione Alarm Server sui dispositivi VIGI, questo articolo fornisce anche indicazioni di troubleshooting per possibili problemi, come errori di connessione al server, anomalie nell’invio dei dati da parte del dispositivo ed errori di parsing lato server.

Requisiti

Videocamera/NVR VIGI
Alarm Server
Laptop

Configurazione

Poiché il formato dei messaggi e il processo di parsing utilizzati nell’interazione tra videocamere VIGI e NVR VIGI sono identici, questo articolo utilizza una videocamera VIGI come esempio dimostrativo.

Step 1. Realizzare la topologia seguendo lo schema indicato.

Connect IPC and laptop to the Internet through switch and router as the demo topology diagram.

Nota: la topologia mostrata in questo articolo è solo a scopo esemplificativo. Gli scenari di deployment reali possono essere più diversificati.

Step 2. Accedere all’interfaccia web della videocamera VIGI tramite il relativo indirizzo IP. Inserire Username e Password, quindi cliccare su Log in.

The web login page of the VIGI camera.

Step 3. Accedere a Settings > Event > Alarm Server, quindi cliccare sul pulsante “+Add”.

The configuration page of Alarm Server.

Step 4. Nella finestra pop-up, inserire le informazioni relative al server di terze parti. In questo articolo viene utilizzato https://webhook.site/#!/ come server di riferimento.

The domain and URL of Alarm Server.

Step 5. Inserire Host IP o Domain e URL del server di terze parti, selezionare il protocollo appropriato, HTTP o HTTPS, e specificare il numero di porta corrispondente: porta 80 per HTTP e porta 443 per HTTPS. In questo articolo vengono utilizzati il protocollo HTTP e la porta 80 come esempio di configurazione. È inoltre possibile scegliere se includere un’immagine allegata nel messaggio evento inviato. Infine, cliccare su Save per applicare e salvare la configurazione.

Enter the alarm server’s information.

Nota:
1. Nei parametri di configurazione, Host IP/Domain indica l’indirizzo IP o il nome di dominio del server, che in questo articolo è webhook.site.

2. URL orrisponde al percorso URL utilizzato nei messaggi HTTP scambiati tra dispositivo e server. In questo documento viene utilizzato l’URL predefinito del server (/e499f73b-b773-4721-b6a1-544a8efaef34).

3. Enhanced Alarm Message Service è supportato dopo gli aggiornamenti firmware di IPC e NVR. Dopo l’abilitazione di questa funzione, l’Alarm Server può includere informazioni di allarme più dettagliate nei messaggi inviati, come campi evento avanzati o attributi evento aggiuntivi. Questo consente alle piattaforme di terze parti di ottenere informazioni di allarme più complete per successive elaborazioni.

Tenere presente che, dopo l’abilitazione di questa funzione, il formato del messaggio di allarme potrebbe essere diverso dal formato precedente. Pertanto, se il server di terze parti ha già implementato una logica di parsing dei messaggi di allarme, potrebbe essere necessario modificare le relative regole di parsing.

Per le differenze nel formato dei messaggi di allarme prima e dopo l’abilitazione di questa opzione, consultare la seconda domanda nella sezione FAQ.

Enter the alarm server’s information.

Step 6. Cliccare sul pulsante Test per verificare lo stato della connessione tra dispositivo e server.

Click the “test” button to check the connection status.

Step 7. Quando viene visualizzato il messaggio pop-up “The service is available”, significa che lo stato della connessione è normale e che la funzione opera correttamente. Cliccare su OK per procedere.

Click ok to finish the configuration.

Step 8. Accedere a Settings > Event > Smart Event > Human Detection e abilitare la funzione di rilevamento persone.

Enable human detection.

Nota: questo articolo utilizza Human Detection come esempio dimostrativo. Le altre funzioni di rilevamento evento avranno effetto nello stesso modo.

Step 9. Nella processing mode, selezionare Send to Alarm Server. Infine, cliccare su Apply.

Select the Send to Alarm Sever under processing mode.

Verifiche

Step 1. Configurare il port mirroring sullo switch per duplicare la porta collegata alla videocamera VIGI sulla porta collegata al laptop. Avviare la cattura dei pacchetti sull’interfaccia di rete del laptop utilizzando Wireshark, quindi attivare l’evento Human Detection.

Step 2. Verificare le informazioni inviate dalla videocamera VIGI.

Scenario 1. Senza immagine allegata

Step 1. Utilizzare il comando/filtro http per filtrare i pacchetti catturati. Quindi controllare HTTP POST Request e HTTP Response.

Use http command to filter the packages.

Step 2. Controllare gli header della richiesta HTTP POST.

Http post request headers.

Nota: la prima riga contiene il metodo POST, l’URI di destinazione della richiesta e la versione HTTP 1.1. L’URI corrisponde alla stringa URL configurata in precedenza nelle impostazioni dell’Alarm Server.

Dalla seconda riga fino alla riga vuota, ogni riga rappresenta una coppia chiave-valore che descrive i metadati della richiesta. Questi includono Host, Content-Type, Content-Length e Cache-Control.

Quando Content-Type è impostato su application/json, significa che viene inviato solo il messaggio evento, senza immagine allegata, e che il corpo della richiesta è una stringa in formato JSON.

Ogni riga termina con \r\n. Una riga vuota composta solo da \r\n indica la fine degli header della richiesta e l’inizio del corpo della richiesta.

Step 3. Controllare il corpo della richiesta HTTP POST.

Http post request body.

Nota: nel payload JSON, ip rappresenta l’indirizzo IP dell’IPC che invia il messaggio evento, mentre MAC rappresenta l’indirizzo MAC dell’IPC che effettua l’invio. Il campo protocol indica se la comunicazione utilizza il protocollo HTTP o HTTPS. Il campo device_name specifica il nome dell’IPC che invia l’evento.

All’interno di event_list, ogni voce rappresenta un evento incluso nel report, indicando l’orario in cui si è verificato e il nome dell’evento corrispondente.

Step 4. Controllare la HTTP Response. Il codice di stato 200 OK indica che il server webhook.site ha ricevuto ed elaborato correttamente la richiesta.

Http response status code 200.

Step 5. Confrontare i dati inviati nel corpo della richiesta HTTP POST con i dati ricevuti e analizzati dal server webhook.site, per verificare che siano coerenti.

Verify whether the server’s parsing results are correct.

Scenario 2. Con immagine allegata

Step 1. Prima di avviare la cattura dei pacchetti, cliccare sul pulsante Edit nell’angolo in alto a destra della pagina del server webhook.site e modificare il Content-Type per i messaggi con immagini allegate in: multipart/form-data; boundary=ReportEventBoundary.

Change the content type.

Nota: multipart/form-data indica dati misti contenenti sia una stringa JSON sia dati immagine. boundary=ReportEventBoundary specifica il delimitatore utilizzato per separare le diverse parti del payload dati.

Step 2. Utilizzare il comando/filtro http per filtrare i pacchetti catturati. Quindi controllare gli header e il corpo della richiesta HTTP POST.

Http post request headers and body.

Nota: il corpo della richiesta inizia dopo una riga vuota (\r\n). Poiché il Content-Type è multipart/form-data, il corpo è suddiviso in più parti, ciascuna separata dal boundary --ReportEventBoundary. Il corpo della richiesta termina con --ReportEventBoundary--.

La prima parte contiene i dati evento JSON, mentre la seconda parte contiene i dati dell’immagine JPEG. Il campo name indica il timestamp dell’immagine, image/jpeg specifica che questa parte contiene dati immagine JPEG, mentre Content-Length indica la dimensione dei dati immagine.

JPEG DATA rappresenta il contenuto binario dell’immagine JPEG.

Step 3. Controllare la HTTP Response. Il codice di stato 200 OK indica che il server webhook.site ha ricevuto ed elaborato correttamente la richiesta.

Http response status code 200.

Step 4. Confrontare i dati inviati nel corpo della richiesta HTTP POST con i dati ricevuti e analizzati dal server webhook.site, per verificare che siano coerenti.

Verify whether the server’s parsing results are correct.

Nota: il server webhook.site non esegue direttamente il parsing o la decodifica del contenuto dell’immagine caricata. Riceve e visualizza soltanto i dati della richiesta HTTP. Pertanto, saranno visibili solo le informazioni evento e il timestamp dell’immagine corrispondente.

Conclusioni

La funzione Alarm Server è stata configurata correttamente e, quando viene attivato un evento, il messaggio evento e l’immagine snapshot vengono inviati con successo.

Per maggiori informazioni su ogni funzione e configurazione, visitare Support Home per scaricare o consultare il manuale del proprio prodotto.

FAQ

Q1: Se l’Alarm Server è stato configurato correttamente ma il server non riceve dati di allarme quando viene attivato un evento, cosa devo fare?

A1: Eseguire le seguenti verifiche:

Step 1. Effettuare un controllo preliminare della configurazione. Esaminare i log del dispositivo per confermare che l’evento sia stato effettivamente rilevato e attivato e che Send to Alarm Server sia abilitato nelle impostazioni. Allo stesso tempo, verificare tutti i parametri di configurazione dell’Alarm Server sul dispositivo, prestando particolare attenzione al fatto che la porta configurata sia effettivamente in ascolto sul server e che l’URL corrisponda esattamente all’endpoint in ascolto del server.

Step 2. Configurare il port mirroring ed eseguire la cattura dei pacchetti lato dispositivo, quindi controllare in sequenza i seguenti elementi:

TCP Connection: verificare se il three-way handshake TCP tra dispositivo e server viene stabilito correttamente.
HTTP POST Request: confermare che la richiesta POST venga avviata correttamente e che il formato degli header sia corretto. Prestare particolare attenzione al campo Content-Type. Quando vengono inviate solo le informazioni evento, Content-Type deve essere application/json. Quando è inclusa un’immagine snapshot, Content-Type deve essere multipart/form-data e i dati misti, cioè stringa JSON e dati immagine, devono essere separati utilizzando boundary=ReportEventBoundary.
HTTP Response: controllare il codice di stato della risposta HTTP restituito nel pacchetto per confermare se il server risponde correttamente alla richiesta HTTP.

Q2: Qual è la differenza nel formato del messaggio di allarme prima e dopo l’abilitazione di Enhanced Alarm Message Service?

A2: Dopo l’abilitazione di Enhanced Alarm Message Service, il formato del messaggio dell’Alarm Server viene ottimizzato per includere informazioni di allarme più dettagliate. Se il server di terze parti ha già implementato una logica di parsing dei messaggi di allarme basata sul formato precedente, verificare e modificare di conseguenza la logica di parsing.

1. Per VIGI IPC, le principali differenze sono le seguenti:
(1) Ottimizzazione dell'header del messaggio
Dopo l’abilitazione di Enhanced Alarm Message Service, viene aggiunto il campo filename in multipart/form-data. Questo campo viene utilizzato per identificare il nome file dell’immagine snapshot caricata con il messaggio di allarme, migliorando la compatibilità con server di terze parti durante il parsing e il salvataggio delle immagini di allarme.

(2) Ottimizzazione del corpo del messaggio
Dopo l’abilitazione di Enhanced Alarm Message Service, le informazioni di base del dispositivo nel messaggio di allarme, inclusi ip, mac, protocol e device_name, rimangono invariate. La principale ottimizzazione riguarda la struttura di event_list: ogni evento viene ora descritto come un oggetto evento indipendente e vengono aggiunte informazioni di allarme più dettagliate, come videocamera/canale attivato, orario dell’evento, informazioni su area o linea, direzione di attraversamento linea, numero di oggetti e coordinate della posizione dell’oggetto. Consultare la tabella seguente per i dettagli.

Prima dell'abilitazione di Enhanced Alarm Message Service:

Property	Description	Value
ip	Device IP address	ip: {Device IP Address}
mac	Device MAC address	mac: {Device MAC Address}
protocol	Alarm Server protocol	protocol: {Protocol}
device_name	Device name	device_name: {Device Name}
event_list	Event list	Includes the event timestamp and triggered event type list, such as dateTime: {YYYYMMDDHHMMSS} and event_type: [{Event Type 1}, {Event Type 2}].

Dopo l'abilitazione di Enhanced Alarm Message Service:

Property	Description	Value
ip	Device IP address	ip: {Device IP Address}
mac	Device MAC address	mac: {Device MAC Address}
protocol	Alarm Server protocol	protocol: {Protocol}
device_name	Device name	device_name: {Device Name}
event_list	Event list	Each event is described as an independent object.
camera	Triggered camera/channel	camera: {Camera Number}
dateTime	Event timestamp	dateTime: {YYYY-MM-DD HH:MM:SS}
event_type	Triggered event type	event_type: {Event Type}
extra_text	Additional alarm information	Includes extended event information based on the event type and rule configuration.
region_id	Triggered region or line	For region-based events: region_id: {Triggered Region Number}. For line-crossing events: region_id: {Triggered Line Number}.
direction	Line-crossing direction	For line-crossing events: direction: {Direction Description}.
obj_num	Number of detected objects	For events with human/vehicle targets: obj_num: {Object Number}.
obj_rect_info	Object position coordinates	For events with human/vehicle targets: obj_rect_info: {Object Position Coordinates}.

2. Per VIGI NVR, dopo l'abilitazione di Enhanced Alarm Message Service, il formato del messaggio dell’Alarm Server viene ottimizzato principalmente modificando i nomi dei campi, in modo da rendere le informazioni di allarme più chiare e facili da comprendere. Il formato ottimizzato aggiunge il campo Extra Text, riservato alle informazioni di allarme estese. Consultare la tabella seguente per i dettagli.

Prima dell'abilitazione di Enhanced Alarm Message Service:

Property	Description	Value
type	Triggered event type	event_type: {Event Type}
sub_type	Triggered event subtype	event_sub_type: {Event Sub Type}
localtime	Event timestamp	datetime: {YYYY-MM-DD HH:MM:SS}
channel	Triggered channel	camera_number: {Camera Number}
channel_name	Triggered channel name	camera_name: {Camera Name}

Dopo l'abilitazione di Enhanced Alarm Message Service:

Property	Description	Value
Event Type	Triggered event type	event_type: {Event Type}
Event Sub Type	Triggered event subtype	event_sub_type: {Event Sub Type}
EVENT TIME	Event timestamp	datetime: {YYYY-MM-DD HH:MM:SS}
Camera	Triggered channel	camera_number: {Camera Number}
Camera Name	Triggered channel name	camera_name: {Camera Name}
Extra Text	Additional information	The default value is None. Reserved for extension.