Open felipecrs opened 2 years ago
IMO: Taking the HA internal URL + the right port is better than using the configured Frigate URL (which will never be accessible from a browser).
... but that wouldn't work when it's NOT an addon (e.g. just another docker container, or a separate machine entirely). Given the choice between the two, I think as implemented may be a better default as it is at least behaving correct network wise (even if it's not that useful).
Ideally, the HA ingress should allow custom paths instead of only the /dashboard home. That would be better to redirect to, as it would work both internally and externally.
Yes, something like that is the real fix I suspect. This would be an issue with any addon and any use of device URL, might be something to take/discuss upstream.
There is another option, a new configuration (as the RTMP URL template seem below):
That would allow the user to set some kind of "browsable base URL". I would set as http://192.168.1.10:5000
.
Although I still believe the integration is able to detect whether the Frigate is running under the addon (by comparing it to the known addon hostnames for example), and then automatically set the "browsable base URL" as http://${ha-internal-ip}:5000
.
Here is some extra information:
_
to -
in slugs).This should cover most cases, as with the default settings of the addon, it would work.
Later improvements can be made:
If an addon match is found, first check if the Frigate UI port is forwarded (Supervisor API) since user can explicitly disable it.
If the port is not forwarded, make the URL be <home-assistant-external-url>/<addon-slug>
(no direct paths to camera can be given here, unless we implement a function in the Frigate to handle HTTP args to convert them to paths).
If the forward is enabled, check which port is the one used in host. Use that port when substituting the hostname with the Home Assistant internal IP.
Ideally, the HA ingress should allow custom paths instead of only the /dashboard home. That would be better to redirect to, as it would work both internally and externally.
Yes, something like that is the real fix I suspect. This would be an issue with any addon and any use of device URL, might be something to take/discuss upstream.
I think the ingress will transfer any http parameter (I haven't confirmed) like <ha-external-url>/ccab4aaf_frigate?goto=cameras/garden
. But Frigate would need to handle them.
Perhaps they can be handled in nginx itself?
if it stays with the addon address, please add 4601ec1a-frigate-fa
to the info text for the frigate full access version, so we can add it without looking up while adding the integration.
It seems to be possible to have URLs to specific contexts in Hass addons, see the go2rtc example:
https://
I found another "official" example, the AdGuard integration, which when configured with the Adguard Home addon makes the device url open the addon page in the HA ingress:
It seems to be possible to have URLs to specific contexts in Hass addons, see the go2rtc example:
https:///api/hassio_ingress/gDSoAWDx1fTcipX0ive4x2xaXHOGlB4COSf-ebdB0PA/webrtc.html?src=camera.rua
anyway to get this into frigate? messed around with the frigate & addon nginx options couldn't get it working.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Would it be possible to reopen this issue? It's still an issue and maybe someday someone works on it.
Version of the custom_component
v2.3
Configuration
Describe the bug
The newly added Device URLs aren't helpful when the Frigate server is an addon. See:
https://user-images.githubusercontent.com/29582865/168490289-b5e35400-cbdc-4a0d-ae33-23d0110f5c3d.mp4
IMO: Taking the HA internal URL + the right port is better than using the configured Frigate URL (which will never be accessible from a browser).
Ideally, the HA ingress should allow custom paths instead of only the /dashboard home. That would be better to redirect to, as it would work both internally and externally.
Debug log
N/A