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. Make sure you are on a network that can reach the target device and that you have the admin credentials for the device.
Step-by-step deployment
Step 1. Pick the project
Unzip the project files and open deployment.json. Update the LAN field to the ip address/hostname of the touch panel you’re deploying to.
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(Should be named {tenant}-middleware.json. 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 network manager and enter them again in Project Credentials. |
| Project not certified | The certification file is missing, or your Extron account is not certified. | Sign in with a certified account and click Certify Project, or contact us for support |
| Hardware mismatch | The device type does not match the project. | A package built for one model will not deploy to a different model, please contact us for support. |
| 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. |
Crestron (Web UI)
Deploying middleware to a Crestron processor uses the device’s built-in Web UI. Each site is shipped a single compiled program file with a .cpz extension. The same file applies to every supported processor in the family (CP4, RMC, DMPS); the only thing that differs between rooms is the IP address you log into.
Before you start
Make sure you are on a network that can reach the target processor over HTTPS, and that you have the admin credentials for the device. You do not need Crestron Toolbox, an SSH client, or any developer tools — the upload is fully driven from the Web UI in a browser.
You will receive a single file: {Site}Middleware.cpz (e.g. innomate.cpz, ~9 MB). Save it somewhere you can browse to from the same machine that has the Web UI open.
Step-by-step deployment
Step 1. Open the processor’s Web UI
Browse to https://<processor-ip> in Chrome or Edge. The processor uses a self-signed certificate, so the browser will show a “Not secure” warning. Click Advanced → Proceed (or, on the warning page, simply type the literal phrase thisisunsafe; the page captures the keystroke and bypasses the warning). The landing page redirects to the Device Administration login screen. Sign in with the admin username and password supplied for the site.
Step 2. Open Programs Slot Management
From the dashboard, click the Settings tab, then expand Programs. Inside that section, expand Programs Slot Management. You will see a table of ten slots — Crestron CP4 / RMC processors are licensed for up to ten concurrent programs. Innomate middleware always installs into Slot 1; the other slots are reserved for future use or third-party programs and should be left empty.
Step 3. Upload the .cpz
On the row for Slot 1, click the upload icon under Program Editing. A four-step File Upload dialog opens: Browse → File Upload → In Progress → Complete. Click + Browse, set the file-type filter to Customised Files, and select the .cpz you were shipped. Click Open, then start the upload. The transfer takes 30-90 seconds depending on the link.
If the dialog warns about a firmware-version mismatch, tick the Force Load / Skip Compatibility Check option and continue. Innomate’s CPZs are built against the 3-series Simpl# SDK and load cleanly on 4-series processors (CP4) in compatibility mode — this warning is expected and safe.
Step 4. Confirm the program started
When the upload completes, the slot 1 row updates to show:
- Program Name: the DLL name, e.g.
innomate.dll - Registration: Registered (green)
- Execution: Started (green)
Switch to the Status tab and expand Programs → Program Number 1. You should see the program details — Program Name, Program File, Compiled Date, Target Rack (e.g. CP4), Min Firmware Version, and a Program Status of Started. The Program IP Table will be empty; that is expected, because Innomate middleware uses raw TCP rather than CIP.
The middleware registers its hardware (relays, versiports, COM ports, IR ports) and opens TCP listeners on ports 5000, 5001, and 5002 automatically during startup. There is no separate “configure” step — the program is ready to take connections from the room engine the moment its status flips to Started.
Step 5. Verify with the room engine
The processor’s Web UI also exposes a text-console panel — open the Action menu in the top-right and choose Console (or the small terminal icon in the program slot row). All Innomate middleware diagnostics are namespaced under the cmd prefix:
| Console command | Confirms |
|---|---|
cmd help | The middleware cmd handler is loaded |
cmd ns | TCP listeners on 5000/5001/5002 are open; lists every connected room-engine client |
cmd cp | COM ports registered with their current baud configuration |
cmd relay | All relay ports registered and their open/closed state |
cmd dio | Versiports configured as digital outputs (digital inputs are not present on CP4) |
cmd ir | IR output ports registered |
Once the room engine is configured to point at the processor’s IP on TCP 5000, cmd ns will show the connection within a few seconds and the room engine’s controller driver will report IsCommunicating: True. Telemetry for the room (relay state, COM responses) starts flowing back to the monitoring dashboard at that point.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Browser refuses to load the Web UI past the certificate warning | The processor uses a self-signed certificate and the browser is blocking unsafe content. | Click Advanced → Proceed, or type the literal phrase thisisunsafe while the warning page is in focus. |
| Sign In rejects credentials | The admin password has been changed since handover. | Retrieve the current credentials from your network manager and try again. Do not lock the account out — three failed attempts triggers a temporary block. |
| Upload dialog warns about firmware version | The CPZ is built against the 3-series SDK and the target is a 4-series processor (CP4). | Tick Force Load / Skip Compatibility Check and continue. The CPZ runs in compatibility mode without functional difference. |
| Slot 1 status stays at Stopped after upload | The program registered but the runtime declined to start it. | Click the ▶ Start button on the slot 1 row. If it stops again immediately, restart the processor (Action → Restart) and re-check. |
cmd help returns “Bad or Incomplete Command” | The middleware program is not yet registered — usually the slot 1 row also shows Unregistered. | Wait 10 seconds after upload. If still unregistered, click ▶ Start, or re-upload the CPZ to slot 1. |
Room engine reports the controller as offline; cmd ns shows no connections | The room engine cannot reach TCP 5000 on the processor. | Check the room engine config has the processor’s IP and port 5000. Confirm there is no firewall or VLAN ACL between them blocking high TCP ports — only 22/80/443 are commonly allowed. |
| Two slots show the same program registered | The CPZ was accidentally uploaded to multiple slots. | Stop and clear all slots except slot 1. Running two copies causes silent hardware-registration failures (relays, COM ports, TCP listeners can only be claimed by one program at a time). |
| RS-232 device not responding | The COM port is at the default 38400-8-N-1 but the device runs at a different baud rate. | In the console, run cmd cpc <port> <baud> <databits> <parity> <stopbits> — for example cmd cpc 1 9600 8 N 1. The setting persists across reboots. |
Platform notes
- Concurrent programs: CP4 / RMC processors are licensed for up to ten programs running side by side. Innomate middleware always uses slot 1; do not duplicate it into other slots. Crestron does not arbitrate hardware or TCP-port collisions between programs — a second instance will appear to start but its hardware registrations will silently fail because slot 1 already owns them.
- Digital inputs: CP4 processors do not expose physical digital inputs.
cmd dioreports them as unsupported and the JSON-RPCget_digital_input_statuscommand returns the same. RMC3 processors have two digital inputs and behave normally. - COM port count: CP4 has up to six COM ports registered, but only the first two are bridged to TCP (port 5001 → COM 1, port 5002 → COM 2). Additional ports register but are not exposed externally.
- SSH: the processor’s SSH service is for diagnostics only. SFTP and SSH port-forwarding (
direct-tcpip) are administratively disabled by Crestron and cannot be used to deploy or tunnel into the device.