Meraki

John_on_API · ‎Sep 7 2023

I, for one, am a huge fan of these changes. So much easier to find the endpoint I want!

John_on_API · ‎Aug 30 2023

Hi @CiscoLumen the most common data retention period for items in dashboard is 1 month, so if it 404s after 4 weeks then that seems normal! I'd recommend removing your serial number from the post above at your first convenience--it's generally best to not publish them.

John_on_API · ‎Aug 30 2023

Hi @sungod this is intentional -- we want to avoid the "missing keys" or "dynamic keys" problem by returning a consistent set of attributes whenever possible. However, I saw you're using getNetworkDevices -- why use this instead of https://developer.cisco.com/meraki/api-v1/get-organization-devices/ ?

John_on_API · ‎Aug 30 2023

Hi @sungod , is this the same change mentioned here? https://community.meraki.com/t5/Developers-APIs/Sensor-data-models-misalignment-for-downStream-power-latest/m-p/200871#M8575 fyi @KonJain

John_on_API · ‎Aug 30 2023

Hi @xaviervalette , as @Greenberet mentioned, this statement is inaccurate: @xaviervalette wrote: But if you are using the given Webex payload (Network-wide > Alerts > Webhooks > Add or edit webhook templates)... ...you will need to host a script listening for Meraki webhooks, and then posting a message to Webex API (via your Webex Bot). Webex supports incoming webhooks out of the box. Link: https://apphub.webex.com/applications/incoming-webhooks-cisco-systems-38054-23307-75252

John_on_API · ‎Aug 25 2023

Hi @Rusalka thanks for reporting this. I talked to the developer of the plugin and he thinks he has a fix in the works. In the future, if you have issues with the Gsheets plugin please feel free to start a new thread, since it's unrelated to the Python library.

John_on_API · ‎Aug 18 2023

Before converting the JSON, do you see any errors in the JSON? I wonder if this is a CSV conversion issue -- the library doesn't do any CSV conversion. If the API is returning invalid JSON, then that could be an issue with the API. If the API is returning valid JSON, but a CSV converter doesn't successfully parse it, that's probably an issue with the converter.

John_on_API · ‎Aug 18 2023

Hi @Rusalka , thanks for reporting this! I think the GSheets extension doesn't use the Python library. Do you think it could be specific to how Gsheets handles newline characters (e.g. \n)?

John_on_API · ‎Aug 9 2023

Hi @Jamieinbox , it sounds like there's a chance the API endpoint is part of the early access program. For more info we have a post in the sidebar at https://community.meraki.com/t5/Developers-APIs/bd-p/api with full details on the Early API Access program and what it means.

John_on_API · ‎Aug 9 2023

"Network uptime" could mean a few things--what is the end goal (beyond a number itself) that are you looking to achieve, @JamesPickup ? One interpretation might be how many devices in an organization or network are online vice in some other status/availability. https://developer.cisco.com/meraki/api-v1/get-organization-devices-statuses-overview/ can help with this at an aggregate level, and https://developer.cisco.com/meraki/api-v1/get-organization-devices-availabilities-change-history/ can help with the availability changes on a per-device level. Good rec, @Prodrick! If by 'uptime' you mean some explicit information about when devices last booted, or some amount of time since they last booted, as @sungod mentioned above, availability and device-specific uptime per se are not necessarily the same thing. However, that kind of "uptime" is not a reliable stat on its own--it really depends on what you want to do with the information, since there's probably a better way to achieve the end goal. There are good reasons to reboot devices, such as firmware upgrades, for example, and you can check firmware upgrade histories pretty easily. And power outages will be reflected in availability changes, if that's what you're looking to detect. Availability on the other hand more holistically indicates that both the LAN and the WAN are meeting some minimum level of functionality, and covers more use cases, so availability will often be more relevant than per-device uptime. In any case, if you can share more details about what you want to accomplish, that would help!

John_on_API · ‎Aug 9 2023

Hi @Prodrick I'm glad to hear you got a chance to use these endpoints, but sorry to hear there were some errors or empty responses. I recommend removing the serial # from your post for privacy purposes. In both cases, i.e. no data for timespan 300 and 502 errors on some pages, this could be the result of a bug. You should feel confident to report it to Meraki Support for triage.

John_on_API · ‎Aug 7 2023

Thanks for raising this @david_n_m_bond . This looks like a bug and if you'd like you can raise a support ticket to have it documented and prioritized.

John_on_API · ‎Aug 4 2023

Heck yeah https://developer.cisco.com/meraki/api-v1/search/uplinks%20addresses/

John_on_API · ‎Aug 4 2023

Hi @Guillaume6hat I'm really glad to hear that you've had a positive experience using the module and that it's worked as expected. As far as integrating into the Python library, this is possible--could you speak to how it would improve your workflow? To what extent would you want to see it integrated?

John_on_API · ‎Aug 4 2023

Hm, what do you mean by 'pull client Wi-Fi connections'?

John_on_API · ‎Aug 4 2023

Library version 1.36.0 includes the latest capabilities released in dashboard API release 1.36.0. It also includes a number of bugfixes (read more on GitHub.) Install or upgrade with: pip install --upgrade meraki

John_on_API · ‎Jul 21 2023

I can't speak for the teams handling documentation -- support would best answer that -- but such a change would be breaking in the API, so the 'appliance' value in the productTypes enum will not change. This is a cosmetic change in GUI, in any case.

John_on_API · ‎Jul 12 2023

The change history endpoint is live on all shards. Which events endpoint(s) would you like to see aggregated at the organization level?

John_on_API · ‎Jul 12 2023

Hi @Prodrick ! You'll see all the changes: 1. The first change at ~9am to offline 2. The second change ~3pm to online 3. The final change ~7pm to offline You'll also see change events for that device if at any point in the process it was in "alerting" status.

John_on_API · ‎Jul 11 2023

Wow huge honor! Thanks team. Thrilled to be here.

John_on_API · ‎Jul 11 2023

Hi @Badr-eddine thanks for the ping. This does look like a feature request and can be best opened through your sales rep!

John_on_API · ‎Jul 10 2023

This endpoint returns the time-stamped availability change events that occurred for the organization's devices in the requested timespan, and is intended to be a hyper-efficient means of monitoring device availabilities. You can get started by calling: GET /organizations/:organizationId/devices/availabilities/changeHistory An empty result means there were no availability changes for any device in that organization for that timespan. Default timespan is 1 day; maximum timespan is 14 days. Aside from the standard t0/t1/timespan controls, other filters include: productTypes[] networkIds[] serials[] statuses[] Here's an example response, indicating that a single MV device changed from online > offline status, and subsequently changed back online status about 2 days later. It also indicates that no other device in the organization had any change in availability for that timespan. This can be used for many purposes, such as: Finding historical availability information for one or more devices. Has a device changed status around the time the user originally reported an issue? Now you can look back (up to 14 days) and find out! If you monitor device availability via API, then for stable networks, using this history endpoint will be far more efficient than polling availability (or statuses) for every device in the organization. Instead of gathering a ton of "online" data points, you can instead focus on the changes that might evidence an issue (or a resolution). The endpoint reveals only the changes during the timespan, so if you get an empty response, that means there were no changes. In other words, if you have gathered a complete picture as of a given timespan via polling an org's devices' availabilities (either via the /availabilities or /statuses endpoints), then you can subsequently switch to polling for changes from that snapshot, and get the differential data with which to update your locally cached information. Building the "Connectivity" bars the dashboard offers under Organization > Overview > Devices tab Sleeping easier at night, I hope! Thanks to our Early API Access community for your valuable feedback during beta! This endpoint is now GA and we look forward to hearing how this new endpoint helps to streamline your workflows.

John_on_API · ‎Jun 23 2023

To answer your question: The radio index is often (but not necessarily always) 0 for 2.4, 1 for 5, and 2 for either a fixed 6 or flex 5/6-capable radio. Ironically, the endpoint you mentioned probably isn't your best friend for answering your actual question. Have you looked at these? All of these are much more explicit and AFAIC better suited to most if not all use cases regarding spectrum utilization. https://developer.cisco.com/meraki/api-v1/#!get-average-channel-utilization-for-all-bands-in-a-network-split-by-ap https://developer.cisco.com/meraki/api-v1/#!get-average-channel-utilization-across-all-bands-for-all-networks-in-the-organization https://developer.cisco.com/meraki/api-v1/#!get-a-time-series-of-average-channel-utilization-for-all-bands-segmented-by-device https://developer.cisco.com/meraki/api-v1/#!get-a-time-series-of-average-channel-utilization-for-all-bands

John_on_API · ‎Jun 9 2023

Hi @NJNetworkGuy100 you could do this a few ways, but it sounds like https://developer.cisco.com/meraki/api-v1/#!split-network is the simplest/easiest way. After doing this, you can delete whichever switch networks are empty. You could even re-combine the remaining networks (if desired) via https://developer.cisco.com/meraki/api-v1/#!combine-organization-networks Hope this helps!

John_on_API · ‎Jun 9 2023

They should appear as "switch" wherever productType is referenced. For the purposes of firmware upgrades, Catalyst switches are referred to as "switchCatalyst", but that is not a part of the productType enum.

About John_on_API

John_on_API

Community Record

Badges