Why this exists

I work as a backend engineer on IoT systems, including industrial weighing scales (timbangan). I have shipped the kind of custom parser OmniBridge replaces — spent days reverse-engineering vendor protocols that didn't match their own documentation, written glue code nobody else will ever touch. The legacy-hardware integration tax is real and I have paid it.

But this is not a tool just for industrial engineers. The day I first got OmniBridge working on a Modbus PLC demo, I realized the same thirty-second flow would work on:

• Any Arduino project that talks over Serial
• Any scientific instrument with a serial data port (oscilloscopes, spectrometers, bioreactors)
• Any vintage device from the RS-232 era still quietly running in warehouses, labs, and basements
• Any debug port on a router, modem, or embedded board
• Any student project for an embedded systems or IoT class

Anyone who has ever typed screen /dev/tty.usbmodem and stared at unreadable bytes has encountered the problem OmniBridge solves.

When Opus 4.7 shipped with multi-turn tool use, adaptive extended thinking, and a 1M-token context window, I realized the shortcut I had wanted for years was finally buildable. So I built it — across an industrial-to-maker-to-academic spectrum of use cases, not one narrow vertical.

This is Build From What You Know meeting Build For What's Next: a problem category I have lived, addressable by a model capability class that emerged this year, relevant to tens of millions of people with a USB-to-serial cable in a drawer.

⚡ The Problem

Industrial floors, warehouses, labs, and maker workshops run on serial devices from the 1980s-2000s:
weighing scales, GPS receivers, PLCs, Arduinos, lab instruments. These devices speak proprietary
ASCII or binary protocols over RS-232 that take weeks of developer time per device to integrate:

• Decode the protocol manually (vendor docs missing or outdated)
• Write a custom parser
• Build glue code to forward data to modern systems (Slack, databases, cloud APIs)
• Repeat for every. single. device.

OmniBridge replaces that week of work with 5 minutes of "plug in and let Claude figure it out".

🧠 How It Works

graph LR
  Device[Legacy Serial Device<br/>CAS Scale · GPS · Arduino · PLC] -->|RS-232| Port[Serial Port]
  Port --> Rust[Rust Backend<br/>tauri + serialport]
  Rust -->|port:data events| UI[Svelte 5 UI]

  UI -->|Raw bytes| Agent{Claude Agent<br/>Opus 4.7}
  Agent -.->|Tools| Rust
  Agent -->|protocol + regex + presets| Profile[(Device Profile<br/>learned storage)]

  Profile --> Dashboard[Live Dashboard<br/>structured values]
  Profile --> Sender[Command Sender<br/>bidirectional]

  UI -->|Structured JSON| Webhook[Webhook<br/>Zapier · n8n · Home Assistant]
  UI -->|CSV/JSON| Export[File Export]

Core capabilities

1. Protocol Detective — Claude analyzes raw bytes → identifies protocol → generates per-field regex
2. Live Dashboard — real-time parsed values with sparkline charts (no API calls — regex runs locally)
3. Device Profile Learning — remembers each device by VID/PID → instant recognition on reconnect
4. Agentic Investigation — Claude uses tools (read_more_lines, search_pattern, probe_baud, send_bytes, get_device_metadata) to iteratively identify unknown devices
5. Bidirectional Communication — send commands to device with ASCII/HEX input, Claude-generated presets
6. Cloud Bridge — forward structured data to any webhook (Zapier, n8n, Home Assistant, custom)
7. Export — CSV/JSON download for offline analysis

✨ Features

🚀 Quick Start

Download

⬇ Download latest release — DMG (macOS universal) · MSI (Windows) · AppImage (Linux)

Or build from source (below).

First launch

1. Open OmniBridge → click ⚙ Settings → paste your Anthropic API key
2. Click ⊕ Discover Devices to scan serial ports
3. Don't have hardware? Click ▶ Try Demo Mode — virtual CAS Scale, GPS, and Arduino are always available
4. Pick a device → ▶ Monitor → watch raw data stream
5. Click ⚡ Live to auto-analyze, or 🔬 Investigate for agentic multi-step discovery
6. Once identified, switch to 📊 Dashboard tab to see parsed values
7. Click 🔗 Webhook to forward data to Zapier/n8n/your-endpoint

Build from source

Requires: Rust, Node.js 20+, and Tauri prerequisites.

git clone https://github.com/adindamochamad/omnibridge.git
cd omnibridge
npm install
npm run tauri dev

To build a distributable:

npm run tauri build
# Output: src-tauri/target/release/bundle/dmg/OmniBridge_0.1.0_x64.dmg (macOS)
#         src-tauri/target/release/bundle/msi/...                      (Windows)
#         src-tauri/target/release/bundle/appimage/...                 (Linux)

🎛 Demo Mode (no hardware needed)

OmniBridge ships with four virtual devices that emit realistic data streams — ideal for trying the app, recording demos, or stress-testing agentic investigation without hardware:

Toggle via ▶ Try Demo Mode in the sidebar.

🧱 Architecture

Stack

• Tauri 2 — cross-platform desktop shell (native WebView, Rust backend)
• Rust + serialport 4.9 — direct port access, channel-based write, VID/PID classification
• SvelteKit + Svelte 5 (runes mode) — reactive UI
• Anthropic SDK + Claude Opus 4.7 — adaptive thinking, tool use, prompt caching
• @tauri-apps/plugin-store — persistent settings, device profiles, webhook configs

Key files

src-tauri/src/
├── lib.rs              # Tauri commands, monitor thread, channel-based write
└── discovery.rs        # VID/PID device classification (Arduino, FTDI, CH340, CP210x)

src/lib/
├── claude.ts           # analyzeStream (one-shot) + analyzeWithAgent (multi-step)
├── agent-tools.ts      # 6 tool definitions + executor
├── parser.ts           # Regex-based stream parser (live dashboard)
├── profiles.ts         # Device profile CRUD (by VID:PID:Serial)
├── webhook.ts          # Webhook sender with throttle + custom headers
├── export.ts           # CSV/JSON export (structured + raw)
├── demo.ts             # 4 virtual device scenarios (incl. Modbus RTU binary)
└── *.svelte            # UI components: PortCard, DataBuffer, AnalysisPanel,
                        # AgentTracePanel, StructuredDashboard, Sparkline,
                        # CommandSender, WebhookConfigModal, SettingsModal

🧬 Why Opus 4.7 Specifically

OmniBridge is not a chatbot wrapper — every Opus 4.7 capability below maps to a concrete user-visible feature. Downgrade the model and the product breaks.

The investigation loop in detail

User clicks 🔬 Investigate on Modbus PLC
  ↓
[Claude, interleaved reasoning]
  "Binary stream. Hypothesize Modbus RTU framing
   (slave 1, FC 3, 10 registers × 2 bytes + CRC)."
  ↓
[tool: analyze_binary_structure]
  → returns: 21/21 frames pass CRC16 · STRONG MATCH
             frame_length=25, sample_frames_hex=[...]
  ↓
[Claude, now confident — one tool was enough]
  "Strong Modbus RTU match. Emit 5 fields with
   byte-offset regex on hex representation."
  ↓
[Final JSON]
  protocol: "Modbus RTU"
  confidence: 98
  fields: [reg0 ... reg4]   ← 5 real registers; regs 5-9 are zeros
  command_presets: [Read 10 holding regs @0, Read first 2 regs, ...]

That whole flow is ~15 seconds, 2 API calls, and ~$0.22 in tokens. Compare to a human engineer doing the same task from scratch — typically 2–4 hours with a Modbus RTU reference manual open, roughly $200–400 of engineering time. OmniBridge is ~1,000× cheaper per identification.

🎨 Interaction Model

One-shot vs agentic analysis

• ⬡ Analyze — single API call, fast (~5 sec). Good for straightforward ASCII protocols.
• 🔬 Investigate — multi-step agent with tools, slower (~15-30 sec). Best for unknown or binary protocols.

Live mode auto-trigger

• ⚡ Live toggle auto-analyzes as data accumulates
• Thresholds: 10 lines → first trigger, 15 lines → retry, 25 lines → force-fire
• Debounce: 400ms (works for 1Hz GPS up to 100Hz Modbus)

Cost-conscious defaults

• Claude API is called only on Analyze / Investigate / Live — not for live dashboard updates
• Once a device is learned, reopening loads from local store with zero API calls
• All regex parsing, sparklines, webhook forwarding = free after initial identification

🗺 Roadmap

• Discovery + VID/PID classification
• Protocol Detective (one-shot + agentic)
• Live structured dashboard with regex parsing
• Device profile learning
• Auto baud rate probing
• Bidirectional communication
• Webhook forwarding
• CSV/JSON export
• Demo mode with 3 virtual devices
• Modbus RTU + other binary protocol showcases
• Chat panel — natural language Q&A over buffer
• Multi-device correlation dashboards
• MCP server mode (expose devices as tools to other agents)
• Windows signing + auto-updater
• Session replay (time-travel debugging)

🤝 Contributing

Bug reports, protocol examples, and device profile contributions welcome. Open an issue or PR.

If you test OmniBridge with real hardware (scales, GPS modules, PLCs, sensors), please:

1. Share the VID/PID + manufacturer string
2. Share a short capture (first 50 lines, stripped of any sensitive data)
3. Mention the model in an issue so we can validate the protocol detection

📜 License

MIT — see LICENSE