tblumer/obsidian
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Rename product TallyFlow IoT → TallyFlow Edge across vault

Browse Source 
Update product naming in docs, marketing, architecture, use cases,
and capabilities materials. Rename related notes, screenshot folder,
and marketing image filenames. Keep git/repo identifiers (e.g.
tallyflow-iot) and generic industry IoT language unchanged.
This commit is contained in:
TNB
2026-07-27 15:48:08 -04:00
parent 4d09d3195b
commit cf1e09e1c4
33 changed files with 128 additions and 128 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TallyFlow/Integration/ServiceNow/ServiceNow Integration Approach.md
+3 -3
View File
@@ -14,7 +14,7 @@ flowchart LR
A[TallyFlow Assets Mobile] -->|REST / WebSocket| B[TallyFlow Core]
C[TallyFlow Print] -->|REST| B
D[TallyFlow Capture] -->|REST| B
E[TallyFlow IoT] -->|REST / MQTT| B
E[TallyFlow Edge] -->|REST / MQTT| B
B -->|REST / Integration Hub| F[ServiceNow]
F -->|REST| B
```
@@ -26,7 +26,7 @@ flowchart LR
| Direction | Typical Data | Trigger | Recommended Method |
|---------------------------|---------------------------------------|----------------------------------|-------------------------------------|
| **ServiceNow → TallyFlow** | Asset master data, locations, status | Scheduled or event-driven | ServiceNow Integration Hub → Core REST |
| **TallyFlow → ServiceNow** | Real-time location, RFID scans, condition updates | Mobile scan, IoT event, zone change | Core → ServiceNow REST / Flow Designer |
| **TallyFlow → ServiceNow** | Real-time location, RFID scans, condition updates | Mobile scan, Edge event, zone change | Core → ServiceNow REST / Flow Designer |
| **Bidirectional** | Asset status synchronization | On change or scheduled | Core as middleware |
## Key Integration Points
@@ -41,7 +41,7 @@ flowchart LR
- This data is pushed to ServiceNow for visibility in Asset Management, Work Orders, or CMDB.
### 3. Real-time Location & Condition
- IoT and mobile events flow through Core and are published to ServiceNow (via REST or Integration Hub).
- Edge and mobile events flow through Core and are published to ServiceNow (via REST or Integration Hub).
## Authentication & Security
TallyFlow/Integration/TallyFlow IoT Multi-Reader Benefits.md → TallyFlow/Integration/TallyFlow Edge Multi-Reader Benefits.md
+22 -22
View File
@@ -1,4 +1,4 @@
# TallyFlow IoT Multi-Reader Benefits
# TallyFlow Edge Multi-Reader Benefits
**Status:** Customer talking points
**Date:** 2026-07-13
@@ -17,21 +17,21 @@ Customers often ask why they should not call reader APIs (e.g. Impinj) directly.
- 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 IoT is that site edge layer.
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 IoT edge] ← ops UI, start/stop, health
[TallyFlow Edge] ← ops UI, start/stop, health
↓
Spreadsheet (CSV) / REST / AMQP (TallyFlow) / …
↓
[Downstream systems]
```
## Benefits of TallyFlow IoT
## Benefits of TallyFlow Edge
General product strengths—useful even when the conversation is not only about multi-reader fan-in.
@@ -89,7 +89,7 @@ Events are normalized to a simple model: reader name, antenna, EPC, TID, RSSI, t
### 3. Unified data can go to a spreadsheet
TallyFlow IoT’s CSV logger writes the combined feed from all readers into spreadsheet-friendly files:
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
@@ -101,18 +101,18 @@ When a spreadsheet is not enough, TallyFlow can also export via:
| Path | Status | Typical use |
| --------------------- | ----------------------------------- | ------------------------------------------------------------ |
| **CSV / spreadsheet** | Built into IoT (`logger`) | File or folder drop (simplest) |
| REST API | Built into IoT (`rest_api`) | Middleware, custom apps, automation (`/tags`, stream, etc.) |
| AMQP → TallyFlow | Built into IoT (`tallyflow`) | Cloud / Core path |
| **Database** | Via app, not a native IoT processor | App consumes REST (or AMQP later) and writes SQL/SQLite/etc. |
| **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 IoT itself. Pattern in production: a site app talks to IoT over REST and persists what the customer needs.
**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 IoT 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 “IoT has a Postgres plugin” unless/until we add one.
- 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 IoT is possible (same event bus as logger/REST), but app-level integration keeps schema and business rules with the customer app.
**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
@@ -154,9 +154,9 @@ They pay for reader hardware either way. The real cost of DIY is owning multi-re
## Related
- Product: TallyFlow IoT (edge service)
- Product: TallyFlow Edge (edge service)
- Egress today: **spreadsheet (CSV)**, REST API, **AMQP → TallyFlow**
- Database today: **via app** (e.g. Alice+Olivia console → SQLite over REST), not a built-in IoT processor
- 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
@@ -176,7 +176,7 @@ Today’s MCP surface is **narrow and read-only**. That is a feature for early u
|-------------|----------------|
| **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 IoT is running before blaming the reader |
| **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 |
@@ -209,9 +209,9 @@ Prioritize in order of risk vs value:
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** — IoT MCP + Core/ServiceNow patterns so an agent can go from “tag seen at dock” to business context (asset, order, location)
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 IoT” is true today. “AI runs your readers” is a future, opt-in story.
**Sell carefully:** “AI can check site RFID status through TallyFlow Edge” is true today. “AI runs your readers” is a future, opt-in story.
---
@@ -226,7 +226,7 @@ Power BI is a consumer of data, not a controller of readers. TallyFlow is the mi
**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 IoT can output that unified data to a **CSV/spreadsheet**; Power BI can load the file, folder, or gateway path with no custom Impinj client
- **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
@@ -234,7 +234,7 @@ Power BI is a consumer of data, not a controller of readers. TallyFlow is the mi
**Typical flow:**
```text
[Impinj × N] → [TallyFlow IoT] → [CSV / REST / AMQP→TallyFlow]
[Impinj × N] → [TallyFlow Edge] → [CSV / REST / AMQP→TallyFlow]
↓
[optional app → database]
↓
@@ -244,11 +244,11 @@ Power BI is a consumer of data, not a controller of readers. TallyFlow is the mi
<!-- 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 IoT integrates with:
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 IoT marketing and benefits documentation.*
*Images added July 2026 for Edge marketing and benefits documentation.*