About this page. Every screenshot below is taken from the live application and then sanitised: addresses are from the reserved documentation range, keys and QR codes are synthetic, device identifiers, room numbers, VLAN IDs, names, ticket contents and floor plans are all replaced or blurred. Nothing on this page is real customer data.
AIR Manager is the operations console we built for a large hospitality property: a hotel with several hundred guest rooms, a dozen food and beverage outlets, a resort spread over multiple buildings, and everything in between. The estate is deliberately multi-vendor: a FortiGate firewall cluster for routing, DHCP and DNS, a Ruckus SmartZone controller with several hundred access points, twenty-five Ruckus ICX switch stacks, a MikroTik-based monitoring server, a PBX, an HR system that decides who is staff, and Microsoft 365 for mail.
Each of those systems is excellent at its own job and each has its own console. None of them knows about the others. The questions an operator actually asks, though, always cross those boundaries:
Answering any of those by hand means logging in to three or four systems, copying identifiers between them, and reconciling naming conventions that were never designed to match. AIR Manager exists to do that correlation once, continuously, and show the answer on one screen.
We never sat down and designed a platform. AIR Manager started as a single page, and every subsequent feature arrived because a real question could not be answered without joining one more data source. That order matters, because it explains why the tool looks the way it does.
The first version did one thing: read the lease table from the FortiGate and show it in a searchable grid. Even that was an improvement, because the firewall's own view is per-scope and cannot be searched across every VLAN at once. Reservations came next, because turning a lease into a reservation on the firewall itself takes far too many clicks.
The moment we joined SmartZone, the lease table changed character. A lease stopped being a bare IP and MAC and became a device on this SSID, on this access point, in this room. That single join created the Location columns, the Rooms monitor and, later, the maps. It also gave us the DPSK manager, because the property runs on dynamic pre-shared keys rather than a forest of SSIDs, and the controller's own DPSK page was never meant for front-of-house staff.
Adding the ICX estate over SNMP and SSH brought wired devices into the same picture: which port, which profile, which PoE budget, and which neighbour is on the other end according to LLDP. This is where Switchports and the port-profile engine came from. Port profiles are the single most important operational control in the building: a profile decides which VLAN, which ACL and which PoE and STP settings a port gets, and applying them consistently across twenty-five switches by hand is exactly the kind of work that produces silent mistakes.