mirror of
https://github.com/esphome/esphome.git
synced 2026-05-10 14:09:14 +08:00
J. Nick Koston
d143df3c49
Add public helpers so the device-builder dashboard backend (esphome/device-builder) doesn't have to import the internal NO_WIFI_VARIANTS list / BOARDS dict to decide whether its basic- setup wizard should emit a wifi: block: - esphome.components.wifi.has_native_wifi(*, platform, board=None, variant=None) - central dispatcher that takes whichever platform-relevant fields the caller has and routes to the right per-platform check internally. As ESPHome adds new platforms (5-6 planned), this is the single place to teach them about Wi-Fi capability - external tooling does not have to grow a parallel per-platform switch. - esphome.components.wifi.variant_has_wifi(variant) - building block for the ESP32 branch (False for H2 / P4 which require esp32_hosted). - esphome.components.rp2040.board_id_has_wifi(board_id) - building block for the RP2040 branch (existing no-arg board_has_wifi() unchanged, now delegates to the new helper). New name (rather than overloading board_has_wifi) so device-builder can feature- detect ESPHome support via try/except ImportError on the new symbol - an older ESPHome would import board_has_wifi successfully but raise TypeError on the explicit-arg call, defeating the fallback. All three wrap implementation-detail tables (NO_WIFI_VARIANTS, the generated BOARDS dict) with explicit-arg signatures + tests, so device-builder pins against a stable surface and a future refactor of the underlying tables doesn't silently break the wizard. Same shape as the device-builder API stabilisation in #16206 and #16290.
