This node uses an API call to Meraki using the URL https://api.meraki.com/api/v1/organizations

the Authorization header is what is used to authenticate. You also have to set it to accept json

This node uses a URL with an expression in the middle to do an API call for each ORG ID that was pulled to pull all the network's for each org

This takes the output data from the previous node and changes the variables to better suit what we'll be using.

This node matches on the NetworkID field, so that the networks we pulled earlier and the Loss / Latency can be combined into one dataset

Like before, This takes the output data from the previous node and changes the variables to better suit what we'll be using.

This node uses JavaScript to look at the calculated averages and if they pass the threshold for 300ms Latency or 2% Loss it will pass that site info forward

This node uses JavaScript to calculate the average over the last 5 entries of packet loss and latency

This uses a URL with an expression in the middle so that for each org ID it will pull the Loss and Latency for their uplinks.

schedules the workflow to run every 5 minutes mon-fri 8am-5pm

This looks at the problematic sites as well as the info from the database. It will pass on all non-matching as if the site name matches with the database then that means we have an open alert for that site already.

This node Looks to see if the alert already exists in the Redis database. If it does exist it won't alert us in Teams

If the alert isn't in the database all the Redis will respond with is "null"

other n8n nodes see null as (no data) and show blank which is fair. So I made this node to look at the null responses and make a response of "false" for a "alertExists" variable. that way we have something to filter on

sends an alert to Dispatch with info related to the site.

Logs the alert and sets the TTL to 3h, after 3h Redis will delete the entry and if the site is still having issues, the next run of the workflow will notify us again

Pulling in Info

This section pulls in all the data we will need to see any possible errors and generate our alert

Changing data

This section pulls together the data we got from the first section and sets everything up to be notified

Notify

This last section is for the push of the alert as well as storing the alert as to not re-notify every time the workflow runs

Explanation

using an HTTP request you will can do a get request for all Organizations your Meraki account has access to.

You will have to Generate your own API key inside of the Meraki Dashboard explained here https://documentation.meraki.com/General_Administration/Other_Topics/Cisco_Meraki_Dashboard_API

You will have to add two headers to your HTTPS node Authorization and Accept. the 1st is how you'll authenticate with Meraki and the second is how it will know how to answer the request.

Using the same methods you'll do a get for Organizations, Network IDs and Uplink stats

Using the Set nodes to organize the data in a "neat" way

Explanation

the Merge node will combine the Networks with their respective stats by matching on NetworkID and networkid and enriching the input

again we add a set node to better organize the statistics of the uplinks.

The first JS node will average the 5 Time stamps of Latency and Packet loss

The last JS node will send the data forward only for sites that pass the threshold (in this example 300ms latency and 2% packet loss)

Explanation

we will send the problematic sites to both the Redis node and the Merge node.

The Redis node does a get request to see if a key exists matching the Network name in Meraki. If so it will respond with the Network name, If not it will respond with "null"

the n8n nodes view "null" as no data (which isn't exactly wrong as it literally is no data) but the next node will just say the input is blank so I've added the JS node to look at the output and respond if an alert does or doesn't exist based on the response of the Redis node.

This time we Merge looking at the NetworkName and keep all non-matching. The reason for this is because if they match, that means the key in the database exists, meaning we've already sent a message that the site is having issues.

We send the tickets forth that don't match and we will send a teams message that will notify of a Network passing the threshold for issues. I've included the Network URL and re-written the message to include a hyperlink that way the alert can be used to take you straight to the problematic site.

Finally we log the site in the database with a TTL of 3h, this way if the error has not been fixed in 3h we will get another message.

other usecases

If you feel confident enough the Teams nodes can be replaced with a node that can generate a ticket for your PSA such as ConnectWise Mange. That way these are generating tickets rather than just messages.

get meraki organizations and get network ids and get uplink loss and latency

Purpose and structure

This folder contains the get meraki organizations and get network ids and get uplink loss and latency workflow. Its executable nodes use code, httpRequest, manualTrigger, merge, microsoftTeams, redis, scheduleTrigger, set. The table and connection map below are derived from the JSON, not an inferred guarantee of behavior.

Setup

Import inactive. Configure your own credentials and replace REPLACE_WITH_* values. Review external destinations and Code nodes before running.

Entry points

When clicking "Execute Workflow", Schedule Trigger

Verification

Sanitized source candidate; not runtime-tested. This overview is generated from node metadata. Read the folder README for the connection map, credential types, and license.

Attribution

https://github.com/Zie619/n8n-workflows/blob/94007c1445d9258a7da116646b79473e7c7c3282/workflows/Redis/0387_Redis_Code_Create_Scheduled.json MIT; preserve source notices.