qapu-cli 0.7.2__tar.gz → 0.7.4__tar.gz

{qapu_cli-0.7.2/qapu_cli.egg-info → qapu_cli-0.7.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: qapu-cli
-Version: 0.7.2
+Version: 0.7.4
 Summary: CLI client for the Qapu API - built for the Hermes agent, but usable by anyone talking to api.ovoo.com.tr from outside the Swarm.
 Author: OVOO Technology
 Classifier: Programming Language :: Python :: 3
@@ -56,10 +56,10 @@ Either way installs a `qapu` command (see `pyproject.toml`'s `[project.scripts]`
 |---|---|
 | `qapu ct-check` | Diagnose CT (current transformer) wiring per phase - reversed polarity vs. wrong phase order - from live PF_R/S/T/AE_R/S/T (GET /hermes/data/{device_id}). |
 | `qapu current` | Current synthesis parameters, grouped (RMS, imbalance, THD, crest factor, fundamental component) (GET /hermes/data/{device_id}). |
-| `qapu data` | Readings per variable for a device - latest value, last N buffered readings (--last), daily min/avg/max (--days), or an explicit --start/--end range (GET /hermes/data/{device_id}). |
+| `qapu data` | Readings per variable for a device - latest value, last N buffered readings (--last), daily min/avg/max (--days), an explicit --start/--end range, or a live-refreshed view (--watch) (GET /hermes/data/{device_id}). |
 | `qapu energy` | One day's active/reactive energy breakdown per phase (GET /hermes/energy/{device_id}). |
 | `qapu health` | Check CLI/server version, connectivity, and server status (GET /health, no auth required). |
-| `qapu pipeline` | Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats). |
+| `qapu pipeline` | Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats). `--watch` live-refreshes in place. |
 | `qapu power` | Power synthesis parameters, grouped (active/reactive/apparent, imbalance, power factor) (GET /hermes/data/{device_id}). |
 | `qapu timeline` | Get one device's timeline events (GET /hermes/timeline/{device_id}). |
 | `qapu trend` | Trend for one variable on one device: recent readings, daily min/avg/max, or an explicit --start/--end range (GET /hermes/trend/{device_id}/{variable_id}). |
@@ -319,6 +319,14 @@ qapu data <device_id> --start 2026-08-30 --end 2026-08-31 --days 5    # daily mi
 
 **Refined again same day, per three more rounds of direct feedback**: (1) `--last`'s TIME column showed a coarse relative bucket ("1 gün önce") for every one of the N readings - useless once several readings from the same day all collapse to the same bucket. Added a new `_format_time()` helper (`tools/cli/qapu_cli/main.py`, next to the existing `_relative_time()`) that renders the actual data timestamp as `YYYY-MM-DD HH:MM:SS` instead - used only where each row needs its own real time (this per-reading table); `_relative_time()` itself (SIM last-connection, timeline, etc.) is untouched, still relative, since "how long ago" is the right framing there. (2) The per-variable group tables were initially borderless (`box=None`) for a lighter look - reverted to the same bordered `Table()` style every other CLI table already uses ("görsel kısmı güzelleştir tablolu yap"), since the borderless version read as less like a real table, not more. `--json` output is untouched either way ("--json diyince ai kendine göre okur onu" - raw JSON is for machine consumption, formatting choices don't need to accommodate it). (3) The `VARIABLE_ID — Description (Unit)` heading was originally a plain `console.print()` line sitting above each group's table, not visually part of it - moved onto the `Table` itself via Rich's `title=`/`title_justify="left"`/`title_style="bold"` params, so it now renders attached to the table's own border ("kısmını da tabloya dahil edelim tablo yapısı ile görünsün"). Live-tested against real prod data: `qapu data <id> --search VRMS --last 5` now shows 5 grouped, bordered, titled tables with real per-reading timestamps (e.g. `2026-09-01 03:12:14`).
 
+**`qapu data --watch`/`-w` (added 2026-09-04)** - the same live-refresh idea `qapu pipeline --watch` uses (see that command's own entry further down for the underlying pattern), applied to a single device's latest readings instead of the fleet-wide pipeline summary, per a same-day follow-up ("aynı şekilde data izlerken de bir canlı uç açabilirmiyiz"):
+```bash
+qapu data <device_id> --watch                    # every variable, live
+qapu data <device_id> --watch --search VRMS       # combine with family/search filters, same as normal mode
+qapu data <device_id> --watch --interval 2        # poll every 2s instead of the default 5s
+```
+Only valid for the default latest-value mode - refuses clearly if combined with `--last`/`--days`/`--start`/`--end`/`--json`. Filtering logic (`--energy`/`--gsm`/`--voltage`/`--current`/`--battery`/`--search`) was extracted into a shared `_apply_data_filters()` so the watch loop and the normal path can't drift apart. Each poll after the first shows a `DEĞİŞİM` column - green `▲ <diff>` if a variable rose since the last poll, red `▼ <diff>` if it fell, `·` if unchanged - and `ZAMAN` shows the absolute reading timestamp (`_format_time()`, not `_relative_time()` - a 5-second poll loop would show "0 dk önce" for every row regardless of whether it just changed, same reasoning already applied to `--last`'s per-reading table above). Verified the same way as `pipeline --watch`'s delta logic: `_build_data_watch_table()` called directly with two synthetic consecutive polls (one variable rising, one falling, one flat), confirmed correct `▲`/`▼`/`·` rendering - `rich.Live`'s actual screen-redraw behavior wasn't separately re-verified end to end here either, for the same non-TTY sandbox reason noted under `pipeline --watch`.
+
 ```bash
 qapu trend <device_id> <variable_id>            # GET /hermes/trend/{device_id}/{variable_id} - last 20 raw readings + trend
 qapu trend <device_id> <variable_id> --last 50  # last N raw readings instead of the default 20
@@ -368,6 +376,8 @@ qapu pipeline --json
 ```
 Not device-scoped - a fleet-wide summary across every service in the `ingest -> stream -> calibration -> raw-writer -> synthesis -> ... -> rule` pipeline. Deliberately reads from the real tables each stage actually writes to (`raw_data.stream_time`/`valid_pack` for `hardware`'s ingest, `streams.stream_time` for `data`'s calibration+synthesis completion, `device_timeline.create_time` for `rule`'s observable output, `blockchain.create_time` for mined blocks) rather than any service's own `/health` endpoint - those are point-in-time snapshots (uptime, CPU, last-message-age), not a windowed throughput count. New `common/qapu_common/domain/pipeline.py` (`Pipeline_Stats.get_stats(minutes)`, four plain `SELECT count(*) ... WHERE <time column> >= now() - interval` queries, no caching - these are meant to be live) + `GET /hermes/pipeline/stats` (`services/api/src/routers/hermes.py`, `minutes` query param, 1 to 10080/7 days). **`Rule_Events` deliberately does NOT count rule evaluations** - `rule` evaluates every single stream message 1:1, the same count `Data_Processed` already reports, so repeating it would be redundant; it counts `device_timeline` rows instead, rule's actual observable output (a trigger/reset transition), not every evaluation pass. The CLI prints a bordered summary table plus a soft backlog hint (yellow note, not an error) if `Data_Processed` looks meaningfully behind `Ingest_Valid` (`<80%`) - a sign of consumer lag worth checking, not itself proof of one. Live-tested against real prod DB: `--minutes 60` correctly returned all zeros (no test traffic in the preceding hour at that point in the session), `--minutes 1440` correctly returned real 24h counts, and a fresh real packet sent immediately before a `--minutes 5` check showed up as exactly `+1` across Ingest/Data_Processed/Blockchain_Mined (Rule_Events stayed `0`, correctly - that packet's only variable, `PCB_T`, didn't cross any rule threshold).
 
+**`--watch`/`-w` added the same day**, per direct follow-up request ("pipe line canlı takip edilebilecek bir tool yapabilirmiyiz") - polls the same endpoint every `--interval` seconds (default `5.0`) and redraws the summary in place via Rich's `Live`, instead of printing once and exiting; `Ctrl+C` stops cleanly. Each poll after the first also shows a `DEĞİŞİM` column - green `+N` if a stage's count grew since the last poll, red `-N` if it somehow shrank (shouldn't happen for these monotonic counters within a fixed window, but rendered anyway rather than assumed impossible), `·` if unchanged - a bare redrawn count doesn't read as "live" the way a visible delta does. Refactored the table-building logic into a shared `_build_pipeline_group()` (title + table + optional backlog note, returned as one `rich.console.Group`) used by both the one-shot path and the `--watch` loop, so they can't drift apart. Not combinable with `--json` (a live-refreshed raw-JSON dump isn't a coherent thing to build - errors clearly if both are passed). The delta/redraw logic itself was verified directly (calling `_build_pipeline_group()` with two synthetic consecutive polls and confirming the `+4`/`+2`/`·` rendering, plus the empty-result error path) rather than through a full `--watch` session end to end - `rich.Live`'s screen-redraw behavior depends on `console.is_terminal`, which this environment's piped/non-TTY test harness can't exercise the same way a real interactive terminal does; confirm the actual live redraw looks right in a real terminal session if this is touched again.
+
 `qapu trend` shows a per-variable history plus a simple linear-regression trend line (slope + direction). Three modes, picked by which options you pass:
 - **Raw readings** (`--last N`, default `N=20`): the measurement cache's rolling buffer - bounded to its own depth (~50 most recent packets), *not* a time window. Good for "what's it doing right now."
 - **Daily aggregates** (`--days N`): one row per calendar day (min/avg/max/count), from the same cache the `/measurement/{device_id}/history` endpoint reads - this is what actually covers multi-day/month windows, since the raw buffer doesn't go back that far. `--days` wins over `--last` if both are given (and `--start`/`--end` isn't).

qapu_cli-0.7.2/PKG-INFO → qapu_cli-0.7.4/README.md

@@ -1,15 +1,3 @@
-Metadata-Version: 2.4
-Name: qapu-cli
-Version: 0.7.2
-Summary: CLI client for the Qapu API - built for the Hermes agent, but usable by anyone talking to api.ovoo.com.tr from outside the Swarm.
-Author: OVOO Technology
-Classifier: Programming Language :: Python :: 3
-Requires-Python: >=3.10
-Description-Content-Type: text/markdown
-Requires-Dist: typer<1.0,>=0.12
-Requires-Dist: httpx<1.0,>=0.27
-Requires-Dist: rich<16.0,>=13.0
-
 # Qapu CLI
 
 A thin command-line client for the Qapu API (`api.ovoo.com.tr`), built for the Hermes agent (runs outside this Swarm, in a separate datacenter, and only ever talks to Qapu through this public API) - but usable by anything else that needs to script against Qapu from outside the private network.
@@ -56,10 +44,10 @@ Either way installs a `qapu` command (see `pyproject.toml`'s `[project.scripts]`
 |---|---|
 | `qapu ct-check` | Diagnose CT (current transformer) wiring per phase - reversed polarity vs. wrong phase order - from live PF_R/S/T/AE_R/S/T (GET /hermes/data/{device_id}). |
 | `qapu current` | Current synthesis parameters, grouped (RMS, imbalance, THD, crest factor, fundamental component) (GET /hermes/data/{device_id}). |
-| `qapu data` | Readings per variable for a device - latest value, last N buffered readings (--last), daily min/avg/max (--days), or an explicit --start/--end range (GET /hermes/data/{device_id}). |
+| `qapu data` | Readings per variable for a device - latest value, last N buffered readings (--last), daily min/avg/max (--days), an explicit --start/--end range, or a live-refreshed view (--watch) (GET /hermes/data/{device_id}). |
 | `qapu energy` | One day's active/reactive energy breakdown per phase (GET /hermes/energy/{device_id}). |
 | `qapu health` | Check CLI/server version, connectivity, and server status (GET /health, no auth required). |
-| `qapu pipeline` | Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats). |
+| `qapu pipeline` | Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats). `--watch` live-refreshes in place. |
 | `qapu power` | Power synthesis parameters, grouped (active/reactive/apparent, imbalance, power factor) (GET /hermes/data/{device_id}). |
 | `qapu timeline` | Get one device's timeline events (GET /hermes/timeline/{device_id}). |
 | `qapu trend` | Trend for one variable on one device: recent readings, daily min/avg/max, or an explicit --start/--end range (GET /hermes/trend/{device_id}/{variable_id}). |
@@ -319,6 +307,14 @@ qapu data <device_id> --start 2026-08-30 --end 2026-08-31 --days 5    # daily mi
 
 **Refined again same day, per three more rounds of direct feedback**: (1) `--last`'s TIME column showed a coarse relative bucket ("1 gün önce") for every one of the N readings - useless once several readings from the same day all collapse to the same bucket. Added a new `_format_time()` helper (`tools/cli/qapu_cli/main.py`, next to the existing `_relative_time()`) that renders the actual data timestamp as `YYYY-MM-DD HH:MM:SS` instead - used only where each row needs its own real time (this per-reading table); `_relative_time()` itself (SIM last-connection, timeline, etc.) is untouched, still relative, since "how long ago" is the right framing there. (2) The per-variable group tables were initially borderless (`box=None`) for a lighter look - reverted to the same bordered `Table()` style every other CLI table already uses ("görsel kısmı güzelleştir tablolu yap"), since the borderless version read as less like a real table, not more. `--json` output is untouched either way ("--json diyince ai kendine göre okur onu" - raw JSON is for machine consumption, formatting choices don't need to accommodate it). (3) The `VARIABLE_ID — Description (Unit)` heading was originally a plain `console.print()` line sitting above each group's table, not visually part of it - moved onto the `Table` itself via Rich's `title=`/`title_justify="left"`/`title_style="bold"` params, so it now renders attached to the table's own border ("kısmını da tabloya dahil edelim tablo yapısı ile görünsün"). Live-tested against real prod data: `qapu data <id> --search VRMS --last 5` now shows 5 grouped, bordered, titled tables with real per-reading timestamps (e.g. `2026-09-01 03:12:14`).
 
+**`qapu data --watch`/`-w` (added 2026-09-04)** - the same live-refresh idea `qapu pipeline --watch` uses (see that command's own entry further down for the underlying pattern), applied to a single device's latest readings instead of the fleet-wide pipeline summary, per a same-day follow-up ("aynı şekilde data izlerken de bir canlı uç açabilirmiyiz"):
+```bash
+qapu data <device_id> --watch                    # every variable, live
+qapu data <device_id> --watch --search VRMS       # combine with family/search filters, same as normal mode
+qapu data <device_id> --watch --interval 2        # poll every 2s instead of the default 5s
+```
+Only valid for the default latest-value mode - refuses clearly if combined with `--last`/`--days`/`--start`/`--end`/`--json`. Filtering logic (`--energy`/`--gsm`/`--voltage`/`--current`/`--battery`/`--search`) was extracted into a shared `_apply_data_filters()` so the watch loop and the normal path can't drift apart. Each poll after the first shows a `DEĞİŞİM` column - green `▲ <diff>` if a variable rose since the last poll, red `▼ <diff>` if it fell, `·` if unchanged - and `ZAMAN` shows the absolute reading timestamp (`_format_time()`, not `_relative_time()` - a 5-second poll loop would show "0 dk önce" for every row regardless of whether it just changed, same reasoning already applied to `--last`'s per-reading table above). Verified the same way as `pipeline --watch`'s delta logic: `_build_data_watch_table()` called directly with two synthetic consecutive polls (one variable rising, one falling, one flat), confirmed correct `▲`/`▼`/`·` rendering - `rich.Live`'s actual screen-redraw behavior wasn't separately re-verified end to end here either, for the same non-TTY sandbox reason noted under `pipeline --watch`.
+
 ```bash
 qapu trend <device_id> <variable_id>            # GET /hermes/trend/{device_id}/{variable_id} - last 20 raw readings + trend
 qapu trend <device_id> <variable_id> --last 50  # last N raw readings instead of the default 20
@@ -368,6 +364,8 @@ qapu pipeline --json
 ```
 Not device-scoped - a fleet-wide summary across every service in the `ingest -> stream -> calibration -> raw-writer -> synthesis -> ... -> rule` pipeline. Deliberately reads from the real tables each stage actually writes to (`raw_data.stream_time`/`valid_pack` for `hardware`'s ingest, `streams.stream_time` for `data`'s calibration+synthesis completion, `device_timeline.create_time` for `rule`'s observable output, `blockchain.create_time` for mined blocks) rather than any service's own `/health` endpoint - those are point-in-time snapshots (uptime, CPU, last-message-age), not a windowed throughput count. New `common/qapu_common/domain/pipeline.py` (`Pipeline_Stats.get_stats(minutes)`, four plain `SELECT count(*) ... WHERE <time column> >= now() - interval` queries, no caching - these are meant to be live) + `GET /hermes/pipeline/stats` (`services/api/src/routers/hermes.py`, `minutes` query param, 1 to 10080/7 days). **`Rule_Events` deliberately does NOT count rule evaluations** - `rule` evaluates every single stream message 1:1, the same count `Data_Processed` already reports, so repeating it would be redundant; it counts `device_timeline` rows instead, rule's actual observable output (a trigger/reset transition), not every evaluation pass. The CLI prints a bordered summary table plus a soft backlog hint (yellow note, not an error) if `Data_Processed` looks meaningfully behind `Ingest_Valid` (`<80%`) - a sign of consumer lag worth checking, not itself proof of one. Live-tested against real prod DB: `--minutes 60` correctly returned all zeros (no test traffic in the preceding hour at that point in the session), `--minutes 1440` correctly returned real 24h counts, and a fresh real packet sent immediately before a `--minutes 5` check showed up as exactly `+1` across Ingest/Data_Processed/Blockchain_Mined (Rule_Events stayed `0`, correctly - that packet's only variable, `PCB_T`, didn't cross any rule threshold).
 
+**`--watch`/`-w` added the same day**, per direct follow-up request ("pipe line canlı takip edilebilecek bir tool yapabilirmiyiz") - polls the same endpoint every `--interval` seconds (default `5.0`) and redraws the summary in place via Rich's `Live`, instead of printing once and exiting; `Ctrl+C` stops cleanly. Each poll after the first also shows a `DEĞİŞİM` column - green `+N` if a stage's count grew since the last poll, red `-N` if it somehow shrank (shouldn't happen for these monotonic counters within a fixed window, but rendered anyway rather than assumed impossible), `·` if unchanged - a bare redrawn count doesn't read as "live" the way a visible delta does. Refactored the table-building logic into a shared `_build_pipeline_group()` (title + table + optional backlog note, returned as one `rich.console.Group`) used by both the one-shot path and the `--watch` loop, so they can't drift apart. Not combinable with `--json` (a live-refreshed raw-JSON dump isn't a coherent thing to build - errors clearly if both are passed). The delta/redraw logic itself was verified directly (calling `_build_pipeline_group()` with two synthetic consecutive polls and confirming the `+4`/`+2`/`·` rendering, plus the empty-result error path) rather than through a full `--watch` session end to end - `rich.Live`'s screen-redraw behavior depends on `console.is_terminal`, which this environment's piped/non-TTY test harness can't exercise the same way a real interactive terminal does; confirm the actual live redraw looks right in a real terminal session if this is touched again.
+
 `qapu trend` shows a per-variable history plus a simple linear-regression trend line (slope + direction). Three modes, picked by which options you pass:
 - **Raw readings** (`--last N`, default `N=20`): the measurement cache's rolling buffer - bounded to its own depth (~50 most recent packets), *not* a time window. Good for "what's it doing right now."
 - **Daily aggregates** (`--days N`): one row per calendar day (min/avg/max/count), from the same cache the `/measurement/{device_id}/history` endpoint reads - this is what actually covers multi-day/month windows, since the raw buffer doesn't go back that far. `--days` wins over `--last` if both are given (and `--start`/`--end` isn't).

{qapu_cli-0.7.2 → qapu_cli-0.7.4}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "qapu-cli"
-version = "0.7.2"
+version = "0.7.4"
 description = "CLI client for the Qapu API - built for the Hermes agent, but usable by anyone talking to api.ovoo.com.tr from outside the Swarm."
 readme = "README.md"
 requires-python = ">=3.10"

{qapu_cli-0.7.2 → qapu_cli-0.7.4}/qapu_cli/main.py

@@ -15,7 +15,8 @@ from typing import Any, Optional
 import httpx
 import typer
 from rich.columns import Columns
-from rich.console import Console
+from rich.console import Console, Group
+from rich.live import Live
 from rich.panel import Panel
 from rich.table import Table
 from rich.tree import Tree
@@ -803,42 +804,16 @@ def _print_data_daily_grouped(readings: list[dict[str, Any]]) -> None:
 		console.print(table)
 
 
-# Get a Device's Readings per Variable, Optionally Filtered by Family/Time Window
-@app.command("data")
-def device_data(
-	device_id: str = typer.Argument(..., help="Device ID."),
-	energy: bool = typer.Option(False, "--energy", help="Only Energy segment variables."),
-	gsm: bool = typer.Option(False, "--gsm", help="Only GSM segment variables (signal, network, etc)."),
-	voltage: bool = typer.Option(False, "--voltage", help="Only voltage variables (Unit == V - includes battery voltage)."),
-	current: bool = typer.Option(False, "--current", help="Only current variables (Unit == A)."),
-	battery: bool = typer.Option(False, "--battery", help="Only battery variables (Variable ID starting with B_)."),
-	search: Optional[str] = typer.Option(None, "--search", help="Case-insensitive substring match on the variable ID (e.g. --search vrms for VRMS_R/S/T, or --search AE for AE_R/AE_S/AE_T/AE_L/AE_G - drop the phase/direction suffix to pull the whole family)."),
-	last: Optional[int] = typer.Option(None, "--last", help="Show the last N buffered readings per variable instead of just the latest. Bounded by the buffer's own depth (~50 most recent packets) - not a time window."),
-	days: Optional[int] = typer.Option(None, "--days", help="Show daily min/avg/max over the last N days per variable instead of the latest value. Ignored if --start/--end is also given (the range wins)."),
-	start: Optional[str] = typer.Option(None, "--start", help="ISO date/datetime lower bound, inclusive (e.g. 2026-08-30 or 2026-08-30T14:00:00). Combine with --end for an explicit range - takes priority over --last/--days. Daily min/avg/max narrowed to the range if --days was also given, raw readings otherwise."),
-	end: Optional[str] = typer.Option(None, "--end", help="ISO date/datetime upper bound, inclusive."),
-	as_json: bool = typer.Option(False, "--json", help="Print raw JSON instead of a table."),
-):
-	"""Readings per variable for a device - latest value, last N buffered readings (--last), daily min/avg/max (--days), or an explicit --start/--end range (GET /hermes/data/{device_id})."""
-
-	# Fetch the Readings - Mode Depends on --last/--days/--start/--end,
-	# Already Enriched with Description/Unit/Segment Regardless of Mode
-	params: dict[str, Any] = {}
-	if days is not None:
-		params["days"] = days
-	elif last is not None:
-		params["last"] = last
-	if start is not None:
-		params["start"] = start
-	if end is not None:
-		params["end"] = end
-	readings: list[dict[str, Any]] = client.get(f"/hermes/data/{device_id}", params=params or None)
+# Apply --energy/--gsm/--voltage/--current/--battery/--search Filters to a
+# Readings List - Extracted 2026-09-04 So `data --watch`'s Poll Loop Can
+# Reuse the Exact Same Filter Logic as the One-Shot Path, Rather Than
+# Drifting into a Second Copy.
+def _apply_data_filters(readings: list[dict[str, Any]], energy: bool, gsm: bool, voltage: bool, current: bool, battery: bool, search: Optional[str]) -> list[dict[str, Any]]:
 
 	# Apply Family Filters, if Any - Union (OR) Across Whichever Were Given -
 	# Same Filter Logic Regardless of Mode, Since Variable_ID/Unit/Segment
 	# are Present on Every Row in Every Mode
-	filters_selected = energy or gsm or voltage or current or battery
-	if filters_selected:
+	if energy or gsm or voltage or current or battery:
 
 		# Filter In Place
 		filtered: list[dict[str, Any]] = []
@@ -873,6 +848,112 @@ def device_data(
 		needle = search.strip().lower()
 		readings = [r for r in readings if needle in (r.get("Variable_ID") or "").lower()]
 
+	# Return the Filtered List, Sorted for Stable Output
+	return sorted(readings, key=lambda r: r.get("Variable_ID") or "")
+
+
+# Build a Live-Watch Table for `data --watch` - VARIABLE/VALUE/UNIT/
+# DEĞİŞİM (Changed-Since-Last-Poll Indicator)/TIME, Grouped Neither by
+# Variable (There's Only Ever One Reading per Variable in "Latest" Mode,
+# Unlike --last's Multi-Reading Groups) - Absolute Time (_format_time),
+# not Relative, Since a 5-Second Poll Loop Would Show "0 dk önce" for
+# Every Row Regardless of Whether it Actually Just Changed.
+def _build_data_watch_table(device_id: str, readings: list[dict[str, Any]], previous: Optional[dict[str, Any]], as_of: str) -> Group:
+
+	header = f"[bold]{device_id}[/bold] - Canlı Veri  [dim](güncellendi: {as_of})[/dim]"
+
+	table = Table(show_header=True, header_style="bold")
+	table.add_column("DEĞİŞKEN")
+	table.add_column("DEĞER", justify="right")
+	table.add_column("BİRİM")
+	if previous is not None:
+		table.add_column("DEĞİŞİM")
+	table.add_column("ZAMAN")
+
+	for r in readings:
+		variable_id = r.get("Variable_ID") or "-"
+		value = r.get("Value")
+		value_str = f"{value:g}" if isinstance(value, (int, float)) else "-"
+		unit = r.get("Unit") or "-"
+		reading_time = _format_time(r.get("Time"))
+
+		row = [variable_id, value_str, unit]
+		if previous is not None:
+			prev_value = previous.get(variable_id, {}).get("Value") if isinstance(previous.get(variable_id), dict) else None
+			if prev_value is None or not isinstance(value, (int, float)):
+				row.append("")
+			elif value > prev_value:
+				row.append(f"[green]▲ {value - prev_value:g}[/green]")
+			elif value < prev_value:
+				row.append(f"[red]▼ {prev_value - value:g}[/red]")
+			else:
+				row.append("·")
+		row.append(reading_time)
+		table.add_row(*row)
+
+	return Group(header, table)
+
+
+# Get a Device's Readings per Variable, Optionally Filtered by Family/Time Window
+@app.command("data")
+def device_data(
+	device_id: str = typer.Argument(..., help="Device ID."),
+	energy: bool = typer.Option(False, "--energy", help="Only Energy segment variables."),
+	gsm: bool = typer.Option(False, "--gsm", help="Only GSM segment variables (signal, network, etc)."),
+	voltage: bool = typer.Option(False, "--voltage", help="Only voltage variables (Unit == V - includes battery voltage)."),
+	current: bool = typer.Option(False, "--current", help="Only current variables (Unit == A)."),
+	battery: bool = typer.Option(False, "--battery", help="Only battery variables (Variable ID starting with B_)."),
+	search: Optional[str] = typer.Option(None, "--search", help="Case-insensitive substring match on the variable ID (e.g. --search vrms for VRMS_R/S/T, or --search AE for AE_R/AE_S/AE_T/AE_L/AE_G - drop the phase/direction suffix to pull the whole family)."),
+	last: Optional[int] = typer.Option(None, "--last", help="Show the last N buffered readings per variable instead of just the latest. Bounded by the buffer's own depth (~50 most recent packets) - not a time window."),
+	days: Optional[int] = typer.Option(None, "--days", help="Show daily min/avg/max over the last N days per variable instead of the latest value. Ignored if --start/--end is also given (the range wins)."),
+	start: Optional[str] = typer.Option(None, "--start", help="ISO date/datetime lower bound, inclusive (e.g. 2026-08-30 or 2026-08-30T14:00:00). Combine with --end for an explicit range - takes priority over --last/--days. Daily min/avg/max narrowed to the range if --days was also given, raw readings otherwise."),
+	end: Optional[str] = typer.Option(None, "--end", help="ISO date/datetime upper bound, inclusive."),
+	watch: bool = typer.Option(False, "--watch", "-w", help="Live-refresh the latest-value table in place every --interval seconds (Ctrl+C to stop). Only compatible with the default latest-value mode - not combinable with --last/--days/--start/--end/--json."),
+	interval: float = typer.Option(5.0, "--interval", help="Seconds between refreshes in --watch mode."),
+	as_json: bool = typer.Option(False, "--json", help="Print raw JSON instead of a table."),
+):
+	"""Readings per variable for a device - latest value, last N buffered readings (--last), daily min/avg/max (--days), an explicit --start/--end range, or a live-refreshed view (--watch) (GET /hermes/data/{device_id})."""
+
+	# --watch: Only Meaningful for the Latest-Value Mode - Refuse Clearly
+	# Rather than Silently Ignoring --last/--days/--start/--end/--json
+	if watch:
+		if last is not None or days is not None or start is not None or end is not None or as_json:
+			typer.echo("Error: --watch sadece varsayılan (son değer) modla kullanılabilir, --last/--days/--start/--end/--json ile birlikte kullanılamaz.", err=True)
+			raise typer.Exit(code=1)
+
+		previous: Optional[dict[str, dict[str, Any]]] = None
+		try:
+			with Live(console=console, refresh_per_second=4) as live:
+				while True:
+					readings = client.get(f"/hermes/data/{device_id}")
+					readings = _apply_data_filters(readings, energy, gsm, voltage, current, battery, search)
+					as_of = datetime.now().strftime("%H:%M:%S")
+					if not readings:
+						live.update(Group(f"[bold]{device_id}[/bold] - Canlı Veri  [dim](güncellendi: {as_of})[/dim]", "\n[yellow]Filtreye uyan veri yok.[/yellow]"))
+					else:
+						live.update(_build_data_watch_table(device_id, readings, previous, as_of))
+						previous = {r.get("Variable_ID"): r for r in readings if r.get("Variable_ID")}
+					time.sleep(interval)
+		except KeyboardInterrupt:
+			return
+
+	# Fetch the Readings - Mode Depends on --last/--days/--start/--end,
+	# Already Enriched with Description/Unit/Segment Regardless of Mode
+	params: dict[str, Any] = {}
+	if days is not None:
+		params["days"] = days
+	elif last is not None:
+		params["last"] = last
+	if start is not None:
+		params["start"] = start
+	if end is not None:
+		params["end"] = end
+	readings: list[dict[str, Any]] = client.get(f"/hermes/data/{device_id}", params=params or None)
+
+	# Apply Family/Search Filters, if Any
+	filters_selected = energy or gsm or voltage or current or battery
+	readings = _apply_data_filters(readings, energy, gsm, voltage, current, battery, search)
+
 	# JSON Output - Everything at Once, Never Paginated
 	if as_json:
 
@@ -885,11 +966,10 @@ def device_data(
 		typer.echo("Bu cihaz için henüz veri yok." if not (filters_selected or search) else "Filtreye uyan veri bulunamadı.")
 		return
 
-	# Sort for Stable Output, then Print with the Table Shape the Mode Needs -
-	# the Response Shape (Daily/History/Value Keys) is What Actually Decides
-	# This, not the Request Params Directly, Since --start/--end Alone (no
-	# --days) Comes Back in the Same "History" Shape --last Uses
-	readings = sorted(readings, key=lambda r: r.get("Variable_ID") or "")
+	# Print with the Table Shape the Mode Needs - the Response Shape
+	# (Daily/History/Value Keys) is What Actually Decides This, not the
+	# Request Params Directly, Since --start/--end Alone (no --days) Comes
+	# Back in the Same "History" Shape --last Uses
 	if days is not None:
 		_print_data_daily_grouped(readings)
 	elif last is not None or start is not None or end is not None:
@@ -1256,32 +1336,49 @@ def device_energy(
 # Get One Variable's Trend on One Device - Either the Last N Raw Buffered
 # Readings, or Daily Min/Avg/Max Over the Last N Days (Mutually Exclusive -
 # --days Wins if Both are Given)
-@app.command("pipeline")
-def pipeline_stats(
-	minutes: int = typer.Option(60, "--minutes", help="Window size in minutes (default 60, max 10080/7 days)."),
-	as_json: bool = typer.Option(False, "--json", help="Print raw JSON instead of the summary table."),
-):
-	"""Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats)."""
-	result: dict[str, Any] = client.get("/hermes/pipeline/stats", params={"minutes": minutes})
+def _window_label(minutes: int) -> str:
 
-	if as_json:
-		typer.echo(json.dumps(result, indent=2))
-		return
+	# Format a Window Size as "N dk" or "N sa" (Whole Hours Only)
+	if minutes < 60 or minutes % 60 != 0:
+		return f"{minutes} dk"
+	return f"{minutes // 60} sa"
 
-	if not result:
-		typer.echo("İstatistikler alınamadı.")
-		return
 
-	window = result.get("Window_Minutes", minutes)
-	window_label = f"{window} dk" if window < 60 else (f"{window // 60} sa" if window % 60 == 0 else f"{window} dk")
+# Build the Pipeline Summary as a Single Renderable (Title + Table +
+# Optional Backlog Note) - Shared by the One-Shot Print and the --watch
+# Live Loop Below, so Both Stay in Sync as the Table's Shape Evolves.
+# `previous` (the Last Poll's raw stats dict, or None) Lets --watch Show a
+# "+N since last check" Delta per Stage, Which is What Actually Makes a
+# Polling Loop Feel "Live" Rather than Just a Table that Happens to
+# Redraw - a Bare Count with No Motion Indicator Doesn't Read as
+# Streaming.
+def _build_pipeline_group(result: dict[str, Any], minutes: int, previous: Optional[dict[str, Any]] = None, as_of: Optional[str] = None) -> Group:
 
-	console.print(f"[bold]Pipeline Özeti[/bold] - son {window_label}\n")
+	title = f"[bold]Pipeline Özeti[/bold] - son {_window_label(minutes)}"
+	if as_of:
+		title += f"  [dim](güncellendi: {as_of})[/dim]"
+
+	if not result:
+		return Group(title, "\n[red]İstatistikler alınamadı.[/red]")
 
 	table = Table(show_header=True, header_style="bold")
 	table.add_column("AŞAMA")
 	table.add_column("SAYI", justify="right")
+	if previous is not None:
+		table.add_column("DEĞİŞİM", justify="right")
 	table.add_column("DETAY")
 
+	def delta_str(key: str, current: int) -> str:
+		if previous is None:
+			return ""
+		prev_value = previous.get(key, 0) or 0
+		diff = current - prev_value
+		if diff > 0:
+			return f"[green]+{diff}[/green]"
+		if diff < 0:
+			return f"[red]{diff}[/red]"
+		return "·"
+
 	ingest_total = result.get("Ingest_Total", 0)
 	ingest_valid = result.get("Ingest_Valid", 0)
 	ingest_invalid = result.get("Ingest_Invalid", 0)
@@ -1289,18 +1386,65 @@ def pipeline_stats(
 	rule_events = result.get("Rule_Events", 0)
 	blocks_mined = result.get("Blockchain_Mined", 0)
 
-	table.add_row("Ingest (hardware)", str(ingest_total), f"{ingest_valid} geçerli, {ingest_invalid} geçersiz")
-	table.add_row("Data İşlendi (data)", str(data_processed), "kalibrasyon + sentez tamamlanan paket")
-	table.add_row("Kural Olayları (rule)", str(rule_events), "tetiklenen/sıfırlanan olay (device_timeline)")
-	table.add_row("Blockchain Kazıldı", str(blocks_mined), "yeni blok")
+	rows = [
+		("Ingest (hardware)", ingest_total, "Ingest_Total", f"{ingest_valid} geçerli, {ingest_invalid} geçersiz"),
+		("Data İşlendi (data)", data_processed, "Data_Processed", "kalibrasyon + sentez tamamlanan paket"),
+		("Kural Olayları (rule)", rule_events, "Rule_Events", "tetiklenen/sıfırlanan olay (device_timeline)"),
+		("Blockchain Kazıldı", blocks_mined, "Blockchain_Mined", "yeni blok"),
+	]
+	for label, value, key, detail in rows:
+		row = [label, str(value)]
+		if previous is not None:
+			row.append(delta_str(key, value))
+		row.append(detail)
+		table.add_row(*row)
 
-	console.print(table)
+	parts: list[Any] = [title, table]
 
 	# Simple Backlog Hint - not an Alert, Just a Note if the Numbers Look
 	# Off (data_processed Should Track ingest_valid Closely Since data
 	# Consumes qapu.raw 1:1)
 	if ingest_valid > 0 and data_processed < ingest_valid * 0.8:
-		console.print(f"\n[yellow]Not: Data işlenen paket sayısı ({data_processed}), geçerli ingest sayısından ({ingest_valid}) belirgin şekilde düşük - olası birikme/gecikme, kontrol edilebilir.[/yellow]")
+		parts.append(f"[yellow]Not: Data işlenen paket sayısı ({data_processed}), geçerli ingest sayısından ({ingest_valid}) belirgin şekilde düşük - olası birikme/gecikme, kontrol edilebilir.[/yellow]")
+
+	return Group(*parts)
+
+
+@app.command("pipeline")
+def pipeline_stats(
+	minutes: int = typer.Option(60, "--minutes", help="Window size in minutes (default 60, max 10080/7 days)."),
+	watch: bool = typer.Option(False, "--watch", "-w", help="Live-refresh the summary in place every --interval seconds (Ctrl+C to stop), instead of printing once."),
+	interval: float = typer.Option(5.0, "--interval", help="Seconds between refreshes in --watch mode."),
+	as_json: bool = typer.Option(False, "--json", help="Print raw JSON instead of the summary table. Not combinable with --watch."),
+):
+	"""Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats)."""
+
+	if as_json and watch:
+		typer.echo("Error: --json ve --watch birlikte kullanılamaz.", err=True)
+		raise typer.Exit(code=1)
+
+	# --watch: Poll on a Live-Refreshed Loop Until Ctrl+C
+	if watch:
+		previous: Optional[dict[str, Any]] = None
+		try:
+			with Live(console=console, refresh_per_second=4) as live:
+				while True:
+					result: dict[str, Any] = client.get("/hermes/pipeline/stats", params={"minutes": minutes})
+					as_of = datetime.now().strftime("%H:%M:%S")
+					live.update(_build_pipeline_group(result, minutes, previous=previous, as_of=as_of))
+					previous = result or previous
+					time.sleep(interval)
+		except KeyboardInterrupt:
+			return
+
+	# One-Shot Fetch
+	result: dict[str, Any] = client.get("/hermes/pipeline/stats", params={"minutes": minutes})
+
+	if as_json:
+		typer.echo(json.dumps(result, indent=2))
+		return
+
+	console.print(_build_pipeline_group(result, minutes))
 
 
 @app.command("trend")

qapu_cli-0.7.2/README.md → qapu_cli-0.7.4/qapu_cli.egg-info/PKG-INFO

@@ -1,3 +1,15 @@
+Metadata-Version: 2.4
+Name: qapu-cli
+Version: 0.7.4
+Summary: CLI client for the Qapu API - built for the Hermes agent, but usable by anyone talking to api.ovoo.com.tr from outside the Swarm.
+Author: OVOO Technology
+Classifier: Programming Language :: Python :: 3
+Requires-Python: >=3.10
+Description-Content-Type: text/markdown
+Requires-Dist: typer<1.0,>=0.12
+Requires-Dist: httpx<1.0,>=0.27
+Requires-Dist: rich<16.0,>=13.0
+
 # Qapu CLI
 
 A thin command-line client for the Qapu API (`api.ovoo.com.tr`), built for the Hermes agent (runs outside this Swarm, in a separate datacenter, and only ever talks to Qapu through this public API) - but usable by anything else that needs to script against Qapu from outside the private network.
@@ -44,10 +56,10 @@ Either way installs a `qapu` command (see `pyproject.toml`'s `[project.scripts]`
 |---|---|
 | `qapu ct-check` | Diagnose CT (current transformer) wiring per phase - reversed polarity vs. wrong phase order - from live PF_R/S/T/AE_R/S/T (GET /hermes/data/{device_id}). |
 | `qapu current` | Current synthesis parameters, grouped (RMS, imbalance, THD, crest factor, fundamental component) (GET /hermes/data/{device_id}). |
-| `qapu data` | Readings per variable for a device - latest value, last N buffered readings (--last), daily min/avg/max (--days), or an explicit --start/--end range (GET /hermes/data/{device_id}). |
+| `qapu data` | Readings per variable for a device - latest value, last N buffered readings (--last), daily min/avg/max (--days), an explicit --start/--end range, or a live-refreshed view (--watch) (GET /hermes/data/{device_id}). |
 | `qapu energy` | One day's active/reactive energy breakdown per phase (GET /hermes/energy/{device_id}). |
 | `qapu health` | Check CLI/server version, connectivity, and server status (GET /health, no auth required). |
-| `qapu pipeline` | Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats). |
+| `qapu pipeline` | Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats). `--watch` live-refreshes in place. |
 | `qapu power` | Power synthesis parameters, grouped (active/reactive/apparent, imbalance, power factor) (GET /hermes/data/{device_id}). |
 | `qapu timeline` | Get one device's timeline events (GET /hermes/timeline/{device_id}). |
 | `qapu trend` | Trend for one variable on one device: recent readings, daily min/avg/max, or an explicit --start/--end range (GET /hermes/trend/{device_id}/{variable_id}). |
@@ -307,6 +319,14 @@ qapu data <device_id> --start 2026-08-30 --end 2026-08-31 --days 5    # daily mi
 
 **Refined again same day, per three more rounds of direct feedback**: (1) `--last`'s TIME column showed a coarse relative bucket ("1 gün önce") for every one of the N readings - useless once several readings from the same day all collapse to the same bucket. Added a new `_format_time()` helper (`tools/cli/qapu_cli/main.py`, next to the existing `_relative_time()`) that renders the actual data timestamp as `YYYY-MM-DD HH:MM:SS` instead - used only where each row needs its own real time (this per-reading table); `_relative_time()` itself (SIM last-connection, timeline, etc.) is untouched, still relative, since "how long ago" is the right framing there. (2) The per-variable group tables were initially borderless (`box=None`) for a lighter look - reverted to the same bordered `Table()` style every other CLI table already uses ("görsel kısmı güzelleştir tablolu yap"), since the borderless version read as less like a real table, not more. `--json` output is untouched either way ("--json diyince ai kendine göre okur onu" - raw JSON is for machine consumption, formatting choices don't need to accommodate it). (3) The `VARIABLE_ID — Description (Unit)` heading was originally a plain `console.print()` line sitting above each group's table, not visually part of it - moved onto the `Table` itself via Rich's `title=`/`title_justify="left"`/`title_style="bold"` params, so it now renders attached to the table's own border ("kısmını da tabloya dahil edelim tablo yapısı ile görünsün"). Live-tested against real prod data: `qapu data <id> --search VRMS --last 5` now shows 5 grouped, bordered, titled tables with real per-reading timestamps (e.g. `2026-09-01 03:12:14`).
 
+**`qapu data --watch`/`-w` (added 2026-09-04)** - the same live-refresh idea `qapu pipeline --watch` uses (see that command's own entry further down for the underlying pattern), applied to a single device's latest readings instead of the fleet-wide pipeline summary, per a same-day follow-up ("aynı şekilde data izlerken de bir canlı uç açabilirmiyiz"):
+```bash
+qapu data <device_id> --watch                    # every variable, live
+qapu data <device_id> --watch --search VRMS       # combine with family/search filters, same as normal mode
+qapu data <device_id> --watch --interval 2        # poll every 2s instead of the default 5s
+```
+Only valid for the default latest-value mode - refuses clearly if combined with `--last`/`--days`/`--start`/`--end`/`--json`. Filtering logic (`--energy`/`--gsm`/`--voltage`/`--current`/`--battery`/`--search`) was extracted into a shared `_apply_data_filters()` so the watch loop and the normal path can't drift apart. Each poll after the first shows a `DEĞİŞİM` column - green `▲ <diff>` if a variable rose since the last poll, red `▼ <diff>` if it fell, `·` if unchanged - and `ZAMAN` shows the absolute reading timestamp (`_format_time()`, not `_relative_time()` - a 5-second poll loop would show "0 dk önce" for every row regardless of whether it just changed, same reasoning already applied to `--last`'s per-reading table above). Verified the same way as `pipeline --watch`'s delta logic: `_build_data_watch_table()` called directly with two synthetic consecutive polls (one variable rising, one falling, one flat), confirmed correct `▲`/`▼`/`·` rendering - `rich.Live`'s actual screen-redraw behavior wasn't separately re-verified end to end here either, for the same non-TTY sandbox reason noted under `pipeline --watch`.
+
 ```bash
 qapu trend <device_id> <variable_id>            # GET /hermes/trend/{device_id}/{variable_id} - last 20 raw readings + trend
 qapu trend <device_id> <variable_id> --last 50  # last N raw readings instead of the default 20
@@ -356,6 +376,8 @@ qapu pipeline --json
 ```
 Not device-scoped - a fleet-wide summary across every service in the `ingest -> stream -> calibration -> raw-writer -> synthesis -> ... -> rule` pipeline. Deliberately reads from the real tables each stage actually writes to (`raw_data.stream_time`/`valid_pack` for `hardware`'s ingest, `streams.stream_time` for `data`'s calibration+synthesis completion, `device_timeline.create_time` for `rule`'s observable output, `blockchain.create_time` for mined blocks) rather than any service's own `/health` endpoint - those are point-in-time snapshots (uptime, CPU, last-message-age), not a windowed throughput count. New `common/qapu_common/domain/pipeline.py` (`Pipeline_Stats.get_stats(minutes)`, four plain `SELECT count(*) ... WHERE <time column> >= now() - interval` queries, no caching - these are meant to be live) + `GET /hermes/pipeline/stats` (`services/api/src/routers/hermes.py`, `minutes` query param, 1 to 10080/7 days). **`Rule_Events` deliberately does NOT count rule evaluations** - `rule` evaluates every single stream message 1:1, the same count `Data_Processed` already reports, so repeating it would be redundant; it counts `device_timeline` rows instead, rule's actual observable output (a trigger/reset transition), not every evaluation pass. The CLI prints a bordered summary table plus a soft backlog hint (yellow note, not an error) if `Data_Processed` looks meaningfully behind `Ingest_Valid` (`<80%`) - a sign of consumer lag worth checking, not itself proof of one. Live-tested against real prod DB: `--minutes 60` correctly returned all zeros (no test traffic in the preceding hour at that point in the session), `--minutes 1440` correctly returned real 24h counts, and a fresh real packet sent immediately before a `--minutes 5` check showed up as exactly `+1` across Ingest/Data_Processed/Blockchain_Mined (Rule_Events stayed `0`, correctly - that packet's only variable, `PCB_T`, didn't cross any rule threshold).
 
+**`--watch`/`-w` added the same day**, per direct follow-up request ("pipe line canlı takip edilebilecek bir tool yapabilirmiyiz") - polls the same endpoint every `--interval` seconds (default `5.0`) and redraws the summary in place via Rich's `Live`, instead of printing once and exiting; `Ctrl+C` stops cleanly. Each poll after the first also shows a `DEĞİŞİM` column - green `+N` if a stage's count grew since the last poll, red `-N` if it somehow shrank (shouldn't happen for these monotonic counters within a fixed window, but rendered anyway rather than assumed impossible), `·` if unchanged - a bare redrawn count doesn't read as "live" the way a visible delta does. Refactored the table-building logic into a shared `_build_pipeline_group()` (title + table + optional backlog note, returned as one `rich.console.Group`) used by both the one-shot path and the `--watch` loop, so they can't drift apart. Not combinable with `--json` (a live-refreshed raw-JSON dump isn't a coherent thing to build - errors clearly if both are passed). The delta/redraw logic itself was verified directly (calling `_build_pipeline_group()` with two synthetic consecutive polls and confirming the `+4`/`+2`/`·` rendering, plus the empty-result error path) rather than through a full `--watch` session end to end - `rich.Live`'s screen-redraw behavior depends on `console.is_terminal`, which this environment's piped/non-TTY test harness can't exercise the same way a real interactive terminal does; confirm the actual live redraw looks right in a real terminal session if this is touched again.
+
 `qapu trend` shows a per-variable history plus a simple linear-regression trend line (slope + direction). Three modes, picked by which options you pass:
 - **Raw readings** (`--last N`, default `N=20`): the measurement cache's rolling buffer - bounded to its own depth (~50 most recent packets), *not* a time window. Good for "what's it doing right now."
 - **Daily aggregates** (`--days N`): one row per calendar day (min/avg/max/count), from the same cache the `/measurement/{device_id}/history` endpoint reads - this is what actually covers multi-day/month windows, since the raw buffer doesn't go back that far. `--days` wins over `--last` if both are given (and `--start`/`--end` isn't).