Forecast from the right end of the window, and from the level shown

Four defects stacked into one nonsense report: cartridges at 20% claiming four
days, cartridges at 1% claiming weeks.

The root cause is a Zabbix API detail. `limit` caps the whole result set rather
than each item, and the query sorted ascending, so the cap kept the OLDEST rows
in the window. A four-cartridge printer polled every five minutes writes over
100k readings in 90 days; the forecast was fitted to the first few days of that
and nothing since. Every rate was real and every rate described a cartridge
thrown away three months ago. Nothing in the output looks wrong, which is why
it needed pinning in a test rather than a comment.

A 90-day burn rate does not need every individual poll, so a long window now
reads hourly trends - the table meant for this, a tenth of the rows, and kept
longer. Raw history serves short windows and any item a site keeps no trends
for. Both are fetched newest-first with the budget scaled per item.

Second, the countdown was computed from the last stored reading while the level
displayed was the live one, so the two could disagree by a whole cartridge. The
live level is now what the countdown divides. A live level far above the stored
run means it was swapped since the last reading, and that is reported as a
replacement rather than as a collapse in the burn rate.

Third, at or below 5% a cartridge reads as empty rather than as a slow drain.
At 1% losing a tenth of a point a day the arithmetic says ten days. The printer
is out of toner, and it is the first thing to order.

Fourth, the days-left column spanned the printer's rows, so the printer's
soonest figure was printed beside every supply it had. That alone accounts for
the shape of both complaints: a healthy cartridge wearing its neighbour's
deadline, and an empty one wearing a number that belonged to nothing on its row.

Also fixes float-typed supplies vanishing from any printer that also had an
integer-typed one - they live in different history tables and the fetch stopped
at whichever answered first.

Not verified against live data: Zabbix is not reachable from the dev box.

plugins/printers/services/zabbix_service.py

@@ -220,37 +220,119 @@ class ZabbixService:
             })
         return supplies
 
-    def gethistory(self, itemids, days=90, limit=5000):
+    # Per item, per call. Zabbix applies `limit` to the WHOLE result set, not
+    # per item, so the budget is multiplied by the number of items asked for.
+    HISTORY_PER_ITEM = 2000
+
+    def gethistory(self, itemids, days=90, peritem=None):
         """Raw level history for supply items: {itemid: [(clock, value), ...]}.
 
-        Zabbix keeps this already - we simply never asked for it. history=3 is
-        the unsigned-integer table, which is where a percent-remaining item
-        lands; a site that types the item as float would need history=0, so a
-        miss falls back rather than erroring.
+        Ordered oldest-first, which is what the analysis expects.
+
+        Two things about the Zabbix API make the obvious call return the wrong
+        rows, and both bit us:
+
+          * `limit` caps the whole answer, not each item. A four-cartridge
+            printer polled every five minutes writes over 100k rows in 90 days.
+          * combined with `sortorder: ASC`, the cap keeps the OLDEST rows - so a
+            "90 day" request came back holding the first few days of the window
+            and nothing since. Every rate was computed from history a quarter of
+            a year stale.
+
+        So: sort DESC to keep the NEWEST rows, scale the budget by item count,
+        and hand back ascending.
+
+        history=3 is the unsigned-integer table, where a percent-remaining item
+        lands; a site that types the item as float needs history=0. Items can be
+        split across the two, so both are asked and the results merged - an
+        earlier version stopped as soon as either answered, which silently lost
+        every float-typed supply on a printer that also had an integer one.
 
         Returns {} when Zabbix is off or unreachable, so callers degrade to
         "no estimate" instead of failing.
         """
         if not itemids:
             return {}
+        itemids = [str(i) for i in itemids]
+        peritem = peritem or self.HISTORY_PER_ITEM
         timefrom = int(time.time()) - days * 86400
         collected = {}
+
         for historytype in (3, 0):
+            outstanding = [i for i in itemids if i not in collected]
+            if not outstanding:
+                break
             rows = self._apicall("history.get", {
                 "output": "extend",
                 "history": historytype,
-                "itemids": list(itemids),
+                "itemids": outstanding,
                 "time_from": timefrom,
                 "sortfield": "clock",
-                "sortorder": "ASC",
-                "limit": limit,
+                "sortorder": "DESC",
+                "limit": peritem * len(outstanding),
             }) or []
             for row in rows:
                 collected.setdefault(str(row.get("itemid")), []).append(
                     (row.get("clock"), row.get("value")))
-            # Items live in one table or the other; stop once something answered.
-            if collected:
-                break
+
+        for itemid, points in collected.items():
+            points.reverse()          # DESC came back; analysis wants ASC
+        return collected
+
+    # Trends are hourly aggregates and are kept far longer than raw history.
+    # 90 days of raw 5-minute readings is 26k rows an item; the same window in
+    # trends is 2160. For a burn rate over months that is the right table -
+    # nothing is gained by fitting a line through every individual poll.
+    TRENDS_MIN_DAYS = 7
+    TRENDS_PER_ITEM = 3000
+
+    def gettrends(self, itemids, days=90, peritem=None):
+        """Hourly level averages: {itemid: [(clock, value), ...]}, oldest first.
+
+        Same `limit` caveat as gethistory - it caps the whole answer, so the
+        budget is scaled and the sort is DESC.
+
+        Returns {} if trends are not kept (a site can set the trend period to
+        0), which is a real configuration, not an error. Callers fall back to
+        raw history.
+        """
+        if not itemids:
+            return {}
+        itemids = [str(i) for i in itemids]
+        peritem = peritem or self.TRENDS_PER_ITEM
+        timefrom = int(time.time()) - days * 86400
+        rows = self._apicall("trend.get", {
+            "output": ["itemid", "clock", "value_avg"],
+            "itemids": itemids,
+            "time_from": timefrom,
+            "sortfield": "clock",
+            "sortorder": "DESC",
+            "limit": peritem * len(itemids),
+        }) or []
+
+        collected = {}
+        for row in rows:
+            collected.setdefault(str(row.get("itemid")), []).append(
+                (row.get("clock"), row.get("value_avg")))
+        for itemid, points in collected.items():
+            points.reverse()
+        return collected
+
+    def getlevelhistory(self, itemids, days=90):
+        """Level history for a forecast, from whichever table serves it best.
+
+        Trends for a long window, raw history for a short one, and raw history
+        for any item the trend table has nothing for.
+        """
+        if not itemids:
+            return {}
+        if days < self.TRENDS_MIN_DAYS:
+            return self.gethistory(itemids, days=days)
+
+        collected = self.gettrends(itemids, days=days)
+        missing = [i for i in (str(i) for i in itemids) if not collected.get(i)]
+        if missing:
+            collected.update(self.gethistory(missing, days=days))
         return collected
 
     def getpingstatus(self, ip: str) -> str: