Camera stream authentication in an HMI browser when URL logins fail

Your camera feed used to be one URL pasted into an HMI browser widget. Newer camera firmware demands a login, credentials inside the URL are being retired, and per-camera certificates expire one by one. A picture that commissioned cleanly dies a year later. The failure chain, the certificate arithmetic behind it and the gateway architecture that holds are set out below. You will finish able to choose between an NVR and a vision controller for the gateway role, size it by port count and bandwidth, and write the spare-part procedure that keeps the feed alive across camera swaps.

Why did the camera URL stop working in the HMI browser?

Two changes landed together: newer camera firmware refuses anonymous browser access, and the user:password@address form that used to work is being dropped. An embedded HMI browser that never supported it anyway now has nothing to load.

Both halves of the old trick broke at once. On the camera side, firmware revisions now enforce authentication. An anonymous request comes back as 401 Unauthorized with a WWW-Authenticate header, the HTTP challenge-and-response flow the web is built on. A desktop browser answers that challenge with a login box. An embedded HMI widget has none, so it renders an empty frame.

On the URL side, writing the login into the address itself sends the password unencrypted on every request. Browser makers have spent years stripping support for exactly that form. Several camera makers still accept it over plain HTTP, which is why it half-works on the bench; treat that as a countdown, not a design. The MJPEG stream URL with username and password guide covers the format and where it breaks.

If the widget side of your set-up is still vague, the camera live stream in an HMI web viewer widget guide shows what a browser widget accepts and what it silently rejects.

Why do camera certificates turn a spare-part swap into a downtime call?

Camera TLS certificates are typically valid for one to three years, so a line with six cameras hands you six independent expiry dates. Any one of them turning stale blanks the feed until someone imports a new certificate on the HMI.

HTTPS works only when the browser trusts the certificate the server presents. On a panel HMI you import each camera's certificate into the trust store once and mark it trusted; from then on the feed displays. The cost is not the first import, it is every one after. Camera-side certificates are self-signed and bound to the unit, so a shelf spare cannot be pre-staged. Swap a failed camera and the replacement presents a new certificate. The feed stays blank until that certificate reaches every client that shows it.

Roll the two rules together and the arithmetic looks like this:

A line with six cameras and two-year validity: 6 ÷ 2 = 3 renewals per year, and 12 ÷ 3 = 4, so a certificate job lands every four months on average. Each job is a stop: import on the camera side, import into the HMI trust store, restart the widget, confirm the frame. Consolidate onto one gateway certificate of the same two years and it is 1 ÷ 2 = 0.5 renewals per year, one job every 24 months. The ratio 3 ÷ 0.5 = 6 is the whole argument for the gateway: six times fewer certificate events, on a date you chose.

What is the one-gateway architecture that survives camera revisions?

The fix that outlives camera revisions is one authenticated gateway between cameras and HMI. An NVR or a re-streaming vision controller takes the camera streams on the machine network and serves the HMI one HTTPS address with one login and one certificate.

The layout has three zones. The cameras keep their logins on the machine network — RTSP with credentials is fine there, because it runs box to box inside your cabinet and never through a browser. The gateway pulls those streams and re-serves them. The HMI consumes a single HTTPS address from the gateway and never talks to a camera again, so the snapshot login that dies at session timeout stops being a per-panel fire drill.

Each side now fails independently of the other. When a camera revision changes its URL paths or login behaviour, you update the pull on the gateway. No panel, client or project file is touched. The HMI-facing side is stable because you own it: the gateway presents a certificate you issued, with a renewal date you put in the calendar. When a shelf spare becomes the replacement, its credentials change in one config file and the HMI keeps loading the same address.

For the service itself — pull RTSP, re-serve snapshots or MJPEG over HTTPS — the restream an RTSP stream for display in an HMI browser guide walks through a working build. The display multiple IP camera streams on one HMI screen guide extends it to a wall of feeds.

Should the gateway be an NVR or a vision controller?

Choose the NVR when video is its own job with recordings and many channels. Choose the vision controller when the machine already has one, because it adds the gateway role to hardware that is already there and shortens the spare-parts list.

Both work. An NVR is purpose-built: centralized authentication, one certificate to manage, token-style snapshot URLs as its native interface, and recording if the customer wants footage. The trade-off is a second device family on the shelf and a second box to monitor. A vision controller is already on the machine whenever there is vision on the machine: powered, networked and on the bill of materials before the gateway role costs it anything.

On a line where inspection downtime is costly, keep the gateway on its own controller and let the vision box stay single-purpose; the port-count math is identical either way. For surveillance-heavy cells the NVR wins on its native territory. For everything else the controller usually wins, and the next section sizes it.

Which vision controller fits the gateway role?

Count ports first: one for each camera, one for the HMI or plant network, and one spare. The vision controllers range starts at 8 GB of memory, which is ample for a service that re-serves snapshots.

PoE is a cabling decision, not a gateway requirement: choose powered ports only when a new cell would need camera-side PoE switches anyway.

The catalog spans compact boxes to powered multi-camera hubs, and the table puts the three useful shapes side by side:

All 3 share: Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The MV-VC2140-128G40-1T is the compact pick: 3-4 LAN ports, 8 GB of memory and a 1 TB HDD for logs.

A cell with two cameras plus the uplink fits with a port to spare. That 1 TB drive also buys evidence footage: at 2 fps and 150 kB per frame, 300 kB/s × 86,400 s ≈ 25.9 GB per day, so 1,000 GB ÷ 25.9 ≈ 38 days of continuous snapshots.

The MV-VC3301H-128G66 steps up to 5+ LAN ports on an Intel Core i3, with PCIe expansion supported and no PoE. It includes a vision software license (VM6200Pro), so inspection and the gateway can share one box where the duty cycle allows.

For a powered hub, the card below is the shape to match:

The MV-VC5525-256G70-NN pairs PoE camera ports with 5+ LAN ports, 8 built-in channels and 32 GB of memory on a 12th-gen Intel Core i5. Cameras power and stream over the same ports. The feed count comes from the bandwidth arithmetic below, not from the box.

How much network does a snapshot feed really need?

A polling snapshot feed costs about 2.4 Mbit/s at 2 fps with 150 kB JPEG frames: 150 kB × 2 frames/s × 8 bits/byte = 2,400 kbit/s. A 100 Mbit line carries roughly forty feeds and a Gigabit uplink is never the bottleneck.

The frame size is the swing factor. A mid-quality 1920×1080 JPEG lands between 80 and 200 kB depending on scene clutter, so budget 150 kB and re-measure on your own scene. At 1 fps the same feed costs 150 × 1 × 8 ÷ 1000 = 1.2 Mbit/s. Monitoring windows run happily at 1-2 fps, because the consumer is a human eye.

Prefer the polled snapshot to a held-open MJPEG stream. A stream keeps a socket and a decoder busy on the HMI for every open page, which is what the why an MJPEG stream slows HMI pages guide measures. The snapshot poll costs nothing between refreshes. The runtime-side trade-off is laid out in live camera image in an HMI runtime: snapshots vs streams.

When is the one-gateway answer wrong?

Skip the gateway only when a single camera feeds a full Windows or Linux HMI panel. Then install that camera's certificate once, mark it trusted in the panel's certificate store, and re-import on renewal — one camera means one certificate is already the minimum.

That exception is honest arithmetic, not laziness: with one camera, a gateway adds a second certificate, a second box and a second failure point to save nothing. Revisit it the moment the camera count reaches two. Revisit it too when the HMI is an embedded browser that cannot import certificates at all — then the gateway is not a nice-to-have, it is the only path that works.

Keep the inspection camera out of the gateway entirely, in every case. A locate or measurement camera feeds the vision runtime its own frames on its own link. Route it through a browser-oriented feed instead and its timing and settings drift, which is the trap behind vision locate that works in teach but fails at run time. The gateway serves people; the runtime serves the algorithm.

What do you check before ordering?

Before you order, settle five numbers: camera count, PoE or separate power, snapshot rate in fps, certificate owner and renewal date, and the spare-part procedure written down. With those fixed, the gateway choice is arithmetic, not debate.

Ports and power

• One LAN port per camera, one uplink, one spare — port count is the first sizing number.
• PoE on the gateway only if it replaces camera-side switches; otherwise standard ports and the switches you have.

Bandwidth and refresh

• Fix the poll rate first (1-2 fps for monitoring), then multiply by a frame size measured on your scene before you promise a feed count.

Certificates

• Decide who issues the gateway certificate and on what validity, and enter the renewal in the maintenance calendar on commissioning day.
• Confirm the HMI browser accepts a plant-CA certificate; where a panel cannot, import a gateway certificate into that panel once and be done.

Spares

• Image a second controller with the re-stream service and shelf it: a failed gateway becomes a swap, not a rebuild.
• Write the camera-swap runbook: the new camera's credentials go into the gateway config, the HMIs stay untouched.

Send the camera list, the HMI type and the poll rate through the quote form and the gateway sizing comes back as a parts list. The contact page is the line to the applications team when the certificate policy is the open question.