Or write your own automations so you understand how they work and can fix them yourself.
1 Like
Iām seeing the following in my supervisor logs since updating to 2022.4.4
22-04-15 17:31:42 ERROR (MainThread) [supervisor.store.git] Can't update https://github.com/home-assistant/addons repo: Cmd('git') failed due to: exit code(128)
cmdline: git fetch -v --update-shallow --depth=1 origin
stderr: 'fatal: Could not read from remote repository.'.
22-04-15 17:31:42 INFO (MainThread) [supervisor.resolution.module] Create new issue IssueType.CORRUPT_REPOSITORY - ContextType.STORE / core
22-04-15 17:31:42 INFO (MainThread) [supervisor.resolution.module] Create new suggestion SuggestionType.EXECUTE_RESET - ContextType.STORE / core
and additionally
22-04-15 17:26:14 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished name='Task-166' coro=<Repository.update() done, defined at /usr/src/supervisor/supervisor/store/repository.py:106> exception=StoreGitError()>
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/store/git.py", line 155, in pull
await self.sys_run_in_executor(
File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/local/lib/python3.9/site-packages/git/remote.py", line 886, in fetch
res = self._get_fetch_info_from_stderr(proc, progress,
File "/usr/local/lib/python3.9/site-packages/git/remote.py", line 750, in _get_fetch_info_from_stderr
proc.wait(stderr=stderr_text)
File "/usr/local/lib/python3.9/site-packages/git/cmd.py", line 502, in wait
raise GitCommandError(remove_password_if_present(self.args), status, errstr)
git.exc.GitCommandError: Cmd('git') failed due to: exit code(128)
cmdline: git fetch -v --update-shallow --depth=1 origin
stderr: 'fatal: protocol error: bad pack header'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/store/repository.py", line 110, in update
await self.git.pull()
File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 108, in wrapper
raise err
File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 106, in wrapper
return await self._method(*args, **kwargs)
File "/usr/src/supervisor/supervisor/store/git.py", line 195, in pull
raise StoreGitError() from err
supervisor.exceptions.StoreGitError
After I updated, all the installed community add-ons I have in my system lost their icons and no additional community add-ons were available in the store UI. I have added the community add-on repo url to the additional repositories list as a work around. Wondering if anyone else is seeing this?
1 Like
What version of Supervisor are you on?
supervisor-2022.04.0
You can join the beta program and install 2022.04.2 which should fix this. Or wait for the stable release.
I have no issues with the beta.
ok thanks will give it a go and report back
ok yeah seems to be behaving on the beta version. So potentially not 2022.4.4 related and instead a know issue with supervisor-2022.04.0 that has a fix ready to come down the pipe. Thanks @tom_l
22-04-15 17:50:20 INFO (MainThread) [supervisor.store.git] Update add-on https://github.com/home-assistant/addons repository
22-04-15 17:50:20 INFO (MainThread) [supervisor.store.git] Update add-on https://github.com/hassio-addons/repository repository
22-04-15 17:50:31 INFO (MainThread) [supervisor.store] Loading add-ons from store: 62 all - 0 new - 0 remove
22-04-15 17:50:31 INFO (MainThread) [supervisor.store] Loading add-ons from store: 62 all - 0 new - 0 remove
1 Like
I am not going to assume on @jdggitās part, but for my sake, I am never going to be able to replicate the complexity that some of these controller blueprints are containing (or what ControllerX is capable off). And with that said, I also rather want to spend my restricted time, building things that havenāt been built before, instead of reinventing the wheel.
That of course invalidates my ability to complain, but I still think it should have been listed as a breaking change (at least after attention was raised on the matter through Github), so people who read the release notes wouldnāt be surprised.
But in order to help we need to see the event logs as I requested before.
As I have understood itās not a breaking change itās a bug.
But as the bug is so devastating for many it perhaps should have been added in the release notes when it was noted.
There is really nothing to help with, as I donāt think it is a bug, itās just a change where adjustments to associated automations needs to be performed.
Intended (or unintended) the args that were passed with some controller presses was changed with 2022.4.0.
For instance for the Hue Dimmer switch, it was the up, down and off button that changed. So the automation was listening for X, but now Y gets passed, therefore the automation stops to trigger for those 3 buttons.
It is this change (that I would call breaking) that could have been listed, as soon as it was known about (has been reported on GitHub).
The solution is then to change the automations to start listening for Y instead. And multiple blueprints (and ControllerX) has been modified to account for this change.
And I just want to add that I love HA and the people who spent vast time on making Home Automation easy for me. Which is why I am not complaining, just suggesting the above gets added as a breaking change.
2 Likes
Yet again. If you want it to listen for Y then post what Y is by going to the developer tools ā events and listen to what Y is and we can help you change the blueprint/automation to listen for Y.
1 Like
Thank you for the offer, but itās already fixed. Iām only interested in that the change is documented in the release notes so the next guy wonāt be surprised.
1 Like
Is this new? Iāve never noticed it before.
Either way, surely some mistake?
What are you referring to? The toasts (notifications) appearing at the bottom of the screen informing you about the startup process? They have been in there quite some time now.
1 Like
The notification is new 
The message has probably been there for at least last year of versions I believe
No, the reference to hassio.
I could be wrong but Iām sure it used to say āHome Assistantā
And yeah I have seen the toasts before
yep same here on supervised install debian 11
yeah it says hassio instead of Home Assistant(?) Also noticed itā¦
Iāve just updated to 2022.4.4.
Has the behaviour of binary sensors (secretly ) changed since the first release notes were issued?
I took some notes affecting my setup on the release day of 2022.4.1 and I made a note that there was a new setting to have binary sensors persist their state across restarts. It seems now that under certain circumstances this is automatic.
Iām not complaining because the ānewā way is better, but surely some kind of update should have been made in the release notes?