Comment configurer le serveur d'alarmes sur une caméra VIGI

Sommaire

Introduction

Prérequis

Configuration

Vérification

Conclusion

Questions/Réponses

Introduction

La fonctionnalité Serveur d'alarme est conçue pour recevoir les messages d'événements envoyés de manière proactive par les caméras VIGI et les NVR VIGI lorsqu'un événement d'alarme est déclenché.

Les informations incluses dans le rapport seront progressivement enrichies au fur et à mesure de la mise à jour des versions logicielles des appareils, notamment avec le type d'événement, l'horodatage de l'événement, les détails du périphérique et une image instantanée facultative de l'événement.

Cette fonctionnalité permet une liaison transparente des alarmes et un traitement métier entre les appareils VIGI et les systèmes tiers.

En plus de décrire comment configurer la fonction Serveur d'alarme sur les appareils VIGI, cet article fournit également des recommandations de dépannage pour les problèmes potentiels, tels que les échecs de connexion au serveur, les rapports de données anormaux des appareils et les erreurs d'analyse côté serveur.

Prérequis

• Caméra/NVR VIGI
• Serveur d'alarme
• Ordinateur portable

Configuration

Comme le format des messages et le processus d'analyse utilisés lors de l'interaction entre les caméras VIGI et les NVR VIGI sont identiques, cet article utilise une caméra VIGI comme exemple de démonstration.

Étape 1. Construisez la topologie conformément au schéma de topologie ci-dessous.

Remarque : La topologie présentée dans cet article est fournie uniquement à titre indicatif. Les scénarios de déploiement réels sont plus variés.

Étape 2. Connectez-vous à l'interface Web de la caméra VIGI avec son adresse IP. Saisissez le nom d'utilisateur et le mot de passe, puis cliquez sur Connexion.

Étape 3. Accédez à Paramètres > Événement > Serveur d'alarme, puis cliquez sur le bouton « +Ajouter ».

Étape 4. Dans la fenêtre contextuelle, saisissez les informations relatives au serveur tiers. Dans cet article, https://webhook.site/#!/ est utilisé comme serveur de référence.

Étape 5. Saisissez l’adresse IP de l’hôte ou le domaine du serveur tiers ainsi que son URL, sélectionnez le protocole approprié (HTTP ou HTTPS) et indiquez le numéro de port correspondant (port 80 pour HTTP et port 443 pour HTTPS). Dans cet article, le protocole HTTP et le port 80 sont utilisés pour la démonstration de configuration. Vous pouvez également choisir d’inclure ou non une image jointe dans le message d’événement envoyé. Enfin, cliquez sur Enregistrer afin d’appliquer et de sauvegarder la configuration.

Remarque :
1. Dans les paramètres de configuration, l’adresse IP de l’hôte/le domaine correspond à l’adresse IP ou au nom de domaine du serveur, qui est dans cet article webhook.site.

2. L’URL correspond au chemin URL utilisé dans les messages HTTP échangés entre l’appareil et le serveur. Dans ce document, l’URL par défaut du serveur (/e499f73b-b773-4721-b6a1-544a8efaef34) est utilisée.

3. Service amélioré de messages d’alarme est pris en charge après les mises à jour du micrologiciel des IPC et des NVR. Après activation de cette fonction, le Serveur d’alarme peut inclure des informations d’alarme plus détaillées dans les messages d’alarme transmis, telles que des champs liés aux événements améliorés ou des attributs supplémentaires. Cela permet aux plateformes tierces d’obtenir des informations d’alarme plus riches pour un traitement ultérieur.

Veuillez noter qu’après l’activation de cette fonction, le format des messages d’alarme peut être différent du format précédent. Par conséquent, si votre serveur tiers dispose déjà d’une logique d’analyse des messages d’alarme, vous devrez peut-être ajuster les règles d’analyse correspondantes.

Pour connaître les différences du format des messages d’alarme avant et après l’activation de cette option, consultez la deuxième question-réponse dans la section Questions/Réponses.

Étape 6. Vous pouvez cliquer sur le bouton « Tester » afin de vérifier l’état de la connexion entre l’appareil et le serveur.

Étape 7. Lorsqu’un message contextuel affiche « Le service est disponible », cela indique que l’état de la connexion est normal et que la fonction fonctionne correctement. Cliquez sur OK pour continuer.

Étape 8. Accédez à Paramètres > Événement > Événement intelligent > Détection humaine, puis activez la fonction de détection humaine.

Remarque : Cet article utilise la détection humaine comme exemple de démonstration. Les autres fonctions de détection d’événements fonctionneront également de la même manière.

Étape 9. Dans le mode de traitement, veuillez sélectionner « Envoyer au Serveur d’alarme ». Enfin, cliquez sur Appliquer.

Vérification

Étape 1. Configurez la mise en miroir des ports sur le commutateur afin de refléter le port connecté à la caméra VIGI vers le port connecté à l’ordinateur portable. Lancez ensuite une capture de paquets sur l’interface réseau de l’ordinateur portable à l’aide de Wireshark, puis déclenchez l’événement de détection humaine.

Étape 2. Vérifiez les informations envoyées par la caméra VIGI.

Scénario 1. Sans image jointe

Étape 1. Utilisez la commande « http » pour filtrer les paquets capturés. Vérifiez ensuite la requête HTTP POST et la réponse HTTP.

Étape 2. Vérifiez les en-têtes de la requête HTTP POST.

Remarque : La première ligne contient la méthode POST, l’URI cible de la requête et la version HTTP 1.1. L’URI correspond à la chaîne URL configurée précédemment dans les paramètres du Serveur d’alarme.

À partir de la deuxième ligne jusqu’à la ligne vide, chaque ligne représente une paire clé-valeur décrivant les métadonnées de la requête. Celles-ci comprennent notamment Host, Content-Type, Content-Length et Cache-Control.

Lorsque Content-Type est défini sur application/json, cela indique que seul le message d’événement est envoyé (sans image jointe) et que le corps de la requête est une chaîne au format JSON.

Chaque ligne se termine par \r\n. Une ligne vide composée uniquement de \r\n indique la fin des en-têtes de la requête et le début du corps de la requête.

Étape 3. Vérifiez le corps de la requête HTTP POST.

Remarque : Dans la charge utile JSON, ip représente l’adresse IP de l’IPC qui transmet le message d’événement, et MAC représente l’adresse MAC de l’IPC émetteur. Le champ protocol indique si la communication utilise le protocole HTTP ou HTTPS. Le champ device_name indique le nom de l’IPC qui transmet l’événement.

Dans event_list, chaque entrée représente un événement inclus dans le rapport, en indiquant l’heure d’occurrence de l’événement et le nom d’événement correspondant.

Étape 4. Vérifiez la réponse HTTP. Un code d’état 200 OK retourné indique que le serveur webhook.site a reçu et traité la requête avec succès.

Étape 5. Comparez les données envoyées dans le corps de la requête HTTP POST avec les données reçues et analysées par le serveur webhook.site afin de vérifier qu’elles sont cohérentes.

Scénario 2. Avec image jointe

Étape 1. Avant de commencer la capture des paquets, cliquez sur le bouton Modifier situé dans l’angle supérieur droit de la page du serveur webhook.site, puis modifiez le Content-Type des messages contenant des images jointes en multipart/form-data; boundary=ReportEventBoundary.

Remarque : multipart/form-data indique des données mixtes contenant à la fois une chaîne JSON et des données d’image. boundary=ReportEventBoundary définit la limite utilisée pour séparer les différentes parties de la charge utile.

Étape 2. Utilisez la commande « http » pour filtrer les paquets capturés. Vérifiez ensuite les en-têtes et le corps de la requête HTTP POST.

Remarque : Le corps de la requête commence après une ligne vide (\r\n). Comme le Content-Type est multipart/form-data, le corps est divisé en plusieurs parties, chacune séparée par la limite --ReportEventBoundary. Le corps de la requête se termine par --ReportEventBoundary--.

La première partie contient les données JSON de l’événement et la deuxième partie contient les données de l’image JPEG. Le champ name indique l’horodatage de l’image, image/jpeg indique que cette partie contient des données d’image JPEG et Content-Length indique la taille des données de l’image.

JPEG DATA représente le contenu binaire de l’image JPEG.

Étape 3. Vérifiez la réponse HTTP. Un code d’état 200 OK retourné indique que le serveur webhook.site a reçu et traité la requête avec succès.

Étape 4. Comparez les données envoyées dans le corps de la requête HTTP POST avec les données reçues et analysées par le serveur webhook.site afin de vérifier qu’elles sont cohérentes.

Remarque : Le serveur webhook.site ne procède pas lui-même à l’analyse ou au décodage du contenu de l’image envoyée. Il reçoit et affiche uniquement les données de la requête HTTP. Par conséquent, seules les informations relatives à l’événement et l’horodatage correspondant de l’image sont visibles.

Conclusion

Vous avez configuré avec succès la fonctionnalité Serveur d’alarme. Lorsqu’un événement est déclenché, le message d’événement ainsi que l’image instantanée sont correctement transmis.

Pour en savoir plus sur chaque fonction et configuration, veuillez consulter la page Accueil du support afin de télécharger ou consulter le manuel correspondant à votre produit.

Questions/Réponses

Q1 : Si le Serveur d’alarme a été correctement configuré mais qu’aucune donnée d’alarme n’est reçue par le serveur lorsqu’un événement est déclenché, que dois-je faire ?

R1 : Veuillez effectuer les vérifications suivantes :

Étape 1. Effectuez une première vérification de configuration. Consultez les journaux de l’appareil afin de confirmer que l’événement a bien été détecté et déclenché, et que l’option Envoyer au Serveur d’alarme est activée dans les paramètres. Vérifiez également tous les paramètres de configuration du Serveur d’alarme sur l’appareil, en portant une attention particulière au fait que le port configuré soit bien écouté par le serveur et que l’URL corresponde exactement au point d’accès d’écoute du serveur.

Étape 2. Configurez la mise en miroir des ports et capturez les paquets du côté de l’appareil, puis vérifiez successivement les éléments suivants :

• Connexion TCP : Vérifiez si la négociation en trois étapes TCP entre l’appareil et le serveur est correctement établie.
• Requête HTTP POST : Confirmez que la requête POST est initiée correctement et que le format des en-têtes de requête est valide. Portez une attention particulière au champ Content-Type. Lorsque seules les informations d’événement sont transmises, le Content-Type doit être application/json. Lorsqu’une image instantanée est incluse, le Content-Type doit être multipart/form-data, et les données mixtes (chaîne JSON et données d’image) doivent être séparées à l’aide de boundary=ReportEventBoundary.
• Réponse HTTP : Vérifiez le code d’état HTTP retourné dans le paquet afin de confirmer que le serveur répond correctement à la requête HTTP.

Q2 : Quelle est la différence entre le format des messages d’alarme avant et après l’activation du Service amélioré de messages d’alarme ?

R2 : Après activation du Service amélioré de messages d’alarme, le format des messages du Serveur d’alarme est optimisé afin d’inclure des informations d’alarme plus détaillées. Si votre serveur tiers possède déjà une logique d’analyse basée sur l’ancien format, veuillez vérifier et modifier cette logique d’analyse en conséquence.

1. Pour les IPC VIGI, les principales différences sont les suivantes :
(1) Optimisation de l’en-tête du message
Après activation du Service amélioré de messages d’alarme, le champ filename est ajouté dans multipart/form-data. Ce champ permet d’identifier le nom du fichier de l’image instantanée envoyée avec le message d’alarme, améliorant ainsi la compatibilité avec les serveurs tiers lors de l’analyse et de l’enregistrement des images d’alarme.
(2) Optimisation du corps du message

Après activation du Service amélioré de messages d’alarme, les informations de base du périphérique dans le message d’alarme, notamment ip, mac, protocol et device_name, restent inchangées. L’optimisation principale concerne la structure de event_list : chaque événement est désormais décrit comme un objet événement indépendant, et des informations d’alarme plus détaillées sont ajoutées, telles que la caméra/le canal déclenché, l’heure de l’événement, la région ou la ligne concernée, la direction de franchissement de ligne, le nombre d’objets et les coordonnées de position des objets. Consultez le tableau ci-dessous pour plus de détails.
Avant activation du Service amélioré de messages d’alarme :

Après activation du Service amélioré de messages d’alarme :