homematicip_cloud: migrate binary sensors to entity descriptions#166052
homematicip_cloud: migrate binary sensors to entity descriptions#166052lackas wants to merge 1 commit intohome-assistant:devfrom
Conversation
Refactor simple binary sensor entities to use EntityDescription pattern instead of individual subclasses. This consolidates 7 entity classes (motion, presence, smoke, water, battery, rain, power mains) into a single HomematicipSimpleBinarySensor class with descriptions. Adds has_entity_name support to the base entity class and translation keys for sub-entity names (battery, rain).
|
Hey there @hahn-th, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
There was a problem hiding this comment.
Pull request overview
Refactors the homematicip_cloud integration’s simpler binary sensor entities to use the EntityDescription pattern, reducing per-entity subclass boilerplate while keeping backward compatibility for existing unique_ids.
Changes:
- Introduces
HmipBinarySensorEntityDescriptionand a genericHomematicipSimpleBinarySensorto replace several simple binary sensor subclasses. - Updates
HomematicipGenericEntity.nameto delegate to Home Assistant’s standard naming/translation machinery whenhas_entity_nameis enabled. - Adds translation strings for the new
batteryandrainbinary sensortranslation_keys.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| homeassistant/components/homematicip_cloud/strings.json | Adds entity name translations for battery and rain binary sensors. |
| homeassistant/components/homematicip_cloud/entity.py | Adjusts entity naming to support has_entity_name + translations via _name_internal. |
| homeassistant/components/homematicip_cloud/binary_sensor.py | Migrates several simple binary sensors to EntityDescriptions and adds the generic entity class + mappings. |
| if self.has_entity_name: | ||
| if not self.platform_data: | ||
| return self._name_internal(None, {}) | ||
| return self._name_internal( | ||
| self._device_class_name, | ||
| self.platform_data.platform_translations, | ||
| ) |
There was a problem hiding this comment.
Because HomematicipGenericEntity overrides Entity.name, Home Assistant will no longer use Entity’s default suggested_object_id logic (which uses object-id translations). For entities that rely on translation_key/EntityDescription (e.g. the new battery/rain sensors), this means the entity_id generated on first creation can depend on the user’s UI language (platform_translations) instead of the stable default-language object-id translations. Consider overriding suggested_object_id for this integration (at least when has_entity_name is True) to derive the object id via _name_internal(..., platform_data.object_id_platform_translations) like Entity does, so new entity_ids are language-independent.
Proposed change
RFC / prototype for @joostlek to review the approach before migrating more platforms.
Refactors simple binary sensor entities from individual subclasses to the EntityDescription pattern (following the ViCare model as suggested by Joost). This consolidates 7 entity classes into a single
HomematicipSimpleBinarySensorclass with descriptions:Converted: motion detector, presence detector, smoke detector, water detector, power mains failure, rain sensor, battery sensor
Left as legacy classes (too complex for the description pattern): cloud connection, acceleration/tilt, contact/shutter interfaces, storm (custom icon), sunshine (extra attrs), FLC lock/glass break, security groups, chamber degraded
Key design decisions (looking for feedback):
legacy_class_nameon description — preserves unique_id backward compatibility since unique_ids are currently derived from class names (HomematicipMotionDetector_DEVICEID). Is there a better approach?Base class
nameproperty —HomematicipGenericEntityoverridesEntity.namewhich prevents HA's_name_internalfrom handlingtranslation_key. For entities withhas_entity_name=True, we delegate to_name_internalexplicitly. Is this acceptable, or should we refactor the base class differently?name=Nonevstranslation_key— primary entities (motion, presence, smoke, water, power) usename=Noneon the description (entity IS the device). Sub-entities (battery, rain) usetranslation_keyfor the name suffix. Correct approach?Home name prefix — the legacy
nameproperty prepends the HmIP home name to every entity. Withhas_entity_name, this prefix disappears. Entity IDs are stable (stored in registry), but friendly names change for users with a home name set. Acceptable?All 159 existing tests pass without modifications.
Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all.To help with the load of incoming pull requests: