Reading NovaStar LED processors without breaking the wall
Every LED wall on a festival site runs through a NovaStar processor, and the only thing that talks to one is NovaStar's own software. Here is what is actually on the wire, and why the first release only reads.
Every LED wall I have worked on runs through a NovaStar processor, and the only thing that talks to one is NovaLCT or VMP — Windows software, on a laptop, usually the one laptop on site that nobody is allowed to touch. If you want to know whether the wall is actually receiving a signal, you walk over and look at it.
That is a strange gap. The processors are on the network. They answer questions. There is simply no third-party way to ask.
RepositoryPythonlegofsalmon/novasunWhat is actually on the wire
The short version, after a couple of weeks of packet captures and reading everything NovaStar has published: it is all one register bus. NovaLCT and VMP are not doing anything exotic — they read and write registers over a documented protocol, and current COEX controllers additionally expose a JSON API on port 8001 with no authentication at all.
Control is very achievable. It is configuration — cabinet mapping, calibration coefficients — where the real work lives, because that is venue knowledge no probe can recover. Which port feeds which wall is something a human knows and a network does not.
The findings are written up properly in docs/investigation.md, along with the wire format, the register map, and worked examples. If you only read one file, read that one.
Why the first release only reads
I could have shipped write support first. I deliberately did not.
A blackout command sent to the wrong processor during a set is not a bug report, it is an incident. So the first useful thing is a read-only monitor: is the processor reachable, is it receiving, what is it doing right now. That answers the question I actually have at 2 a.m. without introducing a way to make things worse.
The same reasoning runs through the monitoring in Crewbox — the Art-Net, sACN and NovaStar listeners there are all read-only by construction, not by convention. A tool that watches your show should not be able to change it.
RepositoryTypeScriptlegofsalmon/crewboxScreens, not IP addresses
Nobody thinks "192.168.1.40 port 3". They think "the main wall" and "the side fill". So the application models screens — a named wall assembled from parts of one or more processors — and every action addresses only its own output ports. Blacking out the main wall cannot touch the side fill sharing that processor.
A few other decisions that came out of the same instinct:
- Controls appear only if the connected model supports them. Inputs whose select code is unestablished show greyed, with the reason.
- Blackout, freeze and test pattern confirm before they send.
Unreachableis a state with a retry, not an error dialog — includingin-use, which is just what you see when NovaLCT already holds the session.
State lives in novasun.app.state and the HTTP service only exposes it, so a
different front end can import the state layer directly and skip the web server
entirely.
Where it goes
Configuration is the hard half and it is next. Cabinet mapping is where a mistake is expensive and slow to undo, so it will get the same treatment: read it, show it, make it obvious, and only then let anyone write it.