I fed this back to support on the case I opened and gave a link to your post.   They said they're investigating a wider issue than just my case, so good to know they are aware and working on resolution. ... View more

I've seen similar on n383 over the last couple of weeks, seems to be degrading over time.   From my end (using Meraki Python package), the problem is showing as server disconnects and server not accepting connections, rather than HTTP errors.   I opened a case yesterday, low priority but fast contact back from support, and then provided a lot of detail info to them.   As above, open a case is the best approach.   ... View more

Empty array typically means there are no matching events/other data, empty/null elements can  occur in many API responses.   You need to precisely define what you mean by "connected" and "disconnected", in the terms exposed by the available APIs and how wifi association/authentication work.   I.e. if a client moves out of range, there's no "disconnect me' event, it simply is no longer seen, but disconnection can still be inferred from the absence of information based upon some rules about things like when it was last seen.   The scanning API is used by commercial applications to determine client connect/other metrics (and at massive scale.)   In very simple outline, how the scanning API can be used...   detect a client not currently in list of connected clients, add it, set the 'first seen' timestamp   detect one that is already in the list, update the 'last seen' timestamp   periodically, go through the list, if the 'last seen' is too long ago, call it disconnected    There needs to be additional book-keeping to record/consolidate multiple sessions, but you see the basic idea.   This a very simplistic approach, in practice you'd also fuse with other data to refine results, such as RSSI, location, any authentication service info, data usage etc..   ... View more

For wireless clients, another approach is to use the scanning API... https://developer.cisco.com/meraki/scanning-api/#!introduction   Client data is delivered in real time to then analyse for 'presence' purposes. You can either write your own server, or there are open source and commercial options.   Another approach would be some kind of screen scraper to get what you need from the Location Analytics page on dashboard (which is driven by the same data as scanning API I think).   ... View more

Options depend on what type of client "connection" you are trying to measure.   Unless it is a connection type with explicit connected and disconnect events, you have to see what else you can use.   You could use https://developer.cisco.com/meraki/api-v1/#!get-network-clients   ...then call the difference between firstSeen and lastSeen the connection time for each client (within the sample period), you could then average the result.   But it is probably not going to be that accurate.   For wireless clients you could use...    https://developer.cisco.com/meraki/api-v1/#!get-network-clients   ...to get the list of clients (do it on each network), then iterate through the wireless ones with...     https://developer.cisco.com/meraki/api-v1/#!get-network-wireless-client-connectivity-events   ...using the assoc and disassoc events and timestamps to calculate the total time 'associated' over the sample period, call that the 'connected' time, then divide by clients to get the average.   ... View more

There are a generic methods (including some ready to use libraries) to 'flatten' JSON to key:value pairs, which you could then convert to row/column form.   But I don't really think that helps you as you'd just end up with umpteen columns named by the composite keys which you'd still need to interpret to make sense of the info.   When I extract data for reporting/analysis, I just write Python to pull out the bits I want from the nested structures, iterating through if necessary, and then output them as one row at a time in a standard column format of my choosing, that then feeds into downstream analysis routines.   Due to differences in the JSON structures returned depending on context (and sometimes null data), the code needs to be specific to the API call (and in some cases, the way the API call is being used and its target.)   From a quick look at the google sheet source, this is what it is really doing. It has specific output code for each API call it supports, i.e. it is not figuring it out dynamically, it is hard-coded.   See the code section titled "Reports"  https://gist.github.com/dexterlabora/9884aa4399715df8f453ea9de63255a0  that's the code from around line 688 onwards (at least with current numbering.)   ... View more

You need to handle multiple pages of client details if you are using the 'raw' API.   If you use the Python SDK, it will do the page handling for you, for instance...   clients = await aiomeraki.networks.getNetworkClients(net['id'], timespan=t, perPage=1000, total_pages="all")   ...can return many thousands of clients.   ... View more

When looking at a single day, the summary numbers on the Dashboard location analytics page are hourly averages (over the 24 hour day), otherwise they are daily averages.   The discrepancy you see may simply be due to that.   For a single day, if you had 24 devices connecting, each for an hour, I'd assume the hourly average would be one.   Though I'd guess time connected is also part of the calculation, so if the 24 devices each connected for a total of two hours, the hourly average would be two.   Comparing what is seen in Dashboard to what is calculated using API data is not always straightforward. To get the same answer you would need to replicate how the Dashboard calculation is being made (which is not something that is documented).       ... View more

I've found it still breaks down under load, such as when nested to get per device/other element data for hundreds of networks in 'one' aio call, then calls will intermittently fail with the error "429 Too Many Requests".   To handle that, inside the sub-functions there's a capped exponential backoff and retry if a failure occurs.   This issue certainly was in v0 and beta/early v1, perhaps the library code improved since then? But I've not tried running without the extra error recovery as it also helps gracefully recover from other transient errors that can occur.   This is used in scripts that daily pull various performance data for analysis for large organizations that we manage, it's important that it operates without human intervention to recover/re-run. Any time there's a 'new' error found, I try to add code to avoid/recover.   ... View more

This looks like the only call that returns app data, you'd need to try it against a test device to see if the return data gives what you are looking for... https://developer.cisco.com/meraki/api-v1/#!get-network-sm-device-softwares   You will need to find your organization ID, you can find it with... https://developer.cisco.com/meraki/api-v1/#!get-organizations   Also you need the network ID of a system manager network, use this to find all networks and choose an SM one... https://developer.cisco.com/meraki/api-v1/#!get-organization-networks   To create a script to automate things, the loop would be...   get all networks in the org with... https://developer.cisco.com/meraki/api-v1/#!get-organization-networks   iterate through that list, testing the productTypes element for each network that is a system manager network, run the get-network-sm-device-softwares call to get the device data   I recommend using the Python API library as it does a lot of the low level stuff for you... https://pypi.org/project/meraki/   ... View more

To get all networks (including the name) in an organization, you can use...   https://developer.cisco.com/meraki/api-v1/#!get-organization-networks   That'll give you all you are after with just two API calls.   If you've not tried it, the Python library simplifies using the API...   https://pypi.org/project/meraki/1.12.0/   ... View more

If you are using MX appliances for WAN connection, you can use...   https://developer.cisco.com/meraki/api-v1/#!get-organization-appliance-uplink-statuses   This will get you the status of every uplink in the organization, it includes the public IP.   ... View more

In the example you posted it looks like you are using the V0 API which I think is now deprecated, do you see the same with V1?   Fwiw I use the API across several organizations for monitoring/stats/analytics, using quite a few different endpoints, currently with the Python V1 library. Defensive programming with plenty of error recovery is essential, the error recovery in the library is certainly not always enough.   There will be faults at times, some may take quite a while to fix, but there will also be transient faults, including Internet/other issues unrelated to Meraki's infrastructure, all can disrupt things.   One thing that may reduce issues is using an organization's specific shard rather than the generic api.meraki.com, there's another recent thread about this.   You mention polling every minute, if that is on multiple networks/devices in an organization you might also be hitting the rate limit at times.   I guess you prefer the same approach on multiple vendors, but it seems odd to do such frequent polling of an orchestrator that can itself send you alerts as/when they occur, maybe you could get what you need more reliably via webhooks? ... View more

You can use this call on each network, it includes IP address...   https://developer.cisco.com/meraki/api-v1/#!get-network-devices ... View more

Don't think there's an org-wide call for clients.   You can just use getOrganizationNetworks to get the list of networks, then iterate over that with getNetworkClients to give you the complete client list, or use a filter argument to limit response to the one you want based on client MAC.   ... View more

Fyi the problem with the getNetworkWirelessDevicesConnectionStats call has been fixed.   It's possible the latency stats call will also work now, I suggest try a test.       ... View more

The API service is not 100% reliable.   From experience, it's failry common to have transient/one-off failures.   Others may continue for hours, days, or even months - there's at least one V1 endpoint that stopped working in January, it still doesn't work, I have a case open for this, Meraki say it's not a priority to fix it!   You can code to handle transient failures with delay-retry loops, for long term ones you can try using the equivalent V0 endpoint instead (assuming there is one).   If something has just started failing and it is persistent, I suggest open a case, at least then it will be known, it may then get fixed, there was an issue with some shards a couple of weeks back, it was resolved in a few days. ... View more

For SNMP you would need to set up a SNMP server to receive the traps, then configure Dashboard to send to that server. It's limited compared to webhooks.   For webhooks you also need a server, but it's probably faster/simpler to try out.   https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Meraki_Device_Reporting_-_Syslog%2C_SNMP%2C_and_API#Meraki_Dashboard_Webhooks   https://developer.cisco.com/meraki/webhooks/   See here for using with a simple JSON server...   https://developer.cisco.com/meraki/build/meraki-webhooks-with-json-server/   With the lack of documentation on precisely what will be sent, it's not possible to say if you'll get what you are looking for, so you need to try and see if you are lucky!   Quickest way could be to use Heroku to host the JSON server for free...   https://github.com/jesperorb/json-server-heroku#deploy-to-heroku   ...then configure an MX test network to send webhooks to your server, cut the power the MX for a short period and see what webhooks sends when the MX restarts.   ... View more

Yes, but have you actually looked at the webhook/SNMP data to see if it gives the reason?   Until you try it, you won't know. ... View more

I've never seen appliance lost power/reboots reported in Dashboard network event log, nor in the events returned by getNetworkEvents (using V1 API).   It always seemed a curious omission, as on the device page summary tab, the 'connectivity' timeline bar does pop-up a message saying there was a reboot and the cause (typically lost power or firmware update), clearly the information is there.   I haven't tried, but my guess is webhooks or SNMP would be the best bet, as I think they can give alerts for device going offline/online, you'd need to set up something to receive them. ... View more

Yes, just tried running on an affected org and also looks ok now.   Thanks for the update.   ... View more