UniMon 0.1.2

Added

• Send to SiteMon can trust a certificate that isn't valid (a self-signed one), which fixed "CERTIFICATE_VERIFY_FAILED": "Trust its certificate..." shows the fingerprint to compare with SiteMon's, and from then on the card and key are sent only to a server that shows exactly that certificate (and stop if it changes). Changing the address drops it.

Changed

• The blue tint on the dashboard background (added in 0.1.1) is gone; the background is the original dark and light again.

UniMon 0.1.1

Changed

• The default web port for new installs is 7443 (was 8444). An existing install keeps its port.
• A slight blue tint on the dashboard background, to tell UniMon from the other MonStack apps.

Fixed

• The browser tab icon was missing (UniMon's blue mark is now the favicon, also on the wallboard).
• The sign-in help showed the data folder without its backslashes (C:ProgramDataUniMon).

SiteMon 0.1.1

Added

• Send to SiteMon can trust a certificate that isn't valid (a self-signed one), which fixed "CERTIFICATE_VERIFY_FAILED": "Trust its certificate..." shows the fingerprint to compare with SiteMon's, and from then on the card and key are sent only to a server that shows exactly that certificate (and stop if it changes). Changing the address drops it.

SiteMon 0.1.0

Added

• The skeleton on MonStack's shared core: sign-in, users, two-step sign-in, audit log, backup and restore, appearance, web server and HTTPS, email, alerts and in-app updates, all through the shared web shell. Port 3443, purple.
• --demo runs three stub apps (a FortiMon, a UniMon and a MerakiMon card) so the dashboard and the wallboard have something to show.
• Its own card at GET /api/card/v1: one entry per monitored app (status, counts, headline).
• The pull collector: add, test, edit, pause and remove an app in Settings > Apps (name, address and a card key sealed on the server). SiteMon reads each app's card every 30 seconds with a small pool and shows ok, connecting, offline, key refused, needs SiteMon update, or unreadable card; a failed read keeps the last card with "last seen".
• An https app is trusted by its certificate: Test shows the fingerprint before any key is sent, and later connections must show the same one (or pass a normal check). A changed certificate shows the app as offline and the key is not sent.
• The push receiver: an app that SiteMon can't reach sends its card to POST /api/card/v1 with an incoming key SiteMon made for it (shown once, kept hashed, tied to that one app, can be replaced or revoked, audited). It is read by the same card reader as a pulled app, and is shown as offline when nothing arrives within 3 of its intervals.
• The last card, the last read and a short status history per site are kept in sitemon.db, so a restart shows the last data straight away.
• The wallboard (/wall): a tile per site across all apps, refreshed every 30 seconds, with filters by app, vendor and status (kept in the address, e.g. #app=, #vendor=, #status=). An app that is offline or refused shows its last data dimmed with "last seen".
• Alerts to email, Teams or a webhook: an app offline, key refused, needing a SiteMon update or unreadable, and back again; a site going critical, degraded or minor, and back to healthy. One alert per change, not per read; a resolved alert keeps the problem's severity.

MerakiMon 0.1.3

Added

• Send to SiteMon can trust a certificate that isn't valid (a self-signed one), which fixed "CERTIFICATE_VERIFY_FAILED": "Trust its certificate..." shows the fingerprint to compare with SiteMon's, and from then on the card and key are sent only to a server that shows exactly that certificate (and stop if it changes). Changing the address drops it.

MerakiMon 0.1.2

Changed

• Critical ports look like FortiMon's: an amber outline (and a small star) on the port grid, with "critical" in the legend.
• The Switch ports tab is gone: the Switches tab has all of it. "all N ports" on a switch card now lists every port of that switch in place (and "notable ports only" goes back), with the same columns, the port detail and the critical toggle.

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 o...

MerakiMon 0.1.0

Added

• The backend: Meraki organisations with a read-only API key, one site per network, health checks, history, changes feed, alerts, card and updater on the shared core.
• Installers: a Windows MSI (service or program, tray icon, firewall rule) and a Linux .run (systemd service), with signed in-app updates.
• Choose which networks of an organisation are monitored, when adding its API key and later under Settings > Organisations > Edit. By default every network is monitored, including new ones; once some are unticked, networks that appear later are marked new and wait to be ticked.
• Network Map tab: the network's devices and the links between them (from Meraki's link-layer topology, read every 15 minutes), coloured by device state, with port names; click a device for its details.
• Find Device tab: search every site you may see for a device by name, MAC (any format), IP (LAN or uplink) or serial; each hit links to its site, Devices tab, Network Map or details. Only Meraki's own devices are found: client MACs and IPs are not polled.
• VPN tab: the site-to-site (Auto VPN) status of the network's appliance (hub or spoke, uplinks) and each peer, Meraki or third-party, with whether Meraki reports it reachable. One call for the whole organisation, read every 2 minutes; organisations that don't use site-to-site VPN just show nothing. A peer that stays unreachable raises a warning, and an appliance with no reachable peer at all a critical issue (new health area "VPN", alert kind "VPN peer unreachable"). Latency and loss per peer are not read yet.
• Wi-Fi Clients tab: the wireless clients Meraki saw on a network in the last hour (name, MAC, IP, SSID, access point, VLAN, usage, last seen), with search, sorting and counts by SSID and by access point. Read every 5 minutes, one call per monitored network, kept in memory only (never in the history) and shown only to people who may see that site; the history keeps just a count per site.

Fixed

• Switch ports that are unplugged or switched off are no longer counted as having errors (Meraki lists them under errors).
• The Reports tab now reads the history MerakiMon actually stores: health, the organisation's clients, and latency and loss over all of a site's WAN links.

FortiMon 1.12.0

Where FortiMon updates from: FortiMon now has its own public page, github.com/RowShack/FortiMon. This is the last
release published on RowShack/MonStack. The first time 1.12.0 starts, it switches Settings > Updates over to the new
page by itself (one entry in the audit log), and later releases appear there. Nothing to do on your side. If your
server blocks GitHub, allow github.com/RowShack/FortiMon as well.

Added

• Updates: a tag_prefix setting. Empty means the shared page's <app>-v tags; an app's own page uses v.

Changed

• Updates: the repository and tag prefix move to RowShack/FortiMon and v on first start.

FortiMon 1.11.3

Added

• Send to SiteMon can trust a certificate that isn't valid (a self-signed one), which fixed "CERTIFICATE_VERIFY_FAILED": "Trust its certificate..." shows the fingerprint to compare with SiteMon's, and from then on the card and key are sent only to a server that shows exactly that certificate (and stop if it changes). Changing the address drops it.

Changed

• The red tint on the dashboard background (added in 1.11.2) is gone; the background is the original dark and light again.