Get AP status

Solved
RaphaelL
Kind of a big deal
Kind of a big deal

Get AP status

Hi , 

 

Is there a efficient way to retrieve AP status ? ( online , offline , repeater ) 

 

I have not seen an API call for that and you can't see it from the dashboard - Overview - Devices  page. 

 

Only way I found is to dump all my AP MAC adresses and compare DHCP leases to find if the AP has a lease or not...

 

I have more than 1000++  AP so I can't go network by network to find that info.

 

Thanks ! 

 

1 Accepted Solution
Nash
Kind of a big deal

I've got a report I run that checks for repeaters.

 

I turn the JSON into objects because I found it easier than manipulating raw JSON later on.

 

It iterates across dozens of orgs, hence my logic below.

 

If you want to see exactly how I did it, look here. It's a work in progress that needs reworking.

 

Order of operations:

 

  1. Get org list
  2. Get network list
  3. Grab device list per network
  4. Convert device list into a list of device objects, since I find it easier (createDeviceObj)
  5. Below in report generating chunk, for device in devicelist:
    1. check if lanIp is None: (line 572 in script above)
    2. If None, check if model is MR
    3. If MR, set report value as "Repeater AP?"

View solution in original post

11 Replies 11
BrianP
Getting noticed

organizations/{{organizationId}}/deviceStatuses This call will get the status of all devices in the organization. You can use that to get all AP statuses.
BrianP
Getting noticed
RaphaelL
Kind of a big deal
Kind of a big deal

Thanks for the reply

 

As expected that doesn't work ! 

 

Status is either offline or online or alerting. I want to know if an AP is in repeater mode or not. 

 

 

EDIT : I think my first message , wasn't that clear. My appologies

 

Thanks 

Sorry didn't catch the 'repeater' requirement. Not sure off the top of my head if any API endpoint exposes that info. I will take a look and get back if I see anything.
SoCalRacer
Kind of a big deal

Not available at this time to my knowledge.

Nash
Kind of a big deal

I've got a report I run that checks for repeaters.

 

I turn the JSON into objects because I found it easier than manipulating raw JSON later on.

 

It iterates across dozens of orgs, hence my logic below.

 

If you want to see exactly how I did it, look here. It's a work in progress that needs reworking.

 

Order of operations:

 

  1. Get org list
  2. Get network list
  3. Grab device list per network
  4. Convert device list into a list of device objects, since I find it easier (createDeviceObj)
  5. Below in report generating chunk, for device in devicelist:
    1. check if lanIp is None: (line 572 in script above)
    2. If None, check if model is MR
    3. If MR, set report value as "Repeater AP?"
BrianP
Getting noticed

Awesome. Any reason to do the 'Grab device list per network' step ?

There is a get all Devices in Org call that is the exact same info as the get list per network. Should save a ton of API calls.

https://developer.cisco.com/meraki/api/#/rest/api-endpoints/devices/get-organization-devices

GET /organizations/{organizationId}/devices
Nash
Kind of a big deal


@BrianP wrote:
Awesome. Any reason to do the 'Grab device list per network' step ?

There is a get all Devices in Org call that is the exact same info as the get list per network. Should save a ton of API calls.

https://developer.cisco.com/meraki/api/#/rest/api-endpoints/devices/get-organization-devices

GET /organizations/{organizationId}/devices

 

I wanted to check switches/APs set for DHCP against DHCP pools on the MX in their networks. Then if the MX was the DHCP server for that device, check the MX's pool for a reservation for that device's IP.

 

All of my clients have a single network for each physical location, for switches/AP/MX. So once I got inside the network, I could check all of that without having to do a rummage to figure out which MX to compare the switches and APs to.

 

That gave me logic that I could follow more easily. Crunching the returns and writing the spreadsheet slows the process down enough that I didn't hit the call speed limiter.

BrianP
Getting noticed

Fair enough. For people who have issues hitting the Rate limit ( due to other active monitoring API calls ), it would be significantly faster to do the network list call and the full org device list call, and correlate the device to the correct network in the code, instead of the individual calls per network.

Either way, you solved Raphael's issue!
Nash
Kind of a big deal


@BrianP wrote:
Fair enough. For people who have issues hitting the Rate limit ( due to other active monitoring API calls ), it would be significantly faster to do the network list call and the full org device list call, and correlate the device to the correct network in the code, instead of the individual calls per network.

Either way, you solved Raphael's issue!

Definitely agree. 🙂 I can do things sloppily sometimes because Auvik and I are the only things making calls, and Auvik rate limits itself.

 

There are advantages and disadvantages to being the only automator on your team.

RaphaelL
Kind of a big deal
Kind of a big deal

Nice ! 

 

I didn't think it that way !  I will script that in python.

 

Thanks for the help !

Get notified when there are additional replies to this discussion.