feat: implement scene triggers using device automation and bump versi…#333
Open
oleost wants to merge 28 commits into
Open
feat: implement scene triggers using device automation and bump versi…#333oleost wants to merge 28 commits into
oleost wants to merge 28 commits into
Conversation
Author
|
Hold with pull for now, trying to also implement to get history support. |
Author
|
Believe it works now, if anyone else wants to test also |
…ene activations - Check packet.retain flag in message handler and skip retained set commands - Clear retained SET messages for scenes during discovery (matching existing behavior for output devices) - Bump version to 0.19.6 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ches HA publishes commands with retain=true because the discovery config payload includes retain:true. The previous fix incorrectly blocked ALL retained SET commands, including normal light/switch control commands from HA. Now only scene SET commands are blocked when retain flag is set. Bump version to 0.19.7 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Author
|
Fixed a issue with "ghost" activation of scenes, which I also had when manually picking up the events. Hopefully its fixed now. |
…plejd Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…+ rap HA publishes the scene activate command with retain=true (scene discovery had retain:true). With the subscription using rap:true, that retained flag is preserved even on live delivery, so every "Activate" press arrived with packet.retain=true and was dropped by the retained-SET guard - the scene never executed (only the faked event was sent back to HA). Set retain:false on scene commands so activations are momentary and pass the guard. The guard now only blocks genuinely stale retained messages. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- config.json/repository.json url now point to oleost/hassio-plejd so Home Assistant fetches docs and updates from this fork instead of upstream. - CHANGELOG.md now documents the fork's scene releases (0.19.2, 0.19.8, 0.19.9) so the changes show up in the Home Assistant add-on page. - Bump version to 0.19.9. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…e image The pinned base image (ghcr.io/hassio-addons/base 18.2.0) ships musl-1.2.5-r10 while the Alpine v3.22 repo now has r12. musl-dev requires the exact musl version, so apk aborted with "musl breaks musl-dev" when installing the build dependencies, failing every image build (not specific to any code change). Upgrade musl/musl-utils before installing build deps so versions match again, without bumping the whole base image (avoids s6/runtime layout changes). Also point the Docker image labels (maintainer, usage, vcs-url) to the fork. Bump version to 0.19.10. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
0.19.10's targeted `apk upgrade musl musl-utils` was a no-op because the base image pins musl to an exact version in its world dependencies, so the "musl breaks musl-dev" build failure persisted. `apk upgrade --available` resets the versioned world pins and upgrades all base packages to the current Alpine v3.22 repo (incl. musl r12), resolving the conflict. Stays on base image 18.2.0 (no Alpine/Node jump). Bump to 0.19.11. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
No apk workaround could move musl off the version the old base image (18.2.0) holds, so the "musl breaks musl-dev" build failure persisted across 0.19.10/11. Bump the base image to 21.0.0 (Alpine 3.24), which is internally consistent, and drop the apk upgrade workaround. The hassio-addons base no longer publishes armhf/armv7/i386 (v19+), so drop those archs; the add-on now targets aarch64 and amd64. Bump to 0.19.12. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Collapses the 0.19.8-0.19.12 development churn (scene activation fix plus the musl/base-image build-fix iterations) into a single, coherent 0.20.0 changelog entry describing the fork's delta from upstream 0.19.0. No functional change vs 0.19.12. Minor bump reflects the dropped 32-bit architectures. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a GitHub Actions workflow that builds the aarch64/amd64 add-on images with
home-assistant/builder. On a published release it pushes the images to
ghcr.io/oleost/{arch}-hassio-plejd (tagged with the config.json version);
pull requests and master pushes run a build-only --test check.
config.json now sets "image" so Home Assistant pulls the pre-built image
instead of building locally, avoiding local build failures (e.g. the base-image
musl issue) and speeding up installs/updates. Bump to 0.21.0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
home-assistant/builder@2026.06.0 failed with "manifest unknown" because the
ghcr.io/home-assistant/{arch}-builder:2026.06.0 docker image does not exist for
that action tag. 2026.03.2 has published builder images for both arches.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The legacy home-assistant/builder@<tag> with --target failed: first the builder docker image for the action tag was missing (manifest unknown), then it could not locate config.json (/tmp/build_config). Switch to the modern home-assistant/builder/actions/build-image composite action, which builds the Dockerfile directly with buildx. Base image is passed per-arch via BUILD_FROM build-args. Cosign signing disabled for simplicity. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
build-image builds for the runner's native platform and does not set --platform,
so the aarch64 job on an amd64 runner failed to resolve the arm64-only base
image ("no match for platform in manifest"). Build aarch64 on a native arm64
runner (ubuntu-24.04-arm) and amd64 on ubuntu-24.04.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Replace the original author's "Buy me a coffee" link and the upstream Gitter badge with a clear Credits section attributing Marcus Westin (icanos) and ha-plejd. Apache-2.0 license and copyright are retained unchanged. - Point install/release URLs at the oleost fork; drop the non-existent develop branch references (contribute via master). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Move install/requirements/tested-on to the repo README (discover & install) and keep configuration/usage/troubleshooting in the add-on README. Relocate the startup-error note into Troubleshooting, merge voice/HomeKit, and fix a couple of typos. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Compute image tags in a step so beta images (workflow_dispatch or pre-release) are pushed with just their version tag, leaving :latest pointing at the last stable release. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A thin second add-on (slug plejd_beta) in the same repo that points at the pre-built beta image tag on GHCR. Lets testers install the beta from the existing Add-on Store repository URL instead of copying files manually. Ships no code of its own; bump its version to publish a new beta. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Runbook for supporting new Plejd hardware: distinguishes the simple recognition-layer mapping (PlejdApi._getDeviceType) from the deep protocol path (new BLE command codes + HA entity type), with file map, testing and beta-release steps. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Link the community BLE reverse-engineering docs (icanos icanos#163, klali/ha-plejd) and capture concrete byte-layout facts (command codes, special device ids, 2-byte LE dim, button mapping, on-demand light-level state read) for deep-path device work. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Trying to fix issue #320
Please verify my commits, did them using AI to help, so how sane the code is must be checked. But its working for me.
If jcarli would like to test?