fix(server): build on chips with no die-temperature sensor (#56)

tigo_server included driver/temperature_sensor.h unconditionally for the
Diagnostics die-temp readout. The classic ESP32 has no such peripheral, so
IDF compiles esp_driver_tsens out for it: soc/clk_tree_defs.h never defines
TEMPERATURE_SENSOR_CLK_SRC_DEFAULT, and the header's own
TEMPERATURE_SENSOR_CONFIG_DEFAULT() macro then fails to expand. Reported as
an IDF v5 regression (#55), but it is a chip capability gap — the same IDF
5.5.5 builds this fine on the S3 every day. SOC_TEMP_SENSOR_SUPPORTED is
defined in soc/esp32s3/soc_caps.h and absent from soc/esp32/soc_caps.h.

The peripheral is now compiled out where the SoC lacks it. That unblocks a
real class of board: WROVER modules are classic ESP32s that *do* carry the
PSRAM this component needs, and until now they could not build it at all.
/api/status already reported internal_temp as null when unavailable (#28),
so no API or UI shape changes. A user-wired internal_temperature_id keeps
working on any chip — it is a plain sensor::Sensor and never touches this
driver.

Behind that compile error sat a second wall the reporter would have hit
next. tigo_server assembles whole HTML pages and JSON responses in memory;
with no `psram:` block ESPHome never sets CONFIG_SPIRAM, psram_malloc()
resolves to the internal heap, and ~130KB fragments to OOM under dashboard
polling — a crash hours later, not a build failure. That is now a
validation error naming the sensors-only path, which needs no PSRAM.

Verified: classic ESP32 + quad PSRAM + tigo_server compiles clean (64.4%
flash) — #55's exact failure, reproduced and fixed. S3 unchanged and still
links temperature_sensor_install (nm: present on S3, absent on ESP32). A
no-PSRAM config now fails at `esphome config` with the explanation. Docs
build with valid links.

Author: RAR

CHANGELOG.md

@@ -14,6 +14,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - **The config builder can generate wired configs.** A board that declares an on-board Ethernet PHY now emits an `ethernet:` block and no `wifi:`/`captive_portal:` at all, and the Wi-Fi fields disappear from the form. Bluetooth is compiled out on this board to buy back flash, so CCA-over-BLE is unavailable there; HTTP CCA import is unaffected.
 
 ### Fixed
+- **`tigo_server` builds again on the classic ESP32.** It included `driver/temperature_sensor.h` unconditionally for the Diagnostics die-temperature readout, but the classic ESP32 has no such peripheral, so IDF compiles that driver out and the header's `TEMPERATURE_SENSOR_CONFIG_DEFAULT()` macro fails to expand — `'TEMPERATURE_SENSOR_CLK_SRC_DEFAULT' was not declared in this scope` ([#55](https://github.com/RAR/esphome-tigomonitor/issues/55)). The peripheral is now compiled out on chips that lack it, which unblocks the WROVER modules — classic ESP32s that do have the PSRAM this component needs. `/api/status` already reported the field as null when unavailable, so nothing else changes. A user-wired `internal_temperature_id` still works on any chip; it is a plain sensor and never touches this driver.
+- **`tigo_server:` without a `psram:` block is now a config error instead of a device that dies later.** The web server assembles whole HTML pages and JSON responses in memory. With no `psram:` block ESPHome never sets `CONFIG_SPIRAM`, so those allocations fall back to the ~130KB internal heap and fragment it to OOM under dashboard polling — a crash hours in, not a build failure. Validation now says so up front and points at the sensors-only path, which needs no PSRAM.
 - **A per-panel sensor entry that lists no measurements is now a config error instead of a silent no-op.** `address` and `name` say which panel and what to call it; the entities come from the sub-keys (`power: {}`, `voltage_in: {}`, ...). An entry with none produced nothing at all, with no warning — which reads as "my panels never appeared in Home Assistant" and sends people looking at heap limits and device counts ([#48](https://github.com/RAR/esphome-tigomonitor/issues/48)). Validation now names the offending entry and lists the available sub-keys.
 
 ## [2.0.0] - 2026-08-14

components/tigo_server/__init__.py

@@ -1,5 +1,6 @@
 import esphome.codegen as cg
 import esphome.config_validation as cv
+import esphome.final_validate as fv
 from esphome.components import tigo_monitor, light, sensor, ble_client, esp32_ble_tracker
 from esphome.const import CONF_ID, CONF_PORT
 from pathlib import Path
@@ -43,7 +44,39 @@ def _validate_cca_source(config):
     return config
 
 
+def _require_psram(config):
+    """Refuse to build the web server on a board with no PSRAM.
+
+    tigo_server builds whole HTML pages and JSON API responses in memory from
+    the httpd task; PSRAMString and the psram_* containers assume 8MB of
+    external RAM. Without a `psram:` block ESPHome never sets CONFIG_SPIRAM, so
+    psram_malloc() resolves to the internal heap — the build succeeds, then
+    fragments ~130KB of internal RAM to OOM under dashboard polling. That is a
+    crash hours later on someone's roof, not a compile error, so catch it here.
+
+    tigo_monitor itself is unaffected and needs no PSRAM: its device and node
+    tables are a few KB. A board without PSRAM runs a sensors-only build that
+    feeds Home Assistant over the native API.
+    """
+    if "psram" not in fv.full_config.get():
+        raise cv.Invalid(
+            "tigo_server requires PSRAM, and this configuration has no `psram:` "
+            "block.\n\n"
+            "It builds whole HTML pages and JSON responses in memory, so on a "
+            "board with only internal RAM it compiles and then runs out of heap "
+            "under load. Either:\n"
+            "  * add a `psram:` block, if your board actually has PSRAM, or\n"
+            "  * remove `tigo_server:` and run sensors-only to Home Assistant "
+            "over the native API. tigo_monitor needs no PSRAM.\n\n"
+            "boards/esp32-lilygo-t-can485.yaml is a worked sensors-only example; "
+            "panel discovery there uses the \"Generate YAML Config\" button "
+            "instead of the web UI."
+        )
+    return config
+
+
 def _final_validate(config):
+    _require_psram(config)
     # ESPHome disables mbedtls SHA-384/512 on IDF >= 6.0 to save flash. Both of our
     # crypto paths need them back:
     #  * cloud_import: everything above the leaf in Tigo's cert chain is SHA-384-signed

components/tigo_server/tigo_web_server.cpp

@@ -28,7 +28,6 @@
 #include <cmath>
 #include <sys/time.h>
 #include <mbedtls/base64.h>
-#include <driver/temperature_sensor.h>
 #include "cJSON.h"
 
 namespace esphome {
@@ -594,6 +593,11 @@ void TigoWebServer::setup() {
     if (external_temp_sensor_ != nullptr) {
       ESP_LOGI(TAG, "Using configured internal_temperature sensor for die temp");
     } else {
+#ifndef TIGO_HAS_DIE_TEMP
+    // No die-temperature peripheral on this chip (classic ESP32). Diagnostics
+    // reports the field as null; everything else is unaffected.
+    ESP_LOGI(TAG, "No die temperature sensor on this chip - Diagnostics will omit it");
+#else
     // The requested range must be fully contained in ONE hardware range — the driver's
     // temperature_sensor_choose_best_range() looks for a single table entry with
     // range_min <= requested_min && range_max >= requested_max, and fails the whole
@@ -625,6 +629,7 @@ void TigoWebServer::setup() {
                     "internal_temperature platform, wire it via internal_temperature_id", esp_err_to_name(err));
       temp_sensor_handle_ = nullptr;
     }
+#endif  // TIGO_HAS_DIE_TEMP
     }  // end else (no external sensor wired)
 
     ESP_LOGI(TAG, "All routes registered");
@@ -2799,9 +2804,11 @@ void TigoWebServer::build_esp_status_json(PSRAMString& json) {
       internal_temp = external_temp_sensor_->state;
       internal_temp_ok = true;
     }
+#ifdef TIGO_HAS_DIE_TEMP
   } else if (temp_sensor_handle_ != nullptr &&
              temperature_sensor_get_celsius(temp_sensor_handle_, &internal_temp) == ESP_OK) {
     internal_temp_ok = true;
+#endif
   }
 
   // Get network stats
@@ -3791,12 +3798,14 @@ void TigoWebServer::loop() {
 }
 
 TigoWebServer::~TigoWebServer() {
+#ifdef TIGO_HAS_DIE_TEMP
   // Clean up temperature sensor if it was initialized
   if (temp_sensor_handle_ != nullptr) {
     temperature_sensor_disable(temp_sensor_handle_);
     temperature_sensor_uninstall(temp_sensor_handle_);
     temp_sensor_handle_ = nullptr;
   }
+#endif
 }
 
 }  // namespace tigo_server

components/tigo_server/tigo_web_server.h

@@ -21,7 +21,25 @@
 #include <freertos/FreeRTOS.h>
 #include <freertos/semphr.h>
 #include <esp_heap_caps.h>
+#include <soc/soc_caps.h>
+
+// Not every ESP32 has a die-temperature peripheral. The classic ESP32 has none,
+// so IDF compiles esp_driver_tsens out for it — soc/clk_tree_defs.h never
+// defines TEMPERATURE_SENSOR_CLK_SRC_*, and the header's
+// TEMPERATURE_SENSOR_CONFIG_DEFAULT() macro fails to expand ("'TEMPERATURE_
+// SENSOR_CLK_SRC_DEFAULT' was not declared in this scope", #55). Including the
+// header unconditionally therefore broke the build on every classic ESP32 —
+// including the WROVER modules that do have the PSRAM this component needs.
+//
+// The die temperature is one optional field on the Diagnostics page, and
+// /api/status already reports it as null when unavailable (#28), so the whole
+// peripheral is compiled out rather than faked. A user-wired
+// internal_temperature_id still works on any chip: it is a plain
+// sensor::Sensor and never touches this driver.
+#if defined(SOC_TEMP_SENSOR_SUPPORTED) && SOC_TEMP_SENSOR_SUPPORTED
+#define TIGO_HAS_DIE_TEMP 1
 #include <driver/temperature_sensor.h>
+#endif
 #include <vector>
 #include <string>
 #include <set>
@@ -127,7 +145,9 @@ class TigoWebServer : public Component
   std::string api_token_{""};
   std::string web_username_{""};
   std::string web_password_{""};
+#ifdef TIGO_HAS_DIE_TEMP
   temperature_sensor_handle_t temp_sensor_handle_{nullptr};
+#endif
   sensor::Sensor *external_temp_sensor_{nullptr};  // optional, wins over our own handle
   CcaSource cca_source_{CcaSource::HTTP};
 

site/src/content/docs/guides/troubleshooting.md

@@ -180,13 +180,24 @@ uart:
 
 ### Memory Limits
 
-PSRAM is required.
+PSRAM is required — but only by `tigo_server`, not by `tigo_monitor`.
+
+A config with `tigo_server:` and no `psram:` block is now rejected at validation
+time rather than compiling into a device that runs out of heap hours later. The
+web server builds whole HTML pages and JSON responses in memory; without
+`psram:` ESPHome never sets `CONFIG_SPIRAM`, so those allocations land on the
+~130KB internal heap and fragment it to OOM under dashboard polling.
+
+If your board has no PSRAM, drop `tigo_server:` and run sensors-only to Home
+Assistant over the native API — `boards/esp32-lilygo-t-can485.yaml` is a worked
+example. Panel discovery there uses the **Generate YAML Config** button instead
+of the web UI.
 
 ### ESP32 Internal Temperature Reads Nothing
 
 `/api/status` returns `"internal_temp": null` and the Diagnostics view shows no die temperature.
 
-The ESP32 has a single temperature peripheral, and it installs exactly once. Two things break it:
+Most ESP32s have a single temperature peripheral, and it installs exactly once. Three things break it:
 
 1. **Range must fit one hardware range.** `temperature_sensor_install()` needs the requested range to sit inside a *single* entry of the chip's range table — on the ESP32-S3 that is `{50..125, 20..100, -10..80, -30..50, -40..20}`. A request spanning two entries (e.g. `-10..110`) matches none, fails with `ESP_ERR_INVALID_ARG` ("Out of testing range"), and the sensor never installs. Fixed in 2.0.0-beta.4, which requests `-10..80`. The configured range is only a starting hint — the driver follows the hardware onto another range at read time, so a hot die still reads correctly.
 2. **Another component owns the peripheral.** If you also run ESPHome's `internal_temperature` platform, its install and ours race and the loser reads nothing. Wire the existing sensor into `tigo_server` instead of letting both try:
@@ -201,7 +212,9 @@ tigo_server:
   internal_temperature_id: die_temp
 ```
 
-Look for `Failed to install temperature sensor: <err>` in the boot log to tell the two apart.
+3. **The chip has no such peripheral at all.** The classic ESP32 (including the WROVER modules with PSRAM) has none — only the S2/S3/C-series and P4 do. There is nothing to configure here; the field is simply absent. The boot log says `No die temperature sensor on this chip - Diagnostics will omit it`.
+
+Look for `Failed to install temperature sensor: <err>` in the boot log to tell the first two apart.
 
 ### PSRAM Not Detected After Enabling