MerakiMon 0.1.1

Added

• History charts in a device's detail (the panel that opens from a device), from MerakiMon's own stored history with no extra Meraki calls and the same History range as the tabs (the picker is repeated in the panel): online over time for every device; for an access point its clients and busiest-radio channel utilisation; for an MX its uplinks' latency, loss and usage; for a switch the ports with a link and, where Meraki reports per-port rates, its traffic in and out. Two new stored series per device kind, written with the existing history (dev|<serial>|up, sw|<serial>|ports, sw|<serial>|rx and tx): counts and rates only, never a client MAC or name; same retention as the rest, no schema change.
• Capacity issues in the health analysis (cap:ports): a network whose switch ports are forecast to reach the planning limit (cap_ports_pct 90% of its ports) within cap_warn_days (30, warning) or cap_crit_days (7, critical), or that is already above it, is raised like any other issue: confirmed over several polls, cleared once the forecast moves clearly away (15% margin, so it does not flip), acknowledgeable, counted in a new Capacity area of the health score, sent by the alerts and reports (new alert area and problem type "Capacity running out"), and listed above the forecasts on the Capacity tab. The days, the limit and the window are settings (thresholds). Ports of a device or port left out of the score (Issues & events > Score exclusions) are left out of the forecast, and a network left out of the score leaves the issue out too. WAN and client trends have no limit in the Meraki API, so they stay trends and raise nothing.
• Warm spare (HA) pair state, at the top of the VPN tab (now called "VPN & HA", as in FortiMon): for a network with an MX pair, who is primary and who is the spare, whether the spare is online, each appliance's uplinks and the one traffic leaves on, the virtual IPs, and a "last failover" line with a list of the failovers MerakiMon itself noticed (Meraki's API has no failover history, so MerakiMon compares the primary between polls and keeps the last 20 for 30 days in the site's saved state; the time is when it noticed). The roles come from the uplink statuses already read every poll (highAvailability); GET /networks/{id}/appliance/warmSpare (configured primary and spare, uplink mode, virtual IPs) is read every 30 minutes for monitored networks with an appliance, 6 at most a poll, optional (a failure only marks it partial). A member counts as primary only while Meraki sees it online. Health checks as in FortiMon: spare not online (ha:spare:*, warning, ha_confirm 3 polls), both appliances primary or none (ha:split:*, ha:none:*, critical), a failover in the last 24 hours (ha:failover:*, info; a warning from ha_failover_warn 2 of them; ha_failover_notice_s 86400). All three thresholds are in the thresholds setting; device and network exclusions apply. The demo's HQ pair has failed over three hours ago. Not yet checked on real gear (the real organisation has no pair): shapes are from Cisco's documentation and the fake Meraki.
• Port history and per-port traffic on the Switches and Switch ports tabs. Meraki's organisation-wide port call carries no traffic, PoE watts, clients or LLDP/CDP neighbour on a real organisation, so each switch is also asked once on its own (GET /devices/{serial}/switch/ports/statuses, averaged over the last half hour, because a few minutes comes back as zeros): at most 3 switches a poll, the stalest first, each again after 10 minutes, only switches of the monitored networks that Meraki reports online, and optional (a failure, a refused key on that call or a 429 only marks it partial and the last reading is kept for up to 30 minutes). That fills RX/TX, PoE watts (watt-hours over the time asked), Clients and "Connected to" (the LLDP or CDP neighbour, name and port only). Meraki keeps no port history, so MerakiMon records each port's up/down changes itself in the site's saved state (at most 50 changes a port, pruned with the history retention, kept over restarts): "lost link" is now a port that went down within the last day and is still down (it survives a restart), a port that is down on its first sighting is not a lost link, and a port switched off by an admin or on a switch that is offline is neither a lost link nor a flap. The grid marks a flapping port (⇅), the tables show "Changes 24h" and a flapping badge, and clicking a port opens its detail with its recent link changes (also from the Switch ports tab). Health check port:<serial>:<port>:flap (warning, as in FortiMon): at least port_flap_count (6) up/down changes within port_flap_minutes (60), so a reboot or a sleeping PC does not raise it; both are settings. Port exclusions and critical ports apply, and a critical port's lost-link issue now says how long ago the link was lost. The demo shows a flapping port, a lost link and traffic.
• Failed Wi-Fi connections, a section at the top of the Wi-Fi Clients tab (as in FortiMon): the failed connection attempts of the network for the last hour or 24 hours, counted by the step they failed at (association, authentication, DHCP, DNS), by SSID, by access point and by failure type, Meraki's own success rates for the last hour and day, and the most recent failures (time, client, SSID, access point, step, failure) with search and sorting. Four calls a network (wireless/failedConnections, wireless/connectionStats twice, wireless/ssids for the names) every 5 minutes, at most 3 networks a poll, only the networks you monitor; optional (a failure only marks it partial, a network without wireless answers 400 and has none). The list holds client MACs, so it is kept in memory only (GET /api/failed), never in the history or the public snapshot.
• Health checks "Failed Wi-Fi connections" (wifi-fail:*), as in FortiMon: many different devices failing to associate or log in on one SSID in the last hour (wifi_fail_clients 3 devices, wifi_fail_min 10 attempts, wifi_fail_ratio 20% of the network's attempts; critical at 60%), devices that join but get no IP address (DHCP), and failures piling up on one access point. Failures on a score-excluded SSID or access point raise nothing; the issues carry counts only, never client MACs. The three thresholds are in the thresholds setting.
• Access point cards on the Wi-Fi tab: state, model, IP, firmware, serial, number of clients, the SSIDs it broadcasts, a table of its radios (2.4, 5 and 6 GHz: channel, channel width, transmit power, and channel utilisation as total, Wi-Fi and other), the first clients on it (from the Wi-Fi Clients data, memory only) and a utilisation chart from MerakiMon's own history (the busiest radio, one series per access point; client counts are stored too). Two organisation-wide calls every 5 minutes (wireless/ssids/statuses/byDevice and wireless/devices/channelUtilization/byDevice, the last hour's mean), both optional: no wireless licence (400 or 404) means no radios, a failure or a 429 only marks it partial and keeps the last reading. The cards replace the old state-only ones on the Wi-Fi tab (its firmware tile, online chart and drill-down are kept) and a new "Radios busy" tile counts radios at the warning level.
• Health check "Wi-Fi channel busy" (radio-util:<serial>:<band>): a radio whose channel is busy at or above chan_util_warn (70%, warning) or chan_util_crit (85%, critical) for several polls, as in FortiMon. Both thresholds are in the thresholds setting; an excluded access point or network raises nothing that counts, and an offline access point is not judged.
• Diagnostics controls on the Issues & events tab, like FortiMon's: a filter bar (severity, area, acknowledged or excluded, free text), tick boxes with Acknowledge, Mute and Remove acknowledgement for several issues at once (POST /api/ack and /api/ack/remove with ids), score exclusions per network (a device by serial, a switch port, an SSID name, or the whole network: still listed, marked excluded, raising no alerts and not lowering the score) and critical switch ports (a lost link raises a critical "Critical port ... has no link" issue, errors on the port are critical, a disabled port or an offline switch raises nothing extra). Critical ports carry a star on the Switches and Switch ports tabs. Both are stored per network in the history database (POST /api/policy, needs the acknowledge permission, audited as score.exclude, score.include, port.critical and port.normal). The demo shows both on HQ.
• Switches tab: one card per switch with its port grid (1G up, 10G+ up, below 1G, errors, lost link, unused, disabled, PoE), the switch's facts (ports up, PoE ports powered, firmware, IP, MAC, state) and a table of the notable ports (connected devices from Meraki's LLDP/CDP topology, uplinks, errors, slow links). A switch stack is one box with its members, their roles and its own details panel. The Switch ports tab stays as the full list; each card links to it. A port that was connected within the last day and is not now shows as a lost link (kept in memory, so it starts empty after a restart).
• Network Map links are coloured like FortiMon's: 10G or faster blue and thick, below 1G amber, errors or down red, WAN green, no port data faint, with a legend and a tooltip on each link (speed, state, traffic when Meraki gives it). Meraki's topology has no link speed, so it comes from the switch port at the link's end; links with no switch port (appliance to access point) stay faint.
• Switch stacks are read for each monitored network that has switches (GET /networks/{id}/switch/stacks, every 30 minutes, optional: a failure only marks it partial and the stack still comes from the topology, without roles).

Fixed

• A stacked switch showed on the Network Map as "not managed by Meraki". The stack is now one switch node with its name, member count and a state taken from its members (all online, alerting if some are not, offline), its links kept, and its members listed in the tooltip and in a details panel.