Controlling your display
Underneath everything sits one idea: a display is driven by short text commands, addressed by position.
0:DISPLAYCHAR:A
Module 0 is whichever module received the command, 1 is the next one downstream, @ is all of them. That's the whole interface. Every tool below is a client speaking that protocol, so nothing here does anything you couldn't do yourself with curl, and nothing locks you to one piece of software. The full command list is on the electronics page.
Three ways to drive a display exist today. They aren't stages you graduate through. Pick whichever fits what you're doing.
| Module web UI | play.flipforward.de | local-control | |
|---|---|---|---|
| Where it runs | On the module itself | In the cloud | Desktop app, macOS, Windows & Linux |
| Needs internet | No | Yes | No |
| Finds displays | You type the IP | After pairing | Automatically, on your network |
| Homing & alphabet setup | Yes | Yes | Yes |
| Multi-row displays | No | Yes | Yes |
| Images & custom alphabets | No | Yes | — |
| Firmware updates, logs | No | No | Yes |
| Cycling through several messages | No | — | Yes, on a repeat interval |
| Saved playlists | No | — | Not yet |
| Open source | — | — | Yes |
| Best for | First power-up, quick checks | Getting going fast, remote control, testing without hardware | Installations, maintenance, working offline |
The module web UI
Every module runs its own small web interface. On first power-up it opens a WiFi network called "flip forward". Connect to it, open a browser, and you get a setup page. Once you've given it your WiFi credentials, the same page is reachable at the module's IP address on your network.
It's deliberately minimal: home the module, configure the alphabet, set a character. No playlists, no multi-row displays. Enough to get a module working and to check one that's misbehaving, and it's always there, with no app, no account and no internet.
play.flipforward.de
play.flipforward.de is the easiest way to get going, and the only one that works without hardware.
It runs two kinds of display, and this is the part worth understanding: virtual twins and hardware displays behave identically. A virtual display in the browser and a wall of real modules take the same content, the same alphabets and the same commands. So you can design a display, build the alphabet, load an image and get everything right before a single module exists. When the hardware arrives, the same configuration drives it.
Virtual displays let you build and test any display size in the browser, with sound. Pair a module with your WiFi and play drives it remotely over MQTT from anywhere. Multi-row displays get defined here too, including which rows form one logical display and how characters map across them. Images render across a grid of modules, alternative alphabets can be previewed before you have flaps printed, and webhooks push updates in from any external system.
It's free, and it's the intended way to drive displays with more than one row.
local-control
local-control is a desktop app for macOS, Windows and Linux, and it has quietly become the way most people run their displays. It's open source, and installers for all three platforms are on the releases page.
It finds displays by itself. Point it at a network and it discovers every module via mDNS/Bonjour (service type splitflap), so there are no IP addresses to write down and no pairing step. Where discovery is blocked, add a display by IP instead.
From there it does the things the other two can't. Firmware gets flashed from a local .bin file, served by a small HTTP server the app runs on your own machine, or from a public URL, so updating an installation doesn't mean touching each module one at a time. A live activity log records every command sent and every request received, which is how you debug a module that won't behave. A guided calibration flow walks through aligning a module's flaps step by step. Individual modules can be told to reboot, blink, home or show a single character. Text can be sent as a list that cycles on a repeat interval.
It's also fully local. Nothing leaves your network, and nothing depends on an internet connection or on play.flipforward.de being reachable. For a gallery, an office, or anywhere the network is closed off, that's usually what decides it.
Download local-control for macOS (Intel and Apple Silicon), Windows, or Linux as .AppImage or .deb. The source is on GitHub if you'd rather run it with npm start.
local-control can cycle through several messages on a repeat interval, which covers a lot of installations. What doesn't exist is a proper playlist: a named sequence you can save to a file, reload later, and hand to someone else. That's next on the list. If you're planning an installation that depends on rotating content, say so, because it helps to know what shape it needs to take.
Building your own
The protocol is simple enough that writing your own control software is a small job. Send an HTTP POST to a module and it forwards the command down the chain:
curl --request POST \
--url http://IP_OF_FIRST_MODULE/command \
--header 'content-type: application/x-www-form-urlencoded' \
--data command=3:BLINK
Every tool above uses that same path. Home Assistant, a cron job, a shell script or your own app all work equally well. The electronics page has the commands and the serial route.