Operational platforms must unify dynamic entity metadata with high-frequency sensor streams. Omnismith routes telemetry metrics directly to time-series tables for live visualization.
Operational visibility requires the tight unification of structured business context with high-frequency telemetry. In the cold-chain fleet management model established in previous entries, the system contains core records: 5 drivers, 7 vehicles, and 4 shipments. While the structural identity of a vehicle or the assignment of a driver remains stable, environmental attributes like Temperature and Fuel Level generate rapid, continuous data streams from physical hardware sensors.
Processing high-frequency streams through traditional document update paths creates structural friction. Relational index writes, entity validation logic, and document serialization overhead introduce latency, degrading the performance of real-time operational interfaces.
Omnismith isolates these data paths at the database layer. By decoupling structural metadata from high-volume telemetry, the platform maintains active indexing while capturing real-time streams for visual consumption on user dashboards.
Isolated Ingestion Pipelines
The architecture splits attribute types into dimensions and metrics. Dimensions represent the structural parameters of an entity (such as a vehicle's make/model or a driver's license status) and are updated via the document modification path. Metrics represent time-series values and flow through an independent path optimized for rapid writes.
Telemetry observations bypass the core entity document engine. When a refrigeration sensor or cellular gateway transmits hardware data, it communicates directly with the dedicated metric ingestion endpoint.
The Ingestion Payload
The ingestion endpoint accepts one or multiple metric observations for a specific entity ID. Data points are written straight to TimescaleDB tables, bypassing document-level indexing overhead.
POST /v1/entities/019f51ca-8401-7243-910f-a22e901fb39f/metrics HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>
{
"metric_values": [
{
"attribute_id": "019f51bf-3604-710b-9356-28f724f05f24",
"value": "-18.5",
"updated_at": "2026-07-20T12:00:00Z"
},
{
"attribute_id": "019f51bf-35aa-7340-86f7-5c903a6a38f0",
"value": "85.2",
"updated_at": "2026-07-20T12:00:00Z"
}
]
}
Omitting the updated_at parameter defaults the observation timestamp to the server arrival time. The engine accepts the array with an HTTP status code 202 Accepted, shifting the values directly into the asynchronous stream processing layer.
Real-Time Telemetry Automation in Action
To demonstrate this high-frequency ingestion pipeline under realistic operating conditions, we can deploy an automated telemetry generator script. In a production setting, this script mirrors the behavior of cellular gateways mounted inside fleet vehicles or IoT sensor daemons.
The script targets multiple vehicle entities simultaneously, generating continuous metric updates for Temperature (e.g. -18.5°C refrigerated cargo baseline) and Fuel Level every 5 seconds:
import time
import random
import requests
from datetime import datetime
API_BASE_URL = "https://api.omnismith.io/v1"
API_TOKEN = "your-bearer-token-here"
UPDATE_INTERVAL_SECONDS = 5
VEHICLES = [
{
"name": "TRK-001 (Volvo FH16)",
"entity_id": "019f51ca-8401-7243-910f-a22e901fb39f",
"temp_attr_id": "019f51bf-3604-710b-9356-28f724f05f24",
"fuel_attr_id": "019f51bf-35aa-7340-86f7-5c903a6a38f0",
"temp": -18.5,
"fuel": 85.2,
},
{
"name": "TRK-002 (Scania R-Series)",
"entity_id": "019f51ca-84a7-714a-b9df-0712b47dc025",
"temp_attr_id": "019f51bf-3604-710b-9356-28f724f05f24",
"fuel_attr_id": "019f51bf-35aa-7340-86f7-5c903a6a38f0",
"temp": 5.0,
"fuel": 42.0,
}
]
def push_metrics(vehicle):
# Simulate slight temperature fluctuation and fuel consumption
vehicle["temp"] = round(vehicle["temp"] + random.uniform(-0.3, 0.3), 2)
vehicle["fuel"] = round(vehicle["fuel"] - random.uniform(0.01, 0.05), 2)
url = f"{API_BASE_URL}/entities/{vehicle['entity_id']}/metrics"
payload = {
"metric_values": [
{"attribute_id": vehicle["temp_attr_id"], "value": str(vehicle["temp"])},
{"attribute_id": vehicle["fuel_attr_id"], "value": str(vehicle["fuel"])}
]
}
headers = {"Authorization": f"Bearer {API_TOKEN}"}
res = requests.post(url, json=payload, headers=headers)
print(f"[{datetime.now().strftime('%H:%M:%S')}] {res.status_code} Accepted | {vehicle['name']} -> Temp: {vehicle['temp']}°C, Fuel: {vehicle['fuel']}%")
while True:
for vehicle in VEHICLES:
push_metrics(vehicle)
time.sleep(UPDATE_INTERVAL_SECONDS)
As the automation pushes observations into the pipeline every 5 seconds, Omnismith Engine captures the high-frequency stream. The connected dashboard widgets update their visual series data dynamically without manual page refreshes:
Building the Observability Layer
For non-technical operators and fleet managers, raw database payloads must be compiled into visual shapes. Omnismith provides a dashboard manager that allows users to place, organize, and tie UI components directly to underlying templates and telemetry attributes.
Dashboards are constructed using a multi-block grid architecture. Four foundational block types handle distinct visual requirements:
| Block Type | Primary Operational Purpose | Core Data Source |
|---|---|---|
| Stat | High-level KPI tracking and inventory totals | Aggregated template entity counts |
| Gauge | Immediate boundary check for vital telemetry metrics | Target entity metric value with min/max thresholds |
| Chart | Historical trend plotting and correlation analysis | Time-bucketed metric series across one or more entities |
| List | Contextual record views and reference correlation | Filtered entity document data with dimension parameters |
Configuring Dashboard Blocks Programmatically
Behind the user interface, every visualization block is registered via the backend schema as a discrete entity container. The block configuration parameters outline the data-fetching requirements that the platform evaluates during frontend rendering.
1. Monitoring Fleet Status with Stat Blocks
To display the total scale of operations to a fleet manager, a stat block counts active items within a target template context. The block queries the entity directory to yield a singular integer.
POST /v1/dashboards/019f52c1-881a-7b3c-9000-8f0000010000/blocks HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>
{
"type": "stat",
"title": "Total Active Vehicles",
"config": {
"template_id": "019f51bf-366c-72b9-94e1-0435af01e34a"
}
}
2. Safeguarding Temperature with Gauge Blocks
A fleet operator must spot when cargo compartment conditions deviate from standard tolerances. A gauge block targets the target template and metric attribute ID of a specific fleet asset, evaluating the value against predefined operational bounds.
POST /v1/dashboards/019f52c1-881a-7b3c-9000-8f0000010000/blocks HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>
{
"type": "gauge",
"title": "Vehicle 01 Refrigeration Unit",
"config": {
"template_id": "019f51bf-366c-72b9-94e1-0435af01e34a",
"metric_attribute_id": "019f51bf-3604-710b-9356-28f724f05f24",
"min": -30,
"max": 10,
"aggregate": "avg",
"filters": [
{
"field": "id",
"operator": "equals",
"value": "019f51ca-8401-7243-910f-a22e901fb39f"
}
]
}
}
3. Analyzing Fuel Trends with Chart Blocks
To spot asset inefficiencies or unexpected telemetry drops over long journeys, engineers require multi-hour line charts. The chart block instructs the database engine to run mathematical time-bucketing on the underlying logs across entities belonging to the target template.
POST /v1/dashboards/019f52c1-881a-7b3c-9000-8f0000010000/blocks HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>
{
"type": "chart",
"title": "Fuel Consumption Over Time",
"config": {
"template_id": "019f51bf-366c-72b9-94e1-0435af01e34a",
"metric_attribute_id": "019f51bf-35aa-7340-86f7-5c903a6a38f0",
"aggregate": "avg",
"bucket_width": "15 minutes",
"time_window": 86400,
"entity_limit": 10
}
}
The resulting single-asset view (TRK-001 Volvo FH16 Dashboard) combines Gauge blocks for real-time operational boundaries alongside 1-hour aggregated trend charts:
Runtime Computation Layer
When a user opens a dashboard, the application executes a batch resolution step across the active blocks via /v1/dashboards/{dashboardId}/blocks/{blockId}/resolve. The platform handles database query assembly internally.
For chart blocks, the system converts configuration inputs into optimized database aggregations. If a chart specifies a bucket_width of 15 minutes and an aggregate of avg, Omnismith uses native hypertable functions to roll up raw sensor inputs into a lightweight JSON array structure:
{
"block_id": "019f52c2-11fa-7cbb-a330-1b2c3d4e5f6a",
"title": "Fuel Consumption Over Time",
"type": "chart",
"bucket_width": "15 minutes",
"series": [
{
"entity_id": "019f51ca-8401-7243-910f-a22e901fb39f",
"entity_name": "TRK-001 (Volvo FH16)",
"data_points": [
{ "time": "2026-07-20T12:00:00Z", "value": 85.2 },
{ "time": "2026-07-20T12:15:00Z", "value": 84.8 },
{ "time": "2026-07-20T12:30:00Z", "value": 84.1 }
]
}
]
}
Non-technical managers interact exclusively with the resulting visual components: the text counters update, gauges swing to represent raw sensor readings, and line charts draw ongoing trends.
When expanded across the entire asset fleet, the Vehicles Monitoring dashboard aggregates time-bucketed metric series across multiple vehicle entities simultaneously, rendering a unified comparative stream:
Architectural Performance Tradeoffs
Bypassing standard document serialization for metric fields yields high transaction performance, but introduces distinct processing parameters.
Because the metric stream bypasses the primary EAV document engine, updates to high-frequency attributes do not re-index the parent entity record instantly. Filtering fleet entities via the global structural search engine (POST /v1/entities/search/{template_id}) operates on the entity document data state. If an operator requires real-time telemetry updates to trigger automations or update document filters, the platform utilizes an event-driven background pipeline to synchronize the entity document index asynchronously.
Unifying this real-time telemetry model with immediate visual components establishes a responsive environment for all platform participants. Engineers leverage high-performance endpoints to offload heavy device metrics, while non-technical project owners monitor visual dashboards containing unified business tracking data.
In the next entry of this series, the platform will utilize these incoming metric points to demonstrate event-driven automations, establishing trigger conditions that alert operators over external communication lines the instant anomalies are recorded.
Top comments (0)