John,   this call is what we need to meet a customer reporting requirement, but it seems to have major problems - I've tried it on two different MX devices. Whether used via the Meraki Python library, or using the test window on the Meraki developer hub, it returns values that are dramatically larger than Dashboard reports, and sometimes far higher than a physical uplink is capable of.   Choosing a network with MX84 HA pair (similar discrepancy occurs with a single MX65W)...   For the 'last day', Dashboard summary reports c, 400 MB download / 490 MB upload.   The same network, with timespan and sample period both 86400 is below, the result the developer hub page gives has figures far higher than Dashboard.   A separate issue is why are two cellular uplinks reported, both called 'cellular'? This uplink is not configured, but I could understand one appearing as an idle default, but two with the same name seems very strange.     [ { "startTime": "2022-06-20T00:00:00Z", "endTime": "2022-06-21T00:00:00Z", "byInterface": [ { "interface": "cellular", "sent": 0, "received": 0 }, { "interface": "cellular", "sent": 0, "received": 0 }, { "interface": "wan1", "sent": 1234125007, "received": 681064422 }, { "interface": "wan2", "sent": 256459293, "received": 307045519 } ] } ]         ... View more

I'm also seeing a massive discrepancy between the data from this API call and what Dashboard shows.   For a network that contains only an MX84 HA pair, with dual WAN links:   For 20th June (from 000000 to 23599 UTC), with 600 second sample period, API data says... Total Tx bytes  1,484,364,604 Tota Rx bytes     982,713,386   Changing to a 3600 seconds sample period gives only slightly different values 1,453,143,728 and  953,523,815 so it isn't especially sensitive to sample period.   Also, looking at the numbers returned, the reported bytes transferred (both tx and rx)  in the 600 seconds often far exceeds the capacity of the WAN link.   Dashboard summary report for that network on the same day... Total data uploaded       490.7 MB Total data downloaded  404.3 MB   I also checked on an MX65W, the API reports c. 150MB for both send and received, the Dashboard summary reports 0 kilobytes for both, again a big discrepancy.   The API call is reporting more than twice the Dashboard figure, and also impossibly high transfer rates for the sample time period.   Seems clear the API call is returning bad data.   ... View more

Yes, I forgot that, if the plan is rotated you'd need to transform coordinates.   I guess you could calculate the floorplan's angle of rotation using Pythagoras, then counter rotate all coordinates to proceed as above.   ... View more

Not tried it, but I'd just calculate the absolute difference from lower-left lat/long to top-left and AP lat/long values to normalise them to that corner, i.e. lower-left becomes 0,0 in the coordinate system.   Then figure out the scale based on the lower-left top-left difference (I'm simplifying by pretending we're on a plane not a sphere, which for likely floorplans is fine)...   Divide drawing height (in metres) by the lower/top-left latitude difference to get the scaling factor, multiply the AP latitude by that to get AP distance 'up' from lower-left. Use the same scale factor on the AP longitude to get horizontal distance from lower left.   If you sketch things out on a piece of paper with some real values and do the calculations by hand, it'll help see how this works.   It's a quick and dirty method, should be good enough for likely floor sizes away from the poles, if you search online you can find more rigorous methods that take into account that we're (roughly) on a sphere.   ... View more

The device list returned by getNetworkFloorPlans includes the APs on the floor plan and each AP's latitude and longitude.   https://developer.cisco.com/meraki/api-v1/#!get-network-floor-plans   It also returns the latitude and longitude of each of the floorplan's corners, its centre and also the width and height of the floor plan.   From that you can calculate each AP's position in metres from the corner.   ... View more

I use openpyxl to create excel files, instructions and tutorial are here... https://openpyxl.readthedocs.io/en/stable/   ... View more

I just cut/pasted direct from a script that I added timespan to, it works when I run it...   t=31*24*60*60 ports = await aiomeraki.switch.getDeviceSwitchPortsStatuses(d['serial'], timespan=t)   ... View more

The Python library supports timespan...   def getDeviceSwitchPortsStatuses(self, serial: str, **kwargs): """ **Return the status for all the ports of a switch** https://developer.cisco.com/meraki/api-v1/#!get-device-switch-ports-statuses - serial (string): (required) - t0 (string): The beginning of the timespan for the data. The maximum lookback period is 31 days from today. - timespan (number): The timespan for which the information will be fetched. If specifying timespan, do not specify parameter t0. The value must be in seconds and be less than or equal to 31 days. The default is 1 day. """   Usage would be like...   serial="1234-1234-1234" t=31*24*60*60 getDeviceSwitchPortsStatuses(serial, timespan=t)   ... View more

This call  https://developer.cisco.com/meraki/api-v1/#!get-device-switch-ports-statuses   allows timespan up to 31 days (timespan=2678400).   The way you add the parameters depends how you are coding, i.e. Meraki Python library, crafting you own URLs, something else etc.   I suggest look at the linked page (see the 'template' tab on the right for a few examples) and associated usage info. ... View more

I'd think you need to add extra things to the existing PYTHONPATH or other variables, rather than add it standalone.   I.e. if the one you're adding is overriding the existing one set up by the install, it'd explain why other things stopped working.   If the original settings are lost, just repeat the Python install.   Then check the value of PYTHONPATH, whatever it is, append the location of the Meraki package, each path in the list is separated with a semicolon ;   If you type    pip show meraki    it'll tell you the install path. ... View more

Sounds like an issue with your install/set-up, I'd guess the search path in the environment is not set correctly.   I'm not familiar with Python on VS/Windows, but try checking the PYTHONPATH setting, see here in the Windows section...   https://bic-berkeley.github.io/psych-214-fall-2016/using_pythonpath.html   ...this page also includes a simple script to tell you the value of the variable, if you run it in VS and then as executable, see if the answers differ.   ... View more

If it were possible for an admin to define multiple org-specific keys that were either full admin or read-only, it'd address many of my wishes.   As it stands I (or another admin) need to create multiple logins, each needing a different email alias, each needing TFA set-up. If the admin changes, it all needs ripping up and redoing. It's not a good solution with multiple orgs.   The API authentication process starts with the key, clearly the logic to look-up a key is there.   That's the point at which the access privileges for that key are established it doesn't seem a huge complication to make those privileges those of the key rather than of the owning admin.   If it really must be based on a user ID, then let admins create multiple aliases that each have only one editable thing in their user profile: the API key (everything else just inherits from the parent ID.)   The login email address could use a syntax like n!real.email@real.com  where the n is a Dashboard generated 'alias ID' followed by a '!', so we don't need to create and manage real email aliases, there's still only the single admin email - this alias isn't ever used as an email address, the ! is never going to get routed as a bang path 😀   Then we just add the alias ID as the admin and it can have it's own org access settings.   It's a bit of a 'bag on the side', but again it's something that feels it should be possible as a simple extension.   ... View more

You need to specify the destination IP, it's mandatory.   For instance, if I get the details for a few minutes for WAN 1 on an MX that is set to use 8.8.8.8 for it's latency reporting, with query parameters...   timespan 1200, resolution 60, interface wan1, ip 8.8.8.8   I get...   [ { "startTs": "2022-05-31T12:48:00Z", "endTs": "2022-05-31T12:49:00Z", "lossPercent": null, "latencyMs": null, "goodput": null, "jitter": null }, { "startTs": "2022-05-31T12:49:00Z", "endTs": "2022-05-31T12:50:00Z", "lossPercent": 0, "latencyMs": 13.96, "goodput": 100000, "jitter": 0.35 }, { "startTs": "2022-05-31T12:50:00Z", "endTs": "2022-05-31T12:51:00Z", "lossPercent": 0, "latencyMs": 13.92, "goodput": 100000, "jitter": 0.38 }, { "startTs": "2022-05-31T12:51:00Z", "endTs": "2022-05-31T12:52:00Z", "lossPercent": 0, "latencyMs": 13.95, "goodput": 100000, "jitter": 0.34 }, { "startTs": "2022-05-31T12:52:00Z", "endTs": "2022-05-31T12:53:00Z", "lossPercent": 0, "latencyMs": 14.04, "goodput": 100000, "jitter": 0.53 }, { "startTs": "2022-05-31T12:53:00Z", "endTs": "2022-05-31T12:54:00Z", "lossPercent": 0, "latencyMs": 13.9, "goodput": 100000, "jitter": 0.28 }, { "startTs": "2022-05-31T12:54:00Z", "endTs": "2022-05-31T12:55:00Z", "lossPercent": 0, "latencyMs": 13.87, "goodput": 100000, "jitter": 0.35 }, { "startTs": "2022-05-31T12:55:00Z", "endTs": "2022-05-31T12:56:00Z", "lossPercent": 0, "latencyMs": 13.91, "goodput": 100000, "jitter": 0.21 }, { "startTs": "2022-05-31T12:56:00Z", "endTs": "2022-05-31T12:57:00Z", "lossPercent": 0, "latencyMs": 13.85, "goodput": 100000, "jitter": 0.29 }, { "startTs": "2022-05-31T12:57:00Z", "endTs": "2022-05-31T12:58:00Z", "lossPercent": 0, "latencyMs": 13.94, "goodput": 100000, "jitter": 0.3 } ]   ... View more

As above, sounds like an issue with your install/set-up, I'd guess the search path in the environment is not set correctly.   I'm not familiar with Python on VS/Windows, but try checking the PYTHONPATH setting, see here in the Windows section...   https://bic-berkeley.github.io/psych-214-fall-2016/using_pythonpath.html   ...this page also includes a simple script to tell you the value of the variable, if you run it in VS and then as executable, see if the answers differ.   ... View more

It's just how the API calls behave.   When creating a network, dashboard says...   You can create a network with multiple types of Meraki hardware (Combined hardware) or a network for one type of hardware. Additionally you can create a Systems Manager network.   Afaik by default networks are 'combined', there's no documentation saying that the API return value includes only productTypes where one (or more) of a type is present.   I'd guess the latter return value is a legacy of internal structure from earlier times, as it doesn't include cameras or sensors.   ... View more

If you can't do it with action batch, and assuming you are using Python, another way to speed things up is use the asyncio option in the library.   This allows you to run the requests concurrently, much faster than iterating through hundreds/thousands of networks/devices waiting for each to complete   You may need to wrap some back-off and retry logic around the API calls as the rate limit will kick in and the built-in recovery in the library is not always enough.   See https://github.com/meraki/dashboard-api-python there are some examples.   ... View more

Bear in mind that you are using v0 API endpoints, v0 has been deprecated for some time and is now in sunset period where operation is not guaranteed, see: https://community.meraki.com/t5/Developers-APIs/Dashboard-API-v0-End-of-Support-Sunset-amp-Grace-Period/m-p/138696#M5473   You really should use v1, it is the current version and is where new features are added. ... View more

We saw API failures between 0100-0200 UTC on both USA and EU hosted organizations.   Seemed to be transient, only a couple of API calls failed hard enough for our system to give up on back-off/retry.   ... View more

Examples are in https://github.com/meraki/dashboard-api-python/tree/master/examples     ... View more

You can use https://developer.cisco.com/meraki/api-v1/#!get-device to get a device's coordinates.   ... View more

Have all the devices generating location data been correctly placed on the map?   I think any 'stray' ones may default to the SF area. ... View more

In general, the API call support for grabbing data for a specific time period is inconsistent, in some cases absent..   For events, I just grab the lot and iterate through with...   if event['occurredAt'] >= starttime and event['occurredAt'] <= endtime:     do something   ...to get events for the time period I want.   Forty years ago I was tweaking every line of assembler and using tricks to save CPU cycles, this just makes me feel dirty.   ... View more

You need to persuade them to open an internal case with the Dashboard-API support team. ... View more

For us the issue was resolved on 21st around midday UTC.   If you still see a problem then I suggest post a comment on the case you opened asking for an update.   ... View more

Normal operation still for me, no server disconnects/non-connects, using the gateway. ... View more