openccu-loom-types
Generated Pydantic models + enum definitions for the openccu-loom
REST + WebSocket contract. Sister-repo to the
openccu-loom daemon;
publishable as openccu-loom-types on PyPI.
What this package provides
openccu_loom_types.enums— every enum from the daemon'spkg/hmenum. Each enum is astr-typed PythonEnumwhose values match the wire strings the CCU emits. Source of truth:assets/schemas/enums.jsonin the openccu-loom repo.openccu_loom_types.rest— Pydantic models for the REST surface. Generated fromassets/openapi.yamlviadatamodel-code-generator.openccu_loom_types.ws— Pydantic models for the WebSocket envelope + push payloads. Generated from the same OpenAPI document (the WS envelope schemas live incomponents.schemasper ADR-0020).
Why this exists (asks.md C1 + C3)
Higher-level clients (openccu-loom-client, the future
homematicip_local refactor) need stable typed bindings against the
daemon. Without a published types package each consumer would
duplicate the model code and drift away from the daemon's wire
contract. This package is the single import every Python consumer
shares — version-pinned and CI-rebuilt on every openccu-loom release.
Regeneration workflow
Set OPENCCU_LOOM_REPO to a local checkout of the daemon repo
(default: ../openccu-loom):
# Step 1 — make sure the daemon repo's schema export is fresh:
make -C "$OPENCCU_LOOM_REPO" export-schemas
# Step 2 — regenerate this package's models:
make generate
The two-step split keeps the daemon repo authoritative; this package never re-parses Go source.
Tooling required
- Python >= 3.11
datamodel-code-generator>= 0.25 (for REST + WS Pydantic models)
Install both with pip install -e '.[dev]'.
Versioning & contract identity
The package version (const.VERSION) is independent of the daemon
version; the regeneration workflow bumps the patch number on every
daemon release. The daemon coupling is carried by two stamped
constants in const.py (written by make generate →
scripts/stamp_const.py):
SCHEMA_DIGEST— canonical digest of the daemon's contract assets these types were generated from (definition: daemon ADR-0028). Clients compare it againstGET /api/v1/info.schema_digestto verify exact type/daemon parity at connect time.DAEMON_API_VERSION— the daemon'sapi_versionat generation time. Minor bumps add fields without breaking existing consumers; major bumps remove or rename payload fields, scopes, or capabilities — see ADR-0020 in the daemon repo.
Regeneration and release are automated end to end. The daemon's
release workflow fires a repository_dispatch (daemon-release) at
this repo, which drives this chain:
regenerate-on-daemon-releasechecks out the daemon at the released tag, regenerates all modules, stamps the constants, bumps the version, seeds a baseline changelog section, opens a PR from aregen/daemon-<tag>branch, and enables auto-merge.ciruns on the PR:Test(the suite) andRegen clean(re-runsmake generateagainst the branch's daemon tag and fails on any drift, so hand-edits to generated modules are caught).- Once the required checks are green the PR squash-merges;
tag-on-regen-mergethen pushesv<version>. - The tag triggers
release-on-tag→ GitHub Release →python-publish→ PyPI.
Manual fallback: workflow_dispatch with the tag, or the local
two-step flow above.
CI / release setup
The automation needs three one-time repository settings; without them the chain stops after step 1:
- A
RELEASE_PATsecret — a fine-grained PAT (or GitHub App token) withcontents: write+pull-requests: write. The regen PR and the release tag are pushed with it, because a branch/PR/tag created via the defaultGITHUB_TOKENdoes not trigger the downstream CI and release workflows (GitHub's recursive-workflow guard). - Branch protection on
mainrequiring theTestandRegen cleanstatus checks — auto-merge waits on these. - Allow auto-merge enabled in the repository settings.
What this package does NOT contain
- HTTP / WebSocket transport — see
openccu-loom-client(when published) for the higher-level client. - Any business logic — types only.
- Async helpers — types are framework-neutral.
Development
Parts of openccu-loom-types are developed with agentic AI assistance, primarily Claude Code. Submitted issues are likewise triaged and analysed with agentic help. Every change is still reviewed by a human maintainer and must pass the project's tests before it lands — the AI speeds up the work, it does not replace the review gate.
Contributions made with AI assistance are welcome and subject to the rules in AI_POLICY.md.
License
MIT. See LICENSE.
1 maintainer
Release files for openccu-loom-types 0.2.4
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| openccu_loom_types-0.2.4.tar.gz | 48.0 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| openccu_loom_types-0.2.4-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 94.7 kB
Release files / openccu_loom_types-0.2.4.tar.gz
| Download URL | openccu_loom_types-0.2.4.tar.gz |
|---|---|
| Size | 48.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
56df968d1f153a44c13e415269e008079f8721c47ded1de67c5a5452041b3327
|
|
BLAKE2b-256 checksum How to use checksums |
81de134ffb06985f0907975b1e5eb65fa7ce4d9281592d8794a335e36bed3926
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.13
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 31, 2026.
Transparency logRelease files / openccu_loom_types-0.2.4-py3-none-any.whl
| Download URL | openccu_loom_types-0.2.4-py3-none-any.whl |
|---|---|
| Size | 46.6 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
9ed1741200ed15437135ffd58e8f1490c9c8378ad08ac920e12360e4580e63ff
|
|
BLAKE2b-256 checksum How to use checksums |
db70f2e6f2de9147da2e578e10f9613d7dc9a194bcd841de458f1c5a21fb25f7
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.13
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 31, 2026.
Transparency log
