I've been looking at how to replicate our existing reporting/analytics without polling using getOrganizationDevicesStatuses but it's not straightforward... The replacements don't include publicIP, which is useful for simply inferring whether it's a single device outage, or one where a device/WAN/other failure is taking out multiple devices. I don't see another simple way to get the publicIP, calls that get it for MX/Z are no use as not all devices are behind an MX/Z. Am I missing an easy way to get publicIP? If not, can it be added at least to the replacement operation getOrganizationDevicesAvailabilities it shouldn't break anything. Also, one of our main use cases is contractual SLA analysis/reporting, which typically is calendar month, sometimes also by local timezone. I'd certainly like to move from our current polling approach to a monthly one, but for that a lookback of at least a couple of days more than 31 days is needed to allow for timezones and any transient problems that delay colection, otherwise we lose data. The https://developer.cisco.com/meraki/api-v1/get-organization-devices-availabilities-change-history/ documentation says has a maximum lookback of 2678400, exactly 31 x 24 x 60 x 60, meaning that unless we ran it at 235959 on the last day of the month for each timezone, it's possible to lose visibility. In practice we run 'monthly' data gathering early UTC on the 2nd of the following month, simply allowing for where we need to report by local timezone and to giving some buffer in case of a problem. The 'easy' way out would be to run it daily instead of monthly, but IMHO it'd be better if this and other calls with one-month lookback hard limits were extended by a couple of days to fit better with the common customer desire to have monthly reports and the need for a bit of contingency 😀
... View more
