M5-T07: add latest-reading cards and Recharts trend charts; readings return most-recent rows

openapi/openapi.json

@@ -936,7 +936,7 @@
           "api-modbus"
         ],
         "summary": "Get Readings",
-        "description": "Return time-range readings for a device.\n\nResults are ordered by ``recorded_at`` ascending and capped by ``limit``\n(max {_READINGS_LIMIT_MAX}) to prevent accidental full-table exports.\n\nThe query uses the ``(device_id, recorded_at)`` composite index for\nefficient time-window scans.\n\nQuery parameters:\n- ``start``: inclusive lower bound (ISO8601 datetime)\n- ``end``: inclusive upper bound (ISO8601 datetime)\n- ``limit``: max rows to return (default 500, max {_READINGS_LIMIT_MAX})",
+        "description": "Return time-range readings for a device.\n\nWhen the window contains more rows than ``limit``, the **most recent** N rows\nare returned (``ORDER BY recorded_at DESC LIMIT n``), then reversed to\nascending order before being sent to the client.  This ensures that for long\ntime-range requests (e.g. 6 h / 24 h) the caller always sees the latest data\nrather than the oldest segment of the window.\n\nWhen the window has fewer rows than ``limit`` the full window is returned in\nascending order — behaviour is identical to a plain ascending query.\n\nThe response schema is unchanged: items are always ``recorded_at`` ascending.\n\nThe query uses the ``(device_id, recorded_at)`` composite index for\nefficient time-window scans.\n\nQuery parameters:\n- ``start``: inclusive lower bound (ISO8601 datetime)\n- ``end``: inclusive upper bound (ISO8601 datetime)\n- ``limit``: max rows to return (default 500, max {_READINGS_LIMIT_MAX})",
         "operationId": "get_readings_api_modbus_devices__uuid__readings_get",
         "parameters": [
           {

openapi/openapi.yaml

@@ -678,9 +678,24 @@ paths:
       description: 'Return time-range readings for a device.
 
 
-        Results are ordered by ``recorded_at`` ascending and capped by ``limit``
+        When the window contains more rows than ``limit``, the **most recent** N rows
 
-        (max {_READINGS_LIMIT_MAX}) to prevent accidental full-table exports.
+        are returned (``ORDER BY recorded_at DESC LIMIT n``), then reversed to
+
+        ascending order before being sent to the client.  This ensures that for long
+
+        time-range requests (e.g. 6 h / 24 h) the caller always sees the latest data
+
+        rather than the oldest segment of the window.
+
+
+        When the window has fewer rows than ``limit`` the full window is returned
+        in
+
+        ascending order — behaviour is identical to a plain ascending query.
+
+
+        The response schema is unchanged: items are always ``recorded_at`` ascending.
 
 
         The query uses the ``(device_id, recorded_at)`` composite index for