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

Please do report this to support. ... View more

Hi @MilosJovanovic taking off my employee hat and speaking as a civilian, this sounds a bit like unintended behavior. You might want to check with support on this -- imho, MQTT should use the same network ID that dashboard API uses.   You might report this as "MQTT API doesn't use the network ID in topics" and point them to this thread.   In the meantime, I think you'll need to use the device serial number, and poll getOrganizationDevices (you can filter on productTypes[]=wireless, if you only care about MR), to find out what the network ID of a given MR is.   Putting the employee hat back on, this is a limitation on the MQTT side, and not a flaw with dashboard API. ... View more

Status, latency, etc. changes can be alerted on for WAN2 and other uplinks with the Meraki Insight feature set. I think it's included in the SD-WAN license tier. ... View more

I do not understand--you should not need to reprocess the entire organization if you are using the changelog operation (getOrganizationConfigurationChanges), which would give you, at the top of its response, an entry like this, if someone changes the name of a device:   { "ts": "2024-09-10T23:13:53.834424Z", "adminName": "Person Name", "adminEmail": "your@email.address", "adminId": "0", "networkName": "NETWORK NAME", "networkId": "L_000000000000000000", "networkUrl": "/URL_HERE/manage/usage/list", "ssidName": null, "ssidNumber": null, "page": "Cellular Gateways", "label": "Updated name", "oldValue": "bc:db:09:00:00:00: OLD NAME", "newValue": "bc:db:09:00:00:00: NEW NAME", "oauthClientId": null }   With the old/new value attributes you not only have the MAC of the device, you also have both the new and the old names.    Why would you have to reprocess the entire organization? ... View more

In addition to @Kevin_R's advice, AirMarshal SSIDs, rules and settings are all queryable via API: https://developer.cisco.com/meraki/api-v1/search/?q=airmarshal   ... View more