Pixelhue U5 / U5 Pro / U5 mini event controllers

Verdict. Pixelhue built its consoles around a service that already does the hard part of being someone else's control surface. UCenter holds a model of the show, draws the panel from it, runs its own gesture and mode logic, and reports intents rather than button ids — and it takes that model from whoever publishes one. Published a LivePremier's screens, inputs and memories, it labelled its keys with them and handed back S2, LIVE_2 and Memory 2 when they were pressed; the brand of switcher underneath is a host-side decision. The U5 and U5 Pro turn out to be Windows PCs, the mini a Rockchip Linux box, and both run the same Go framework with the same structs, so one integration covers the line; the U3 is a different, closed stack. The fences are all Companion's: the built-in Companion sees 24 keys of ~203, but the protocol beneath it sees every key, the T-bar and — once bound — every fader and encoder. All of this is the vendor's own service observed on the wire, not a console; lamps, key displays, the physical T-bar's tag and whether the U5's port answers off-box are what a unit on the bench would settle.

Method

Two bases, and no console on the bench — nothing on this page was read off a running unit. The first is static: the firmware packages Pixelhue publishes (U5 mini V1.0.3, U3 V4.0.6, U5 and U5 Pro NewOS V1.8.0 of 2026-01-08) were unpacked down to their filesystems and read, and the control application inside them ships its Vite source maps, so the command vocabulary, the REST calls and the payload formatters were read as the vendor's original TypeScript rather than reconstructed from a bundle. The second is the vendor's own control service running: the U5 Pro's UCenter binary, taken from that image, in a Windows 11 VM, and the native macOS build PixelFlow installs, driven by the vendor's own on-screen virtual U5. Everything labelled verified from that second basis was observed on the wire from that service — which, like a switcher simulator, is not hardware. The U3 was identified and left: its Apollo binary protocol was not pursued.

Artifacts examined

• Pixelhue firmware packages U5MINI V1.0.3, U3_full_update_V4.0.6.STD, U5_NewOS_V1.8.0_20260108 and U5Pro_NewOS_V1.8.0_20260108 — NovaStar Nova containers around a squashfs (mini), ext4 and legacy blobs (U3), and a Clonezilla image of a whole Windows install (U5 / U5 Pro)
• ucenter_win.exe / ucenter_darwin_arm64 — the Go control service; its ncp.toml, runtime.toml and the key XML (key_function.xml, key_mini.xml, midi_key.xml) that carry the bus map, the key state machine and the Music-MIDI layout
• pixelflow.exe (Electron) — its app.asar, including the Unico web app's source maps (6,191 original TypeScript files), the on-screen keyboard key tables and a WebSocket relay for the built-in Companion
• The mini's nvcontroller (Go, aarch64) and Lcd (Qt) processes, the embedded headless Companion 4.3.2 bundle, and Pixelhue's open-source Companion surface plugin and switcher module, whose sources are plain JavaScript
• Wire traffic from the vendor's own UCenter running headless and from its virtual U5 panel, decoded with our own NOVA-frame codec, plus a reference client that publishes a model and logs the intents that come back

No manufacturer firmware, binaries or documentation are redistributed here. Artifacts are referenced by name and version only. See the method and legal statement for the basis on which this analysis was performed and the boundaries it observes.

Hardware architecture

Software architecture

Update path & security model

These rows describe how a platform validates a firmware image, because that is a structural fact about its architecture. They are not a vulnerability disclosure and no exploit, bypass or circumvention technique is published here. Licensing and entitlement mechanisms are out of scope throughout — seescope boundaries.

What is programmable

1. 1Publish a switcher model to UCenter and answer its intents

   The route the vendor's own app uses, and the one with no fence: the console labels, pages and lights its own keys from whatever model it is given and returns numbered intents carrying the host's identities. Proven against the vendor's service with an Analog Way LivePremier model driving a LivePremier simulator — screen select, input to preview, take, cut, match PGM, recall, store, freeze, FTB and the T-bar — with no key painting and no Pixelhue switcher anywhere.

2. 2The raw key stream plus key/action

   The same socket reports every key by id and business state, and REST injects presses. For a host that wants a plain button box, this is it — and injection makes the whole chain testable with no console.

3. 3The built-in Companion surfaces

   The mini is already a network Companion surface on 17100 that any Companion can point at. On the U5 / U5 Pro the built-in Companion is useful but confined to 24 or 12 keys, and gets no T-bar, faders or encoders.

4. 4Music MIDI

   A documented-in-config USB-MIDI layout for the whole panel, off by default. Serviceable for a lighting or media server; the continuous-control encoding is not settled.

5. 5The U3

   A closed binary protocol and no Companion. The hardest of the four and not pursued.

Traps

Mistakes this analysis actually made, or came close to making. They are recorded because each one produces a plausible-looking wrong answer rather than an obvious failure.

• Publishing 0-based key positions. index is 1-based; 0-based silently drops the first object of every bus — Screen 1 vanished and key 0 showed Screen 2 — with no error anywhere. The console's own key_mini.xml says 1-based in writing; it was learned from the panel first.
• Trusting ok on an empty model. Empty arrays always validate, so {} answering ok proves nothing. The useful signal is the failure: the service returns Go unmarshal errors naming the struct and field it rejected (RInput, inputs.hasBackup), which is the fastest way to learn the schema.
• Two publishers. The model is last-writer-wins, and the vendor's own PixelFlow main window republishes its project a second after its virtual panel opens — so both apps act on every press and the keys show the other app's buses. And a new vendor client connecting wipes the published model without telling the publisher, which has to notice its labels vanish and republish.
• Taking the vendor's tag list at its word for the T-bar. The web app's whitelist names 0x00101304; the virtual panel's T-bar arrives on 0x00101358. Code keyed to the documented tag hears nothing.
• Expecting fader and encoder moves without a binding. Unbound, they are dropped inside the service and no client hears them — the silence looks exactly like a broken socket.
• Sending ip / port headers to the MIDI routes on the macOS build. That build's REST proxies to the device the headers name; naming itself, the MIDI family loops until the process runs out of file descriptors.
• Reading the key-state item from an older record. It carries businessID, open and businessType, not the icon field the first teardown assumed; and a held key reports only its repeat code, never the click code, so a non-repeating action has to fire on the first repeat.

Open questions

• A real console. Everything here is the vendor's control service with its panel check off, or its virtual panel — what the physical key displays and lamps do with a published model, and whether the real T-bar reports on 0x00101358 like the virtual one or on the 0x00101304 the web app names, are unobserved.
• Whether 19999 answers from the LAN on a shipped U5 / U5 Pro. It binds all interfaces; the console's own firewall configuration was not examined. If it does not, U5 integration means software on the console, where the mini needs none.
• The mini's nvcontroller has never been run. Its structs, routes and key XML match the Pro's and add only the area-switch keys its eight-wide buses need; whether it too refuses to start without its panel, and whether its LCD renders business labels or only Companion images, is open.
• Layer names and the cue list. Layers bind only on the active screen and carry no label into the panel, and cues, medias and funcs were only ever published empty.
• The swallowed press. Rarely, an injected down/up pair in the right order produces no command. It was caught on the vendor's service, not our client, and would not reproduce on demand.
• The U3's Apollo protocol.

Related entries

• Analog Way LivePremier / Aquilon — Video presentation switcher
• Analog Way Midra series — Video presentation switcher
• Analog Way LiveCore — Video presentation switcher
• Blackmagic Design ATEM (switcher family) — Live production video switcher