Opt-in, receive-only adoption of a 1W installation's controller key. More...

#include "oneway_key_adoption.h"
#include "hub_internal.h"
#include "proto_codecs.h"

Include dependency graph for oneway_key_adoption.cpp:

Namespaces
namespace	esphome
namespace	esphome::home_io_control

Detailed Description

Opt-in, receive-only adoption of a 1W installation's controller key.

A 1W device broadcasts CMD_ONEWAY_ADD_CONTROLLER (0x30) while its key-copy gesture is active, handing its network's system key to whichever controller is listening. The payload is wrapped with the public TRANSFER_KEY under an IV derived only from the sender's own node address, both of which are available to anyone in radio range — so overhearing that one frame is enough to recover the key. This file turns that into a deliberate, time-boxed, user-armed action.

This is a property of io-homecontrol, not something this project introduces. The same framing applies as to 2W key extraction (key_extraction_responder.cpp): the protocol offers no confidentiality for the key-copy gesture, so the honest response is to make the capability explicit, opt-in and loud rather than to pretend it is unavailable.

Differences from its 2W sibling, both deliberate:

Receive-only. Nothing here transmits. 2W extraction impersonates an unpaired device to make a foreign hub pair to it; this only listens for a frame a device sends of its own accord, so it cannot disturb an existing installation at all.
One adoption per arm. The window closes as soon as a key is recovered, bounding the period in which a key-bearing frame is captured and matching the single physical gesture the user performs.

The recovered key is never persisted — not to NVS, not to a Home Assistant event. It is reported once for the user to paste into their own YAML/secrets, which is ADR 0018's paste-and-reflash shape, exactly as the 2W feature does.

Definition in file oneway_key_adoption.cpp.

Namespaces

Detailed Description