i’m using /rest/o/{organization_id}/d/{device_id} to get device details like:
name
sim carrier
so on
the problem I see is API is not returning I see some times few keys of response json are missing. which is very annoying and my app can’t rely on peplink’s API.
I care about the interfaces key in the response, but if is missing 3 out of 10 cases.
on top of that a stupid msg '{msg': 'Polling from device'}, if api is still polling for the information, why did even the call finish and returning response?
what is the use of this app?
can anyone help me with this? or how can i reach someone who could fix it.
The concept behind this is that the API does not want to return stale data for some dynamic data fields. It also does not want to hold up the API client while it is querying data from the device(s). So it returns a PENDING code with the live status data missing. When the API client sees the return code, it should query again after one or two seconds. The return code should normally be SUCCESS and the fields will be filled with data.
I assume you want to know what the WANs’ types are. You are close. There is a “type” field under each “interface”. Possible types are “ethernet”, “wifi”, “gobi” (=cellular), “usb”, “openvpn”, etc.
hi @Michael, thank you very much for your clarification. I fixed it in my app.
Now I have a different issues.
I’m trying to figure monthly usage carrier wise,
I can use bandwidth endpoint and mention wlanid=2 , problem is we use multiple sims and switch between them a couple of times, then the output from this endpoint is the sum of both carriers which is not I’m looking for.
sim_usages endpoints look useful for me here, but the problem is, upload/download figures don’t match within control UI. UI uses bandwidth API. why the output from these two APIs are different.
The InControl web site just uses the same set of API to generate the SIM usage reports. So they must match. The differences may be because your input parameters are different or wrong.
I have a tip for you. But it will need some web development skills. Before loading up the SIM Card Reports on InControl, press F12 to enable the developer tool on your Chrome browser. After a specific SIM card report is loaded, in the Developer Tool, select the Network tab, then the “XHR” tab in the filter bar, look for the API call that is for retrieving the requested data, and then click into it. On the right pane, select the “Headers” tab, check the “Query String Parameters” field. It shows what parameters the InControl web site has passed to the API endpoint to request the piece of data. Compare the input parameters with your API client’s.
@Michael you already answered me, but i have question.
i have more than 100 pep waves , so i have to call end point 100 times, and wait for 2 sec and then call it it again to get dynamic data.
i’m using async programing so , calls exeeding 20 (your limit), per second. what is the best way to get rid of this issue.
i found https://api.ic.peplink.com/rest/o/xxx/d?device_ids=57&device_ids=65&device_count=2&has_status=true&fetch_hwmon=true
instead of calling 100 times, i can use this api and mention all device id’s , right ? out put is the same i guess, i have to poll first and wait for 2 sec , for fresh data.
what im not sure is, how many devices i can pass at a time to this query. do u have a limit , i dont want to relalise a limit and modify my program again.
@Michael after limiting to 20 requests as you said, which is the limit.
i see Too Many Requests error sometimes.
even i limit 20 requestst per second. do you still have any limitation on number of calls
same org. I think i was doing more than 20.
what i dont understand is,
my async program spanning requests simultaneously .
when u say 20 calls, doe these 20 calls needs to be resolved before i make fresh batch of 20 requests.
The system just counts how many requests make to the system per second. It does not care whether they finish, or how much time they last.
We found you made 35 requests in one second on 2020-11-19 at 22:31:28 UTC. So the system rejected some of the requests. Any requests that come after the 20th one will potentially be rejected. In this case, we see 3 instead of 35-20=15 requests were rejected.