Middleware is the piece of software we load onto AV controllers and processors so that the room hardware can participate fully in an Innomate-controlled space. It is typically deployed to the device that sits closest to the rest of the room gear, such as a Crestron CP4 or RMC, an Extron control processor, an Extron TLP touch panel, or an AMX controller.
What middleware is for:
Middleware serves three purposes depending on where it is deployed and what the room requires: Passthrough, Monitor and Control, and Custom UI.
Passthrough
Many rooms contain devices that are not reachable over the main control network. They sit on an isolated serial bus, an IR loop, or a local IP segment behind the controller. The controller or processor is the only device with a physical connection to them.
Middleware running on that controller relays commands from the room engine out through the local ports to the unreachable devices, and relays responses back. This is how displays, projectors, microphone mixers, blind controllers, and DSPs become reachable to the rest of the control stack.
Monitor and Control
Some devices expose a vendor API, but that API does not cover everything the hardware can report or do. Firmware-level state such as lamp hours, fan speed, input detection, button health, brightness, and error conditions is often only available through a proprietary event channel that the published API ignores.
Middleware subscribes to those internal channels, normalises the events, and exposes them through a consistent interface. This is how the fleet monitoring tools know a device is unhealthy before the end user notices, and how the room engine can control features the vendor API does not cleanly support.
Custom UI
On touch panels and control processors that support on-device runtimes, middleware is the user interface itself. It renders the panel home screen, handles button presses, drives source selection, and talks back to the room engine over the network.
This is how an end user in a teaching space, meeting room, or auditorium interacts with the room. The panel runs Innomate code end-to-end, and the rest of the control stack never has to be exposed to the user.
Supported Platforms
Middleware is packaged and deployed differently for each vendor family. Each vendor has its own runtime, its own deployment tool, and its own certification or signing requirements.
| Vendor | Typical target device | Deployment tool |
|---|---|---|
| Extron | TLP Pro, IPCP control processor | ControlScript Deployment Utility, Global Scripter |
| Crestron | CP4, RMC, DMPS | Crestron Toolbox, Webui |
| AMX | NX controller, Modero touch panel | NetLinx Studio |
Deployment Guides:
The remainder of this page documents deployment for each supported vendor. Guides for additional platforms will be added as they come online.
Extron (ControlScript Deployment Utility)
Deploying middleware to an Extron controller or touch panel uses the vendor’s ControlScript Deployment Utility. Each site is shipped a deployment bundle containing one project per room. Every project has the same internal layout; the only value that differs between rooms is the address of the target device.
Before you start
Make sure you have the ControlScript Deployment Utility installed and that you are signed in. Make sure you are on a network that can reach the target device and that you have the admin credentials for the device.
The projects shipped in the deployment bundle are already certified. New projects that you generate using the provided tool inherit the same certification. A ControlScript-certified Extron account is only required if the certification ever needs to be reissued.
Project architecture
A middleware project is a folder containing everything the target device needs. The layout below is the same for every project. The filenames in your bundle may differ in spelling but the structure is always this shape.
| Item | Description |
|---|---|
| Project file | The top-level manifest. It tells the deployment utility which folders contain the source, layout, and assets, and it carries the address of the target device. This is the file you point the utility at. |
| Source folder | The Python source that runs on the device. This is the middleware itself. |
| Layout folder | The graphical layout that the panel renders. For Extron touch panels this is a GDL file. |
| Asset folders | Supporting folders for sounds, images, and infrared files. They may be empty if the project does not use them. |
| Deployment variables | A small file holding values the middleware reads at runtime, such as room name, default sources, and feature flags. |
| Certification and credential files | Two opaque files issued by Extron. They prove the project was built by a certified account and the deployment utility will refuse to deploy without them. |
Step-by-step deployment
Step 1. Pick the project
Each room in the bundle has its own project folder. Open the folder for the room you are deploying to. If the room you need is not in the bundle, run the package generator tool that ships alongside the bundle, enter the room ID, and it will produce a new project folder in the same place.
Step 2. Open the ControlScript Deployment Utility
Launch the ControlScript Deployment Utility. On the main screen, click Browse and select the project file inside the room’s project folder. The utility reads the project file and loads the rest of the project automatically.
Step 3. Check the certification
Look for the Last Certified timestamp next to the Certify Project button. If a timestamp is shown, the project is certified and can be deployed. If no timestamp is shown, or the utility reports that the project is not certified, sign in with a ControlScript-certified Extron account and click Certify Project. Under normal operation this step is not required because the shipped projects are already certified.
Step 4. Enter the device credentials
Click Project Credentials. The dialog lists the target device with its address already filled in from the project. Enter the admin username and password for the device and click Save. Credentials are held in memory for the session only and are not written back into the project.
Step 5. Deploy
Click Deploy to push the full project to the device. Use Deploy Code Only for a faster push when the user interface layout has not changed and you are only updating behaviour. The Messages panel at the bottom of the utility reports progress. A successful deployment reports that the hardware was found, that the credentials are valid, that the hardware matches the project, and finally that the deployment completed.
Step 6. Verify on the device
The device reboots into the new software within about thirty seconds. Confirm that the expected home screen appears on the touch panel, or that the controller comes back online and responds to commands from the room engine. If telemetry for the room starts flowing back to the monitoring dashboard, the deployment is live.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Hardware not found | The device address is unreachable from your network. | Check the address in the room list. Ping the address. Confirm you are on the correct network or VPN. |
| Wrong credentials | The admin password has been changed. | Retrieve the current credentials from your secure store and enter them again in Project Credentials. |
| Project not certified | The certification file is missing, or your Extron account is not certified. | Regenerate the package with the Room Package Generator, or sign in with a certified account and click Certify Project. |
| Hardware mismatch | The device type does not match the project. | Confirm the device model in the room list. A package built for one model will not deploy to a different model. |
| Device boots to a blank screen | The layout file did not make it to the device. | Run Deploy rather than Deploy Code Only to re-push the full project including the layout. |