Describe the bug
The 4.0.1 release ships "version": "3.6.0" in custom_components/gree/manifest.json, so HACS can never mark the update as done. Every user on 4.0.1 gets a permanent "Update available" notification that reappears after each successful update.
HACS compares the release tag against the version field of the installed manifest. Those two disagree for 4.0.1, so the update entity never clears:
"installed_commit": "4a8db99", <- already the newest code
"last_commit": "4a8db99",
"last_version": "4.0.1", <- from the release tag
"version_installed": "3.6.0" <- from manifest.json
To Reproduce
- Have the integration installed via HACS.
- Update to 4.0.1. It reports success.
- Restart Home Assistant.
- The 4.0.1 update notification is back. Repeats indefinitely.
Expected behavior
After updating to 4.0.1 the notification clears, because the manifest version matches the release tag.
Root cause
The 4.0.1 tag and release were created outside the release automation, so the manifest bump step never ran:
refs/tags/4.0.1 points at 4a8db99c7156a8b2964b39850cb266b29042abf4, a commit from 2026-05-15 whose only change is Clarify TimeOut error message in README. The release itself was published 2026-06-26.
master is currently at that same commit 4a8db99, and its manifest.json still reads 3.6.0.
release-publish.yml has not run since 2026-04-15 (3.6.0: Automated manifest.json updates). It triggers on pushes to master that touch custom_components/gree/manifest.json, and the revert never touched that file.
So the automation added in 3.6.0 (per #428) works as designed, but it is bypassed whenever a release is tagged by hand. That is exactly what happened when 4.0.1 was tagged onto the pre-4.0 commit to roll back the 4.0.0 connectivity problems.
Suggested fix
Cut a 4.0.2 through the normal release-bump workflow so the manifest and tag line up again.
One thing to watch: release-bump.yml computes the next version from the manifest's current value, which is 3.6.0. A patch bump therefore produces 3.6.1, which still sorts below the existing 4.0.1 tag and would leave everyone's notification stuck. The bump needs to land on something above 4.0.1.
It may also be worth guarding against hand-tagging in general, for example a CI check that fails when a tag does not match the manifest version at that commit. This is the fourth time the two have drifted (#363, #425, #428).
Additional context
Nothing is functionally broken. The installed code is correct and matches the 4.0.1 tag. The only symptom is the notification that will not clear, so anyone hitting this can safely press Skip in the meantime.
Platform:
- OS: Home Assistant Container
- Version: 4.0.1 (HACS)
Describe the bug
The
4.0.1release ships"version": "3.6.0"incustom_components/gree/manifest.json, so HACS can never mark the update as done. Every user on 4.0.1 gets a permanent "Update available" notification that reappears after each successful update.HACS compares the release tag against the
versionfield of the installed manifest. Those two disagree for 4.0.1, so the update entity never clears:To Reproduce
Expected behavior
After updating to 4.0.1 the notification clears, because the manifest version matches the release tag.
Root cause
The 4.0.1 tag and release were created outside the release automation, so the manifest bump step never ran:
refs/tags/4.0.1points at4a8db99c7156a8b2964b39850cb266b29042abf4, a commit from 2026-05-15 whose only change isClarify TimeOut error message in README. The release itself was published 2026-06-26.masteris currently at that same commit4a8db99, and itsmanifest.jsonstill reads3.6.0.release-publish.ymlhas not run since 2026-04-15 (3.6.0: Automated manifest.json updates). It triggers on pushes tomasterthat touchcustom_components/gree/manifest.json, and the revert never touched that file.So the automation added in 3.6.0 (per #428) works as designed, but it is bypassed whenever a release is tagged by hand. That is exactly what happened when 4.0.1 was tagged onto the pre-4.0 commit to roll back the 4.0.0 connectivity problems.
Suggested fix
Cut a 4.0.2 through the normal
release-bumpworkflow so the manifest and tag line up again.One thing to watch:
release-bump.ymlcomputes the next version from the manifest's current value, which is3.6.0. Apatchbump therefore produces3.6.1, which still sorts below the existing4.0.1tag and would leave everyone's notification stuck. The bump needs to land on something above 4.0.1.It may also be worth guarding against hand-tagging in general, for example a CI check that fails when a tag does not match the manifest version at that commit. This is the fourth time the two have drifted (#363, #425, #428).
Additional context
Nothing is functionally broken. The installed code is correct and matches the 4.0.1 tag. The only symptom is the notification that will not clear, so anyone hitting this can safely press Skip in the meantime.
Platform: