Apologies for bumping an old thread, but Google points here -- is this really still the case? Is there no API endpoint to view uptime or ... anything? ... View more

Sure can, and I do, it's just that I would prefer if I had a more direct way to make this query, like the v0 API, which allows a request for a specific MX.   Now I have to account not only for searching the data, but presumably pagination as well for sufficiently large organizations.     ... View more

I'm providing network monitoring with the API, and each firewall is a node that has its own 'instances' that are polled regularly. I can't make a single call and then distribute that data to each node. ... View more

Thanks for the example John, however I'm not able to avoid making a call for every MX I need to check. Granted the amount of 'waste' we're talking about is trivial, there should still be a filter available on this call. Caching is also not an option.   I understand v1 was just released, so I'm curious if the intent is to stick with bulk requests like this, or if targeted/filtered calls will be introduced down the road.     ... View more

Understood, thanks! ... View more

Yep, that was it, I forgot about the pagination. Thanks! ... View more

I had to do something similar, I just poll the past 5 minutes every 5 minutes, and average the values (sloppy but I don't actually need granular accuracy).    It's unfortunate that the API doesn't enforce a minimum time frame, it would avoid a lot of confusion.  ... View more

I definitely know the feeling! Really hoping that as v1 gets developed this becomes less of an issue. It looks like that's happening, based on the layout of the new web page. I'm assuming the "schema definition" section will list out all potential field values. ... View more

Yep, I've been getting used to just looking at output over and over until I find exceptions 🙂 ... View more

Fortunately I'd never have enough for it to ever meaningfully skew the data, good point though! ... View more

Gotcha, thanks for confirming Philip. ... View more

Thanks for helping me confirm!   The API apparently returns 'null' instead of zeros when there haven't been any connection attempts in the specified timespan.   Expected: { "assoc": 0, "auth": 0, "dhcp": 0, "dns": 0, "success": 0 }   Actual: null   ... View more

I think the issue is that the uplinks probably aren't in the ideal configuration for HA, as well as the fact that you apparently can't do 3 uplinks on an MX. It would be best if we knew what your topology looked like exactly.   Ideally, you'd bring circuit A into your switching on VLAN X, and attach both MX's primary uplinks to the switching on VLAN X. Repeat for circuit B, on VLAN Y, with the MX's secondary uplinks also on VLAN Y. This would utilize a switch stack, with each circuit on a different stack member.    This allows either MX to operate on both circuits, via VRRP.   This is problematic however if your circuits do not have at least a /29 allocated, because VRRP won't have enough enough addresses.(Network ID, broadcast, gateway, MX 1, MX 2, VIP = 6 IPs)   The 3rd circuit would have to go on some other device, so I imagine that and the above are why you're in this situation.   But back to your API query, you're probably in the same situation I am, in that the data from DeviceSwitchPortStatuses is on approximately a 5 minute refresh: https://community.meraki.com/t5/Developers-APIs/How-frequently-are-switch-port-status-packets-updated/m-p/76423#M2892    So that has the same problem as the 5 minute webhook delay, meaning automating quick custom failover using the API is basically off the table.   I'd suggest not removing the 3rd uplink, just move it to the standby MX. Worst case scenario, you just have to manually fail back to the primary, instead of getting stuck with the primary using the 3rd (and presumably worst) circuit. (I'm assuming your uplink preference is MX 1 uplink 1, MX 2 uplink 1, MX 1 uplink 2). ... View more

Thanks all! That makes sense and I can work with knowing that it's about 5 minutes. ... View more

Haha, every time! ... View more

Think I figured it out, UpdateNetworkDeviceModel does not behave properly.   name = dictionary.get('name') tags = dictionary.get('tags') lat = dictionary.get('lat') lng = dictionary.get('lng') address = dictionary.get('address') notes = dictionary.get('notes') move_map_marker = dictionary.get('moveMapMarker') switch_profile_id = dictionary.get('switchProfileId') floor_plan_id = dictionary.get('floorPlanId')   All possible fields are always returned and sent in the PUT. For values you did not pass, like switch_profile_id, null is returned. The API rejects a null value for this key.   Passing the parameters composed by the Python API to curl results in various errors:   {"errors":["Device's network must be bound to a configuration template (that supports switches) to allow for switch profile binding"]} {"errors":["'moveMapMarker' must be a boolean"]}   So TL;DR the underlying UpdateNetworkDeviceModel has to be updated with additional logic to not send invalid values when they're not set. ... View more