PotoP API Translator

Un flux s’ouvre en trois parties : la requête exactement telle que l’autre système l’a envoyée (méthode, URL, corps), les étapes PotoP — chaque appel REST avec son chemin, son code d’état et les millisecondes qu’il a pris — et la réponse renvoyée dans le format propre de l’autre système. Le résultat est l’un de ok, error, refused ou unsupported, et c’est ce que les compteurs additionnent. Ce détail est le moyen le plus rapide d’apprendre ce qu’une commande d’un fabricant fait réellement sur PotoP ; c’est pourquoi le banc d’essai ouvre la même vue pour les commandes que vous envoyez vous-même.

La liaison demande à PotoP VMS Studio un jeton d’API portant le nom du traducteur, avec un jeu de droits prédéfini, créé au nom de l’administrateur qui a appuyé sur le bouton ; le jeton est stocké chiffré et peut être révoqué ici ou dans le VMS. La même page montre le flux d’événements que le traducteur garde ouvert pour numéroter chaque événement PotoP, le certificat qu’il présente sur chaque port (celui du serveur VMS lui-même, suivi à travers ses renouvellements, ou un certificat provisoire qu’il a créé lui-même) et, pour chaque type de connecteur, s’il est prêt, combien sont configurés, ou qu’il n’est pas encore construit.

Il n’y a aucune liste d’utilisateurs dans le traducteur. Le formulaire de connexion s’adresse à la connexion du VMS lui-même, respecte la connexion en deux étapes, puis vérifie que le compte est administrateur ; tout autre compte est refusé en toutes lettres. La session est un cookie strict pour ce navigateur, d’une durée glissante de trente minutes ; chaque modification porte un en-tête CSRF, et huit tentatives échouées depuis une même adresse en cinq minutes mettent cette adresse en pause. La page est servie avec le certificat du serveur PotoP, et un navigateur qui ouvre localhost est redirigé vers un nom pour lequel le certificat a été émis.

Le traducteur présente le certificat du serveur VMS sur chaque port de connecteur et suit ses renouvellements : l’adresse indiquée sous Général fonctionne en HTTPS dès qu’elle est saisie dans le PLC ou le système de gestion. Les ports sont des étiquettes : un second port — 443 ou 80 pour un système qui ne peut pas en recevoir d’autre — s’ajoute sans redémarrage, et les ports utilisés par le serveur PotoP lui-même sont refusés avec le motif. Supprimer ce connecteur demande une confirmation et s’inscrit dans le journal d’activité à votre nom.

Ajouter un compte génère un mot de passe de dix-huit caractères affiché une seule fois ; seul un hachage scrypt est conservé, vérifié à côté de la boucle principale du service avec une courte mémorisation, de sorte qu’un système qui se connecte à chaque requête ne coûte rien de plus. Dix mots de passe erronés mettent ce nom en pause depuis cette adresse pendant cinq minutes. Autoriser le HTTP en clair ouvre un avertissement que vous devez accepter en votre nom, et le HTTPS continue de fonctionner sur le même port. Les groupes en dessous sont les autorisations par connecteur : une commande dont le groupe est désactivé est refusée dans le vocabulaire propre de l’autre système ; Modifier les paramètres est désactivé par défaut.

Une intégration Sense désigne un serveur par un long numéro et une caméra par un identifiant d’appareil, tous deux issus de l’installation remplacée. La table de correspondance donne à chaque paire sa caméra PotoP ; sans correspondance, l’identifiant d’appareil est pris comme numéro de caméra PotoP, et une caméra associée n’est joignable que sous son numéro associé. Les commandes qui ont nommé un numéro inconnu ne sont pas devinées : le numéro est collecté dans la liste en dessous, avec sa fréquence et sa dernière occurrence, et Associer… en démarre une ligne de correspondance — laissez l’autre système tourner une minute et la liste dit ce qu’il attend encore.

ICX parle en numéros d’appel, numéros de sortie et d’entrée, numéros de caméra et de moniteur. Un numéro d’appel est le poste PotoP VoIP du même numéro, sauf correspondance ; une sortie devient réelle lorsqu’une macro PotoP est désignée pour la mise en marche et l’arrêt ; une entrée est impulsée par un type d’événement PotoP, éventuellement d’une seule caméra, pendant un certain nombre de secondes ; un moniteur est une disposition PotoP et le panneau où la caméra est placée. Sous les tableaux, le connecteur liste les paires tâche/type qu’il a reçues sans gestionnaire, pour qu’une fonction manquante soit vue plutôt que devinée.

Le connecteur répond à l’API de configuration de Milestone avec ses propres identifiants, stables d’un redémarrage à l’autre. Une intégration qui recherche les caméras, les sorties ou les types d’événements par leur nom fonctionne donc sans changement ; celle qui a été programmée avec les GUID de l’ancienne installation XProtect les épingle ici, chacun à l’objet PotoP qui l’a remplacé, le type d’identifiant étant choisi parmi caméras, matériel, serveurs d’enregistrement, sorties, événements d’entrée, événements définis par l’utilisateur, types d’événements, vues, utilisateurs de base et rôles. Les sorties reçoivent un numéro, un nom et une macro PotoP, pour que leur déclenchement commute réellement quelque chose.

PotoP est un système vidéo, et la page le dit sans détour : les alarmes atterrissent dans le registre des alarmes de PotoP avec un identifiant d’instance égal au numéro d’alarme PotoP, la protection vidéo est une conservation d’images, l’enregistrement est l’enregistrement manuel de PotoP, les événements sont publiés sous les noms de Security Center. Le contrôle d’accès, l’intrusion, la patrouille LPR et le stationnement n’ont pas d’équivalent — leurs entités sont conservées, leurs rapports répondent Ok avec une liste vide, leurs actions répondent Fail avec un message qui en donne la raison — et rien n’est jamais présenté comme accompli alors qu’il ne l’est pas.

Chaque famille porte ses codes de tâche et de type ICX sous son nom, pour qu’un ingénieur protocole puisse chercher directement 40/80 ou 80/AC. Presque chaque famille devient une opération du point de terminaison de commande d’interphonie du VMS — call, hangup, dtmf, busy, privacy, page, conference, output, input, door code, request, desk — et la note dit ce qui diffère : confidentialité respectée par appel, mode simplex rapporté mais non imposé, un canal radio comme salle de conférence. Les familles conservées sont les parties que seul un poste Commend possède, que PotoP stocke par poste et rapporte comme un événement.

Les 75 lignes couvrent les points de terminaison de connexion, les WebSockets d’événements et de messagerie, les alarmes, les signets, les verrous de preuve, WebRTC et chaque type de ressource de configuration de la MIP VMS API publiée. Les lignes complètes s’appuient sur PotoP (caméras, serveurs d’enregistrement, sorties, événements définis par l’utilisateur en tant que macros, vues en tant que dispositions, utilisateurs de base et rôles en tant que vrais utilisateurs et groupes) ; les lignes conservées stockent ce que l’autre système crée et le lui rendent avec leurs propres identifiants ; et chaque tâche que PotoP ne peut pas accomplir — tronquer le stockage, changer le mot de passe d’un appareil, remplacer du matériel — est indiquée comme répondue par une erreur plutôt que par un faux succès.

Le Web SDK reçoit ses réponses dans sa propre syntaxe d’appel de méthode q=, en JSON ou en XML, sous la forme moderne ou héritée selon l’en-tête Accept. Les entités proviennent des caméras, serveurs, utilisateurs, groupes, macros et de l’état d’interphonie de PotoP, avec un identifiant logique égal au numéro PotoP ; les méthodes caméra, le PTZ, les sorties, les tuiles et les alarmes correspondent aux appels affichés ; le flux d’événements transporte le flux de PotoP sous 37 noms d’événements Security Center. Les lignes du contrôle d’accès, de l’intrusion, du LPR et du stationnement sont les lignes honnêtes : entités conservées, rapports vides et actions qui échouent avec un motif.

ICX est binaire : le banc propose donc chaque famille de commandes avec des exemples travaillés dont vous remplacez les numéros par les vôtres, affiche le message hexadécimal qu’il va envoyer et décode chaque trame de réponse en mots clairs, à côté des appels PotoP qui l’ont produite. La deuxième partie simule ce qui se passe dans PotoP VoIP — un appel sonne, est pris, se termine, un poste se déconnecte, une sortie commute, une demande d’appel est émise — et affiche les messages d’état ICX que le connecteur émettrait ; ils n’atteignent le système raccordé que si la case est cochée, et cela s’inscrit dans le journal d’activité. La troisième partie est le fil en direct, chaque trame entrante et sortante.

Le journal est la table d’audit propre au traducteur, conservée à côté du journal des événements dans son fichier SQLite : connexions à la console avec leur adresse, chaque modification de connecteur avec le champ et la personne, connexions refusées d’autres systèmes une fois par adresse, nom et motif en cinq minutes, clients ICX refoulés, et chaque message d’état que le banc a poussé vers un système en production. Ce que le jeton du traducteur a fait sur le VMS est consigné là aussi, dans la piste d’audit de PotoP sous le nom du jeton : les deux registres ensemble disent qui a fait quoi, de quel côté.