homematicip_local
Copilot instructions608 starsChanged 5 months agoMITView on GitHub
This file provides GitHub Copilot with context-specific instructions for working with the Homematic(IP) Local integration for Home Assistant. Project: Homematic(IP) Local for OpenCCU Type: Home Assistant Custom Integration Language: Python 3.14+ Domain: homematicip_local Architecture: Async, event-driven, push-based state updates MANDATORY: Every Python file must start with: STRICT MODE: All code must be fully typed (mypy strict mode enabled). ALL parameters (except self/cls) must be keyword-only: Events fired by the integration: - homematic.keypress - Button press events (CLICKEVENTSCHEMA required) - homematic.impulse…
We split this copilot-instructions.md into the rules it gives an agent
20 rules. About 0 are common, 14 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈14
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
MANDATORY: Every Python file must start with:
- Distinctive: line 25
STRICT MODE: All code must be fully typed (mypy strict mode enabled).
- Very specific: line 54
Always end with a period (.)
- Distinctive: line 55
Use imperative mood for methods: "Return device" (not "Returns")
- Distinctive: line 56
Use declarative for classes: "Represents a device"
- Distinctive: line 57
Don't repeat type information already in annotations
- Very specific: line 116
Add translations to strings.json, translations/en.json, translations/de.json
- Distinctive: line 138
All new code must have tests
- Very specific: line 139
Use pytest with @pytest.mark.asyncio
- Very specific: line 140
Use existing fixtures from tests/conftest.py
- Distinctive: line 145
Before suggesting commits, ensure code passes:
- Distinctive: line 186
Before submitting a PR:
- Distinctive: line 219
When suggesting documentation updates:
- Distinctive: line 243
When reviewing code or generating suggestions:
- Distinctive: line 245
Type Safety: Ensure full type coverage (mypy strict)
- Distinctive: line 246
Docstrings: Check imperative mood, periods, no redundancy
- Very specific: line 247
Keyword-Only Args: Verify *, present in all method signatures
- Distinctive: line 248
Push vs Pull: Ensure no polling (only push-based updates)
- Very specific: line 249
Translation Coverage: Check strings.json → en.json → de.json
- Distinctive: line 251
Documentation: Update relevant docs when behavior changes
≈ “Common” is an estimate: at least 1 in 5 of the 3,669 Copilot instructions files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
GitHub Copilot Instructions for Homematic(IP) Local
This file provides GitHub Copilot with context-specific instructions for working with the Homematic(IP) Local integration for Home Assistant.
Project Context
Project: Homematic(IP) Local for OpenCCU
Type: Home Assistant Custom Integration
Language: Python 3.14+
Domain: homematicip_local
Architecture: Async, event-driven, push-based state updates
Code Generation Rules
1. Import Requirements
MANDATORY: Every Python file must start with:
from __future__ import annotations2. Type Annotations
STRICT MODE: All code must be fully typed (mypy strict mode enabled).
# ✅ CORRECT
def get_device(self, *, address: str) -> Device | None:
"""Return device by address."""
return self._devices.get(address)
# ❌ INCORRECT - Missing types
def get_device(self, address):
return self._devices.get(address)3. Keyword-Only Arguments
ALL parameters (except self/cls) must be keyword-only:
# ✅ CORRECT
def create_entity(
*, # Force keyword-only
control_unit: ControlUnit,
data_point: DataPoint,
) -> Entity:
"""Create a new entity."""4. Docstring Conventions
- Always end with a period (
.) - Use imperative mood for methods: "Return device" (not "Returns")
- Use declarative for classes: "Represents a device"
- Don't repeat type information already in annotations
# ✅ CORRECT
@property
def device_address(self) -> str:
"""Return the device address."""
# ❌ INCORRECT
@property
def device_address(self) -> str:
"""Returns the address as a string""" # Wrong tense, no period, redundant5. Import Organization
from __future__ import annotations
# 1. Standard library
import asyncio
from typing import TYPE_CHECKING
# 2. Third-party (Home Assistant)
from homeassistant.core import HomeAssistant
# 3. First-party (aiohomematic)
from aiohomematic.const import Interface
# 4. Local imports
from .const import DOMAIN
# 5. TYPE_CHECKING imports
if TYPE_CHECKING:
from aiohomematic.central import CentralUnitArchitecture Patterns
Entity Pattern
class MyEntity(AioHomematicGenericEntity[GenericDataPoint], SensorEntity):
"""Entity description."""
_attr_has_entity_name = True
_attr_should_poll = False # Always False - push-based updates only
@property
def native_value(self) -> StateType:
"""Return the current value."""
return self._data_point.valueService Pattern
- Define in
services.yamlwith schema - Implement handler in
services.py - Register with
async_register_admin_service - Add translations to
strings.json,translations/en.json,translations/de.json
Event Pattern
Events fired by the integration:
homematic.keypress- Button press events (CLICK_EVENT_SCHEMA required)homematic.impulse- Impulse eventshomematic.device_error- Error state notifications (DEVICE_ERROR_EVENT_SCHEMA required)
Critical Don'ts
❌ Never poll for state updates - use push-based updates only
❌ Never use _attr_should_poll = True
❌ Never omit type annotations
❌ Never use bare except: clauses
❌ Never create backward compatibility shims or deprecated aliases
❌ Never modify device MASTER paramsets excessively (can damage device storage)
❌ Never skip updating docstrings when changing code behavior
❌ Never forget to update translations (strings.json → en.json → de.json)
Testing Requirements
- All new code must have tests
- Use pytest with
@pytest.mark.asyncio - Use existing fixtures from
tests/conftest.py - Aim for 100% coverage on critical files
Prek Checks
Before suggesting commits, ensure code passes:
prek run --all-filesThis includes:
- ruff (linting & formatting)
- mypy (strict type checking)
- pylint (code quality)
- codespell (spell checking)
- translation validation
Pull Request Guidelines
Target Branch
- Always target:
main
Commit Message Format
<type>(<scope>): <subject>
<body>
<footer>Types: feat, fix, docs, style, refactor, test, chore
Example:
feat(climate): Add boost mode for HmIP-eTRV-2
Implements boost mode with new service and entity attributes.
Closes #123PR Checklist
Before submitting a PR:
□ All tests pass (pytest --cov=custom_components tests)
□ Prek hooks pass (prek run --all-files)
□ Type hints complete (mypy strict mode)
□ Docstrings updated
□ Translations added (strings.json, en.json, de.json)
□ Documentation updated (README.md, CLAUDE.md, docs/*.md as needed)
□ Changelog updated (changelog.md)
□ No legacy compatibility layers or deprecated codeCommon Import Aliases
import voluptuous as vol
from aiohomematic.central import CentralUnit as hmcu
from aiohomematic.client import Client as hmcl
from aiohomematic.model.custom import definition as hmed
from aiohomematic.support import support as hmsVersion Information
- Integration Version: 2.0.0
- Minimum HA Version: 2026.3.1+
- Python Target: 3.14+
- aiohomematic Version: 2026.3.1
Documentation Structure
When suggesting documentation updates:
- CLAUDE.md - AI development guide (architecture, patterns, strict rules)
- CONTRIBUTING.md - Human contributor guide
- README.md - User documentation
- docs/BEHAVIORAL_COMPATIBILITY.md - API stability guidelines
- docs/naming.md - Entity/device naming conventions
- changelog.md - Release history (update for every PR)
Key Files
| File | Purpose |
__init__.py | Integration entry point |
config_flow.py | Configuration UI & validation |
control_unit.py | Central control logic |
services.py | Service handlers |
generic_entity.py | Base entity class |
const.py | Constants & enums |
strings.json | UI strings (primary source) |
manifest.json | Integration metadata |
Code Review Focus Areas
When reviewing code or generating suggestions:
- Type Safety: Ensure full type coverage (mypy strict)
- Docstrings: Check imperative mood, periods, no redundancy
- Keyword-Only Args: Verify
*,present in all method signatures - Push vs Pull: Ensure no polling (only push-based updates)
- Translation Coverage: Check strings.json → en.json → de.json
- Test Coverage: Suggest tests for new functionality
- Documentation: Update relevant docs when behavior changes
Integration-Specific Patterns
Control Unit Access
# Access central instance
central = control_unit.central
# Access device coordinator
device = central.device_coordinator.get_device(address=address)
# Access client coordinator
has_client = central.client_coordinator.has_client(interface_id=interface_id)Event Data Transformation
# KEYPRESS/IMPULSE events need cleanup_click_event_data
event_data = cleanup_click_event_data(event_data=event_data)
if is_valid_event(event_data=event_data, schema=CLICK_EVENT_SCHEMA):
hass.bus.async_fire(event_type=trigger_type.value, event_data=event_data)Device Lookup
# Get device entry for device_id
if device_entry := self._async_get_device_entry(device_address=device_address):
device_id = device_entry.id
name = device_entry.name_by_user or device_entry.nameQuality Standards
This is a production-grade integration with:
- 100% test coverage on critical files
- Strict mypy enforcement
- Comprehensive pre-commit validation
- Full bilingual support (English/German)
- Behavioral compatibility guarantees
Match this quality bar when generating code suggestions.
For more details, see:
- CLAUDE.md - Comprehensive AI development guide
- CONTRIBUTING.md - Human contribution guidelines
- README.md - User documentation
Where files are headingNew Copilot instructions files have more rules about branches and pull requests, and fewer about code style.
Of the Copilot instructions files we read, the 2,297 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository3 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- add-deviceSkill
- add-translationSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

