We don't maintain any concept of an undocumented feature. ... View more

Hi Ryan, once you have gathered the port schedule IDs for a device, use getOrganizationConfigurationChanges afterward to see if it ever changed. This is much more efficient than gathering per-device configs over and over. ... View more

Hi @Quokka, these operations are all part of the latest Python libraries. Please ensure you're using 1.53 or later.   If you are seeing timestamps from 1970, I'd work with Meraki Support to nail down the cause. ... View more

If we take getNetworkClients as an example. There's only one documented path for this operation, which is {baseUri}/networks/{networkId}/clients.    Using undocumented base URIs is a separate issue, and covered in this notice. ... View more

Hi @seb90 I also tested this out and I found that I got that None response, too, so I'm with you! Coincidentally, I was involved in the original development of this operation, and I know it did work, once upon a time 🦄🌈👸🏼.   Meraki Support is your best bet for a solution. But I know that traffic analytics are calculated according to one of two frameworks: the first, TA, is legacy. The newer one, NBAR, is what I'm using today and have been using for months. It's possible that the API operation queries TA data, finds none, then response None. Probably not an ideal result. Coincidentally, my Organization > Summary Report page "Top applications by usage" does show results, so perhaps the GUI page is using a different operation in the backend.    Either way, I think the network ID filter is a red herring, and I recommend reporting it to Meraki Support. ... View more

API docs issues would go through Support. Python library issues would go through the GitHub repo. ... View more

An org-wide switch ports usage history operation,  getOrganizationSwitchPortsUsageHistoryByDeviceByInterval,  has also been released. For usage information, this operation is far more efficient than using the getDeviceSwitchPortsStatuses operation, and unlike the single-device operation, offers t1 controls and a history. This one will be included in the January 2025 docs update. In the meantime, here's the schema:   { "/organizations/{organizationId}/switch/ports/usage/history/byDevice/byInterval": { "get": { "description": "List the historical usage and traffic data of switchports in an organization.", "operationId": "getOrganizationSwitchPortsUsageHistoryByDeviceByInterval", "parameters": [ { "name": "organizationId", "in": "path", "description": "Organization ID", "schema": { "type": "string" }, "required": true }, { "name": "t0", "in": "query", "description": "The beginning of the timespan for the data. The maximum lookback period is 31 days from today.", "schema": { "type": "string" } }, { "name": "t1", "in": "query", "description": "The end of the timespan for the data. t1 can be a maximum of 31 days after t0.", "schema": { "type": "string" } }, { "name": "timespan", "in": "query", "description": "The timespan for which the information will be fetched. If specifying timespan, do not specify parameters t0 and t1. The value must be in seconds and be less than or equal to 31 days. The default is 1 day. If interval is provided, the timespan will be autocalculated.", "schema": { "type": "number", "format": "float", "maximum": 2678400 } }, { "name": "interval", "in": "query", "description": "The time interval in seconds for returned data. The valid intervals are: 300, 1200, 14400, 86400. The default is 1200. Interval is calculated if time params are provided.", "schema": { "type": "integer" } }, { "name": "perPage", "in": "query", "description": "The number of entries per page returned. Acceptable range is 3 - 50. Default is 10.", "schema": { "type": "integer" } }, { "name": "startingAfter", "in": "query", "description": "A token used by the server to indicate the start of the page. Often this is a timestamp or an ID but it is not limited to those. This parameter should not be defined by client applications. The link for the first, last, prev, or next page in the HTTP Link header should define it.", "schema": { "type": "string" } }, { "name": "endingBefore", "in": "query", "description": "A token used by the server to indicate the end of the page. Often this is a timestamp or an ID but it is not limited to those. This parameter should not be defined by client applications. The link for the first, last, prev, or next page in the HTTP Link header should define it.", "schema": { "type": "string" } }, { "name": "configurationUpdatedAfter", "in": "query", "description": "Optional parameter to filter items to switches where the configuration has been updated after the given timestamp.", "schema": { "type": "string", "format": "date-time" } }, { "name": "mac", "in": "query", "description": "Optional parameter to filter items to switches with MAC addresses that contain the search term or are an exact match.", "schema": { "type": "string" } }, { "name": "macs", "in": "query", "description": "Optional parameter to filter items to switches that have one of the provided MAC addresses.", "schema": { "type": "array", "items": { "type": "string" } } }, { "name": "name", "in": "query", "description": "Optional parameter to filter items to switches with names that contain the search term or are an exact match.", "schema": { "type": "string" } }, { "name": "networkIds", "in": "query", "description": "Optional parameter to filter items to switches in one of the provided networks.", "schema": { "type": "array", "items": { "type": "string" } } }, { "name": "portProfileIds", "in": "query", "description": "Optional parameter to filter items to switches that contain switchports belonging to one of the specified port profiles.", "schema": { "type": "array", "items": { "type": "string" } } }, { "name": "serial", "in": "query", "description": "Optional parameter to filter items to switches with serial number that contains the search term or are an exact match.", "schema": { "type": "string" } }, { "name": "serials", "in": "query", "description": "Optional parameter to filter items to switches that have one of the provided serials.", "schema": { "type": "array", "items": { "type": "string" } } } ], "responses": { "200": { "description": "Successful operation", "content": { "application/json": { "schema": { "type": "object", "properties": { "items": { "type": "array", "items": { "type": "object", "properties": { "name": { "type": "string", "description": "The name of the switch." }, "serial": { "type": "string", "description": "The serial number of the switch." }, "mac": { "type": "string", "description": "The MAC address of the switch." }, "network": { "type": "object", "properties": { "name": { "type": "string", "description": "The name of the network." }, "id": { "type": "string", "description": "The ID of the network." } }, "description": "Identifying information of the switch's network." }, "model": { "type": "string", "description": "The model of the switch." }, "ports": { "type": "array", "items": { "type": "object", "properties": { "portId": { "type": "string", "description": "The string identifier of this port on the switch. This is commonly just the port number but may contain additional identifying information such as the slot and module-type if the port is located on a port module." }, "intervals": { "type": "array", "items": { "type": "object", "properties": { "startTs": { "type": "string", "format": "date-time", "description": "The starting timestamp of the given interval." }, "endTs": { "type": "string", "format": "date-time", "description": "The end timestamp of the given interval." }, "data": { "type": "object", "properties": { "usage": { "type": "object", "properties": { "total": { "type": "integer", "description": "The total amount of data sent and received (in kilobytes)." }, "upstream": { "type": "integer", "description": "The amount of data sent (in kilobytes)." }, "downstream": { "type": "integer", "description": "The amount of data received (in kilobytes)." } }, "description": "Usage data for the given interval." } }, "description": "A breakdown of how many kilobytes have passed through this port during the interval timespan." }, "bandwidth": { "type": "object", "properties": { "usage": { "type": "object", "properties": { "total": { "type": "number", "format": "float", "description": "The average speed of the data sent and received (in kilobits-per-second)." }, "upstream": { "type": "number", "format": "float", "description": "The average speed of the data sent (in kilobits-per-second)." }, "downstream": { "type": "number", "format": "float", "description": "The average speed of the data received (in kilobits-per-second)." } }, "description": "Bandwidth usage data for the given interval." } }, "description": "A breakdown of the average speed of data that has passed through this port during the interval." }, "energy": { "type": "object", "properties": { "usage": { "type": "object", "properties": { "total": { "type": "number", "format": "float", "description": "The total energy in watt-hours delivered by this port during the interval" } }, "description": "Energy data for the given interval." } }, "description": "How much energy (in watt-hours) has been delivered by this port during the interval." } } }, "description": "An array of intervals for a port with bandwidth, traffic, and power usage data." } } }, "description": "The number of ports on the switch with usage data." } } }, "description": "Switches" }, "meta": { "type": "object", "properties": { "counts": { "type": "object", "properties": { "items": { "type": "object", "properties": { "total": { "type": "integer", "description": "The total number of items in the dataset" }, "remaining": { "type": "integer", "description": "The number of items in the dataset that are available on subsequent pages" } }, "description": "Counts relating to the paginated items" } }, "description": "Counts relating to the paginated dataset" } }, "description": "Metadata relevant to the paginated dataset" } } }, "example": { "items": [ { "name": "Example Switch", "serial": "Q555-5555-5555", "mac": "01:23:45:67:ab:cd", "network": { "name": "Example Network", "id": "L_12345" }, "model": "MS120-8", "ports": [ { "portId": "1", "intervals": [ { "startTs": "2024-02-11T00:00:00.090210Z", "endTs": "2024-02-11T00:20:00.090210Z", "data": { "usage": { "total": 40867, "upstream": 23008, "downstream": 17859 } }, "bandwidth": { "usage": { "total": 2.2, "upstream": 1.2, "downstream": 1.0 } }, "energy": { "usage": { "total": 2.2 } } } ] } ] } ], "meta": { "counts": { "items": { "total": 1, "remaining": 0 } } } } } }, "headers": { "Link": { "schema": { "type": "string" }, "description": "A comma-separated list of first, last, prev, and next relative links used for subsequent paginated requests." } } } }, "summary": "List the historical usage and traffic data of switchports in an organization.", "tags": [ "switch", "monitor", "ports", "usage", "history", "byDevice", "byInterval" ] } } }   ... View more

Hi @NathanL which API operation(s) did you use that evidenced this issue?    The getNetworkDevices operation mentioned above is deprecated, so I'm interested if this is happening with any operations that aren't deprecated. ... View more

I would leverage port profiles instead of switch profiles. Several API operations are available in Early Access: https://developer.cisco.com/meraki/api-v1/search/?q=port%20profile ... View more

If you're using both classic Meraki and Catalyst devices, then I'd look at https://developer.cisco.com/meraki/api-v1/get-organization-firmware-upgrades-by-device/ instead. This one breaks it out by device, but might more work to consume if you're classic Meraki only. ... View more

I'm not sure how closely those numbers should align, because I'm not familiar with the methods that produce the data. But it is something that you can review with Support, if you're interested.   If you're comparing API with GUI, then you'll need to make sure that you're using the same timespan controls on the API as on the GUI, and it's possible that you'll need to map timezones if you want them to line up (API uses UTC, org-wide data in GUI typically uses UTC, network-specific data in GUI often uses the network's configured timezone). ... View more

For long-term data storage, you will be well served to store data client-side. You can know when/if to update the data by following the availabilities change history operation on some regular interval (e.g. once every 2 weeks). ... View more

You could alternatively calculate the total usage by multiplying the "average" usage with the "counts" value from this operation: https://developer.cisco.com/meraki/api-v1/get-network-clients-overview/   x = counts.total = total number of clients y = usages.average = average usage per client   x * y = total client usage ... View more

Hi @Jason_42 at a glance, your script looks pretty solid (haven't tested). For classic Meraki devices you can simplify however by leveraging the relationship between network and device. For example, for classic Meraki devices, all devices of a given product type in a network have the same firmware version. So you only need firmware version once per network per product type, rather than once per device.   You can also leverage the fact that the FW version doesn't change unless an admin or Meraki schedules an upgrade.   With that in mind, another way to build the report would be to:   1. getOrganizationFirmwareUpgrades, which you're already polling, which gives you the completedAt timestamp (that's the one you need for each device's "date firmware applied" column), the toVersion.shortName attribute, and the productTypes attribute. 2. getOrganizationDevices instead of the deprecated getNetworkDevices, which gives you all the devices serials, models, and their product type and network IDs.   From there, for each device, pair it with the relevant info from getOrganizationFirmwareUpgrades.  ... View more

Device models do not change, and can be inferred from the four-letter prefix of the serial number. So once per model you can build the mapping and infer the model client-side, if you like. ... View more

Hi @CBurkhead , if the device is offline for 2+ weeks, then it's dormant. If it's "offline" then it can only be offline for <2 weeks, in which case it's necessarily within the timespan of change history. It would have to be offline for more than a month for it to not have status change information in the change history operation, in which case, Meraki dashboard is probably not the source of truth you need to find out why it went offline, in any case, since it's almost certainly not a Meraki-side issue that explains why it went offline. Of course, if your application polls the change history once a month, then you'd have this information as well, for posterity. ... View more