-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Name of frigate "full access" addon in Home Assistant breaks automated restart of addon #133
Comments
This would be a pretty big breaking change, every user's frigate integration would be broken and would need to be removed and resetup. |
While true, what's the alternative? Otherwise this needs a fix sooner or later anyways. Reinstalling Frigate is not all that complex once you moved your frigate.yaml(s) aside. ;-) |
While this is true I would assume that every Frigate user can handle setting up integration again given the fact that Frigate needs some skills to get set up in the first place. Right now the add-on is not compatible with HA 2023.9 and while it works who knows if update or two down the road Supervisor will start to refuse starting the add-on at all or the ingres stops working and in my eyes that would be a bigger issue than having to set up integration again. |
The issue with resetting up the integration isn't because some users might have difficulty. It's that all changed entities, all enabled entities that are disabled by default, etc will be reversed and that may break automations if users don't remember all that was done. And regardless that's a bad user experience. There's also no confirmation that this isn't just a bug or something the supervisor can work around Frigate can already be restarted using MQTT restart topic and in the next version of the integration there will be a button as well |
If that's really the case, one can imagine a pre/postprocess that adjusts these entities when installing the new addon.
Well, the HA Core team confirmed that from their point of view this issue is to be fixed by the owner of the addon. Though, my personal opinion is that the HA Supervisor should be able to deal with multiple '-' in an addon's name. But ... who am I to judge ... it's their call.
Brilliant, thanks. Feel bad I did not consider this. ;-) Another thought: maybe time is up to consolidate "frigate" and "frigate (full access)" to just "frigate", so that this addon features the switch to gain full access... Less effort on your side as well... ;-) |
I can easily see the future that new users will not be able to install the add-on at all due to incorrect name. I need the ability to stop and start the add-on when requested due to Frigate tendency to write to share that is not ready. (from what I can tell, during the shutdown Frigate will sometimes write to already unmounted share so my solution is to stop the add-on few minutes before scheduled shutdown) |
Not sure if it is the worst ... but I saw your comment on the issue I raised with the core team (should have been with the supervisor team) and I tend to agree with it.
Indeed ... in addition I restart the addon in order to switch between different camera settings (.yamls) as frigate does not allow to disable ffmpeg streams at runtime. While this sounds a bit bad, I'd like to bring across that I really like frigate very much. Absolutely stunning, reliable and fast. Thank you! |
This is still misunderstanding the problem. The issue with different addon is that the hostname changes. Currently the frigate integration doesn't support changing the api host so the integration must be deleted and readded. That action causes everything to be reset to default. There's nothing the integration can do to "adjust to that" The only way it would work is if the frigate integration supported changing the api host in the config panel (which i believe there is an open feature request for)
Link? |
I think it still might be a misunderstanding (by @mib1185 ) of what the issue really is. I tried to comment with clarification on that issue but it is already closed. |
My bad, too quickly accepting the response :-( |
Looks like we have a fix via home-assistant/core#100070 just need to wait for 2023.9.2 to drop :) |
Well HA Core 2023.9.2 dropped few hours ago and it looks like my automatons are working again! 🎉 |
Indeed! MIne too. I removed the workaround of restarting through MQTT. Which was a bit ugly anyways and the "restart" was rather a "stop" relying on the switch in the addon's UI to "restart once crashed". Much better now |
In Home Assistant the addon will be named something like "ccab4aaf-frigate-fa". Using HA OS 2023.9
Now: if you create an automation (e.g. using the HA UI) that simply wants to restart the addon, it will fail with an error.
Same thing if you execute the restart by calling the service to restart the addon.
Side note: restarting using the Frigate addon's UI works fine.
The issue is the name of the addon. More specifically the second '-' in "ccab4aaf-frigate-fa". Home Assistant will create a slug that is "ccab4aaf_frigate-fa" by replacing the first '-' with a '_'.
The remaining '-' makes the slug invalid.
I do not know if this something to be resolved in HomeAssistant or in Frigate (full access). I did raise the issue in HA Core as well: [https://github.com//issues/133]
Update: The HA Core team declined the issue and advised to get it changed in the Frigate HASS addon.
Simplest workaround seems to be: rename the full access version of the addon to something like "ccab4aaf-frigatefa".
I'd appreciate some hint if I can somehow rename the addon in a HA instance directly. I doubt it but wanted to ask ... and am afraid of side effects
The text was updated successfully, but these errors were encountered: