fix(config_httpd): gate temp-sensor code behind CONFIG_SOC_TEMP_SENSOR_SUPPORTED - #50
Merged
Conversation
…R_SUPPORTED esp_driver_tsens was an unconditional REQUIRES and the temp-sensor init/ read/deinit calls were unconditional too, breaking the build on SoC variants without a temperature sensor. Gate both behind CONFIG_SOC_TEMP_SENSOR_SUPPORTED; handler_monitor still always returns a temp_c JSON field (null when unsupported) so the REST API shape is unchanged. Cherry-picked from liestrela/microlink@1649d987. Closes #29 Co-authored-by: Adrian.Nguyen-Qualgo <nguyen.ndt@qualgo.net> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Kconfig-gating a REQUIRES entry silently no-ops in this build (documented a few lines above for esp_driver_uart/esp_driver_gpio, same root cause): REQUIRES is resolved before Kconfig is available, so CONFIG_SOC_TEMP_SENSOR_SUPPORTED evaluates false regardless of target and esp_driver_tsens never gets linked in -- while ml_config_httpd.c's post-Kconfig #if CONFIG_SOC_TEMP_SENSOR_SUPPORTED is true on esp32s3, so it tries to include a header from a component that was never required. CI caught this: "driver/temperature_sensor.h: No such file or directory" on every v6.0.1 build. The CONFIG_SOC_TEMP_SENSOR_SUPPORTED check in ml_config_httpd.c already correctly gates the feature at compile time; only the REQUIRES gating attempt was wrong. Co-authored-by: Adrian.Nguyen-Qualgo <nguyen.ndt@qualgo.net> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
esp_driver_tsenswas an unconditionalREQUIRESand the temperature-sensor init/read/deinitcalls in
ml_config_httpd.cwere unconditional too, breaking the build on ESP32 SoC variantswithout a temperature sensor.
CONFIG_SOC_TEMP_SENSOR_SUPPORTED.handler_monitorstill always returnsa
temp_cJSON field (nullwhen unsupported), so the REST API shape is unchanged for clients.liestrela/microlink@1649d987— applied cleanly with noadaptation needed, original authorship preserved on the commit.
FORK_PRS.mdbookkeeping gap: row 5 (issue Yield per-peer in disco_periodic_probes to avoid starving same-core tasks (mined from cplewes/microlink) #24) was missed when marking rows doneafter PR fix(wg_mgr): yield 1 tick per peer in disco_periodic_probes #49 merged.
Closes #29
Test plan
idf.py buildnot runnable in this sandbox (no ESP-IDF installed) — needs a real build,ideally on both a temp-sensor-capable target (e.g. esp32s3) and one without support, to confirm
both compile and
handler_monitor's JSON output is correct in both cases.🤖 Generated with Claude Code