If AV monitoring ignores the application layer, you're flying blind.

If your AV management platform doesn't incorporate the application layer, you're missing the biggest data source in the room, the biggest cost-saving opportunity, and the foundation for every AI capability that matters.

Here's what that means. Right now, the application that controls every room in your estate (the software that drives the touch panel, switches sources, manages audio and video, and delivers the user experience) is sitting on a hardware controller, custom-programmed by an integrator, unique to that room, and untouched since the day it was installed. Your monitoring platform can see whether devices are online. It cannot see what users are doing, where they're struggling, how the room is being used, how the devices are configured, the application on the controller, or what the devices are logging. That context lives inside the control layer, and if your platform excludes it, you are operating on a fraction of the available intelligence.

You're also paying more than you need to. Every room with a dedicated hardware controller and a custom-programmed application carries the cost of that controller, the programming, the integrator's design and commissioning time, and custom-designed touch panels locked to a single vendor. None of that is necessary when the application runs from the cloud.

Innomesh closes this gap by incorporating AV control as a managed application layer served from the cloud. No in-room controllers. No custom programming. The application is part of the subscription, is evergreen, is highly available and is continuously improved. And because Innomesh owns the application layer, it captures user interaction data, native device telemetry, centralised logs, device configurations, and user sentiment that monitoring-only platforms will never have access to.

To understand the gap, look at how AV control has worked for the last 25 years. An integrator designs a room, installs a hardware controller (Crestron, AMX, Extron, Q-SYS), writes a custom application for that controller, loads it, and walks away. The application controls the displays, the audio, the cameras, the video switching, and the touch panel interface.

Then nothing happens. For years.

That application sits on that controller, unpatched and unmanaged, for the life of the hardware. The industry calls it "if it ain't broken, don't fix it." Multiply that across hundreds or thousands of rooms, and you get an estate of unique, isolated applications with no central management, no version control, and no way to push improvements.

The consequences compound over time:

• Configuration drift. Room settings change as technicians make local fixes. No mechanism corrects the drift or detects it.
• Inconsistent user experience. Every room looks and behaves differently. Users can't walk into a new room and know how to start a meeting.
• Bug accumulation. Issues discovered in one room's application exist in others too, but there's no way to deploy a fix across the fleet.
• Stale technology. The application can't evolve. No new features, no AI integration, no data collection, no cloud connectivity.
• High cost of change. Any modification requires an integrator, on-site access, and custom programming time.

Adrian Whitaker, Associate Director of Learning Environments at QUT, described what this looked like before Innomesh:

AV monitoring and management platforms address part of the problem. They give you visibility into device health, alerting, remote troubleshooting, and limited analytics. That's valuable.

But monitoring platforms sit alongside your existing AV control infrastructure. The controllers stay in the room. The custom-programmed applications stay on the controllers. The integrator programming model stays intact. You gain some observability, but the unmanaged application layer remains untouched. And if you face an application layer problem, such as a bug in the room's program, a misconfiguration, a memory leak, or a security exposure, the monitoring platform cannot detect it, diagnose it, or fix it. The bug persists until someone physically reprograms the controller.

This is the architectural gap. You can monitor a room, alert on a fault, and reboot a device remotely. But you cannot update the control application, standardise the user interface, correct configuration drift, deploy a bug fix across your fleet, or evolve the room experience without sending an integrator back to reprogram the controller.

The controller and the application on it remain the unmanaged layer in the stack. The same architectural gap shows up across enterprise UC management more broadly: monitoring sees the surface; it doesn't run the layer where the user experience lives.

Innomesh replaces the in-room controller with a cloud-native application layer. Each room runs as its own containerised instance in the cloud, deployed across highly available data centres in an active-active configuration, not on a hardware processor in the rack. This changes everything about how AV control operates.

Luke Lickfold, Manager of AV Infrastructure at the University of Queensland, captured the shift:

This is the part most people miss. When a platform only monitors devices from the outside, it sees health data: is the device online, is it responding, what firmware is it running? That's useful but limited.

When a platform controls the application layer inside the room, it sees everything the user does and everything the devices report natively.

User interaction data. Because Innomesh drives the touch panel, it captures every user interaction: which source was selected, whether a user switched inputs within seconds (suggesting confusion), how long it took to start a meeting, and whether the help function was triggered. This is data that a monitoring platform sitting outside the controller can never access because it doesn't own the interface.

Native device data. Innomesh deploys applications on controllers that are native to each manufacturer's ecosystem. This gives the platform access to data and telemetry that is normally locked inside proprietary APIs and ecosystems. A monitoring platform polling a device over the network sees surface-level health. Innomesh, running inside the manufacturer's environment, sees the full picture.

User sentiment. Innomesh provides sentiment collection directly on the touch panel in the room. Users rate their experience with a quick tap. That sentiment data correlates with ServiceNow tickets and device alerts, giving your support team context about whether a room issue is affecting the user experience or whether users are satisfied despite what the monitoring data suggests.

Proactive issue detection. By combining interaction data with device telemetry and user sentiment, Innomesh can detect rooms where users are struggling before a formal support ticket is raised. If a user is pressing too many buttons within a short period of time, following a certain pattern, that might indicate a configuration problem, not a device failure. A monitoring-only platform would never see it.

This data advantage compounds over time. Every interaction, every sentiment rating, and every native device signal feeds into an operational picture that enables AI-powered insights, trend analysis, and eventually self-support capabilities on the touch panel itself, where users can interact with an AI assistant directly in the room via the panel or a QR code on their mobile device.

Traditional AV control deployments start from scratch. Every room requires design, programming, and consultancy before a single device is configured. That's weeks of work and thousands of dollars per room.

MarketSpace (marketspace.innomate.com.au) is Innomesh's free, community-driven marketplace of AV room templates. It flips the model entirely.

Universities and organisations that have deployed Innomesh can opt in to contribute their room configurations back to the community. Each template includes schematics, bills of materials, power and data requirements, UI designs, the AV control application and complete configuration files. Another organisation can take a proven, production-tested blueprint from a peer institution and deploy it in its own environment at no additional expense. No consultancy fees. No design fees. No programming fees.

MarketSpace is members-only and opt-in. Access is available to Innomesh members who choose to participate: if you contribute, everything the community has contributed is shared back with you. Innomate curates all content, so members don't have to do anything beyond opting in.

No competing AV control or monitoring platform offers a community where customers share and reuse production-proven room configurations.

Queensland University of Technology manages over 1,100 rooms. Before Innomesh, they ran AMX controllers with bespoke programming. They evaluated multiple platforms and chose Innomesh specifically because of the vendor-agnostic, cloud-delivered control model.

The result: room software and configuration live entirely in the cloud. Their existing AMX controllers run generic Innomesh middleware that extends the lifecycle of hardware assets that would otherwise require replacement. No room-specific programming exists on the controller. QUT can change a room's behaviour, update the user interface, or add a new device type from the portal without dispatching a technician. And the migration was non-intrusive: no hardware changes, keeping 12-year-old AMX G5 touch panels and NetLinx controllers operational, with the user experience maintained, preserving familiar branding and workflows.

Adrian Whitaker described the difference:

The University of Aberdeen replaced a patchwork of AV control and monitoring solutions across 304 spaces and 2,500+ devices with a single Innomesh deployment. And because Innomesh controls the application layer, Aberdeen now has access to interaction and operational data they never had before.