PotoP API Translator

A flow opens into three parts: the request exactly as the other system sent it (method, URL, body), the PotoP steps — each REST call with its path, status code and the milliseconds it took — and the answer that went back in the other system's own format. The outcome is one of ok, error, refused or unsupported, and that is what the counters add up. The detail is the fastest way to learn what a vendor's command really does on PotoP, which is why the test bench opens the same view for the commands you send yourself.

Linking asks PotoP VMS Studio for an API token named after the translator with a fixed preset of rights, made under the administrator who pressed the button; the token is stored encrypted and can be withdrawn here or in the VMS. The same page shows the event feed the translator keeps open to number every PotoP event, the certificate it serves on every port (the VMS server's own, followed through renewals, or a stand-in it made itself) and, per connector kind, whether it is ready, how many are set up, or that it is not built yet.

There is no user list in the translator. The sign-in form posts to the VMS's own login, honours two-step sign-in, and then checks that the account is an administrator; anyone else is refused in words. The session is a strict cookie for this browser with a sliding thirty-minute life, every change carries a CSRF header, and eight failed attempts from one address in five minutes pause that address. The page is served over the PotoP server certificate, and a browser that opens localhost is redirected to a name the certificate was issued for.

The translator serves the VMS server's certificate on every connector port and follows its renewals, so the address under General works over HTTPS the moment it is typed into the PLC or the management system. Ports are tags: a second one — 443 or 80 for a system that cannot be given another — is added without a restart, and ports the PotoP server itself uses are refused with the reason. Remove this connector asks for a confirmation and is written to the activity log under your name.

Add account generates an eighteen-character password shown once; only a scrypt hash is kept, checked beside the service's main loop with a short memo so a system that signs in on every request costs nothing extra. Ten wrong passwords pause that name from that address for five minutes. Allow plain HTTP opens a warning you must accept by name, and HTTPS keeps working on the same port. The groups below are permissions per connector: a command whose group is off is refused in the other system's own vocabulary, Change settings is off by default.

A Sense integration addresses a server by a long number and a camera by a device id, both from the installation that was replaced. The map gives each pair its PotoP camera; without a mapping the device id is taken as the PotoP camera number, and a mapped camera is reachable only under its mapped number. Commands that named an unknown number are not guessed: the number is collected in the list below with how often and when last, and Map… starts a mapping row from it — let the other system run for a minute and the list says what it still expects.

ICX speaks in call numbers, output and input numbers, camera and monitor numbers. A call number is the PotoP VoIP extension of the same number unless mapped; an output becomes real when a PotoP macro is named for on and off; an input is pulsed by a PotoP event type, optionally of one camera, for a number of seconds; a monitor is a PotoP layout and the panel the camera is put on. Below the tables the connector lists task and type pairs it received and has no handler for, so a missing feature is seen rather than guessed.

The connector answers Milestone's configuration API with ids of its own, stable across restarts. An integration that looks cameras, outputs or event types up by name therefore works unchanged; one that was programmed with the GUIDs of the old XProtect installation pins them here, each to the PotoP object that replaced it, with the id type chosen from cameras, hardware, recording servers, outputs, input events, user-defined events, event types, views, basic users and roles. Outputs get a number, a name and a PotoP macro so that triggering one really switches something.

PotoP is a video system, and the page says so plainly: alarms land in PotoP's alarm register with the instance id equal to the PotoP alarm number, video protection is a footage hold, recording is PotoP's manual recording, events are published under Security Center's names. Access control, intrusion, LPR patrol and parking have no counterpart — their entities are kept, their reports answer Ok with an empty list, their actions answer Fail with a message that says why — and nothing is ever pretended to have happened.

Each family carries its ICX task and type codes under the name, so a protocol engineer can look up 40/80 or 80/AC directly. Almost every family becomes one op of the VMS's intercom command endpoint — call, hangup, dtmf, busy, privacy, page, conference, output, input, door code, request, desk — and the note says what differs: privacy honoured per call, simplex mode reported but not enforced, a radio channel as a conference room. Kept families are the parts only a Commend station has, which PotoP stores per station and reports as an event.

The 75 rows cover the sign-in endpoints, the events and messaging WebSockets, alarms, bookmarks, evidence locks, WebRTC and every configuration resource type of the published MIP VMS API. Complete rows are backed by PotoP (cameras, recording servers, outputs, user-defined events as macros, views as layouts, basic users and roles as real users and groups); kept rows store what the other system creates and give it back with ids of their own; and every task PotoP cannot perform — truncating storage, changing a device password, replacing hardware — is listed as answered with an error rather than a pretended success.

The Web SDK is answered with its own q= method-call syntax, JSON or XML in the modern or legacy form as the Accept header asks. Entities come from PotoP's cameras, servers, users, groups, macros and intercom state with the logical id equal to the PotoP number; camera methods, PTZ, outputs, tiles and alarms map to the calls shown; the event stream carries PotoP's feed under 37 Security Center event names. The rows for access control, intrusion, LPR and parking are the honest ones: kept entities, empty reports, and actions that fail with a reason.

ICX is binary, so the bench offers every command family with worked examples whose numbers you change to yours, shows the hex message it will send and decodes each answer frame into words beside the PotoP calls that produced it. The second part simulates what happens in PotoP VoIP — a call rings, is answered, ends, a station drops off, an output switches, a call request is raised — and prints the ICX status messages the connector would emit; they reach the connected system only when the box is ticked, and that is written to the activity log. The third part is the live wire, every frame in and out.

The log is the translator's own audit table, kept beside the event journal in its SQLite file: console sign-ins with their address, every connector change with the field and the person, refused sign-ins of other systems once per address, name and reason in five minutes, ICX clients turned away, and every status message the bench pushed to a live system. What the translator's token did on the VMS is recorded there too, in PotoP's audit trail under the token's name, so the two books together answer who did what on which side.