obsidian/TallyFlow/Integration/TallyFlow Edge Multi-Reader Benefits.md

# TallyFlow Edge Multi-Reader Benefits

**Status:** Customer talking points  
**Date:** 2026-07-13  
**Audience:** Prospects with multiple fixed RFID readers (e.g. Impinj) per site

## Elevator pitch (2 sentences)

TallyFlow sits at each site and turns several readers into one clean tag feed. You get health, start/stop, and local visibility without building and maintaining that plumbing yourself.

## Problem it solves

Customers often ask why they should not call reader APIs (e.g. Impinj) directly. That works for a single reader in a lab. With **several fixed readers per site**, they still need:

- Fan-in from many readers to one place
- A stable event shape for downstream systems (different readers have different event shapes)
- A path out to apps and reports (spreadsheet, API, or message bus)
- Day-2 ops: is the dock reading? restart inventory? which reader is down?

Downstream systems consume data; they do not control readers. Something has to sit in the middle either way. TallyFlow Edge is that site edge layer.

## Architecture story

```text
[Fixed readers × N per site]
        ↓
[TallyFlow Edge]  ← ops UI, start/stop, health
        ↓
  Spreadsheet (CSV)  /  REST  /  AMQP (TallyFlow)  /  …
        ↓
[Downstream systems]
```

## Benefits of TallyFlow Edge

**Recent product notes (code review Jul 2026):** remote reader API for Scout/handhelds; reader-side filtering (validate per site); ATID ATF862 Master mode support; expanded MCP/statistics tools on develop.


General product strengths—useful even when the conversation is not only about multi-reader fan-in.

### 1. Written in Rust for reliable operation

- Built for long-running edge use: memory safety, strong performance, low overhead
- Async design handles many readers and streams without a heavyweight runtime stack
- Suited to unattended site deployments where restarts and flaky processes cost real downtime

### 2. Multi-platform support

- Runs on **Windows**, **Linux**, and **macOS**
- Windows Service install for production servers
- Same config model across platforms so IT is not locked to one OS per site

### 3. Multi-vendor and multi-device

- Fixed RFID: Impinj, Zebra, ATID (and growing)
- Barcode: SNAPI, Aurora where needed
- Remote/virtual readers for mobile and scripts
- One ops surface instead of a tool per brand

### 4. Real-time visibility and control

- Web UI for reader health, recent tags, and start/stop
- REST API for integration and automation
- Heartbeats and status so problems show up before the warehouse calls

### 5. Flexible integration (processors)

- Spreadsheet (CSV), REST, AMQP → TallyFlow out of the box
- Extensible processor model for site-specific paths
- Database and other sinks via apps (or future processors) without rewriting reader drivers

### 6. Production-minded edge footprint

- Local binary/service—works when cloud links are slow or down
- Optional on-site logging for audit and recovery
- Light resource needs relative to full app-server stacks

### 7. Part of the wider TallyFlow story

- Same family as mobile, print, and cloud workflows when the customer grows past fixed readers alone
- Clean handoff into TallyFlow via AMQP when they want Core/cloud, not only local files

## Benefits vs managing readers directly

### 1. One integration per site, not one per reader

Direct vendor APIs mean N hostnames, logins, inventory presets, streams, reconnects, and firmware quirks. TallyFlow configures all readers in one place and runs one service per site.

### 2. Clean, consistent tag data

Events are normalized to a simple model: reader name, antenna, EPC, TID, RSSI, time, direction. Downstream tools do not have to parse vendor-specific stream formats.

### 3. Unified data can go to a spreadsheet

TallyFlow Edge’s CSV logger writes the combined feed from all readers into spreadsheet-friendly files:

- One file (or folder of files) per site instead of N reader streams
- Easy pilot path before investing in heavier integration
- Familiar format for ops, QA, and light analysis

### 4. Flexible handoff to other systems

When a spreadsheet is not enough, TallyFlow can also export via:

| Path                  | Status                              | Typical use                                                  |
| --------------------- | ----------------------------------- | ------------------------------------------------------------ |
| **CSV / spreadsheet** | Built into Edge (`logger`)           | File or folder drop (simplest)                               |
| REST API              | Built into Edge (`rest_api`)         | Middleware, custom apps, automation (`/tags`, stream, etc.)  |
| AMQP → TallyFlow      | Built into Edge (`tallyflow`)        | Cloud / Core path                                            |
| **Database**          | Via app, not a native Edge processor | App consumes REST (or AMQP later) and writes SQL/SQLite/etc. |
| MQTT export           | Not shipped                         | Future processor candidate; same JSON shape as REST.         |

**Database path (today):** We do **not** write customer databases from TallyFlow Edge itself. Pattern in production: a site app talks to Edge over REST and persists what the customer needs.

- Example: Alice+Olivia console (`alice_olivia_console`) connects to TallyFlow Edge REST, handles warehouse workflow, and stores box/EPC state in **local SQLite**.
- Sell as: “unified multi-reader feed + your app (or ours) into the database you already run”—not “Edge has a Postgres plugin” unless/until we add one.

**Optional future:** a native DB processor in Edge is possible (same event bus as logger/REST), but app-level integration keeps schema and business rules with the customer app.

### 5. Operations without opening each reader

- Start / stop inventory (web UI and API)
- Health and heartbeats
- Recent tags for support (“is this portal still reading?”)
- Optional GPIO for local automation

### 6. Site edge reliability

Runs locally (Windows service or Linux). Can log on-site when the cloud is flaky. Timeouts and reconnects so one dead reader does not hang the whole site.

### 7. Adding readers is config, not a new project

Same pipeline for the 2nd reader and the 10th. Shared schema and egress for integrators and BI teams.

### 8. Room to grow without rewriting consumers

Today Impinj fixed; later handhelds, barcodes, another vendor, or keyboard wedge into WMS. Downstream feeds can stay the same.

### 9. Lower software TCO

They pay for reader hardware either way. The real cost of DIY is owning multi-reader orchestration, health, control, and egress forever. TallyFlow is that product.

## When direct reader APIs may be enough

- Single reader pilot / lab
- Strong internal IoT team with an existing broker and warehouse already
- Raw telemetry only, no need for ops UI, multi-vendor, or multi-site packaging

## Suggested talking points

1. Reader APIs control radios; apps and reports need a clean event feed. You need a middle layer.
2. TallyFlow is that layer for multi-reader sites.
3. It can put the unified multi-reader feed in a spreadsheet—or REST / TallyFlow (AMQP) when they outgrow files.
4. One schema, many readers.
5. Site staff can verify RFID without vendor tools or the downstream app.
6. More readers and sites later without rewriting every consumer.

## Related

- Product: TallyFlow Edge (edge service)
- Handheld companion: **TallyFlow Scout** (Collect / Verify / Locate → Edge remote reader API or CSV; not Core Assets)
- Egress today: **spreadsheet (CSV)**, REST API, **AMQP → TallyFlow**
- Database today: **via app** (e.g. Alice+Olivia console → SQLite over REST), not a built-in Edge processor
- AI today: **MCP Streamable HTTP** at `/mcp` (read-only tools; see below)
- Not yet: MQTT *export* (MQTT is used inbound for Zebra today); optional native DB processor; full REST surface as MCP tools
- Typical stack: Impinj Speedway / R700 family fixed readers
- See also: [[ServiceNow Integration Approach]] (enterprise system-of-record pattern via Core)

---

## AI integration (MCP)

### What kind of AI interaction this is good for

Today’s MCP surface is **narrow and read-only**. That is a feature for early use, not a full “AI operates the dock.”

**Good fit today**

| Interaction | Why MCP helps |
|-------------|----------------|
| **Ops / support copilot** | “Which readers are configured?” “Any recent tags?” “Is the service up?” without custom scripts |
| **Site awareness for agents** | An agent (Cursor, Claude Desktop, custom) that already talks MCP can poll health, reader list, and recent tag cache |
| **Troubleshooting** | Compare “UI shows tags” vs “API/MCP shows tags”; confirm Edge is running before blaming the reader |
| **Light inventory questions** | “What EPCs did we see lately?” from the in-memory recent-tag buffer (not full history or BI) |
| **Safe by default** | No start/stop/write over MCP → lower risk of an agent turning RF on/off by mistake |

**Poor fit today (use REST, apps, or human UI instead)**

- Continuous live stream of every tag (MCP is not the NDJSON stream)
- Long history / Power BI-style analytics (use CSV, warehouse, or TallyFlow)
- Autonomous dock control (start/stop inventory, GPO, tag write)
- Complex multi-step workflows that need transactional DB state (that’s the app layer, e.g. Alice+Olivia)

**Mental model:** MCP = *ask the edge what it sees right now*. REST / CSV / AMQP / apps = *run the site and feed systems of record*.

### Current (in the code)

- **Transport:** Streamable HTTP at `GET`/`POST` `/mcp` when the REST API processor is enabled (`rmcp`)
- **Tools live today:**
  - `get_health` — same idea as `GET /api/v1/health`
  - `get_readers` — configured readers/scanners
  - `get_tags` — recent tags/barcodes (in-memory, capped per reader)
- **Not exposed as MCP tools yet:** start/stop, write EPC, reader status/heartbeat POST, live stream, remote-reader submit
- **Generated OpenAPI → MCP JSON** (`api-mcp-gen`, under `core/api/mcp/`) describes a **fuller** REST surface for tooling/docs; the **running** server only registers the three read-only tools
- Smoke test: `core/scripts/test_mcp.sh`

### Future (product options)

Prioritize in order of risk vs value:

1. **More read-only tools** — API info, per-reader status/heartbeat, optional filter on tags by reader name  
2. **Guarded control tools** — start/stop (and later write/GPO) behind explicit confirmation, API key, and/or “AI control enabled” config so agents cannot act by default  
3. **Align gen descriptors with live tools** — or generate the live router from OpenAPI so docs and runtime do not diverge  
4. **Optional MQTT (or other) export** for agent/event buses — separate from MCP; still not required for copilot Q&A  
5. **Higher-level “site summary” tool** — one call: readers up/down, last tag time, tag counts, obvious faults (better for LLMs than raw dumps)  
6. **Cross-product AI** — Edge MCP + Core/ServiceNow patterns so an agent can go from “tag seen at dock” to business context (asset, order, location)

**Sell carefully:** “AI can check site RFID status through TallyFlow Edge” is true today. “AI runs your readers” is a future, opt-in story.

---

## Use cases

### Benefits for Power BI

TallyFlow sits at each site and turns several Impinj readers into one clean tag feed for Power BI. You get health, start/stop, and local visibility without building and maintaining that plumbing yourself.

Power BI is a consumer of data, not a controller of readers. TallyFlow is the middle layer that makes multi-reader RFID practical for reporting.

**Why this matters for Power BI customers:**

- **Unified multi-reader feed** — all site readers in one schema (reader, antenna, EPC, TID, RSSI, time)
- **Spreadsheet path** — TallyFlow Edge can output that unified data to a **CSV/spreadsheet**; Power BI can load the file, folder, or gateway path with no custom Impinj client
- **Other paths when needed** — REST into middleware / Azure Function / a warehouse DB app, or AMQP into TallyFlow then downstream
- **Ops without opening Power BI** — site staff can confirm reads and reader health locally
- **Stable contract** — add readers or change hardware without rebuilding every report

**Typical flow:**

```text
[Impinj × N] → [TallyFlow Edge] → [CSV / REST / AMQP→TallyFlow]
                                      ↓
                         [optional app → database]
                                      ↓
                              [Power BI / reports]
```

<!-- Add more use-case sections below as needed (e.g. WMS, ERP, ServiceNow). -->

## Example Tunnel Hardware (RMS Omega)
These conveyor/tunnel RFID readers are representative of the fixed reader hardware TallyFlow Edge integrates with:

- rms-omega-rfid-tunnel-reader-front.jpg
- rms-omega-rfid-tunnel-reader-rear.jpg
- rms-omega-rfid-tunnel-reader-side.jpg
- rms-omega-rfid-tunnel-reader-control-panel.jpg

*Images added July 2026 for Edge marketing and benefits documentation.*