Home Assistant + ESPHome Sensor Node

This lab guides students through the implementation, configuration, and deployment of network-connected embedded sensor nodes within a Home Assistant smart home ecosystem. Utilizing ESPHome and Espressif microcontrollers such as the ESP32 or ESP8266, students configure and compile custom firmware to interface environmental sensors, establishing bi-directional communication with a central Home Assistant Operating System hub. Working across serial and wireless interfaces, students implement sensor telemetry using Wi-Fi, Bluetooth Low Energy, mDNS discovery, and the ESPHome native API or MQTT protocols. Through hands-on integration, learners analyze networked embedded architectures, manage over-the-air firmware updates, and evaluate device security considerations including captive portals, authentication mechanisms, and transport encryption.

Internet of Things (IoT) embedded systems home automation smart home ESPHome Home Assistant ESP32 ESP8266 microcontrollers sensor nodes MQTT Bluetooth Low Energy (BLE) Over-the-Air (OTA) updates firmware flashing Wi-Fi networking mDNS PlatformIO IoT security

Uploaded by demo on 2026-09-03 · ready · Electronics · Original source ↗

Files: THREAT_MODEL.md · esphome_README.md · haos_README.md · requirements.txt

Readiness checks

  • complete 2026-09-03 15:50 🛡 Cybersecurity: Review before networking · 5 findings 3 searches · 9 pages
    view · PDF

Latest report — 2026-09-03 15:50

Readiness: Home Assistant + ESPHome Sensor Node

Verdict: Ready with caveats · 2026-09-03 · est. parts cost $40–$85 per station (host board + one ESP node + cable) Cybersecurity — software & network: Review before networking

This is the cold check for this lab — there is no previous report, so it establishes the baseline every future check measures against. Sourcing itself is easy: this bill of materials has no PCB components and no manufacturer part numbers, just four commercial off-the-shelf lines, and all three that the lab actually names are cheap and stocked by many sellers today. Two things keep it off a clean "Ready". First, the lab's own sensor modules are never identified in any uploaded file, so one line of the bill of materials cannot be ordered as written. Second, the host board is no longer a free choice: Home Assistant Supervisor 2026.03.0 dropped the 32-bit machine types, and the board-support page the lab points instructors at has not caught up.

Action required

Part Problem Recommended action
Sensor modules and peripheral electronics The lab's materials never identify them — no part numbers, interfaces or quantities in any uploaded file, and no ESPHome YAML config was included Pick the sensors and add them to the bill of materials before ordering. Anything chosen must run at 3.3 V logic levels. Nothing could be priced for this line this run.
Host computing platform (Home Assistant gateway) Home Assistant Supervisor 2026.03.0 removed the armhf/armv7/i386 architectures and the machine types raspberrypi, raspberrypi2, raspberrypi3, raspberrypi4, qemuarm, qemux86, odroid-xu and tinker — but the Board support overview page the lab's README links to still lists Pi2, Pi3, 32-bit Pi4, ODROID-XU4 and Tinker Board Buy a Raspberry Pi 4 Model B with at least 2 GB (or a Pi 5), an ODROID-N2+, or an x86-64 UEFI machine, and install the 64-bit image — the dropped raspberrypi4 is the 32-bit build, not the board. Do not buy an ODROID-XU4 or Asus Tinker Board, and do not reuse an old Pi 2 or Pi 3. Also budget for the power supply, microSD card and Ethernet connection the installation page requires; none of the three is in this bill of materials and none was priced this run.

Cybersecurity — software & network

Review before networking — Every pinned toolchain dependency checked clean except an Intel-macOS-only cryptography pin, but ESPHome's documented defaults leave a node's control, OTA and fallback-AP surfaces open unless the instructor configures authentication and encryption keys, and the lab ships no YAML to show which defaults apply.

Component Version How known Support status
Home Assistant Operating System (HAOS) not determined not determined (haos_README.md names Buildroot LTS, Docker Engine, GRUB/U-Boot, RAUC and AppArmor as the platform but gives no release tag) —
ESPHome (Python CLI/compiler and generated firmware) not determined not determined (no ESPHome release version appears in any file uploaded with the lab; requirements.txt pins its dependencies only) —
cryptography (non-Intel-macOS build hosts) 50.0.1 read from project (fetched/01-requirements.txt (esphome requirements.txt, identical to the copy uploaded with the lab)) —
cryptography (Intel macOS build hosts) 48.0.1 read from project (fetched/01-requirements.txt, second cryptography line, environment marker platform_system == "Darwin" and platform_machine == "x86_64") —
aioesphomeapi (ESPHome native API client) 46.3.0 read from project (fetched/01-requirements.txt) —
paho-mqtt (MQTT client) 1.6.1 read from project (fetched/01-requirements.txt) —
zeroconf (mDNS discovery) 0.151.3 read from project (fetched/01-requirements.txt) —
bleak (Bluetooth LE) 3.0.2 read from project (fetched/01-requirements.txt) —
esptool (flashing) 5.3.1 read from project (fetched/01-requirements.txt) —
platformio (build driver) 6.1.19 read from project (fetched/01-requirements.txt) —
requests 2.34.2 read from project (fetched/01-requirements.txt) —
jinja2 3.1.6 read from project (fetched/01-requirements.txt) —
PyYAML 6.0.3 read from project (fetched/01-requirements.txt) —
ESP-IDF not determined unpinned (a comment in fetched/01-requirements.txt states "esp-idf >= 5.0 requires this"; the build pulls whatever the toolchain resolves, so no exact version exists to check) —
ESP8266 Arduino core not determined not determined (snapshot records it as the toolchain driver invoked via ninja; no version in any provided file) —
tzdata / pyparsing / argcomplete not determined unpinned (fetched/01-requirements.txt declares minimum-version ranges only (tzdata >=2026.3, pyparsing >=3.3.2, argcomplete >=3.7.2)) —
Component Finding Severity Fix available?
cryptography 48.0.1 (Intel macOS build hosts only) On an Intel Mac used as the build host, the pinned cryptography 48.0.1 carries three known flaws (a padding-oracle in PKCS#7 decryption, an exponential certificate path-building slowdown, and a verifier that accepts wildcard names it should reject); every other build host installs 50.0.1, which the same check found clean. — GHSA-g6cj-pr64-35w5, GHSA-jwv3-5hgf-82ww, GHSA-m2h6-j472-rp4c high No — project pins cryptography==48.0.1 for Intel macOS because 49+ ships no Intel macOS wheels; build on Linux or Apple silicon instead and the pin becomes 50.0.1.
ESPHome captive_portal fallback AP If a node cannot reach Wi-Fi, captive_portal raises the node's own fallback access point and auto-loads the web OTA /update endpoint, so a node that loses the classroom network becomes an open flashing target for anyone in radio range. posture Mitigation only — omit captive_portal: from classroom configs, or pair it with web_server auth: and an OTA password
ESPHome native API and OTA encryption The native API link and OTA uploads are encrypted and authenticated only when the config supplies a Noise NNpsk0 encryption key or a password; the documented default on a node with no encryption: block is plaintext OTA, authenticated at most by an OTA password. posture Mitigation only — generate a per-device API encryption key and an OTA key or password before the nodes go on a shared network
ESPHome web OTA endpoint (/update) The web OTA firmware-upload endpoint /update is not covered by the Origin check at all, so wherever web OTA is enabled without web_server auth: anyone who can reach the node can flash their own firmware onto it. posture Mitigation only — set web_server auth: and an OTA password, or leave the web_server OTA platform out of the config
ESPHome web_server component Where a node's YAML enables web_server without an auth: block, every entity view and control endpoint is reachable by anyone who can reach the node, and the Origin header check that blocks browsers is bypassed by design by any non-browser client such as curl or a script. posture Mitigation only — set web_server auth: credentials and keep the nodes on an isolated VLAN or SSID

What this means for your lab

Every pinned Python package in the ESPHome toolchain was checked this run and only one came back with known problems, and that one only bites if you build on an Intel Mac. The real risk in this lab is not a vulnerable library, it is what the sensor nodes do by default. ESPHome's own threat model says plainly that a node's web interface is an open control surface unless the YAML sets a password: with it enabled and no auth, anyone else on the same Wi-Fi can read your students' sensor readings and flip any switch the node controls, and if web OTA or the captive-portal fallback is on, they can upload their own firmware to the device. The lab ships no YAML configs, so which of these apply depends entirely on the configs your students write. Before these nodes go on a campus network: give each device an API encryption key and an OTA password, set web_server auth: if you enable the web interface, leave captive_portal out of classroom configs, and ask campus IT for an isolated VLAN or SSID for the devices. Nothing here says the Home Assistant hub itself is safe or unsafe — the lab never states which HAOS release it uses, so that side could not be checked at all.

Not checked

  • Home Assistant Operating System (HAOS) and its Buildroot/Docker/GRUB/U-Boot/RAUC/AppArmor stack: no release version in the lab's materials, so neither a support-status nor an advisory lookup was possible
  • ESPHome itself (compiler and firmware): no release version in the lab's materials; only its Python dependencies could be checked
  • ESP-IDF: unpinned range (>= 5.0) — no exact version to check
  • ESP8266 Arduino core: version not stated in any provided file
  • tzdata / pyparsing / argcomplete: unpinned minimum-version constraints in requirements.txt — no exact version to check
  • ESP32/ESP8266 firmware libraries pulled by PlatformIO at build time: no vulnerability database covers vendor embedded firmware libraries; absence of advisories here is not evidence of safety
  • MQTT broker: the materials name paho-mqtt as the client but no broker, port or credentials, so there is nothing to check

Parts

Bill of Materials and Hardware Requirements

Part Spec/Package Status Stock Price Source
Host Computing Platform (Home Assistant gateway/server) SBC or x86-64 UEFI PC; 5 V DC or 100–240 V AC; min. 2 GB RAM per the HA installation page readily available multiple sellers $35.00 (RAM not stated in listing); $55.00 2GB; $61.05 4GB starter kit Seeed Studio / PiShop USA / Vilros (Google Shopping, 2026-09-03)
Embedded Sensor Node Microcontroller Development Board ESP32/ESP8266 dev board, DIP pin headers; 5 V USB in, 3.3 V logic readily available multiple sellers $8.00 (ESP32-DevKitM-1); range $3.90–$14.99 across marketplace sellers Mouser via Google Shopping, 2026-09-03
Host-to-Node Serial Programming Cable USB-A to micro-USB (or USB-C), data-capable, USB 2.0 readily available multiple sellers $2.37; range $0.80–$8.22 Monoprice via Grainger (Google Shopping, 2026-09-03)
Sensor Modules and Peripheral Electronics Not stated — must interface at 3.3 V logic not checked — — —

Notes on the rows above:

  • Host board. The $35.00 listing does not state its RAM; the Home Assistant installation page fetched this run gives the requirement as "Raspberry Pi 4 or 5 with power supply (minimum 2 GB RAM), microSD memory card, Ethernet connection", so confirm the variant on the product page before ordering. The ODROID-N2+ and x86-64 mini-PC options the snapshot also allows were not priced this run.
  • ESP board. The lab pins no specific board — "any standard ESP8266 or ESP32-family development board supported by PlatformIO and ESPHome". The priced ESP32-DevKitM-1 uses the ESP32-MINI-1 module rather than the WROOM-32 the snapshot names as its example; both are ESP32-family boards on DIP headers, which is all the lab requires. Other listings this run: ESP32-DevKitC WROOM-32D $3.90 (eBay), Inland ESP32-WROOM-32D $7.99 (Micro Center), KUONGSHUN ESP32-DevKitC $7.99 (Hand Held Legend), ShillehTek ESP-WROOM-32 CP2102 USB-C $8.99, ESP32-DevKitC WROOM-32U $14.99 (Walmart seller).
  • Cable. The lab's one hard requirement for this line is that the cable carries data, not power only — and none of the listings states that in its search result, so check the product page before ordering. Only micro-USB was priced, per the lab's own sourcing plan; if the ESP board you buy has a USB-C port, you need a USB-C data cable instead, which was not priced this run.
  • Sensors. Nothing was checked for this line because nothing was specified — see Action required.

Substitutes

None needed.

Other dependencies

  • Board fabrication: none. No Gerbers, board dimensions or layer counts exist in the lab's materials; every piece of hardware is commercial off-the-shelf.
  • External pages checked this run — all reachable (2026-09-03): ESPHome security best practices, Home Assistant installation, Home Assistant getting started, Board support overview, and the HAOS development-builds index (reachable; its listing is rendered by JavaScript, so only the page title came back as text).
  • One of those pages is stale. The Board support overview still lists Pi2, Pi3B 32/64-bit, Pi4B 32-bit, ODROID-XU4 and Tinker Board in its board table, which Supervisor 2026.03.0 no longer supports. Treat it as a starting point, not a shopping list — see Action required.
  • Accessories the lab omits. The Home Assistant installation page requires a power supply, a microSD card and an Ethernet connection for a Raspberry Pi host. None appears in the bill of materials, and none was priced this run.
  • Not checked this run: the remaining links in the lab's materials — esphome.io, the ESPHome GitHub issues and discussions pages, the Device Builder threat model, home-assistant.io and its /apps/ page, the developer-docs root, ADR-0015 and ADR-0017, and the six upstream project sites (Buildroot, GRUB, U-Boot, Docker Engine, RAUC, AppArmor). No evidence was gathered on them.

Watch list

  • Sensor modules — the open line. Until the lab names its sensors, no future check can price or verify them, and no cost estimate here is complete.
  • Raspberry Pi machine types. The 32-bit removal has already landed; the next thing to watch is whether raspberrypi3-64 and the older ODROID types follow, and whether the developer-docs board table is corrected. Re-read the Supervisor release notes before each cohort orders hardware.
  • The $35.00 Raspberry Pi listing. It sits well below every other Pi 4 offer priced this run and does not state its RAM; it may be a low-memory variant that no longer meets the 2 GB minimum. Worth re-pricing next check.
  • ESP dev-board connector drift. Newer ESP32 boards ship USB-C rather than micro-USB. The cable line was priced as micro-USB only, so a board change silently invalidates it.
  • Raspberry Pi 4 supply generally. Prices this run spread from $35.00 to $249.18 for nominally the same board, which usually signals thin authorized stock and marketplace markup. If the low end disappears, the per-station cost roughly doubles.
Snapshot What the lab depended on when it was uploaded — the baseline the readiness checks research against.

This lab provides the infrastructure, host operating system, and build/flashing toolchain for deploying network-connected sensor nodes using ESPHome integrated into a Home Assistant ecosystem. The system architecture splits into two primary tiers: a central hub running Home Assistant Operating System (HAOS) inside a containerized Buildroot Linux environment, and remote embedded sensor nodes running ESPHome-compiled firmware on Espressif microcontrollers. Operating voltages across the system rely on standard 5 V DC nominal power rails (typically supplied over USB or 5 V DC barrel jack to single-board computers and microcontroller development boards) and an internal 3.3 V DC regulated logic rail on the microcontroller boards for digital signaling and sensor interfaces.

Bill of Materials and Hardware Requirements

No board design files (such as KiCad, Eagle, or Gerber files), electrical schematics, sensor YAML configurations, or component-level bills of materials were provided in the source repository. Consequently, there are no discrete PCB component references (R, C, D, Q, U) to catalog. However, the system documentation and toolchain manifests explicitly mandate the following hardware platforms to execute the lab:

  • Host Computing Platform (Home Assistant Gateway / Server)

    • Identity: Single Board Computer (SBC, e.g., Raspberry Pi or ODROID) or x86-64 personal computer supporting UEFI, compliant with Home Assistant Architecture Decision Records ADR-0015 and ADR-0017.
    • Quantity needed: 1.
    • Footprint/package: COTS Single Board Computer or small form-factor PC chassis.
    • Electrical constraints: 5 V DC input (for standard SBCs via USB-C or DC barrel connector) or 100 to 240 V AC line input for x86-64 hardware.
    • Substitution latitude: Broad latitude. Any SBC or x86-64 UEFI hardware officially supported by Home Assistant OS under ADR-0015 / ADR-0017 can host the platform.
    • Student-operated control: Power button or chassis power switch (if present on x86-64 systems).
    • Sourcing plan: retail shopping search: Raspberry Pi 4 Model B OR ODROID-N2+ OR x86-64 mini PC

  • Embedded Sensor Node Microcontroller Development Board

    • Identity: Espressif ESP8266 or ESP32 development board (implied by requirements for esptool 5.3.1, ninja 1.13.2 for the native ESP8266 Arduino toolchain driver, and ESP-IDF 5.0+ requirements for pyparsing). Described only as ESP8266 / ESP-IDF target boards.
    • Quantity needed: At least 1 node board.
    • Footprint/package: Dual-in-line pin header microcontroller module / development board (e.g., NodeMCU, ESP32-WROOM-32 DevKitC).
    • Electrical constraints: 5 V DC input rail via USB; on-board LDO regulator step-down to 3.3 V DC logic rail. Microcontroller I/O pins run strictly at 3.3 V CMOS levels (non-5V-tolerant on ESP32).
    • Substitution latitude: Any standard ESP8266 or ESP32-family development board supported by PlatformIO and ESPHome.
    • Student-operated control: Onboard tactile pushbuttons for hardware EN/Reset and Boot/GPIO0 flashing control.
    • Sourcing plan: retail shopping search: ESP32 development board OR ESP8266 NodeMCU development board

  • Host-to-Node Serial Programming Cable

    • Identity: USB-A (or USB-C) to Micro-USB (or USB-C) data-capable cable for flashing via pyserial and esptool.
    • Quantity needed: 1.
    • Footprint/package: Standard molded cable assembly.
    • Electrical constraints: 5 V DC power conductors; USB 2.0 full-speed differential signaling.
    • Substitution latitude: Any standard USB cable, provided it carries data lines (not a charge-only cable).
    • Student-operated control: No.
    • Sourcing plan: retail shopping search: USB data cable micro USB or USB-C

  • Sensor Modules and Peripheral Electronics

    • Identity: Described only generically in project title as "Sensor Node". Specific sensing transducers (e.g., I2C, SPI, 1-Wire, or analog temperature/humidity/pressure sensors) and custom interface wiring are omitted from all files in the upload.
    • Quantity needed: Unknown / not stated.
    • Footprint/package: Not stated.
    • Electrical constraints: Must interface with 3.3 V logic levels of the ESP microcontroller.
    • Substitution latitude: Determined entirely by downstream ESPHome component YAML configuration.
    • Student-operated control: Not stated.
    • Sourcing plan: general web research: Which environmental sensors are required for Home Assistant ESPHome Sensor Node lab?

Software and network dependencies

The lab environment depends on a Linux-based host OS for Home Assistant, an ESPHome Python compilation and flashing environment, and underlying embedded toolchains for Espressif chips.

  • Home Assistant Operating System (HAOS)

    • Platform: Buildroot LTS Linux, Docker Engine, GRUB / U-Boot, RAUC, AppArmor.
    • Origin: https://github.com/home-assistant/operating-system
    • Version: not stated (referenced as Buildroot LTS base in haos_README.md; no specific release tag given).
    • Where version came from: not stated.
    • Pinned: No.
    • Manifest location: haos_README.md.
    • Check plan: support-status lookup: Home Assistant Operating System (HAOS) Buildroot LTS

  • Espressif Toolchains and Compilers

    • ESP-IDF: Version >= 5.0 stated in documentation (comment in requirements.txt: "esp-idf >= 5.0 requires this"). Pinned: No. Check plan: not checkable: unpinned version range.
    • ESP8266 Arduino Core: Toolchain driver invoked via ninja; version not stated. Pinned: No. Check plan: not checkable: version not stated.

  • Python Toolchain Packages (from requirements.txt)

    • Manifest location: requirements.txt in repository root.
    • Pinned packages:
      • cryptography: ==50.0.1 (environment: platform_system != "Darwin" or platform_machine != "x86_64"); pinned in requirements.txt. Check plan: vulnerability lookup: cryptography / PyPI / 50.0.1
      • cryptography: ==48.0.1 (environment: platform_system == "Darwin" and platform_machine == "x86_64", retained for Intel macOS wheel support); pinned in requirements.txt. Check plan: vulnerability lookup: cryptography / PyPI / 48.0.1
      • voluptuous: ==0.16.0; pinned in requirements.txt. Check plan: vulnerability lookup: voluptuous / PyPI / 0.16.0
      • PyYAML: ==6.0.3; pinned in requirements.txt. Check plan: vulnerability lookup: PyYAML / PyPI / 6.0.3
      • paho-mqtt: ==1.6.1; pinned in requirements.txt. Check plan: vulnerability lookup: paho-mqtt / PyPI / 1.6.1
      • colorama: ==0.4.6; pinned in requirements.txt. Check plan: vulnerability lookup: colorama / PyPI / 0.4.6
      • tzlocal: ==5.4.4; pinned in requirements.txt. Check plan: vulnerability lookup: tzlocal / PyPI / 5.4.4
      • pyserial: ==3.5; pinned in requirements.txt. Check plan: vulnerability lookup: pyserial / PyPI / 3.5
      • platformio: ==6.1.19; pinned in requirements.txt. Check plan: vulnerability lookup: platformio / PyPI / 6.1.19
      • esptool: ==5.3.1; pinned in requirements.txt. Check plan: vulnerability lookup: esptool / PyPI / 5.3.1
      • click: ==8.3.3; pinned in requirements.txt. Check plan: vulnerability lookup: click / PyPI / 8.3.3
      • aioesphomeapi: ==46.3.0; pinned in requirements.txt. Check plan: vulnerability lookup: aioesphomeapi / PyPI / 46.3.0
      • aiohappyeyeballs: ==2.7.1; pinned in requirements.txt. Check plan: vulnerability lookup: aiohappyeyeballs / PyPI / 2.7.1
      • zeroconf: ==0.151.3; pinned in requirements.txt. Check plan: vulnerability lookup: zeroconf / PyPI / 0.151.3
      • puremagic: ==2.2.0; pinned in requirements.txt. Check plan: vulnerability lookup: puremagic / PyPI / 2.2.0
      • ruamel.yaml: ==0.19.1; pinned in requirements.txt. Check plan: vulnerability lookup: ruamel.yaml / PyPI / 0.19.1
      • ruamel.yaml.clib: ==0.2.15; pinned in requirements.txt. Check plan: vulnerability lookup: ruamel.yaml.clib / PyPI / 0.2.15
      • esphome-glyphsets: ==0.2.0; pinned in requirements.txt. Check plan: vulnerability lookup: esphome-glyphsets / PyPI / 0.2.0
      • pillow: ==12.3.0; pinned in requirements.txt. Check plan: vulnerability lookup: pillow / PyPI / 12.3.0
      • resvg-py: ==0.5.0; pinned in requirements.txt. Check plan: vulnerability lookup: resvg-py / PyPI / 0.5.0
      • freetype-py: ==2.5.1; pinned in requirements.txt. Check plan: vulnerability lookup: freetype-py / PyPI / 2.5.1
      • jinja2: ==3.1.6; pinned in requirements.txt. Check plan: vulnerability lookup: jinja2 / PyPI / 3.1.6
      • bleak: ==3.0.2; pinned in requirements.txt. Check plan: vulnerability lookup: bleak / PyPI / 3.0.2
      • smpclient: ==7.2.0; pinned in requirements.txt. Check plan: vulnerability lookup: smpclient / PyPI / 7.2.0
      • requests: ==2.34.2; pinned in requirements.txt. Check plan: vulnerability lookup: requests / PyPI / 2.34.2
      • py7zr: ==1.1.3; pinned in requirements.txt. Check plan: vulnerability lookup: py7zr / PyPI / 1.1.3
      • platformdirs: ==4.11.5; pinned in requirements.txt. Check plan: vulnerability lookup: platformdirs / PyPI / 4.11.5
      • ninja: ==1.13.2; pinned in requirements.txt. Check plan: vulnerability lookup: ninja / PyPI / 1.13.2
      • filelock: ==3.32.4; pinned in requirements.txt. Check plan: vulnerability lookup: filelock / PyPI / 3.32.4
    • Unpinned packages (explicit findings):
      • tzdata: >=2026.3; unpinned minimum constraint in requirements.txt. Check plan: not checkable: unpinned version range.
      • pyparsing: >=3.3.2; unpinned minimum constraint in requirements.txt (noted as required by esp-idf >= 5.0). Check plan: not checkable: unpinned version range.
      • argcomplete: >=3.7.2; unpinned minimum constraint in requirements.txt. Check plan: not checkable: unpinned version range.

  • Network Exposure and Protocol Posture (derived directly from THREAT_MODEL.md and requirements.txt):

    • Physical / Link Layer: Wi-Fi and Bluetooth Low Energy (BLE, via bleak). Node discovery via mDNS / zeroconf.
    • ESPHome Native API: Binary protocol connecting sensor node to Home Assistant. Optionally encrypted using the Noise protocol pattern NNpsk0 with a pre-shared key (PSK) binding handshake negotiation into MAC verification (THREAT_MODEL.md). Port number not stated in sources.
    • Over-the-Air (OTA) Updates: ESPHome native OTA optionally uses Noise NNpsk0 encryption. By default, when unconfigured, it runs over plaintext or is authenticated via a plaintext password (THREAT_MODEL.md).
    • Web Server Component: When enabled, provides an open HTTP API for entity observation and control. Exposes a web OTA firmware upload endpoint at /update. The web server enforces an Origin header check against the device address for browser CSRF protection, but requests omitting an Origin header (e.g. curl) bypass Origin enforcement by design (THREAT_MODEL.md). Optional HTTP basic authentication (web_server auth:) may be configured, but defaults to unauthenticated/open if unset.
    • Captive Portal: Automatically launches a fallback Wi-Fi Access Point and enables web OTA /update if network connectivity fails (THREAT_MODEL.md).
    • Messaging Protocol: MQTT client library (paho-mqtt 1.6.1) present for message broker communication; broker port and credentials not stated in sources.
    • Operating System Management: Home Assistant OS provides dual-bank OTA updates via RAUC. Remote SSH and web dashboard exposure instructions are not stated in the provided text files.
    • Default Credentials: No default password strings are specified in the files; the system threat model documents that native OTA and the web server operate open and unauthenticated by default unless the configuration author explicitly supplies credentials or encryption keys.

Downloads, External URLs, and Board Fabrication