Perhaps you are not aware, but the call I use in the example will return thousands of clients in one go, all the page handling occurs internally.   You could use the 'make a wish' button and ask for a new API call to return summary client data, perhaps you will be lucky.   ... View more

An alerting device could be due to a number of reasons. See... https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Status_Icon_Meanings ... View more

Why not use the SDK V1, still in beta, but it's pretty good, I've been using it for a few months   https://github.com/meraki/dashboard-api-python   ...currently:  https://pypi.org/project/meraki/1.0.0b13/   Cut/paste from one of my scripts...               # get list of devices on network for the last 24 hours             t = 24 * 60 * 60             clients = await aiomeraki.networks.getNetworkClients(net['id'], timespan=t, perPage=1000, total_pages="all")   This will return all clients, the page handling is done for you.   ... View more

It would be best if you post the actual code/parameter values you are using, and which API version.     ... View more

I use a Centos VM to run all the API access - actually a replicated pair, with limited login access using ssh with keys not passwords and all sitting on a segregated network accessible inbound by VPN only.   The people with direct access to the VMs (and physical UCS servers etc.) are a small subset of ones who have Dashboard admin access (mandatory 2-factor authentication).   Bear in mind, the weakest link is may be people with Dashboard admin read-write access, rather than API key storage/access per se.   For API use that's for stats/reporting only, the API key comes from a dedicated Dashboard account with admin read-only.   The API keys/other credentials are held in a central store as the application uses multiple vendor APIs, and is modular so it's easy to add extra target networks and other APIs.   Everything is run by cron. At runtime credentials are pulled from the store by a 'wrapper' that runs the python scripts and chooses the correct set for each orchestrator/target, then they are put into the environment so the script can get them with os.environ.get()   To protect API keys on a 'shared' system would depend on the environment. You could encrypt them and decrypt on the fly based upon the identity of the requesting process, but at some point they'll exist as plaintext in memory and in principle be vulnerable to a sufficiently skilled user. Really depends on your level of paranoia 🙂   Summary: limit Dashboard admin users, especially read-write make 2-factor Dashboard access mandatory strictly limit access to the system holding the API key(s) keep keys in one place, rather than scattering them around the system   Tbh I wish Meraki had the option for API key to not be linked to individual admin account(s), require 2+ designated admins to modify and maybe be pki/cert-based rather than simple plaintext, as it would improve the security of generating/managing keys. But this is an issue across other SDN APIs too, not picking on Meraki 🙂   ... View more

Here's a simple V1 example...   btw this is using meraki 1.0.0b11   Note that the V1 API names are not the same as in V0, the one to get the Bluetooth settings for a network is... https://developer.cisco.com/meraki/api-v1/#!get-network-wireless-bluetooth-settings     import os import sys import meraki   # set the key in the environment as MERAKI_DASHBOARD_API_KEY   # also define the org id in the environment ORG_ID = os.environ.get("ORG_ID")   def main():     dashboard = meraki.DashboardAPI(         api_key='',         base_url='https://api.meraki.com/api/v1/',         print_console=False,         output_log=False,         wait_on_rate_limit=True       )          try:         networks = dashboard.organizations.getOrganizationNetworks(ORG_ID)     except meraki.APIError as e:         print(f'Meraki API error: {e}')         sys.exit(1)     except Exception as e:         print(f'some other error: {e}')         sys.exit(1)       for net in networks:         if 'wireless' in net['productTypes']:             print(net['name'])             try:                 settings = dashboard.wireless.getNetworkWirelessBluetoothSettings(net['id'])             except meraki.APIError as e:                 print(f'Meraki API error: {e}')                 pass             except Exception as e:                 print(f'some other error: {e}')                 pass             else:                print(settings)     if __name__ == '__main__':     main()   ... View more

Looking at the OP's findings, I'd say the variable number of response samples is just a side-effect of a too-short sampling window (timespan) for a set of events (default 60 second duration) that aren't synchronised with the sampling window, this seems in line with seeing 4 or 5 with a 300 second timespan.   If you need consistent 60 second samples, try making requests every 2-3 minutes with a t0 in seconds of (now-300 seconds)%60 seconds (to align t0 to hh:mm:00) and t1 = t0+300, add new samples to a list, discard or overwrite duplicates.   That should allow plotting without gaps, the only cost is that things will lag a couple of minutes, though you could reduce that by making the API call at a higher rate, say every minute. ... View more

I guess this is V2.x   https://developer.cisco.com/meraki/scanning-api/#!2-1/bluetooth-devices   As step one, dump the complete response for a few tags so that you can manually plot on the floorplan and get a feel for the data by AP.   If a client is not present in at least three different AP observation[], I'd wonder if the location data is safe, where did it come from if < three APs saw the client? By manually examining the data you can decide if it would be sensible to discard such clients until seen by more APs   Do all APs report the same location? I don't know what happens 'inside' Meraki's location system that creates the data, some things to try...   Out of all the different AP observations for a client, try some methods to see if you can improve client location, for instance...   If the location data vary, choose the location with lowest 'unc' (uncertainty value).   Calculate a final location based upon the midpoint of 2-3 locations with lowest 'unc'.           ... View more

I'd assume for BLE that 'last seen by' is just a reporting choice of one AP out of many, i.e. there could be many APs that 'see' a client but only one AP can be chosen.   If position calculation is wrong, as a first step I'd check AP type(s) and firmware are supported for BLE location and API version in use, also check the firmware release notes for any relevant issues etc.   Depends on environment, if allowed you could try turning off PoE to AP11 to 'force' information from elsewhere.     ... View more

Btw this may help understand placement...   https://documentation.meraki.com/MR/Monitoring_and_Reporting/Real-Time_Location_Services_(RTLS)   In our test/demo environment this is pretty much how I set it up (with 10+ APs covering a floor of the building), it's not always practical to put APs at all the corners/edges, but in unobstructed areas 'outside' the AP boundary the results are still reasonable as long as there is line of sight to 3+ APs.   Even with no people there to move things around or affect signal strength, there can still be a few metres jitter in a fixed device's location, depending on your application you might want to consider some filtering to create a 'smoothed' location rather than using a snapshot. ... View more

Your image shows only two APs, unless you've got 3+ APs and the positioning of APs (and devices) is reasonable you will get bad location data.   With only two APs 'seeing' the device, it can only be positioned on a line between the two APs, which is exactly what you are seeing in the location data.   ... View more

Q1. you have a choice...   absolute: using latitude, longitude   ...or...   relative: using x, y offsets from lower left of floorplan(s)   whether to use absolute or relative position really depends on your application   Q2.   assuming you have the required minimum firmware for V3, perhaps you need to have early beta access? simplest way to check is probably to just open a case and ask if that is why you see no location data for V3 ... View more

you can probably do something like this, not elegant though 🙂  ...   for r in response:   # iterates through all the devices found     print(r['serial'])     ls = r['latencyStats']     bt = ls['backgroundTraffic']     print(bt['avg'])     rd = bt['rawDistribution']     for rdi in ["0", "1", "2", "4", fill in the rest of the indices]:         print(rd['rdi'])   I've just typed this on the fly, obviously you'd want to format the printing properly ... View more

The first post won't work, at minimum you need the timespan.   You aren't posting much of the code, which package are you using?   I'm guessing, but as a test, try...   response4 = dashboard.wireless_health.getNetworkLatencyStats("L_637822297226351454", timespan=86400) print(response4)   ... View more

Go to Organization->Firmware upgrades   Then the "All Networks" tab   It will give you a list of networks and firmware status, select the network(s) and then click the "Schedule upgrades" button.   (Or at network level, go to the Network-wide->General page for the network, and you can also do it there.   If you don't get the option to upgrade, check that your AP(s) are supported, from release notes...   This version, and subsequent MR 27.x versions, are only supported on the 802.11ac Wave 2 and 802.11ax MR product portfolio. 802.11ac Wave 1 and older products will not upgrade, should they be in networks configured for MR 27.x versions, and thus the new features will not be available and the bug fixes listed will not apply.   If your APs are supported, but no upgrade is enabled, contact support as maybe they need to enable the beta on your network(s). ... View more

Have you actually got 27.1 running on your APs? until then I do not think you will see the option.   In the dropdown API Version list I have: "V1", "V2", and "V3 (beta)"   If you have installed the firmware, but the v3 option is still not there then open a case and request that they enable it for you.   ... View more

I can see the beta available in Dashboard, it shows MR 27.1 currently.   It's been running on some APs on our test/demo networks for a couple of weeks, I just checked, it seems to be picking up beacons and other devices I don't recall seeing in the Bluetooth client lists before.   Do you have beta firmware enabled for the network(s) that the APs are on?   If you don't have it available, just open a case in Dashboard and request Meraki support enable it for you, this is what I do if I need early access.   ... View more

You need something to receive HTTPS GETs/POSTs on a port of your choice (it used to work with HTTP, but now it must be HTTPS).   Once the initial authentication step is complete, you just receive a stream of POSTs with JSON CMX data.   If you look at the developer site there are some examples linked to it (examples may pre-date the move to HTTPS)...   https://developer.cisco.com/meraki/scanning-api/#!introduction/scanning-api   ...I think this one shows things pretty clearly...https://developer.cisco.com/meraki/ ...look at the 'Location Services' tab, there's also a tutorial... https://developer.cisco.com/learning/lab/meraki-03-location-scanning-python/s   ... View more

Back in April I had a similar problem in development/test of a daily scheduled API extract that ran just after 0000 UTC, there would be short burst of 'page not found' errors, on c. 10-20% of the runs, affecting just a few calls out of many in a run.   In case around 0000 UTC is a busy or somehow 'bad' time, I thought I'd shift things a bit later, there were no further errors.   However, this was during development/test, and there were other changes in the next few days, in particular: - using api.meraki.com instead of api-mp.meraki.com - moved over to the API V1 beta ...it might be worth experimenting with these.   Since late April there've been no further errors, even though the extracts are running against multiple orgs now. ... View more

There's a roundabout way you can get some of what you are after...   i) you can get PoE usage for all the ports on a switch (in watt hours for the specified timespan) with get /devices/{serial}/switchPortStatuses   ii) you can get the switch model name, then use a lookup table to find the PoE power budget for the switch   Doesn't help you with number of power supplies, but it will give you PoE usage and budget ... View more

Thanks for the feedback   I'd also done some testing in the meantime (just using getDeviceSwitchPortStatuses )   If t0 is not specified, then the default timespan 24 hour lookback "from today" means from 'now'   From what you've found, the 31 days lookback "from today" has enough margin for 32x86400 seconds lookback from midnight 'tonight'   i.e. a monthly run on the 1st would always be able to get a full month's data for the previous month, though of course with no safety margin if something delayed the query until the 2nd or later   On the port status data I've gone with taking daily samples just after midnight with t0 at midnight the day before, then assembling into monthly files (to match our customers' reporting frequency), that way if there was a problem it could be recovered, though in this instance a day's missed sample isn't going to matter   I need to make a general wish to be able to set absolute start and end times for sample windows, at least on this call it seems the end is always 'now', as only one of t0 or timespan can be specified according to the documentation   ... View more

Assuming version 1.3...   Once you have followed the steps in the guide, wait, how long depends on how many devices there are   For <100 takes a few minutes, you'll see the Meraki devices appear under Provision->Devices in the Global level hierarchy   From there you can assign them to site(s)   Afaik you can't do much more, for instance... - if you try to provision individual device(s) it will let you try but the end result will be one error per device saying that you can't provision Meraki devices - it doesn't recognize a Meraki AP as eligible to be placed on a floor plan   I recommend using a Meraki admin account that has access to only one Organization, the Dashboard API key will give DNAC access to every Org that the user ID has access to   I've only played with it briefly with DNAC 'Device Controlability' on the Dashboard device set to 'disabled' as I've not seen any documentation explaining what DNAC can/might do if enabled   ... View more