M1 Beta: Decide ESP firmware platform

[mastertape]

Roadmap reference: docs/roadmap/m1-dhl-retrofit-beta.md

Choose the firmware base for the first standalone ESP-based DHL parcel box retrofit prototype.

Options to compare:

• Arduino Core for ESP32
• ESP-IDF
• ESPHome
• mostly custom firmware stack
• hybrid approaches, such as ESP-IDF with selected Arduino libraries or an ESPHome-inspired configuration layer

Acceptance criteria:

• Wiegand input handling is evaluated.
• NFC and optional fingerprint module support are evaluated.
• Local web interface feasibility is evaluated.
• Local storage for users, credentials and logs is evaluated.
• MQTT support is evaluated.
• OTA support is evaluated.
• Offline-first behavior is evaluated.
• Security and update model are considered.
• Long-term maintainability for open-source contributors is considered.
• Future OpenParcelBridge integration is considered.
• The decision avoids unnecessary dependency on Home Assistant or any vendor ecosystem.
• A documented recommendation is added to the roadmap or an ADR.

[mastertape]

Progress update:

The firmware platform discussion has been expanded through external research/brainstorming. Current working direction, not yet a final decision:

• ESP32-C6 remains the preferred strategic target because of the future Thread/Matter/802.15.4 path.
• AP-mode setup and an embedded local web management interface should be treated as mandatory for standalone devices.
• Authoritative access-control logic should not live in ESPHome YAML.
• A promising architecture is to keep OpenParcelBox access-control logic as a framework-independent C++ core, then evaluate ESP-IDF reference firmware and optional ESPHome/custom-component integration paths around it.
• ESPHome remains strategically interesting for OTA, Home Assistant integration, sensors and community reach, but likely as an optional integration/build path rather than the only firmware base.

This issue should stay open until a real ADR is written.

Suggested next step:

• create an ADR for "Firmware architecture direction for M1"
• compare ESP-IDF, PlatformIO/Arduino and ESPHome custom-component approaches against the mandatory standalone web/AP requirement, Wiegand/NFC input, local storage, OTA, MQTT and future rolling-code needs

[mastertape]

Progress update:

Remote-command and key-delegation requirements are now documented and should be considered in the firmware platform ADR:

• docs/access-control/keyring-model.md
• docs/security/remote-command-security.md

Firmware platform evaluation must account for:

• framework-independent access-control core
• stable local actor/key/credential IDs
• scoped integration keys generated from local admin/master authority
• HMAC/signature-style rotating command authorization
• replay protection with request IDs/nonces and time windows
• remote unlock disabled by default
• no direct external control of the lock output
• AP-mode/local web management as a mandatory standalone path

This makes the ESPHome-vs-ESP-IDF question sharper: ESPHome may be useful as integration/OTA/sensor framework, but authoritative key and command validation needs an auditable core component.