One server. Every device.

1 — Devices

Anything with a port or an IP address.

Power supplies, oscilloscopes, multimeters, robots, spectrometers, temperature loggers, ESP32 boards, Arduinos, Raspberry Pis, IP cameras. If it speaks a protocol, Muxit can probably reach it.

Supported transports out of the box: serial and TCP, directly from JavaScript via createSerialTransport and createTcpTransport. Higher-level protocols ride on top: SCPI over either, MQTT through the built-in MqttBridge driver, ONVIF for IP cameras, and vendor binary streams via dedicated drivers.

2 — Drivers

A small adapter for each device's protocol.

A driver is a small adapter that speaks the device's native protocol and exposes a uniform interface — get, set, execute — back to Muxit. The Muxit core never references specific devices; everything goes through this interface.

There are three driver formats, picked to match the kind of hardware you're connecting:

// simple-psu.driver.js
export default {
  meta: {
    name: "SimplePSU",
    properties: {
      voltage: { type: "number", access: "rw", unit: "V" },
      current: { type: "number", access: "r",  unit: "A" },
    },
    actions: { reset: { description: "Reset to defaults" } },
  },
  async init(config) {
    this.transport = createSerialTransport(config.port, { baudRate: 9600 });
  },
  async get(prop) { return await this.transport.query(`${prop}?`); },
  async set(prop, val) { await this.transport.send(`${prop} ${val}`); },
  async execute() { await this.transport.send("*RST"); },
};

All three formats present the same interface to Muxit. Scripts don't know or care which kind of driver is underneath.

3 — Connectors

The driver, configured for your specific device.

A connector wraps a driver with your configuration, custom methods, and computed properties — giving each device a friendly name and a tailored API.

// workspace/connectors/psu.js
export default {
  driver: "MockInstrument",
  config: { defaultVoltage: 0, defaultCurrent: 1.0 },
  poll: ["power"],

  methods: {
    rampTo: [async (c, target) => {
      const current = await c.voltage();
      const step = (target - current) / 10;
      for (let i = 1; i <= 10; i++) await c.voltage(current + step * i);
      return await c.voltage();
    }, "Ramp voltage to target in 10 steps"],
  },

  properties: {
    power: [async (c) => {
      const v = await c.measured_voltage();
      const i = await c.measured_current();
      return Math.round(v * i * 1000) / 1000;
    }, "Calculated power (W)"],
  },
};

The split is deliberate: drivers are commodities, connectors are personal. A driver works for any instance of a device; a connector is your specific configuration of it — your voltage limits, your safety methods, your computed power readout. You write connectors once and they live in your workspace folder, version-controlled with the rest of your code.

The internal slogan: you write connectors, the community builds drivers.

4 — Your code

Scripts, dashboards, AI — all the same API.

In a script, properties read like properties and write like assignments. No await, no callbacks, no boilerplate.

const psu = connector("psu");
psu.voltage = 12;
log.info(`Current draw: ${psu.measured_current}A`);

The same psu object is bound to dashboard widgets, exposed to the AI as tool calls, and accessible to external clients over the WebSocket API. One model, four ways to use it.

When you plug in something new

New instrument? The AI drafts the driver.

Driver coverage is the single biggest reason hobbyist and indie lab automation tools fail to adopt. Muxit turns that on its head: when you plug in a new device, the AI can draft a working connector or driver for you in minutes.

1. Point at a manual (optional). Drop a datasheet or programming manual into your workspace. Not required, but it helps the AI pick the right commands rather than guessing.
2. Probe the instrument. The AI runs *IDN? over TCP, serial, or USB-TMC to confirm vendor, model, serial, and firmware — so the draft matches the actual device in front of you.
3. Muxit drafts the connector. A JavaScript connector config with a declarative command block for properties and methods. For non-SCPI gear, a full custom JavaScript driver.
4. You review and approve. Write safety gates are on by default. Every generated connector is plain JavaScript — no black box. You can hot-reload it into the running server to test.

Every new instrument the AI learns expands the platform for everyone who plugs in the same device next.

The app

One window, three panels.

Muxit runs as a native background service and serves its UI over a local web server. Open it in any browser — or let it run headless on a lab PC and connect from your laptop across the network.

Scripts, drivers, and device communications all run inside the Muxit service, sandboxed. Your automation keeps running even when the browser is closed.

Dashboards

JSON files, drag-and-drop widgets.

Dashboards are JSON files. Drag widgets onto a grid, bind them to device properties, and they update automatically.

Available widgets: gauge, chart, scope, slider, knob, button, toggle, indicator, terminal, video stream.

Drag a property from the hardware panel onto a dashboard to create a widget. Drag a script onto the grid for a start/stop control. Because everything is JSON, dashboards go in version control with the rest of your code.

How AI plugs in

Three ways, all on the same connector API.

Muxit's AI integration sits on top of the same connector API everything else uses. There are three ways to bring AI into the picture, and they coexist:

const cam = connector("webcam");
if (ai("Is the LED still on?", cam.snapshot) === "no") {
  psu.output = false;
}

In all three paths, the AI sees the same connector API your scripts see. Tool calls are visible and gated; write operations require explicit approval by default.

Safety, sandboxing, and what stays local

How Muxit treats your code, your data, your hardware.

What's where on disk

For the curious or the cautious.

• workspace/connectors/ your connector configs (JavaScript files, one per device).
• workspace/scripts/ your automation scripts (JavaScript files).
• workspace/dashboards/ your dashboards (JSON files).
• workspace/drivers/ community JavaScript drivers and SCPI definitions. Premium plugins live in a separate signed-plugin folder.
• workspace/config/ server configuration, including license cache (HMAC-signed) and TLS settings.

The whole workspace/ directory is yours. Point it at a shared drive (Dropbox, OneDrive, NAS) and multiple Muxit installations can read the same connectors, scripts, and dashboards.

Out of scope

What Muxit isn't.

A few things Muxit is not trying to be, in case the framing matters:

See it work

Where to next.

• Muxit for makers →
• Muxit for professionals →
• Pricing →
• Documentation →