API Diagnostics
A service check of the data exchange between AI Analytics and the metering-device platform, probing every request the other reports rely on.
A service check of the data exchange between AI Analytics and the metering-device platform. The report queries, one by one, all the platform requests used by the other reports, and shows which of them respond normally and which return an error. The audience is the administrator and technical support: run it when you suspect an integration failure, and immediately see where the link to the device or server is broken.
What it shows
For each kind of platform request — a row with the result: which endpoint was called, whether the server responded successfully, how many rows of data it returned and what fields were in the first row (to confirm the data format has not changed).
| Row element | What it means |
|---|---|
| Request endpoint | which kind of data was checked (login, fleet list, directories, link sessions, reading archives, device passport) |
| State | whether the server responded successfully or returned an error |
| Row count | how many records arrived in the response |
| Field samples | field names from the first record — a sign that the format has not changed |
The row color is set by the server response code:
| Color | What it means |
|---|---|
| Green («200») | the request works normally |
| Yellow (permission error, except «not found») | access rights need to be checked |
| Red (server error or no timely response) | a problem on the server side |
| Gray («404» — not found) | there is no such request in this platform version |
How it’s calculated
The report queries, one by one, all the platform requests used by the other reports: login, fleet list, directories (device types, utility companies, customers), link sessions (in four parameter variants), reading archives (hourly, daily, monthly, settings), abnormal-situations archives and event logs, as well as the device passport. For each call the endpoint, the server response, the row count and a field sample are recorded. If a specific node is set, the abnormal-situations archives are additionally checked for that node.
Run parameters
| Parameter | Default | Meaning |
|---|---|---|
| Node ID for abnormal-archive probe (optional) | taken from context | if set — the check runs on this node; if empty — the first node from the fleet list is taken |
How to read it
Look at the row colors. All green — data exchange is healthy. Yellow rows mean the server is in place but does not return data without the required rights — a reason to check access. Red rows are a failure on the server side and are addressed first. Gray rows («not found») are often normal: not all devices support all archive kinds, so the absence of abnormal archives on a specific device is not an error.
Note a login quirk: the platform reuses a previously obtained pass for about two weeks, so the login check is usually successful even without an actual re-login on the server.
Related reports
This report is self-contained and depends on nothing. All other fleet reports use the same platform requests it checks — so when they fail, this is where to start diagnostics.
Was this page helpful?
Thanks for your feedback!