getOrganizationDevicesAvailabilitiesChangeHistory broken?

[sungod]

With the deprecation and other issues affecting the getOrganizationDevicesStatuses endpoint, I'm finally getting round to redoing things to use getOrganizationDevicesAvailabilities and getOrganizationDevicesAvailabilitiesChangeHistory.

In testing, getOrganizationDevicesAvailabilitiesChangeHistory is returning out of time-bounds data, and what is returned looks weird...

Changes are returned that fall outside the bounds set by t0 t1, I'm using a one-day t0-t1 period in this instance.

Most 'changes' that are returned are not changes, i.e. old/new status value are the same.

This is from an org with a few hundred devices:

t0 2025-02-18T00:00:00Z

t1 2025-02-18T23:59:59.999999Z

old status	new status	timestamp
offline	online	2025-02-16T08:01:00.121999Z
online	online	2025-02-17T08:01:48.007999Z
online	online	2025-02-18T08:02:06.424999Z

The first two changes are out of t0-t1 bounds, the second two changes are not changes. I'm sure there was no such offline-online change on 16th on every device on every network.

Almost every device returns a similar triplet

It seems the endpoint is mostly returning spurious/bad data.

I decided to try with other orgs. Overall, on three orgs the endpoint is returning only t0-t1 in-bounds data, on three it is behaving as above.

But even on the three orgs where only data for 18th is returned, it is mostly 'changes' from online to online, it's not a change, why is it there?

I really have no idea what, if any, data can be trusted from this endpoint. Is this expected behaviour? It is not as I expect from documentation.

Can anyone from Meraki check/comment on this? I can PM org IDs.

[GreenMan]

A case raised via Meraki Support would be the correct route for this kind of ask.

[sungod]

Yeah, I know, but support always start with "prove it" and a default position that it's my fault.

Before I go down that route, I'd first like to know if this is expected behaviour, and/or if others are not getting the same results.

[Inderdeep]

If i have the laugh button here, i will give you multiple laugh kudos 🙂 

[theo2889]

Were you ever able to get an answer on this? I’m seeing the same thing, and it’s going to be an issue when I switch all of my services over to this call and the history takes 10x as long to return than the availability call. 

[sungod]

After hitting the problem, I gave up on the history endpoint as the priority was moving off the deprecated getOrganizationDevicesStatuses which has been having issues affecting our customer reporting.

Now I'm just polling https://developer.cisco.com/meraki/api-v1/get-organization-devices-availabilities/ it seems to be working correctly. Switched over to this the last week of February and next week we will be doing a full month cross-check against our independent service management platform to see if the two match.

[theo2889]

Got ya. Well I reached out to my contact at Meraki and I’m going to provide them with a ton of data on the issues this morning and he’s going to engage the product team. They were not aware of the issue, so hopefully we find the root cause and they can get it fixed. I’ll keep you updated. 

[GreenMan]

At the risk of receiving some 'feedback'...   the product team would likely have been aware, had the case been raised with Support.   I understand that this only comes accompanied by providing potentially quite a lot of information capturing the detail, all of which takes valuable time, but it really is the best (and only real official) path to raising a problem with the engineering team.   Having a case reference (a parent case) helps tie everything together.