PotoP VMS for Android

The list is the PotoP VMS web client running inside the Android app, so the phone asks the server for the camera inventory over an encrypted HTTPS connection and draws it locally. The green dot is the connection state the server tracks for each camera, refreshed while the screen is open. Add and Discover open the same forms as the browser client, which probe the network for ONVIF devices on the server side rather than on the phone. Nothing is copied to the phone: the list always mirrors the server you are connected to.

Each tile is a live stream the server prepares and the phone plays in its built-in browser engine, the same way the web client does it. The server pulls the camera feed once and serves it to the viewer over WebRTC through its media gateway, so the phone only decodes video and does not talk to the cameras. The time on each tile is the moment of the frame. The screen is kept awake only while a camera plays, and the page is parked after three minutes in the background so live video stops using mobile data.

Layouts are stored on the PotoP server, not in the app. The desktop client, the web client and the phone all read and write the same records, so a wall arranged in the control room shows up on the phone the next time the list loads. Tapping a layout only tells the viewer which cameras go in which tile; the streams themselves are then requested from the server. Access follows the signed-in account, so a user sees the layouts and cameras their role allows.

The app is a native shell around the complete PotoP VMS web client, which is why the menu is not a cut-down mobile edition. The client is served by the PotoP server and only that server, and any standby server it fails over to, is shown inside the app. Links to other sites are handed to the phone's browser, dialler or maps. Because the client is loaded from the server, a server update brings new features to the phone without an app update.

The map tiles come from OpenStreetMap and are drawn by the web client on the phone. Camera positions are stored on the PotoP server and set from a layout panel, which is why the search box can match camera name, house number or street. Nothing about the camera locations goes to a third party; only the tile requests for the visible map area do. Location access on the phone is granted to the server's pages only when a page asks for it.

Playback reads the recordings that the PotoP server wrote to its own storage. Choosing a camera and day asks the server which time ranges exist, which draws the 24-hour bar, and the chosen moment is streamed back to the phone over a WebSocket connection. Speed changes are applied by the server side player, so slow motion and fast forward need no work on the phone. Encrypted recordings are decrypted on the server for authorised users only.

The plan is an image with device markers placed on it by an administrator in the VMS visualization editor. The markers are stored on the server with their device type and reference, so the phone only renders them. A live update channel from the server refreshes their state while the page is open. Touching a camera, door or intercom opens the corresponding live view or action in the same client, using the permissions of the signed-in user.

Each marker on the plan is bound to a real device, and the server sends state changes to the open plan, such as a lock opening or an incoming call. The badge is drawn by the web client from that state, in the corner of the device icon. Because the state comes from the device drivers on the server, the phone does no polling of the devices and needs no network access to them. Only users allowed to operate a door or call an intercom can act on it.

The AI analytics run on the PotoP server, on its GPU or CPU using ONNX-based models, not on the phone. Detections such as people, faces and plates are written to the analytics database together with attributes like colour, gender and confidence. The hub sends the search terms to the server, which queries that database and returns matching entries with their snapshots. The CSV export is produced by the server and saved to the phone's Downloads folder by the app.

The browser lists recording segments held on the chosen PotoP server, filtered by camera and date range. The server can be any node of the installation, including standby servers, so the picker follows what the web client knows about the cluster. A result opens in playback at the selected time. Recordings are not copied to the phone unless you download a clip, and every request is checked against the signed-in user's rights.

The assistant is a chat panel connected to a language model that the operator hosts, for example a local model on the PotoP server, so questions about your cameras do not need to leave your network. The server gives the model a fixed set of tools, such as listing cameras or reading server status, and runs them with the rights of the asking user. Tools that change something are not run silently: the assistant asks its clarifying questions and waits for confirmation first.

The softphone is a SIP client inside the web client, connecting through the WebRTC gateway of the PotoP server, which bridges to the SIP exchange. The phone registers an extension over an encrypted connection, and audio is carried by WebRTC. Microphone access is requested from Android only when the panel needs it and only for the server's own pages. The same extension can call SIP intercoms, other extensions and colleagues on other clients.

Alerts are generated by the PotoP server, for instance when a recording disk crosses a limit or a standby server stops answering. The open client shows them as banners as soon as they arrive. When the app is closed, the same alerts arrive as Android notifications through a long-lived connection the app keeps to your own server, without Google or Firebase. Critical alerts use a separate high-priority channel and can show on the lock screen.

Macros are visual flows made of trigger, condition and action nodes, saved on the PotoP server, where the macro engine runs them around the clock. Server flows react to events like camera events, stream loss or disk warnings and can start recordings or raise alarms. Client flows run in the operator's client. The editor on the phone is the same browser editor, with validation and a simulation mode, so you can inspect or adjust automation while on site.