A WebcamXP5 page displays the camera by running JavaScript that repeatedly requests JPEG files. ScadaBR's “http imagem” data source shows the screen but not the image when given that entire page script. The evidence does not confirm ScadaBR's accepted response format, so treat the integration failure as a content-type or execution-model mismatch until direct-image testing proves otherwise.
Separate the image endpoint from the web page
The supplied HTML initially loads loading.jpg, then JavaScript replaces the image source with a camera-specific JPEG request. It also appends a random query value, which prevents a cached frame from being reused. The important test target is therefore the JPEG response, not the surrounding <script> and <img> markup.
/cam_<camera-number>.jpg?uniq=<random-value>The page defines camera 1 at 640 × 400. Those dimensions control browser presentation; they do not establish which dimensions or formats the ScadaBR data source accepts.
Test the likely integration mismatch
The most likely cause is that the “http imagem” data source expects an image response but receives HTML and JavaScript. This is a hypothesis because the evidence provides no ScadaBR documentation, version, response requirements, or error message.
- Open the direct camera JPEG request independently and confirm that it returns an image without relying on the WebcamXP5 page script.
- Configure the ScadaBR image source with that direct JPEG request instead of pasting the complete HTML/JavaScript block.
- Check the watchlist and verify that successive reads produce changing frames rather than only the page, placeholder, or a cached image.
- If the direct request fails, inspect the returned status, content type, authentication behavior, and network reachability before changing display logic.
Account for refresh and failure behavior
| Observed source behavior | Integration consequence |
|---|---|
Calls LoadImage1() after a 40 ms timeout |
The live effect depends on continuous browser-side requests; copying the script into a non-browser data source may not reproduce it. |
Adds ?uniq= plus a random value |
The changing query is intended to avoid reuse of a cached JPEG. |
Switches to offline.jpg after more than 3 image errors |
An offline placeholder can originate in the page logic rather than from ScadaBR. |
Uses a separate /ptz request with calculated coordinates |
PTZ control is independent of frame retrieval and should be tested only after image display works. |
Verify the result
Confirm three conditions: the selected request returns JPEG data directly, the watchlist renders that response as an image, and repeated reads show new frames. If ScadaBR still displays only a screen or placeholder, record the HTTP response status and content type plus the ScadaBR version and any logged error; the supplied evidence does not contain enough information to identify a product-version defect or a supported embedded-script method.
FAQ
Can I paste the WebcamXP5 JavaScript into ScadaBR “http imagem”?
The reported attempt shows the screen but not the image. Test the direct /cam_<camera-number>.jpg response instead, because the live page depends on browser-executed JavaScript.
Why does the WebcamXP5 image URL include a random value?
The script appends ?uniq= plus a random value on each request so the client requests a new JPEG rather than reusing a cached frame.
Why does the webcam page show offline.jpg?
The supplied script counts image-load failures and selects offline.jpg after more than 3 errors. Test the direct JPEG response to distinguish camera or network failure from page-level fallback behavior.
