julian
22b1b069df
Initialize CLAUDE.md schema, index, and log; ingest three architecture sources (system overview, Teltonika ingestion design, official Teltonika data-sending protocols) into 7 entity pages, 8 concept pages, and 3 source pages with wikilink cross-references.
1.7 KiB
1.7 KiB
title, type, created, updated, sources, tags
| title | type | created | updated | sources | tags | ||||
|---|---|---|---|---|---|---|---|---|---|
| IO element bag | concept | 2026-04-30 | 2026-04-30 |
|
|
IO element bag
The model-specific telemetry inside a Teltonika AVL record. Carried as { id → value } pairs that tcp-ingestion reads byte-correctly without interpreting.
The principle: pass through unchanged
The Ingestion service does not name, interpret, or filter IO elements. It produces a position-record whose attributes field is a verbatim representation of the IO bag, keyed by the numeric IO element ID as a string.
- No renaming.
- No unit conversion.
- No model lookup.
Per-model interpretation lives in the processor, driven by configuration like { "FMB920": { "16": "odometer_km", "240": "movement" } }.
Why this boundary matters
- Model-specific interpretation belongs where the model is known. Doing it in the parser would couple Ingestion to a registry of every device model in the fleet — exactly the coupling the protocol-adapter is designed to prevent.
- A new model never breaks Ingestion. A packet with
IO 1234from an unknown device produces a parser that stores the raw value under"1234"and moves on. The position is still useful; the attribute is recoverable later once the model's mapping is imported.
Structural implications
- 8-bit IO IDs in Codec 8.
- 16-bit IO IDs in Codec 8E (Teltonika ran out of 8-bit slots) plus variable-length values.
- Codec 16 introduces a per-record generation type but the IO bag itself behaves the same.
The parser handles all three identically with respect to interpretation: read bytes per the codec spec, store under string key, hand off.