getOrganizationDevicesStatuses is now deprecated

[RaphaelL]

Hi ,

So I just found out that getOrganizationDevicesStatuses is now deprecated and should be replaced by getOrganizationDevicesAvailabilities and other variants. https://developer.cisco.com/meraki/api-v1/deprecation/#deprecated-operations

I'm fine with that , however with getOrganizationDevicesStatuses we used to be able to get the device model which we do not in getOrganizationDevicesAvailabilities. 

It was useful information for us for many reasons. Is it possible to add-it ?

Cheers ,

[LearningIsFun]

In the meantime you could get the device models from call "getOrganizationDevices"

https://developer.cisco.com/meraki/api-v1/get-organization-devices/

[RaphaelL]

Thanks for the suggestion. This is exactly the workaround we have at the moment

[John_on_API]

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.

[CBurkhead]

From looking at these new endpoints, it seems clear that trying to get some status information for a device that has been offline for more than a month will not be possible. You can get the information that it is offline, but not when it went offline. The last seen datetime that is in the current organization status endpoint is not in getOrganizationDevicesAvailabilities and though you can get this from the offline data returned by getOrganizationDevicesAvailabilitiesChangeHistory, you can't retrieve data more than a month old with that endpoint. Does anyone know where/how to get the datetime a device was last seen for a device that does not involve getOrganizationDevicesStatuses?

[John_on_API]

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.

[CBurkhead]

For the purposes of this application, offline vs. dormant is not relevant. We have customers that are not always quick to allow the repair/replacement of devices at their sites, so there are devices that stay offline for long period of time. We keep track of these on a dashboard that refreshes periodically. This dashboard is also used to monitor more current offline devices as well. Yes, if any of these older devices come online, we will get the normal Meraki email, but we want some backup as well. I would like to be able to avoid having to save datetime data to a file if there is another source for the "last seen" information, but if this is no longer going to be available though the API past a month's time, I will do what I need to do.

[John_on_API]

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).

[sungod]

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 😀