Home IO Control
ESPHome add-on for IO-Homecontrol devices
Loading...
Searching...
No Matches
esphome::home_io_control::HubBoundEntity Class Reference

Mixin for entities bound to the hub itself rather than to one device. More...

#include <platform_entity_base.h>

Inheritance diagram for esphome::home_io_control::HubBoundEntity:
Collaboration diagram for esphome::home_io_control::HubBoundEntity:

Public Member Functions

void set_parent (IOHomeControlComponent *parent)
 Set the parent controller component.

Protected Attributes

IOHomeControlComponentparent_ {nullptr}

Detailed Description

Mixin for entities bound to the hub itself rather than to one device.

The hub-level control entities (discover button, scan-paired-devices button, arming switches, firmware-update button, 1W command/enroll buttons, pairing-result and 1W-last-command text sensors) need only a parent pointer — they act on the hub as a whole and have no device to bind to. This holds that one setter and one member so each entity does not restate it. The tuning number/select entities are deliberately not migrated: they take the parent by constructor injection and keep hub_core.h out of their header via a forward declaration, which this mixin's include of hub_internal.h would defeat.

Why every one of these is created from the home_io_control: block (or a dedicated button: entry) and never from a device-bound switch:/button: platform entry: a user-declared device-bound entry would have to dispatch on the presence of a key (io_device_id, commands:, enrollment:, …) to decide what the entity is, so an entry that merely omitted io_device_id by mistake could be misread as one of these security-sensitive hub entities instead of failing validation. Creating them from the hub block removes that failure mode: there is no shared schema for a device-bound entity and a hub entity to be confused under. This is the shared reason behind all of them; each entity's own doc adds only what is specific to it (the ADR 0021 permission-vs-arming argument, the ADR 0026 physical-interlock argument, the "2W extraction and 1W adoption are deliberately independent" note, and so on).

Definition at line 193 of file platform_entity_base.h.

Member Function Documentation

◆ set_parent()

void esphome::home_io_control::HubBoundEntity::set_parent ( IOHomeControlComponent * parent)
inline

Set the parent controller component.

Parameters
parentPointer to the IOHomeControlComponent instance.

Definition at line 197 of file platform_entity_base.h.

Member Data Documentation

◆ parent_

IOHomeControlComponent* esphome::home_io_control::HubBoundEntity::parent_ {nullptr}
protected

Definition at line 200 of file platform_entity_base.h.


The documentation for this class was generated from the following file: