Two indoor sensors, wind compass, and stop framebuffer cache thrashing

Downstairs and upstairs are now separate readings. The station names them
backwards -- "temperature_4" is downstairs and "inside_temperature" is
upstairs -- so ha_config.h says which is which. Downstairs is the primary:
big number on the card, and it is what the furnace controls on, because it
is where people are and heat rises. Upstairs sits beside it, obviously
subordinate by size, and costs no vertical space in a layout that has none.

The anemometer came back on 2026-08-07, so wind gets its own column: a dial
whose needle points at the direction the wind is coming FROM (weather-vane
convention, matching the cardinal below it), the speed, and a 5-minute trend
arrow.

  - The needle does not animate. A spin would look better, but every animated
    frame is a redraw, and redrawing is what starves the bounce refill ISR.
  - Below 0.5 mph it shows "Calm" and draws no needle. A vane that is not
    being pushed reports whatever it last settled on, which on this station
    is a steady 0 degrees -- a confident needle pointing due north at zero
    wind. The live snapshot caught exactly that.
  - The trend is local, not HA's 10-minute average, so the window is ours to
    pick: 1-minute buckets over 5 minutes, threshold 1.5 mph.

That last point needed the trend engine to stop assuming one hour. Window,
bucket size, minimum age and threshold are now per-channel in a table, which
also removes the threshold arguments main.c was passing in.

Grid drops to 117px cells to make room, so the sun sub-line is just which
event it is and "RAIN TODAY" is "RAIN" -- both were overrunning.

On the artefacts: bounce mode is NOT a DMA read of the framebuffer. The
refill is a CPU memcpy in an ISR, which is why the driver skips the usual
write-back in draw_bitmap ("the data gets read by the CPU as well"). So the
panel streams 750KB per frame at ~44Hz through the DCache, evicting the
working set of everything else on the chip, continuously -- which is the real
reason this board is so sensitive to WiFi and to any extra rendering.
bb_invalidate_cache frees each chunk after it is copied. The header warns it
"can be dangerous if data is written from other core(s)"; that does not apply
here, because it invalidates the buffer being scanned and by design LVGL only
draws into the other one. Whether it is enough is for the panel to say.

Also gives tools/ha_snapshot.py a --token-file so the token no longer has to
travel through a shell command line to reach it.

Co-Authored-By: Claude <noreply@anthropic.com>

main/api/ha_config.h

@@ -14,21 +14,38 @@
 
 #define HA_ENT_OUTDOOR_TEMP     "sensor.moonlight_beach_temperature"
 #define HA_ENT_OUTDOOR_HUMIDITY "sensor.moonlight_beach_humidity"
-#define HA_ENT_INDOOR_TEMP      "sensor.moonlight_beach_inside_temperature"
-#define HA_ENT_INDOOR_HUMIDITY  "sensor.moonlight_beach_humidity_indoor"
+
+/*
+ * Two indoor sensors.
+ *
+ * DOWN is the console's "4" channel and UP is the one the station calls
+ * "inside" -- the names come from the Ambient Weather hardware, not from the
+ * house, so they read backwards. Downstairs is the primary: it gets the big
+ * card AND it is what the thermostat controls on, because it is where people
+ * are. Heat rises, so upstairs typically reads several degrees warmer;
+ * controlling on it would under-heat the living space.
+ *
+ * To swap which one drives the furnace, change HA_ENT_CONTROL_TEMP below --
+ * that is the only place the choice is made.
+ */
+#define HA_ENT_INDOOR_DOWN_TEMP     "sensor.moonlight_beach_temperature_4"
+#define HA_ENT_INDOOR_DOWN_HUMIDITY "sensor.moonlight_beach_humidity_4"
+#define HA_ENT_INDOOR_UP_TEMP       "sensor.moonlight_beach_inside_temperature"
+#define HA_ENT_INDOOR_UP_HUMIDITY   "sensor.moonlight_beach_humidity_indoor"
 #define HA_ENT_DEW_POINT        "sensor.moonlight_beach_dew_point"
 #define HA_ENT_PRESSURE         "sensor.moonlight_beach_relative_pressure"
 #define HA_ENT_RAIN_TODAY       "sensor.moonlight_beach_daily_rain"
 #define HA_ENT_RAIN_RATE        "sensor.moonlight_beach_precipitation_intensity"
 
 /*
- * The anemometer has been offline since 2026-07-27: wind speed, gust and
- * direction all read "unavailable". The display shows blanks for these by
- * design -- no substituting forecast wind for station wind.
+ * The anemometer was offline from 2026-07-27 and came back 2026-08-07. All
+ * three read live again. The UI still treats them as optional -- ha_value_t
+ * carries its own validity and the compass hides itself when direction is
+ * missing -- because this sensor has now failed once and will again.
  *
- * Do not be tempted by sensor.moonlight_beach_max_gust. It is NOT unavailable;
- * it still reports its last value from 2026-07-28 and would render as a
- * plausible live number. Anything using it needs a staleness check first.
+ * The 10-minute averages are the station's own smoothing. The 5-minute trend
+ * shown on the compass is computed locally from the instantaneous speed
+ * instead, so the trend window is ours to choose; see HA_TREND_CH_WIND.
  */
 #define HA_ENT_WIND_SPEED       "sensor.moonlight_beach_wind_speed"
 #define HA_ENT_WIND_GUST        "sensor.moonlight_beach_wind_gust"