When a Mango SCADA page displays many live point values, combining XIDs in a REST request does not reduce the live-update WebSocket count. REST retrieves historical point values, while all live point updates share one WebSocket connection. Treat slow dashboards and closed WebSocket messages as client-rendering or connection symptoms, not evidence that each point owns a separate socket.
Separate Historical REST Reads from Live Updates
| Data path | Purpose | Connection behavior |
|---|---|---|
| REST | Retrieve historical values for one or more points | A multi-XID endpoint can simplify and accelerate requests such as loading a multi-point graph. |
| WebSocket | Deliver live point-value updates | All live values use a single WebSocket, rather than one socket per point. |
A multi-XID REST call therefore addresses historical-data request efficiency. It does not merge live point subscriptions or avoid a browser WebSocket limit because the live values already travel over one connection.
Interpret the Reported Dashboard Symptoms
The reported page contained about 300 constantly updating points while Modbus polling occurred every 1.75 seconds. A Celeron-based PC showed severe delay and logged closed WebSockets, whereas systems using i3, i5, and i7 processors handled the page. This comparison supports browser rendering performance as a diagnostic hypothesis, but it does not prove that CPU performance caused the closures.
The evidence does not identify a supported maximum number of XIDs per REST request, a maximum number of live points, or a required client CPU. Do not select a batch size or hardware threshold without testing the installed API module and actual dashboard workload.
Verify the Live Connection Architecture
- Open the browser developer tools and inspect network connections while the dashboard is running.
- Confirm that live point updates pass through a single WebSocket rather than one connection per displayed point.
- Observe rendering delay while the approximately 300 point values update, and compare it with the Modbus polling interval of 1.75 seconds.
- Correlate visible delay with WebSocket closure entries in Mango logs; keep rendering delay and connection closure as separate symptoms until testing establishes a causal link.
Decide Whether to Use a Multi-XID REST Call
Use the multi-XID capability when retrieving historical values for multiple points, particularly when preparing a graph. Do not implement it solely to reduce live-update WebSockets. The evidence records plans to add the endpoint in the next API module release and a later claim that an update had been implemented, but it supplies no API module version, endpoint syntax, or authoritative release confirmation. Verify availability and request limits in the documentation for the installed module before changing an application.
FAQ
Does each live Mango point open its own WebSocket?
No. The evidence states that all live point-value updates use a single WebSocket connection; verify this in the browser developer tools.
Will one REST request for multiple XIDs fix a slow live dashboard?
Not by reducing WebSockets. Multi-XID REST access applies to historical values, while live updates already share one WebSocket; investigate browser rendering and logged connection closures separately.
How many point XIDs should I include in one Mango REST request?
The evidence provides no supported maximum or optimal batch size. Confirm the installed API module's documented limit and test the historical-data workload before selecting a batch size.