WISPHero: network monitoring for wireless ISPs

What WISPHero does

WISPHero is made for small WISPs, where the same few people run the network, answer the phones and climb the towers. Below, each of its jobs is explained with screenshots from the app itself. They show a made-up demo network, not a real company or real customers.

See what is wrong

The Status page is the screen you leave open. Every device you add gets a card, problems sort to the top, and the page updates every 2 seconds.

One card per device

WISPHero pings each device itself. By default it checks a device every 30 seconds, a business customer every 60 seconds and a residential customer every 2 minutes, and you can change each of these. A device that is down or not in good shape is checked again every 15 seconds. Each check gives a quality from packet loss and reply time (latency), and the card takes that color.

The Status page showing one card per access point. Three red cards for access points that are down, two amber cards for access points with packet loss or high latency (one marked DFS), and green cards for healthy ones. Each card shows the device name, address, site, how long it has been in its current state, and its loss and latency. One green card has a small red up-arrow next to its latency. — One card per device, problems first. The small red arrow on a green card means its latency has been rising.

What a card shows

Color: Green is good, amber is a warning, orange is bad, red is critical or down, and gray is not monitored. The color carries the state, so the front needs no extra words.
Name and address: The address links to the device's own web page.
Status line: How long the device has been in its current state, counted live, such as "Good for 5d 21h".
Loss and latency: Packet loss and reply time from the latest check. Jitter (how much the reply time varies) can be turned on.
Trend arrow: A small red up-arrow means a number is getting worse; a green down-arrow means it is getting better. It appears only after a steady change over several checks, so normal ups and downs do not set it off.
Tags: Up to two short tags, such as Note, DFS (a radar hit), AP Lockup, Grid Outage, Maintenance, Paused, or the customer class (Residential, Business or Tower Owner).

The limits: good is up to 5% loss and 100 ms; warning, up to 15% and 200 ms; bad, up to 30% and 300 ms; anything worse is critical. You can change them for each customer class or device. The issues WISPHero found and a 24-hour graph are on the back of the card: see card diagnostics.

Individual Status cards on a phone: two amber customer cards with packet loss first, then green customer cards, each with its address, a Residential or Business tag, status time, loss and latency. — One card per device on a phone, worst first.

Grouped site cards

When a tower loses power, every device on it goes red at once. With one card per device, that one problem fills the screen with 28 red cards and pushes every other problem out of sight. Grouping folds a site's devices into one card, so one failing tower is one card.

How a grouped card works

The card takes the color of its worst device, so a site with one device down is still red.
It lists five devices, worst first. Among devices in the same state, down devices come first, then backhaul links, then the rest by name.
A line such as "+2 more: 2 critical" sums up the rest. "Show 2 more" opens them inside the card.
The footer counts what is down, such as "7 DOWN", and says how long it has been since the first device dropped, such as "Down for 47m".

Grouped or one card each: you choose

"Group by site" is a setting for each person. Manual, the default, shows one card per device, and you can still group one busy site from its card's menu. Automatic groups every site with two or more devices on screen. The Ungroup button on a grouped card brings back the single cards, and List view always shows one row per device. To see one device's diagnostics, ungroup its site and turn its card over.

Paused for planned work

Pause a device or a whole site, and add a note if you like. While it is paused, it sends no down or outage alerts, and it moves to its own Paused tab. The other views hide it and the "down" count leaves it out, so planned work does not look like an outage. Each card shows the pause note and how long it has been paused.

The Paused tab of the Status page with six cards from one tower under planned maintenance. Each card has a Maintenance tag, a Paused tag with how long it has been paused, and the pause note. One card is red because that radio is down during the work. — Six devices at one tower during planned work. One radio shows red because it is down while the crew works on it.

The day in a few sentences

The dashboard's network view sums up the last 24 hours in short sentences: what went down, for how long, and what still needs attention. The sentences follow fixed rules, not guesswork. When something was not checked, it says "not checked".

The default view is a field briefing: today's weather from the US National Weather Service (MET Norway outside the US) and a "can we climb today?" answer based on the wind limits you set.

The briefing also has a news feed: security advisories, firmware releases, industry news and events from up to 56 public sources. A source is read only while someone has the briefing open. You can turn the feed off, and a super admin can add up to 10 feeds of their own.

The dashboard's Network view. One sentence says 29 devices are down at 3 sites, followed by counts for uptime, latency, outages, slow devices, down devices and radar hits, outages per day for the last week, and a list of what needs attention now. — The Network view: a plain-language summary of the last 24 hours and what needs attention now.

TVs and wall displays

Put the Status page on the screens in your NOC. Each screen keeps its own filters and card size, and a TV needs no password.

Display windows: The Displays menu opens numbered windows. Each one has its own saved filters and size, a TV mode without the header, "fit all cards", keep-awake, full screen and a start-up shortcut.
Pair a TV: Make a one-time code on your computer (8 characters, valid for 10 minutes) and type it on the TV's pairing page. The TV then shows a read-only Status page or map, with no sign-in. It stops working when the person who paired it has not used WISPHero for a while (a grace period you set), or when they unpair it.
Cast: Cast from Chrome or Edge to WISPHero's own receiver page. This needs a Cast app ID that you register yourself, and HTTPS.
Card size: On a TV, a card-size slider from 50% to 300%. On a desktop, choose how many cards fit in a row.

Proven so far: on demo data in a desktop browser. Casting to real hardware and placing windows on several monitors have not yet been checked.

Find the cause

A red card tells you something is wrong. These tools show why, and since when.

Open any card

Double-click a card (double-tap on a phone) and it turns over. The back lists the issues WISPHero found, in plain sentences, then the readings behind them.

Most of the back comes from readings WISPHero has already stored, so it opens fast even during a large outage. A few parts, such as airtime and the router panel, ask the device when you open the card. The back refreshes every 15 seconds. Cards that turn critical can flip over by themselves, so the reason is already showing when you look up. Each person can turn that off.

A row of four access point cards on the Status page. One card is flipped over to its diagnostics side, listing three issues found with its Ethernet port, the port's speed, errors and discards, capacity use, and a graph of Ethernet errors over 24 hours. — Double-click a card to turn it over. The other cards stay as they are.

What the back of a card checks

Each part appears only when there is real data for it. Nothing is filled in with a guess.

Issues found: A plain list of what is wrong now or in the last 48 hours, or "No issues detected". It follows fixed rules.
Signal: The radio's signal and noise level in dBm (decibels relative to a milliwatt; closer to zero is stronger): green at -75 or better, amber from -76 to -78, red at -79 or worse.
Ethernet: The link speed, errors and dropped packets per second, and cable quality. A link slower than you expect is listed under Issues found.
LAN ports: Each local network (LAN) port on the customer radio: up or down, and at what speed.
Fiber: The light level received and sent. The received level turns amber, then red, as it nears the edge of the usable range.
Capacity: Download and upload traffic against what the link can carry: amber at 70%, red at 90%.
Airtime: How busy the access point's channel is. It warns above 50%.
Stations: How many of the access point's customer radios connect at less than 100 Mbps.
Radar (DFS) hit: When the access point heard radar, and how many customer radios it had before and has now.
AP lockup: When an access point (AP) stopped serving customers but still answered ping, and how many it served before.
Router: The customer's MikroTik router: software version, Wi-Fi networks, connected devices and ports.
Grid outage: A utility power outage reported near the device.
Device: Live readings you picked for that device over SNMP (Simple Network Management Protocol, the standard way to read a device's counters).
24-hour graph: The most useful reading for that device, with outages as red bands and the worst moment named.

Signal, LAN ports, airtime and stations come from UISP, Ubiquiti's network manager. Ethernet error counts come from the radio over SNMP, fiber light levels from a Calix E7 fiber system over SNMP, and the router panel from MikroTik or Admiral Platform. The demo has no UISP, so its airtime shows a dash and Stations says it needs UISP. That is what you will see without UISP.

The back of an access point's Status card. Three issues found: the Ethernet link negotiated 100 Mbps where 1000 is expected, 3.4 errors per second, and 0.8 dropped packets per second. Below are the Ethernet readings, capacity meters, airtime, a note that the station count needs UISP, and a 24-hour bar graph where Ethernet errors start in the last few hours. — Access point with a bad cable: the link fell to 100 Mbps and errors started a few hours ago.

The back of a customer radio's Status card. Two issues found: degraded quality and a recent DFS radar hit on its access point. Below are the signal and noise readings, Ethernet link and cable SNR, the LAN port, capacity use, the DFS hit with the station count before it, and a 24-hour signal graph. — Access point with a bad cable: the link fell to 100 Mbps and errors started a few hours ago.

Compare devices side by side

Is it the access point or the customer? Compare puts up to ten devices on the same charts over the same time range. If an access point and its customers slow down together, look at the access point or its backhaul. If one customer drops alone, look at that customer.

How it works

Open History and choose Compare.
Search for devices by name and add up to ten. A live table shows each one's loss, latency and jitter right now.
Pick a time range: 24 hours, 7 days, 30 days, 90 days or your own dates.
Every chart draws one line per device: latency, loss, jitter, uptime, signal, Ethernet errors and speed, fiber light level, traffic, and outages.
Each comparison has its own link, so you can send it to a colleague.

History in Compare mode with four devices over seven days: a latency chart where an access point and one of its customers jump from about 10 ms to over 120 ms on the last day while the other two stay low, and a packet loss chart, one line per device. — An access point and one of its customers slow down together on the last day; the other two devices stay low.

The top of History Compare: four selected devices shown as removable chips, a search box to add more, and a live table with each device's site, loss, latency, jitter and last check. — Pick up to ten devices. Their live numbers show above the charts.

More Compare charts for the same four devices: radio signal, where one customer's signal falls from about -57 to -73 dBm at the end of the week; Ethernet errors and discards, where one access point jumps on the last day; and Ethernet link speed, where that access point drops from 1000 to 100 Mbps. — Signal and Ethernet charts show which device changed, and when.

Compare works on devices. It does not compare whole sites with each other, or one week with another.

History you can graph

Compare is one view of the History page. The other views show about 20 charts of reply time, loss, uptime, outages, signal, Ethernet, traffic and radar hits for one device, one site or the whole network, from the last 24 hours to the last 90 days. Every chart has a Table button with the exact numbers, so you can see, for example, whether a radio gets worse at the same time every evening.

Radios and channels

Some 5 GHz channels are shared with weather radar. When a radio hears radar on one, the rules make it leave that channel for 30 minutes. This is called DFS (dynamic frequency selection), and one radar hit can drop every customer on an access point at once.

Radar (DFS) hits and fallback channels

Every 5 minutes, WISPHero reads the device list from UISP. It marks a 5 GHz Ubiquiti airMAX access point as hit when it has left the DFS channel it was set to, or when UISP reports a radar lockout. Mimosa point-to-multipoint radios are checked over SNMP.
While a hit is active, WISPHero also rereads the radios that were hit every 60 seconds.
Each hit shows the fallback channel the radio moved to, checked against the radio's list of allowed frequencies in UISP.
The FCC (the US Federal Communications Commission) keeps a radio off that channel for 30 minutes. During that time the Reboot button becomes a countdown, such as "FCC lockout: 12 min left", and the server blocks every way to reboot the radio.

The DFS Center showing one access point that heard radar and moved from its configured channel to its fallback channel, with the time left before it can return. — An access point that heard radar, the fallback channel it moved to, and the time left in the FCC lockout.

After the lockout you can reboot the radio through UISP, now or at a set time. That needs a UISP key that allows changes; a read-only key can only watch. Automatic reboots are off unless you turn them on. Radios that WISPHero does not read through UISP or Mimosa SNMP are not checked for radar hits yet.

Why radar keeps hitting

Hit tracking shows which channels hear radar, at which sites, and at what time of day, over the last 3 to 31 days. When three or more radios are hit within 15 minutes, the Burst Investigator groups them into one episode, with a timeline and what to check next.

"How worried should I be?" runs 17 rule-based checks, such as lightning, heavy rain, aircraft, distance to an airport weather radar (TDWR), and whether hits come at the same time each day. Each check shows its reason. A check that could not run says "Not checked", never "Low".

DFS hit tracking for the last seven days: counts of new hits, radios, sites and channels, a bar chart of hits per day split by channel, and a grid showing which hours of the day the hits happened. — Which channels hear radar, at which sites, and at what time of day.

Frequencies and channels: what it does, and what it does not

WISPHero keeps a record of each radio's band, center frequency, compass heading and beamwidth. From this radio frequency (RF) record it finds radios that get in each other's way, and it checks that the record itself makes sense.

RF Defrag: Checks every pair of radios within 5 miles of each other. It marks two radios red when they use the same channel and face each other or share a site, and yellow when they face each other or share a site and are within 20 MHz. Two radios that are both GPS-synced are shown as planned reuse, not as a conflict. You can change the distance and the gap in Settings.
RF data check: A wrong heading or frequency makes every answer wrong. The data check goes through your radios one at a time, worst first, and looks for missing or doubtful headings, bands that do not match the frequency, locations far from their site, and radios that are not GPS-locked. It suggests a fix, such as "Use link bearing 278.3°", and changes nothing until you save.
Live channel tracking: With UISP connected, WISPHero follows each access point's live frequency and records every channel change. When a customer's signal drops because of a channel move or a radar hit, it says so instead of blaming storm damage.

The RF Defrag list. Each row shows a site, a radio, its band, channel width and a status: red rows report a co-channel conflict with another radio at the same site, or an active DFS hit; green rows say Clean Channel; offline rows say the radio is down and cannot be judged. — RF Defrag: red rows share a channel with a radio they face or a radio at the same site.

The RF data check open beside the map. It is on radio 1 of 13 and says no compass heading is stored for this backhaul, offers the bearing of its link as a suggestion, and notes that no beamwidth is stored. The map shows that tower's sector wedges and links. — The data check walks through radios with a missing or doubtful heading, band, frequency or location. Map data © OpenStreetMap contributors.

Radar, interference and weather: why a radio dropped

When an access point goes quiet, the first question is why. WISPHero checks the usual suspects for you, from a radar hit to a storm to a long-distance signal bending in the air, and shows the evidence for and against each one. Every check is rule-based, shows its reason, and says "Not checked" when it could not run, never a guessed "Low".

Airport weather radar (TDWR) overlap: Terminal Doppler Weather Radars sit near big airports and share the 5.6 GHz band with your radios. WISPHero lists the 47 FAA radar sites (from the FCC and WISPA list) and flags any antenna that is within 35 km of one and whose channel is within 30 MHz of the radar's frequency. Both limits are the FCC defaults and you can change them in Settings. A radio whose channel is farther off than that cannot be hearing that radar, and WISPHero says so.
Is that radar even on?: For the nearest weather radars it shows live status from a community outage tracker (not an official source), so a radar that is switched off is not blamed for a hit.
Radio ducting: Under some weather conditions the air bends radio signals far past their normal range, so a distant source can land on your channel. WISPHero draws a ducting forecast map from NOAA's global weather model and uses it as one of its checks.
Storms and lightning: Lightning strikes near a hit (NOAA GOES satellite), heavy rain (NOAA weather radar) and weather alerts (National Weather Service). After a storm, the after-storm check compares each device's signal, Ethernet, fiber and voltage before and after.
Aircraft and space weather: Aircraft near your towers (OpenSky) and solar and space weather (NOAA SWPC) are checked too, so they can be ruled in or out.
Seven ranked explanations: Examples are the radio's own false detection, a fixed TDWR, a local source, ducting and storms. Each of the seven shows the evidence for and against it and the cheapest check to run next.
Bursts and the source area: When three or more radios are hit within 15 minutes, the Burst Investigator groups them into one episode. From which radios heard radar and which did not, it also estimates a rough area where a local source could be, labelled "geometry only, not a position fix".
Why a customer's signal dropped: When a customer's signal drops, WISPHero looks for a radar hit, a channel change or a restart on their access point first, and says which one it found.

Grid outages: is the power out?

When a whole site goes quiet, the cause is often the power company and not your equipment. WISPHero reads public utility outage feeds and tells you when an outage is reported near a tower, so you can tell a dead grid from a dead radio before you send anyone out.

Where the reports come from: Several public outage feeds: Kubra StormCenter (32 utilities are preset), ODIN from the US Department of Energy and Oak Ridge National Laboratory (more than 150 utilities), ArcGIS outage maps that some utilities publish, a NIPSCO feed, and electric co-op maps hosted on outagemap.coop. The default Automatic mode picks the feeds for where your towers are.
How fresh it is: The feeds are checked every 5 minutes.
Where you see it: A Grid Outage tag on the Status card of an affected device, a layer and an entry in the issues panel on the network map, and an alert.
A suspected outage, even with no feed: If your utility publishes no outage map, WISPHero can still notice. When a site's chosen power reference device stops answering ping, it raises a suspected power outage alert.
In diagnostics: Card diagnostics and the Customer Diagnostic list power outages nearby next to the weather and the radar hits. When the cause is a power outage, the Customer Diagnostic does not offer a chance of fixing it by phone, because no one can fix it from a call.

Remote sites

Some sites cannot be reached from your network operations center (NOC): a business customer behind its own router, or a tower behind carrier-grade NAT, the address sharing that blocks incoming connections. A remote agent watches those sites from the inside.

Remote agents

A remote agent is a small computer at the site that watches the devices there and runs network tests when you ask. It reports to your WISPHero server, so the site shows up like any other.

What it is: The same WISPHero software, started in agent mode, with its own small database.
Where it runs: On a small Linux computer at the site, such as a Raspberry Pi, in Docker.
How it connects: Outbound only. About every 45 seconds it calls your WISPHero server over HTTPS, sends its results and picks up any tests you have asked for. You need no VPN (private tunnel), port forward or fixed IP address. If the link drops, it keeps its results and sends them when the link is back.
What you see: The site's devices appear on your Status page and raise alerts like any others.
How you manage it: On the Agents page, an admin registers the agent and gets a one-time token. You run the installer on the box with that token. The installer shows your server's certificate and asks you to accept it; from then on the agent trusts only that server. You can revoke an agent at any time. Each site has one agent.

Tests you can run from the office

Each test shows its latest result and a Run button. A test rides the agent's next check-in, so it starts within about a minute.

A speed test to your own server
Ethernet: link speed, duplex and errors
Wi-Fi: network name, signal, frequency and nearby networks
Gateway ping, and DNS (name lookup)
Path MTU: the largest packet that gets through
Traceroute, and MTR: loss and delay at each hop
A long jitter test
Bufferbloat: delay under load, graded A+ to F
The box's own health, including Raspberry Pi power warnings

A public internet speed test (Cloudflare, with M-Lab as a backup) is there too, but it is off by default because it is the only test that sends traffic to an outside service. The box also shows its own status page on the site's local network, which works even when the link to your server is down.

Proven so far: the check-in and the test round trip have run between two copies of WISPHero on one computer. The agent has not yet run on a real Raspberry Pi or through a real NAT, and its Linux test tools have not yet run on real hardware.

Remote agent diagnostics on a phone: speed test, Ethernet, wireless, gateway ping, DNS and MTU results, each with a Run button. — Run tests at a remote site.

Your network on a map

Towers with their sector wedges, backhaul links colored by the live health of their worse end, customers and fiber, on one map. Link colors refresh every 10 seconds. Layers add weather radar and lightning from NOAA (the US weather and ocean agency), utility power outages, flights and airport weather radar sites.

The same map shows how busy each link is, holds your fiber plant, and plans coverage over real terrain. See below.

A map of six towers joined by backhaul links, with colored sector wedges and small badges marking sites that have problems. — Towers, sectors and backhaul links on a live map. Map data © OpenStreetMap contributors.

Traffic, fiber and coverage

Issues panel: What is wrong now, what went wrong in the last hour, and suggestions: down devices, radar hits, power outages, fiber light levels out of range, open alerts and ports that are down.
Traffic on the links: By default, links are shaded calm (under 60% full), busy (60% to 85%) or full (85% and above). The figures come from what WISPHero already reads from switches, routers, UISP and SNMP, so the overlay adds no polling. Links suggested from LLDP or MikroTik neighbor lists are never added by themselves.
Capacity sheet: Click a link to see each end's capacity and Ethernet speed. Where a reading is wrong, type your own figure.
Fiber plant: Draw poles and splice enclosures and list what is mounted on them. Add fiber paths over several hops, with direction, aerial or underground styling, and hand-drawn routes with their length.
Coverage and path profiles: A coverage heat map for a sector, and a path profile from a customer to their access point. Both use US Geological Survey 10 m or SRTM 30 m terrain, with buildings and forest from OpenStreetMap. The model counts free-space loss, the biggest obstacle in the path, the curve of the earth and 60% of the clear space a radio beam needs (the Fresnel zone). It is a quick planning model, not a full radio study such as Longley-Rice.
Bands and placement: A bar along the top lists the bands your radios use, with counts; pick one to show only that band. A Devices button lists devices with no location, so you can place them.
Map on a TV, or for customers: A read-only map for a paired TV, and an optional outage map on your public status page with a "Check my location" button.

Alerts and customers

Tell the right people once per problem, and answer customers while they are still on the phone.

Alerts that say what happened

When three or more devices at one site are down, you get one site alert, updated as things change, instead of one alert per device. At five or more, it is titled "Suspected Outage". Other alerts cover radar hits, sudden signal drops (10 decibels or more below the device's own normal, ignored for 30 minutes after its access point or radio restarts or changes channel), access point lockups, power outages nearby and battery maintenance.

Alerts reach you as push notifications in your browser or on your phone, or by email through your own mail server. Each person chooses which alerts reach them, and how. A paused device or site sends no down or outage alerts.

More alerts are there when you want them: capacity, cable errors, dropped packets and jitter (each off until you set a limit), limits on any SNMP card reading, MikroTik and Netonix health, and solar power. The alerts bell counts repeats, lets you undo a dismiss, and opens the device, the DFS page or the setting behind an alert. Each person can send themselves a test push and pick their own alert sound, which plays while a WISPHero tab is open.

The alerts list open on a phone, showing a radar hit, a tower power outage, a customer that is down, high latency and a signal drop. — The alerts list on a phone.

Customer Diagnostic

Search for a customer by name, IP address or MAC address, and get one page a support person can read out on the phone: whether the customer's radio answers, its signal, their access point and its health, recent outages, radar hits, power outages and weather nearby, and billing status from Sonar. The strongest evidence comes first.

It also estimates whether the problem can be fixed over the phone, as a percentage with a range and the reasons. It starts from published figures for broadband in general and blends in your own results once 30 similar calls are logged. It gives no percentage when the cause clearly needs something else, such as a tower that is down. Call-center staff can use it without access to settings.

Customer Diagnostic for one customer: the connection status, signal, the access point it uses, an estimate that the problem will likely clear on its own, and two issues found, described in plain words. — What is wrong with a customer's connection, in plain words.

A status page for your customers

Turn on a public page that tells customers whether their area has a known problem, which saves calls. It shows your company name, logo and accent color, with no WISPHero branding. Planned work from your maintenance pauses shows too, and you can place the page inside your own website.

The page is off until you turn it on.

A public status page for a made-up wireless internet provider, with a banner about a problem in one area, a note about planned work in another, and uptime bars for each area. — A public status page your customers can check themselves.

Find where a path breaks

The Ping Tool pings up to 50 addresses side by side, as often as once a second. Each address gets its own graph on one shared timeline, so you can see where along a path the trouble starts.

A missed reply shows as a solid red block, never as zero. Copy the results or save them as a CSV file for a spreadsheet. It stops by itself after 30 minutes.

The Ping Tool pinging six devices side by side, with packet loss, average and current reply times for each, and a graph for each device below. One graph shows a red block where replies stopped. — Ping several devices at once and see where loss starts.

Getting your network in

Everything WISPHero watches is a host: one device or address, in a site such as a tower or a customer's home. Type them in, import a file, or copy them from UISP and your billing system.

Sites and hosts

New Host first asks what you are adding, then shows only the fields that fit it.

Equipment: A tower radio (with its band, frequency and direction for the map), customer equipment, a router or switch, a fiber ONT whose light levels come from a Calix system, or another SNMP device such as a UPS or power system.
Simple checks: Ping an address. Check a DNS server: ping it, ask it to look up a name, or both. Add a power reference: a device that is not on a battery, so that when it goes down, the whole site has lost power. Or add a reference only, which is listed and on the map but never checked.
Sites: Infrastructure (towers), customer premises, remote agent sites and data centers. Poles and splice enclosures are added on the map.
Import a file: Bring in radios from a CSV file (name, latitude, longitude, frequency and, if you like, address) or from the placemarks in a KML file. A preview shows what will be added before anything is saved.

Hosts from UISP

Copy the devices your UISP manages into WISPHero's sites and hosts, so you do not have to type them in. Preview shows what would be added and changes nothing; then a super admin applies it.

No extra load on UISP: It uses the copy of UISP's device list that WISPHero already reads about every 5 minutes. Preview and Apply send no request to UISP, and nothing is ever written to it.
What it adds: Your infrastructure: access points, point-to-point links, routers, switches, and power and fiber gear on tower sites. A UISP site you do not have yet becomes a new tower site.
What it leaves out: Customer equipment, which comes from your billing system. Also devices with no usable management address, devices not yet adopted or switched off in UISP, and devices on no UISP site. Stations on tower sites are left out unless you choose to add them for that one preview.
Nothing twice, nothing lost: A device whose IP or MAC address is already a host is matched, not added again. It never deletes or switches off a host. A device UISP stops listing is only marked missing, and if more than a fifth of your UISP hosts (and at least 5) would go missing at once, none are marked.
Keep it up to date: After the first apply, it can run every hour, every 6 hours, daily or weekly. It is off by default. A run applies only the safe changes and holds the rest for your OK. Hosts you deleted are not added back.

Customers from your billing system

Bring your customers in as hosts from Sonar or from UISP CRM, the billing side of UISP. You choose which customers are monitored.

Sonar: Customer sync, and an import of your network sites and devices with a preview first. Customers are picked by a custom field you set in Sonar, and a button looks up your custom fields. Customer Diagnostic shows a customer's billing status, plan and photos from Sonar.
UISP CRM: Customers are picked by a custom attribute, such as Monitor = Yes. WISPHero reads each one's name, address, plan and speeds. The address to ping comes from the customer's device on their linked UISP site, from the device list WISPHero already reads. It reads only; billing status is not shown for UISP customers.
Safe by default: A customer who no longer qualifies is switched off, never deleted. A host you edited keeps your changes, and one you paused stays paused. The UISP CRM sync also holds back when it would switch off many customers at once. Customer syncs run on a schedule; the UISP CRM sync is off until a super admin turns it on.
Other billing systems: PowerCode, Splynx and Azotel do not sync customers yet. They can be used only for the plan check in Customer Diagnostic.

Customer classes

Mark customer equipment as Residential, Business or Tower Owner. The class sets how often a device is checked (by default every 60 seconds for business, every 2 minutes for residential) and its alert defaults. You can also give each class its own quality limits. The class shows as a tag on the card and as a Status filter.

Devices, discovery and SNMP cards

The Devices page lists your gear by kind, finds devices you have not added yet, and shows any SNMP reading you choose. SNMP (Simple Network Management Protocol) is the standard way to read a device's counters.

Device tables

Access points: Site, model, band and channel, the number of connected customer radios, and a pill reading OK, the number of open issues, or Paused. Click the pill for the issues.
Customer radios: Where each customer came from, their access point and network name, and whether the radio has moved to its backup Wi-Fi network (from UISP).
SNMP and routers: Every SNMP device with one live reading you pick, and every router WISPHero can sign in to or monitor.
Find a MAC address: Look one up across your hosts, UISP and the server's own address table.
Infrastructure diagnostic: A full page for one tower device: radar hits, lockups, Ethernet, fiber and SFP light levels, capacity and its SNMP card.

The Devices page on the access point tab: a table of access points with site, model, band and channel width, the number of connected stations, and a status pill reading OK or the number of issues. — Every access point with its model, band, connected stations and open issues.

Discovery: find what you have not added

Discovery lists the devices on your own network, says which are already monitored, and adds the rest as hosts with one click. It scans only when someone opens the tab or starts a scan, or on a schedule you set.

When it runs: Opening the Discovery tab reads the server's own address table (ARP), which sends nothing. If the last full scan is more than 30 minutes old, it also starts a paced ping scan that stops when you leave the tab; you can turn this automatic scan off. "Scan subnets" shows what it will send and asks first.
Only your own network: Up to 8 subnets in private ranges, carrier-grade NAT (100.64.0.0/10) or link-local. A public range is refused. At most 10 packets a second by default (you can set 1 to 20), and Quiet mode halves it.
What each device is: When you ask it to identify devices, it tries Ubiquiti and MikroTik discovery, 8 management ports, the web page title and SSH greeting, SNMP with your saved settings, and the maker named by the MAC address. Each device says how it was identified.
What you get: Tags for New, Monitored and Not seen lately, "Add as host", and a CSV file of the list.
On a schedule: Off by default. At most once an hour, only inside a time window (1 a.m. to 5 a.m. by default), and either a read of the address table only or a ping scan too.

Proven so far: the address-table read and the ping scan have run on a real local network. The identify step has not yet seen answers from real Ubiquiti or MikroTik gear.

SNMP cards: build a card from any reading

A smart card shows the readings you choose from any device that answers SNMP: a power system, a UPS, a radio with no built-in support. It appears on the Devices page and on the back of the device's Status card.

Four kinds of widget: A number, with a unit, a scale and colors at the limits you set. A status, which turns a raw value into a word and a color, such as "up" in green. Text, such as a firmware version. A table with one column per reading and one row per sensor or port.
Find the reading: Not sure of the number (OID) to ask for? Type the device's address and Discover walks its live SNMP tree; click a result to use it.
Which devices get it: A card can match devices by the start of their SNMP system ID, or you assign it to a host. It works with SNMP v1, v2c and v3.
Alerts: Turn on alerts for a number or status widget, and WISPHero tells you when it turns bad or critical. The alert clears by itself when the reading recovers.
One reading in the list: Star a number or status widget to show it as a column in the SNMP device list.
Ready-made cards: Netonix switches, MikroTik routers and a generic switch card built on the standard interface counters.

MIB files and vendor cards

Import a MIB file: A MIB file is the vendor's list of what a device can report. Upload one and pick readings by name instead of by number; value names such as up and down are filled in for you. Standard MIBs that the file depends on are fetched from a public MIB library. If it depends on another file from the same vendor, upload that too.
Licensed and point-to-point backhaul: SIAE ALFOplus2, Ceragon IP-20 and Cambium PTP 820 and 850, Cambium PTP 650, 670 and 800, Aviat WTM 4000, SAF PhoeniX and Integra-X, Siklu EtherHaul, DragonWave Horizon Compact+, Exalt ExtendAir G2, and Ubiquiti airFiber, airFiber 60 and Wave, and airFiber 5XHD and LTU.
LTE (4G cellular): Baicells customer units and Nova and Neutrino base stations, Teltonika routers, and a card for any LTE radio that answers the standard MIBs.
Power: Tycon power monitors, Morningstar TriStar MPPT charge controllers through Morningstar's EMC-1 adapter, and any UPS with the standard UPS MIB.
Honest by default: Each vendor card starts with only the readings checked against the vendor's own MIB. Readings known only from community reports, or not yet verified, stay off until you turn them on. Every card says "Not verified on hardware" until someone confirms it on a real device.

Switches, routers and other gear

Beyond ping, WISPHero reads the switches and routers at your towers and the routers in your customers' homes. Each reader is polite: one conversation at a time per device, a shared limit for all of them, and longer waits after a device stops answering.

Netonix switches

Switch panel: Every port's link and speed, PoE (power over Ethernet) mode, VLANs, traffic, errors and dropped packets, and what is plugged in when the switch reports its neighbors. Netonix does not report power per port over SNMP, so the panel shows the switch's total power draw.
Health: Temperatures, voltages, fans, total power draw, CPU and memory.
How often: Every 2 minutes, and the switch's settings every 30 minutes, or now with "Poll now". Hourly graphs are kept for 90 days.
Rebuild sheet: Each saved snapshot of the settings is a printable sheet of port names, PoE modes and VLANs, for the day a storm kills a switch. "Compare with the one before" shows what changed.
Alerts: A port that keeps going up and down, power draw above a share of the power budget you enter, and a temperature above your own limit. All are off by default.

MikroTik routers

Monitoring is off for every router until you start it, because a router with a saved login is often a customer's own.

How it reads: RouterOS 7 through its REST API with a saved login. SNMP for RouterOS 6, and for a RouterOS 7 router with no saved login. Every 2 minutes by default, never more often than once a minute, and Quiet mode doubles the wait. It never asks for passwords or other secrets.
What it shows: CPU, memory, temperature, voltage, power supplies and fans, BGP sessions and OSPF neighbors, interface traffic graphs, and counts such as DHCP leases and PPP sessions. Hourly graphs are kept for 90 days.
Snapshots: A record of the router's settings as WISPHero reads them, such as IP addresses, routes and firewall rule counts, with a list of recent changes and a printable rebuild sheet.
Alerts: On by default: high CPU, low free memory, a power supply or fan the router reports as failed, and a BGP session or OSPF neighbor that was up and is gone. Off by default: an interface that keeps going up and down, and temperature or voltage outside limits you enter.

The customer's own router

On the back of a card and in Customer Diagnostic, the router panel shows a customer's MikroTik: its software version, Wi-Fi networks, connected devices, and ports with their errors. It asks the router when you open it.

Direct: RouterOS 7 only, through its REST API over HTTPS with a login you save. A RouterOS 6 router shows as unreachable rather than a wrong answer.
Through Admiral Platform: If your routers connect out to Admiral Platform, one Admiral API key reaches them all, even behind NAT, with no login for each router. It also shows Admiral's recent speed tests.
Bandwidth test: Run a bandwidth test from the router to a test server you set up.
Wi-Fi password: Showing a customer's Wi-Fi password needs a separate router login with that right, and a viewer needs a grant for it. Every reveal is logged.
Never changes anything: The panel only reads. It never changes settings or restarts the router.

Tower power: batteries and solar

A tower is only as good as its power. WISPHero keeps a record of your backup batteries, sizes solar sites, and watches the charge controllers it can read. It never makes up a number: where it does not know something, it says so.

Batteries

A register of the battery banks at your towers, huts and customer sites, grouped by tower with the worst first, so batteries are replaced before an outage proves they are dead. Sites with no bank recorded are listed too.

For each bank you record the chemistry (flooded, flooded OPzS, AGM, gel, LiFePO4 or NiCd), voltage, capacity, strings, install date and what it powers.

The Batteries page: totals for banks in service and overdue maintenance, then banks grouped by tower with chemistry, voltage, capacity, estimated runtime, age, share of expected life used, and maintenance that is overdue or up to date. — Tower battery banks: age, expected life, runtime and maintenance due.

Age and life used: The share of expected life used, with "Plan to replace" at 80% and replace at 100%. A capacity test below 80% of the rating is the measured end of life. An unknown install date gives no age, and an estimated one says "estimated by you". Batteries that makers do not rate in years, such as LiFePO4 and flooded deep-cycle, get no default life until you type one in.
Maintenance: Watering, specific gravity, voltage checks, terminals and torque, inspections, and resistance and capacity tests, each with its due date. Sealed batteries never get watering reminders. Log the work from a phone; entries made without a connection are kept and sent later.
Runtime estimate: Type the load in watts, or use the measured power draw of a Netonix switch, and the share of the battery you plan to use. The estimate shows the figures it came from.
Replacement forecast: How many banks are due for replacement each year.
Reminders: Alerts for overdue maintenance are on by default. Alerts 7 days before work is due, and near the end of a battery's life, can be turned on.
Sources shown: Every default life and maintenance interval shows the maker's or standard's document it came from. A printable site sheet and a CSV file are one click away.

Solar

Size a new solar site, and keep an eye on the ones you have.

Sizing calculator: Enter where the site is, what it powers, how many days it must run without sun, and the panel and controller figures from their datasheets. It works out the battery bank, the number of panels and how to string them, a cold-weather voltage check against the controller's limit, the controller current, a recommended tilt, and a month-by-month balance that flags short months.
Every assumption shown: Sun data comes from NASA's POWER service, one request per new location, kept for 180 days; you can turn it off and type the sun hours yourself. Every default is listed with its source, and the answer is labelled a planning estimate, not an engineered design. Save a result, print it, or export it as CSV.
Charge controllers: Read-only Modbus TCP for Victron GX devices, the Morningstar TriStar MPPT 60 (Ethernet model) and the MidNite Classic. WISPHero only ever reads; it never sends a write command. Power gear with an SNMP card works too.
No controller?: Use the input voltage that a Netonix switch or MikroTik router at the site already reports. It trends with the battery but is not the battery voltage, and the page says so. Or type in readings after a visit.
Graphs and alerts: Battery voltage, state of charge, solar power, charging, load and daily yield, read every 5 minutes by default. Low battery voltage (for 15 minutes, at the level cited for the battery type) and controller faults alert by default. No solar output while the sun is up, a battery that does not reach float for days, and a falling input voltage can be turned on.

Your server, your data

Runs on your own server

Install it on an Ubuntu server or virtual machine, version 24.04 or newer. One installer sets up Docker, the app and its PostgreSQL database. The installer is new and is being tested now, so start on a spare server.
Your data stays on your server

Device and customer data are stored on your server, not ours. The server contacts the systems you connect and public data sources, such as US weather, lightning and radar data, power-outage maps, flight data, satellite orbits and terrain data. While the dashboard's field briefing is open, it also reads public news and security feeds. Your browser loads map tiles from OpenStreetMap, weather radar images from NOAA, and some page code and fonts from public content networks. Settings > System > Network activity lists what the server sends, and many of these can be turned off.
Backups on a schedule

WISPHero backs up its settings every day at 4 a.m. by default and keeps the last 7. Full backups are optional. You can set an optional backup file password, during setup or later in Settings. It encrypts the backup files, and a backup made with it carries what a new server needs to read your saved passwords and API keys. Without it, backups still work, but after a move to a new server you type those saved passwords again, and WISPHero lists which ones. WISPHero cannot recover a forgotten backup file password. Keep a copy of your backups somewhere other than the server.
Signed updates you can undo

To update, you upload an update file in Settings. WISPHero checks its signature before it unpacks anything and makes a backup first. Most updates can be undone for 14 days. An update that makes a database change that cannot be reversed cannot be rolled back from the page. If a new version fails to start three times, WISPHero goes back to the old one by itself.
Roles for your team

Super admin, admin and viewer, checked by the server on every request, with optional two-step sign-in. See sign-in and roles.
Mail through your own server

Alert and password-reset emails go out through your own mail server or Gmail, and Settings has a "Send test email" button. Microsoft 365 is not supported yet.

Sign-in and roles

Who can see what, and how sign-in is protected. The server checks a person's role and sites on every request.

Roles and grants

Super admin: Everything, including managing admins, updates, backups, HTTPS and how long history is kept. There is always at least one.
Admin: Runs monitoring day to day (sites, hosts, devices, alerts and maps) and can add viewers, but cannot manage admins or change the server itself.
Viewer: Sees only the sites they were given. Pages and features are granted one by one: Customer Diagnostic, the outage indicator in the top bar, call-center notes, card notes and the Wi-Fi password reveal. Two quick choices, "Status only" and "Support desk", set them for you.
A record of changes: Role changes, accounts switched off or deleted, and password resets are logged with who did them.

Two-step sign-in

Optional for each person, and you can require it for administrators (it is off by default). After the password, WISPHero asks for the 6-digit code from an authenticator app, such as Google Authenticator, Microsoft Authenticator, Authy, 1Password or Bitwarden.

Recovery codes: Each person gets ten single-use recovery codes for the day their phone is lost.
One use per code: A code that has been accepted can never be used again, and wrong guesses are limited.
Lost phone: A super admin can reset another person's two-step sign-in after typing their own password (and their own code, if they use two-step sign-in). That signs the person out everywhere and leaves their password unchanged.

Proven so far: checked against the standard test codes, not yet with a real phone app.

Account protection

No default passwords: The installer makes a one-time setup code. You type it first, then create the first account.
Passwords and secrets: Passwords are stored as bcrypt hashes. API keys and device passwords that WISPHero keeps are stored encrypted.
Guessing limits: Sign-in attempts are limited for each address and for each account.
Forgot password: A reset link by email that works once and expires after 1 hour.
Uploaded files: Every upload, from a logo to a MIB file, is checked for what it really is, its size and tricks hidden in zip files. Pictures are redrawn before they are kept. Virus scanning with the free ClamAV scanner is optional.

Everything else it does

Header counters: 24-hour uptime, worst latency, and counts of slow devices, down devices and radar hits. The slow count opens a list of those devices.
Outages (24h): every outage of the day, ongoing ones first, with start time and length.
Filters you can share: every Status filter is kept in the page address, so a filtered view can be bookmarked or sent.
A "Reconnecting" banner: if the page loses contact with the server, it says so, so a frozen screen never looks like a healthy network.
Two kinds of notes: a card note that stays on the card and never alerts, or a call-center note that alerts the team.
List view: a dense table of every device instead of cards.
My view: each person picks card size, text size, jitter, trend arrows, flashing and turning cards over by themselves. Admins set the company colors and can lock personal choices.
Signal history: in Customer Diagnostic, a 24-hour or 7-day signal graph with radar hits, channel changes and restarts marked, and the reason for each drop.
Gentle polling: one limit for all device polling, one conversation at a time per device, and longer waits for failing devices. Quiet mode makes the background SNMP readers run half as often and talk to half as many devices at once; ping monitoring is not slowed.
Network activity: Settings lists every job that sends something on the network, with its requests in the last hour, and many can be switched off.
Find a setting: one search across every Settings tab, which also finds a setting by its old name.
Disk usage: see what WISPHero's data takes up, and set an optional size cap with automatic clean-up (off by default).
Release notes: what changed in each version, inside the app.

How far each part is proven

WISPHero is an early version 1 release. It was built and tested on one development computer, against a made-up demo network and test copies of the systems it connects to. For monitoring, a read-only API key (an access key that cannot change anything) is enough; only rebooting a radio needs a key that allows changes.

Run against real public data: US weather alerts and forecasts (National Weather Service), lightning (NOAA GOES satellite), weather radar (NOAA MRMS), radio ducting forecasts (NOAA GFS), utility power-outage maps, the outage status of airport weather radars, and the remote agent's public speed test. Discovery's address-table read and ping sweep have run on a real local network; its identify step has not yet seen real Ubiquiti or MikroTik answers.
Ubiquiti UISP: Built from UISP's published API and from what we learned testing a real UISP with a companion tool. WISPHero's own UISP connection has not yet run against a real UISP; that first run on a live network is next. Everything that reads UISP depends on it: radar hits, signal, LAN ports, stations, access point lockups, backup Wi-Fi changes and Hosts from UISP.
Sonar: Tried against a real Sonar account with a read-only key: the preview of the import of sites and devices, the customer-account query and the photo fetch all worked, and nothing was applied. In a sample of the accounts, only about one in five had a usable IP address in Sonar.
Built from vendor documentation: Cambium cnMaestro and Cambium SNMP, UISP CRM customer sync, Mimosa SNMP, Calix E7 fiber readings, Netonix switches, MikroTik routers (RouterOS 7 and 6), Admiral Platform, Preseem, the ready-made SNMP vendor cards and the solar charge-controller readers. Each was tested against sample data or a test copy of the service, not yet against real equipment or a real account.
Shown on demo data: The Status page and grouping, card diagnostics, History and Compare, the Ping Tool, RF Defrag and the data check, the map, Devices and the SNMP card builder, host import, Batteries, the solar calculator, alerts and email, the public status page, TV displays, backups, updates, roles, two-step sign-in and the phone layout. Push notifications, two-step sign-in and the phone layout have not yet been checked on a real phone.
The installer: The installer and its Docker setup have not yet been run on a real server. That testing is happening now.
Not in this release: Channel planning, channel changes and spectrum analysis; Microsoft 365 mail; and customer sync from billing systems other than Sonar and UISP CRM. PowerCode, Splynx and Azotel can be used only for the plan check in Customer Diagnostic.