PotoP API Translator

Un flusso si apre in tre parti: la richiesta esattamente come l’ha inviata l’altro sistema (metodo, URL, corpo), i passi PotoP — ogni chiamata REST con percorso, codice di stato e millisecondi impiegati — e la risposta tornata indietro nel formato dell’altro sistema. L’esito è uno tra ok, error, refused o unsupported, ed è ciò che i contatori sommano. Il dettaglio è il modo più rapido per capire che cosa fa davvero su PotoP il comando di un produttore, ed è per questo che il banco di prova apre la stessa vista per i comandi che invii tu stesso.

Il collegamento chiede a PotoP VMS Studio un token API intitolato al traduttore, con un insieme fisso di diritti, creato a nome dell’amministratore che ha premuto il pulsante; il token viene conservato crittografato e può essere revocato qui o nel VMS. La stessa pagina mostra il feed eventi che il traduttore tiene aperto per numerare ogni evento PotoP, il certificato che presenta su ogni porta (quello del server VMS stesso, seguito attraverso i rinnovi, oppure uno provvisorio creato da sé) e, per ogni tipo di connettore, se è pronto, quanti ne sono configurati, o che non è ancora stato realizzato.

Nel traduttore non c’è alcun elenco utenti. Il modulo di accesso si rivolge al login del VMS stesso, rispetta l’accesso in due passaggi e poi verifica che l’account sia un amministratore; chiunque altro viene rifiutato a chiare lettere. La sessione è un cookie strict per questo browser con una durata scorrevole di trenta minuti, ogni modifica porta un’intestazione CSRF, e otto tentativi falliti da uno stesso indirizzo in cinque minuti mettono in pausa quell’indirizzo. La pagina è servita con il certificato del server PotoP, e un browser che apre localhost viene reindirizzato a un nome per cui il certificato è stato emesso.

Il traduttore presenta il certificato del server VMS su ogni porta di connettore e ne segue i rinnovi, così l’indirizzo indicato in Generale funziona in HTTPS dal momento in cui viene digitato nel PLC o nel sistema di gestione. Le porte sono etichette: una seconda — 443 o 80 per un sistema a cui non se ne può assegnare un’altra — si aggiunge senza riavvio, e le porte usate dal server PotoP stesso vengono rifiutate con il motivo. Rimuovi questo connettore chiede una conferma e viene scritto nel registro attività a tuo nome.

Aggiungi account genera una password di diciotto caratteri mostrata una sola volta; viene conservato solo un hash scrypt, verificato accanto al ciclo principale del servizio con una breve memoria, così un sistema che accede a ogni richiesta non costa nulla in più. Dieci password errate mettono in pausa quel nome da quell’indirizzo per cinque minuti. Consenti HTTP in chiaro apre un avviso che devi accettare a tuo nome, e l’HTTPS continua a funzionare sulla stessa porta. I gruppi sottostanti sono le autorizzazioni per connettore: un comando il cui gruppo è disattivato viene rifiutato nel vocabolario dell’altro sistema; Modifica impostazioni è disattivato per impostazione predefinita.

Un’integrazione Sense indica un server con un numero lungo e una telecamera con un id dispositivo, entrambi provenienti dall’installazione sostituita. La mappa assegna a ogni coppia la sua telecamera PotoP; senza una mappatura l’id dispositivo viene preso come numero della telecamera PotoP, e una telecamera mappata è raggiungibile solo con il suo numero mappato. I comandi che hanno indicato un numero sconosciuto non vengono indovinati: il numero viene raccolto nell’elenco sottostante con la frequenza e l’ultima occorrenza, e Mappa… avvia da lì una riga di mappatura — lascia girare l’altro sistema per un minuto e l’elenco dice che cosa si aspetta ancora.

ICX parla in numeri di chiamata, numeri di uscita e ingresso, numeri di telecamera e monitor. Un numero di chiamata è l’interno PotoP VoIP con lo stesso numero, salvo mappatura; un’uscita diventa reale quando viene indicata una macro PotoP per l’accensione e lo spegnimento; un ingresso viene impulsato da un tipo di evento PotoP, eventualmente di una sola telecamera, per un certo numero di secondi; un monitor è un layout PotoP e il riquadro in cui viene messa la telecamera. Sotto le tabelle il connettore elenca le coppie task/type che ha ricevuto e per cui non ha un gestore, così una funzione mancante viene vista anziché indovinata.

Il connettore risponde all’API di configurazione di Milestone con id propri, stabili tra un riavvio e l’altro. Un’integrazione che cerca telecamere, uscite o tipi di evento per nome funziona quindi senza modifiche; una programmata con i GUID della vecchia installazione XProtect li fissa qui, ciascuno all’oggetto PotoP che l’ha sostituito, con il tipo di id scelto tra telecamere, hardware, server di registrazione, uscite, eventi di ingresso, eventi definiti dall’utente, tipi di evento, viste, utenti base e ruoli. Le uscite ricevono un numero, un nome e una macro PotoP, così che attivarne una commuti davvero qualcosa.

PotoP è un sistema video, e la pagina lo dice chiaramente: gli allarmi finiscono nel registro allarmi di PotoP con l’id istanza uguale al numero di allarme PotoP, la protezione video è un blocco delle riprese, la registrazione è la registrazione manuale di PotoP, gli eventi vengono pubblicati con i nomi di Security Center. Controllo accessi, antintrusione, pattuglia LPR e parcheggio non hanno un corrispettivo — le loro entità vengono conservate, i loro report rispondono Ok con un elenco vuoto, le loro azioni rispondono Fail con un messaggio che ne spiega il motivo — e nulla viene mai fatto passare per avvenuto.

Ogni famiglia porta i suoi codici task e type ICX sotto il nome, così un ingegnere di protocollo può cercare direttamente 40/80 o 80/AC. Quasi ogni famiglia diventa una op dell’endpoint di comando citofonico del VMS — call, hangup, dtmf, busy, privacy, page, conference, output, input, door code, request, desk — e la nota dice che cosa cambia: privacy rispettata per chiamata, modalità simplex riportata ma non imposta, un canale radio come stanza di conferenza. Le famiglie conservate sono le parti che solo una postazione Commend possiede, che PotoP memorizza per postazione e riporta come evento.

Le 75 righe coprono gli endpoint di accesso, i WebSocket di eventi e messaggistica, allarmi, segnalibri, blocchi delle prove, WebRTC e ogni tipo di risorsa di configurazione della MIP VMS API pubblicata. Le righe complete poggiano su PotoP (telecamere, server di registrazione, uscite, eventi definiti dall’utente come macro, viste come layout, utenti base e ruoli come veri utenti e gruppi); le righe conservate memorizzano ciò che l’altro sistema crea e lo restituiscono con id propri; e ogni operazione che PotoP non può svolgere — troncare lo storage, cambiare la password di un dispositivo, sostituire hardware — è elencata come risposta con un errore anziché con un successo simulato.

Al Web SDK si risponde con la sua stessa sintassi di chiamata di metodo q=, in JSON o XML, nella forma moderna o legacy secondo quanto chiede l’intestazione Accept. Le entità provengono da telecamere, server, utenti, gruppi, macro e stato citofonico di PotoP, con l’id logico uguale al numero PotoP; metodi delle telecamere, PTZ, uscite, riquadri e allarmi corrispondono alle chiamate mostrate; il flusso eventi trasporta il feed di PotoP sotto 37 nomi di evento di Security Center. Le righe di controllo accessi, antintrusione, LPR e parcheggio sono quelle oneste: entità conservate, report vuoti e azioni che falliscono con un motivo.

ICX è binario, così il banco offre ogni famiglia di comandi con esempi svolti in cui sostituisci i numeri con i tuoi, mostra il messaggio esadecimale che invierà e decodifica ogni frame di risposta in parole, accanto alle chiamate PotoP che l’hanno prodotto. La seconda parte simula ciò che accade in PotoP VoIP — una chiamata suona, viene risposta, termina, una postazione si scollega, un’uscita commuta, viene sollevata una richiesta di chiamata — e stampa i messaggi di stato ICX che il connettore emetterebbe; raggiungono il sistema collegato solo se la casella è spuntata, e questo viene scritto nel registro attività. La terza parte è il filo in diretta, ogni frame in entrata e in uscita.

Il registro è la tabella di audit propria del traduttore, conservata accanto al giornale degli eventi nel suo file SQLite: accessi alla console con il loro indirizzo, ogni modifica ai connettori con il campo e la persona, accessi rifiutati di altri sistemi una volta per indirizzo, nome e motivo in cinque minuti, client ICX respinti, e ogni messaggio di stato che il banco ha spinto verso un sistema in produzione. Anche ciò che il token del traduttore ha fatto sul VMS viene registrato lì, nel registro di audit di PotoP sotto il nome del token, così i due registri insieme dicono chi ha fatto che cosa e da quale parte.