Build

Organise a full aircraft into logical panels — overhead, MIP, pedestal — that mirror the real layout.

Give each aircraft its own Project and tell it which aircraft it's for — C172, B738, or the Zibo 737 rather than any 737. Load a different aircraft in X-Plane 12 and the cockpit follows: the right Flows run, LEDs and displays show the new aircraft's state, and switches you left on carry over into it. It works offline, and an aircraft no Project is for simply runs your active Project. The official Cessna 172 Blueprint switches on its own.

Draw behaviour as a node graph. Bind hardware to datarefs and commands, with per-binding value transforms and optional guard conditions. Map ranges that stay in bounds, give a throttle or trim axis a response curve, follow a non-linear gauge face point by point so the fuel or airspeed needle lands on the right mark, and use lookup tables to turn the gear handle into a lamp or the transponder mode into STBY on a display.

Put an old tablet, a phone or a StreamDeck in the cockpit next to your ESP32 panels. Open the Touch Panel from your Bridge in the tablet's browser, claim it with the code on its screen, and wire its buttons, switches, knobs, sliders and lamps in the same Flows as your physical boards, with text such as a radio frequency drawn on the touch panel. Put a gauge on it and its needle follows any dataref through the same Flow you would give a servo; switch the touch panel to full screen and that one gauge fills the whole window, ready to sit behind a 3D-printed or laser-cut bezel, and every named window on the same PC is a touch panel of its own. Install the StreamDeck plugin and it finds your Bridge by itself: a key lights up in the colour your Flow picks, shows the frequency as its title and swaps it when pressed, and a Stream Deck +'s dials turn like encoders. A touch panel for the radio stack you haven't built yet, a StreamDeck for the autopilot. Both run through your Bridge, so they work offline, and touch panels and StreamDecks are currently not counted toward your plan's controller limit.

Plug the joystick, yoke, throttle quadrant or MIDI box you already own into the computer that runs your Bridge, add it from the Controllers page, and bind its buttons, axes, hats, knobs and faders in the same Flows as your panels. Type a lever's calibrated ends and set its deadband, and let Learn fill in a MIDI knob when you turn it. Your Bridge reads them right there, so they work offline, and game controllers and MIDI devices are currently not counted toward your plan's controller limit.

Before writing a single binding, open a controller's pin test: press every button and flip every switch to see it register, light each LED and fill each display by hand. The board is taken out of the cockpit while you test, so nothing reaches X-Plane 12, and it goes straight back to showing the simulator when you're done.

Every controller reports its WiFi signal, free memory, loop time, reconnects and why it last restarted. Your Bridge warns when one crosses your thresholds, like a weak signal behind the panel, memory running low, or a board that keeps dropping off. It also flags a brownout restart, the telltale sign of a weak USB supply. Warnings show next to the controller and on your Bridge's own status page, even offline, and they never change how your cockpit runs.

Open any controller's log from the browser and watch what the board says, live: what it did since it booted, which pins it set up, an expander that stopped answering, every button press it sent and every lamp it lit. Pick how much detail you want, filter it, pause it, or download it to share. The board only sends its log while someone is watching, so it costs nothing the rest of the time. It works on your Bridge's own status page too, with no internet. The claim code never leaves the board this way.

Wire up a COM radio once — the knobs, the swap button, the frequency display — and turn it into a Sub-flow. Drop in COM2, NAV1 or the first officer's side as Instances and bind each to its own hardware and datarefs. Change the Sub-flow later and every Instance changes with it. Select bindings you already drew and make a Sub-flow from them in one click, and detach any Instance that needs to go its own way. Sub-flows travel with your Project into exports and Blueprints, and your cockpit runs them offline like everything else.

Some state lives only in your cockpit: which page a display shows, which digit of a radio a knob is tuning, a mode button the aircraft doesn't model. Keep it in a variable — a button toggles it, a knob steps it, LEDs and displays follow it, and any binding can depend on it. It's kept on your Bridge, so it survives a restart.

Make any binding depend on other simulator values: the master caution lights only while its bus is powered, the radio display goes blank when the avionics switch is off, the test button does nothing without the battery. Or give a whole flow one gate — the overhead panel only while its bus is powered — and every LED, display and gauge needle in it goes off together with the power. When the power comes back, every output shows the simulator's current state again — no stale lamps on a dead panel. While you edit, each condition shows live whether it passes right now, with the value it read, and the flow's gate shows open or closed on the canvas, so you can see why a panel is dark without flying a test.

Prefer text to a canvas? Open a whole Project as YAML or JSON — every controller's wiring, every binding — and edit it like an ESPHome config, with mistakes marked on the line as you type. Preview exactly what will change before you apply it, and keep a copy in your own repository. The Flow Builder and the code always show the same cockpit.

Get a push on your phone when the Bridge disconnects, a controller goes offline, a Flow hits an error, or a firmware update finishes or fails. Setup notifications come on every plan, the Free plan too. On the Pilot plan or higher you also get flight notifications: a heads-up before Top of Descent, and a push when you are airborne and when you have landed. Pick which ones you get, and send yourself a test, in your Notification Settings.

On the Captain plan, invite up to two others into your workspace: a build partner, a flying buddy or a club project. Everyone edits the same cloud configuration, so nobody passes files back and forth.

Every change to what your cockpit runs is kept in the Project's history — Flows, Sub-flows, cockpit variables and the wiring each board was actually running. Broke the MCP with your latest edit? Roll back just that Flow, or the whole Project, after a preview of exactly what changes, and redeploy the old wiring in the same click. Name a restore point before a risky rebuild, and undo the restore itself if you change your mind.

Browse cockpits other builders published — search by aircraft, by the hardware they use, or by what's popular — and start a project from one in a click. Before you do, you see what it needs: which buttons, displays and expander chips, how many boards, and the firmware they must run. Assign each controller group to one of your own boards — a Blueprint made for a game controller you bought, like a Honeycomb Bravo, binds itself to yours — and you're told up front if a board's firmware is too old or it has too few analog pins. Publish your own the same way, as a new Blueprint or a new version of one; your boards' MAC addresses and your devices' serial numbers are never included, and anyone who started from an older version sees what changed.

Pick a proven panel — a switch panel, a basic autopilot MCP, a COM radio — and get its wiring sheet: every pin, what goes on it and how to wire it, plus the parts to buy, from the resistors to the knobs. It comes from the panel's actual configuration, so it can't disagree with it. Wire it up, then add it to the Project you already fly on one of your own boards: its wiring joins whatever is on that board already, without replacing anything, and its behaviour arrives as Sub-flows bound to the default X-Plane 12 datarefs, ready to rebind for another aircraft. Got a panel working? Publish it as a Recipe straight from its board.

Third-party aircraft add their own datarefs and commands, and finding the right one usually means digging through a plugin's files. A Dataref Pack lists them for one aircraft, like the Zibo 737's MCP or the ToLiss A320's FCU, each with what it does. Link a Pack to your Project, with packs for your aircraft suggested, and its entries show up when you search for a target in the Flow Builder. Using one copies it into your Project, so a later version of the Pack never changes a cockpit that already works. Community Packs are listed straight away, moderators mark the ones they've checked against the aircraft as Verified, and you can publish your own from a pasted list or your Project's custom datarefs.

Every time you save, the Flow Builder checks your project's flows and points at what's probably wrong: two flows fighting over the same button, a binding on hardware you haven't deployed yet, a switch nothing uses, or a dataref X-Plane 12 doesn't know or won't let you write. Your Bridge checks datarefs against the simulator you actually fly, add-on aircraft included. The warnings sit on the node they're about and never stop you saving or deploying.

Open the trace panel and press a button: the canvas lights up the binding that fired, with the value it sent, and whether X-Plane 12 got the command or your LED confirmed it. A binding that stayed quiet says why — inactive flow, a different switch position, a condition that didn't hold — and "why didn't it fire?" on any component shows the last thing that happened to it. Your Bridge keeps the last day of traces even offline, on its own status page.

Switch your cockpit to the mock simulator from the Flow Builder and test your flows before you ever load a flight. Set any dataref by hand and watch your LEDs, displays and gauges respond. Flip a switch and its dataref changes, just as in the sim, so the annunciator wired to it lights up. Press a button and the command it would have fired shows up in a log instead of reaching the simulator. It works whether X-Plane 12 is running or not, and nothing reaches the sim while it's on. Stop it or close the panel and your cockpit goes straight back to showing the simulator.

Bind each hardware transition separately — an encoder's clockwise and counter-clockwise turns, or a switch's on and off positions, can drive different commands.

Wire a magneto key, transponder mode or fuel selector as one component with a contact per position — on board pins or an expander, with one position allowed to have no contact at all, like OFF. Name the positions, then write the position straight to a dataref (magnetos 0–4 need nothing else), translate it with a lookup, or fire a different command for each one. A fast twist from OFF to BOTH sends BOTH, not every position on the way.

Spin a heading or altitude knob fast and each click counts for more, so dialling from 090 to 270 takes a flick instead of dozens of turns — and a slow turn still moves one step at a time. Pick Gentle or Strong per binding, or set your own curve, so the same knob can sweep a heading on one panel and fine-tune a radio on another.

Put a hobby servo or an X27.168 gauge stepper behind a needle — on four pins of its own or a VID6606 driver chip — and bind it to any dataref. Type in where the face's marks sit, in degrees, so 100 kt lands on the 100 kt mark even when the scale squeezes up top. The controller swings the needle smoothly at the speed you set, finds its zero stop by itself at every power-up, and puts it straight back on the simulator's value. No servo yet? Draw the gauge on a Touch Panel instead and swap in the real needle later, without changing the Flow.

Put a 20×4 character LCD or a small OLED on the controller's I²C bus and lay out its screen in the Flow Builder: "COM1" and the active frequency on the top row, standby underneath, the transponder code below that. Each value is its own field bound to its own dataref, formatted to the decimals you want, and a lookup can show text like STBY or ALT. Give it the panel's power as a gate and the screen goes blank with the avionics switch, then shows the current frequencies again as soon as it comes back. Bind the panel-brightness dataref to an OLED's contrast or an LCD's backlight and the screen dims with your panel lights instead of glaring at night.

Run a WS2812 LED strip behind your panel and split it into ranges: the backlight of each section, a lamp per annunciator, the three gear lights. Give each range the colour of its lens, then let the panel-brightness dataref dim the backlight as you turn the knob in X-Plane 12. One lookup turns a gear light red in transit and green when down. A brightness cap per strip keeps it within what your power supply can deliver, and the inspector tells you how much current full white would draw.

Turn a knob to step the heading bug, altitude preselect or baro setting directly — wrapping 359 to 000, stopping at the limits — or make a momentary button toggle a light, even when the aircraft has no command for it. Every step starts from what X-Plane 12 actually shows, so a fast spin never loses a click and an autopilot that moves the bug still wins.

Give a button a short press, a long press, a double press, or a repeat while you hold it — flip the standby frequency on a tap and swap the other radio on a hold, or hold an altitude button to keep stepping. The controller measures each press itself, so WiFi lag never turns a tap into a hold, and a held button always stops repeating the moment you let go.

Wire a MAX7219/MAX7221 chain once, then claim runs of digits on it and drive each from its own dataref — radio frequencies, squawk codes, altitude preselects. One eight-digit module can show two values side by side. Bind the panel-brightness dataref to the display's brightness and the digits dim with your backlight knob instead of glaring at night, and go blank with the avionics bus.

Wire a potentiometer, slide pot or hall sensor to an analog pin and bind it to a dataref — throttle, mixture and prop levers, trim wheels, panel brightness. Calibrate it by moving the lever through its travel while the builder watches the live reading, so a lever whose linkage only turns part of the pot still reads end to end. A lever at rest sends nothing, a centred trim wheel holds neutral, and on connect a lever left at idle puts the sim back in step with it.

Run out of pins long before you run out of switches? Add Expanders — MCP23017 or PCF8574 chips on I²C, 74HC165 and 74HC595 shift-register chains, or a CD4067 mux — and put buttons, switches, LEDs and even analog levers on their pins. Pick the Expander and the pin as the board prints it (B3, chip 2 · Q5) and the builder checks the wiring before you save. Eight MCP23017s on one bus give a single controller 128 more pins. If an Expander stops answering, the Flow Builder says which components went dark while the rest of the panel keeps working.

Wire a CDU or GPS keypad the way it is built, as a matrix of rows and columns, and a 60-key FMC costs 16 pins instead of 60. Every key is an ordinary button in the Flow Builder: one click adds a button for each key, laid out like the keypad, and you bind EXEC, the line-select keys and the scratchpad letters to their commands. Each key debounces, buffers and takes press gestures on its own, so a long press on CLR can clear the whole scratchpad. Got a keypad without diodes? The controller ignores the phantom key a three-key press can create, so the simulator never sees a key you didn't press.

Identify each ESP32, ESP32-S3 or ESP32-C3 board by its MAC address and define its GPIO map once — the pin picker shows that board's own pinout and only offers the pins it can use. No per-PC COM-port bookkeeping. Adding a board to your workspace takes the claim code it shows over USB or on its own setup page, so nobody else on your network can take it over — and from then on the board and your Bridge prove to each other who they are every time they connect, so no other device can pose as either. Older boards added before that can be locked out with one switch until you enter their claim code. When a board dies, pick a spare one and it takes over the dead board's wiring and bindings in every project, checked against its own pins first and deployed in one step.

Install the controller firmware straight from Chrome, Edge or Firefox — on an ESP32, ESP32-S3 or ESP32-C3 board; the flasher picks the right image for the chip it finds — then pick your WiFi network in the same dialog — the board tries it before saving it, joins while still on the USB cable, and finds your Bridge by itself. One more click claims it for your workspace. No temporary access point to join, no IP address to type. A board keeps up to three WiFi networks and joins the strongest access point of any of them, moving to a clearly stronger one of a mesh network while idle — add the club or fly-in network in the app before you travel, and it goes out with the next deploy.

Flash a controller over USB once; after that, update its firmware from the browser. Boards are updated and verified one at a time: the first one runs the new firmware for a two-minute canary soak before the rest follow, and you watch it count down. A board only keeps the new firmware once it has applied its wiring — if it can't, crashes, or isn't confirmed in time, it rolls back to the old version by itself and the rest of the batch is left untouched. Before you start, any board whose last wiring update failed to apply is flagged. A board whose firmware is too old for your Bridge says so, and is updated from the same screen. Only firmware signed by CockpitConnect is accepted: each board checks the signature itself before it installs anything, so a tampered image is never installed.

Deploy a controller's wiring or change a Flow while the Bridge is offline — it catches up the moment it reconnects. Each controller shows whether its config is waiting for the Bridge, waiting for the board, or running, so nothing drifts silently. A button press or knob turn made during a brief Wi-Fi drop still reaches the sim once the board is back, and anything too old to still be what you meant is dropped rather than replayed.

Hardware input is treated as intent; the simulator confirms the truth. Switches, levers and LEDs stay in step with X-Plane 12.