Compatibility

Will Muxit work with your device?

Almost certainly — but let's be honest about what that means. Muxit doesn't ship with a pre-built driver for every instrument on earth. It ships with the building blocks and AI help to get any device working in one sitting, and then it's yours forever.

The honest premise

One small file per device. After that, it's permanent.

Muxit ships with a handful of built-in drivers (webcam, ONVIF, MQTT, files, G-code), three declarative protocols (Scpi, LineText, BinaryStream) that cover most benchtop, serial, and binary devices, and transports for serial, TCP, and USB-TMC. For your specific device, you (or the built-in AI) write one small connector config: a readable JavaScript file that lives in your workspace, gets version-controlled like any other code, and is yours to keep, edit, or share.

That's the trade. We don't pretend to have shipped a driver for every instrument that exists; we ship the tools that make the one-time connect step take minutes instead of weeks. The more your device speaks a standard (SCPI, MQTT, ONVIF, plain serial), the less work there is — often zero.

The ladder of effort

Find your device. See how much work it really is.

Four tiers from "zero setup" to "not yet documented". Most lab gear sits in tier A or B.

A

Built-in

0 minutes · pick driver, done

Drivers compiled into Muxit. No install, no config beyond the connection details. Always free.

Examples: USB webcams, ONVIF IP cameras, MQTT brokers, file-watcher inputs, G-code / GRBL CNC, SMTP / webhook notifiers, TestDevice (simulator).

AI not needed.

B

Declarative protocol config

5–15 minutes · AI drafts end-to-end

For anything that speaks a standard wire format. Pick a built-in protocol (Scpi, LineText, or BinaryStream), point it at a transport (serial, TCP, or USB-TMC), and describe the device in a short declarative schema. No driver code. Same shape every time, whether it's SCPI, plain text lines, or binary frames.

Examples: SCPI scopes, PSUs, DMMs and SMUs (Rigol, Siglent, Keysight, Tektronix, GW Instek, Aim-TTi, old HP / Agilent); Arduino and datalogger text streams; Modbus-RTU and other fixed binary-frame sensors.

AI: end-to-end. Probes the device, reads the manual or captures a few frames, drafts the schema, validates, and hot-reloads with no restart. Maker tier and up.

C

Custom driver (JS or Python)

hours to a day · AI scaffolds it

For devices no built-in protocol fits: stateful handshakes, request/response ASCII oddballs, multi-subsystem instruments, or a vendor SDK you want to keep using. Write a small driver in JavaScript (V8 sandbox, with the createSerialTransport / createTcpTransport factories) or Python (your existing top-level functions become properties and actions, no boilerplate).

Examples: a request/response ASCII power meter, an ESP32 with your own framing, in-house DAQ rigs, instruments with only a vendor Python or C SDK.

AI: scaffolding. Drafts the driver shell and helps explore the wire with the serial-probe connector. Wiring up edge cases stays your call.

D

Not (yet) supported

No documented path today

A small but real set of devices have no clean path in Muxit today. We list them so you can plan, not so you can be surprised after buying.

Examples: USB HID-only devices (custom HID controllers, some sensors), raw GPIB without a vendor virtual-COM shim, CAN bus, vendor binary protocols that don't ride on serial or TCP.

On the roadmap. If you need one of these, get in touch; it helps us prioritise.

What the AI actually does

End-to-end for declarative protocols. A capable helper for the rest.

The "AI drafts your config" claim isn't aspirational: for the declarative protocols (Scpi, LineText, BinaryStream) it's a working flow on Maker tier and up. Here it is for a SCPI instrument, in four steps you can watch happen:

1. Point at the programming manual.

Paste a vendor PDF or URL into the chat. The AI extracts the SCPI command tree and the device's identification string.

2. Probe the real device.

With your approval, the AI sends *IDN? and a small set of harmless queries to confirm the model matches the manual. No write operations without explicit confirmation.

3. Draft the connector config.

The AI writes a declarative schema block covering the commands you'll actually use. You see the diff before it's written.

4. Review & approve.

You click approve, the connector hot-reloads, and the device shows up in your workspace. The file is plain JavaScript: readable, editable, version-controllable.

For Tier C (custom drivers), the serial-probe connector gives the AI an interactive view of the wire so you can reverse-engineer together. Fully automated drafting for arbitrary custom protocols is on the roadmap.

Your step-by-step

What to do when you sit down with a new device.

Step 1: Identify what it speaks.

SCPI? Plain serial text? Binary frames? Ethernet with a documented API? USB HID? The wire format decides the tier, and most lab gear lands in tier A or B.

Step 2: Check Tier A.

Cameras, MQTT brokers, files, and G-code machines are built in. Open Muxit, add a connector, pick the driver, fill in the host or path. Done.

Step 3: Standard protocol? Let the AI draft it.

Speaks SCPI, prints text lines, or sends binary frames? Open the chat, give it the vendor and model (or let it sniff the wire), attach the manual if you have one. Approve the probes; approve the draft; you have a working connector in minutes.

Step 4: Something exotic? Write a custom driver.

If no built-in protocol fits, copy a worked driver from workspace-template/connectors/_examples/ and adapt it in JavaScript or Python. Use the serial-probe connector to inspect bytes if you're unsure.

Step 5: Test, commit, share.

The connector you end up with is one readable file. Commit it to your team's repo, or share it back to the community. Next person (including future you) skips the setup entirely.

From the bench

Three real connectors.

Same workspace, same API. The first two are declarative protocol configs with no driver code at all; only the last needed a custom driver.

Rigol DP832 power supply

Tier B · 7 minutes. SCPI over LAN. AI drafted the whole config from the programming manual; we changed nothing.

rigol-dp832.js
// rigol-dp832.js — declarative SCPI connector
export default {
  protocol: "Scpi",
  connection: { type: "tcp", host: "192.168.1.100" },
  config: {
    schema: {
      properties: {
        voltage: { cmd: "VOLT", type: "float", unit: "V" },
        current: { cmd: "CURR", type: "float", unit: "A" },
        output:  { cmd: "OUTP", type: "bool" },
      }
    }
  }
};

Arduino datalogger

Tier B · 6 minutes. Plain text lines over serial. The same declarative schema as SCPI, no driver code; the AI matched each printed line to a typed property.

arduino-logger.js
// arduino-logger.js: LineText protocol, no driver code
export default {
  protocol: "LineText",
  connection: { type: "serial", port: "COM3", baudRate: 115200 },
  config: {
    schema: {
      properties: {
        temperature: { prefix: "TEMP: ", type: "float", unit: "C" },
        humidity:    { prefix: "RH: ",   type: "float", unit: "%" },
      }
    }
  }
};

Your lab's in-house Python rig

Tier C · half a day. A one-off bench setup controlled by Python code your lab already has. Wrap the existing top-level functions and they become connector properties and actions, with no Driver subclass and no JSON-RPC boilerplate.

bench-rig.py
# bench-rig.py — wrap your lab's own Python code as a Muxit device
from rig_io import connect_serial, read_voltage, read_temperature, set_pump_rate

def connect():
    connect_serial("/dev/ttyUSB0")

def voltage():
    return read_voltage()

def temperature():
    return read_temperature()

def pump_rate(rate_ml_min):
    set_pump_rate(rate_ml_min)

Honest limits

What doesn't have a clean path yet.

We'd rather you find this out here than after a purchase. These categories don't have a documented Muxit path today. Some are on the roadmap; others depend on community demand.

USB HID-only devices.

Custom HID controllers, some lab USB peripherals. A sandboxed createHidTransport() is on the roadmap.

Raw GPIB (IEEE-488).

If your vendor's IO library exposes the instrument as a virtual COM port, it works as serial. True GPIB transports are not shipped.

CAN bus and proprietary fieldbuses.

No native CAN, EtherCAT, or PROFIBUS support. A serial-attached gateway works; direct adapters do not.

Unusual binary framing.

The BinaryStream protocol handles the common cases declaratively: header magic, fixed-size and length-prefixed frames, inter-frame-gap framing, and Modbus-style CRC. Exotic framing it doesn't cover yet (COBS, less common CRC families) means dropping to a custom driver with raw-mode serial; for most devices that's a handful of lines.

Missing your category? Tell us what device — it's how the roadmap gets prioritised.

What you end up owning

One small file. Yours forever.

At the end of the setup — five minutes, fifteen minutes, or a few hours — you have a single readable JavaScript or Python file in your workspace. Not a binary, not a vendor account, not a subscription per device.

  • No vendor lock-in. The connector is plain code in a folder you own.
  • No black-box driver. You can read every line, change anything, audit what it does.
  • No per-device licence. One Muxit licence covers every device you connect.
  • Version-controllable. Diff it, review it, commit it like any other source file.
  • Shareable. Hand it to a colleague, drop it in a repo, contribute it back.

Try it with your device → How the architecture works →