hass protocol not working after 2024.11

[bradyemerson]

I'm no longer able to retrieve camera feeds via the hass:// protocol after updating Home Assistant to 2024.11. In this version they did significant refactoring of the Camera entity

I believe the issue is that the websocket call to exchange SDP changed from "type": "camera/web_rtc_offer" to "type": "camera/webrtc/offer".
New implementation: home-assistant/core@675ee8e#diff-1afc12e5bc3856abf6faf0dd854e4eb89e0c42de2320f910c4c97071522aa5baR202
(Edit: for some reason the deep links aren't working. File is homeassistant/components/camera/webrtc.py, line 202)

Example of the change in a test: home-assistant/core@675ee8e#diff-5d8717c7e858fd3693aa909ef8a5fb6c31aa503ae7578ceee2844e28e1428870R611
(Edit: File is tests/components/nest/test_camera.py, line 611)

I have not tested this, but I think the change would be here:

go2rtc/pkg/hass/api.go

Line 59 in 25145f7

"type": "camera/web_rtc_offer",

[felipecrs]

This is a duplicate of #1440, but #1440 is closed already.

[bradyemerson]

It looks like #1440 was closed by the user switching to the nest protocol. The comments don't appear to address the underlying error in the hass protocol.

[pissten]

So glad to have found this thread. I've searching the entire web to find the cause of this. Also experiencing that my HA nest camera streams are not available anymore, after upgrade to > 2024.11.x

Probe output:
streams: hass: wrong response

Error when watching stream:
webrtc/offer: streams: hass: wrong respons

[pissten]

Would it be possible to ask for a patch-fix for this, and a prebuilt package to download?

[pissten]

I'm no longer able to retrieve camera feeds via the hass:// protocol after updating Home Assistant to 2024.11. In this version they did significant refactoring of the Camera entity

I believe the issue is that the websocket call to exchange SDP changed from "type": "camera/web_rtc_offer" to "type": "camera/webrtc/offer". New implementation: home-assistant/core@675ee8e#diff-1afc12e5bc3856abf6faf0dd854e4eb89e0c42de2320f910c4c97071522aa5baR202 (Edit: for some reason the deep links aren't working. File is homeassistant/components/camera/webrtc.py, line 202)

Example of the change in a test: home-assistant/core@675ee8e#diff-5d8717c7e858fd3693aa909ef8a5fb6c31aa503ae7578ceee2844e28e1428870R611 (Edit: File is tests/components/nest/test_camera.py, line 611)

I have not tested this, but I think the change would be here:

go2rtc/pkg/hass/api.go

Line 59 in 25145f7

"type": "camera/web_rtc_offer",

Hi @bradyemerson ,

I just tried to apply the change on line 59 of api.go.
After creating a new custom image and recreate my docker container, i now have a different error:

"streams: SetRemoteDescription called with no ice-ufrag"

logs:

12:13:29.332 DBG [mjpeg] add consumer error="streams: SetRemoteDescription called with no ice-ufrag"
12:16:38.544 DBG [webrtc] add consumer error="streams: SetRemoteDescription called with no ice-ufrag"
12:16:38.574 TRC [streams] dial cons=1 prod=0 error="SetRemoteDescription called with no ice-ufrag"
12:16:38.574 DBG [mjpeg] add consumer error="streams: SetRemoteDescription called with no ice-ufrag"
12:16:38.492 TRC [webrtc] remote candidate="candidate:1454149214 1 udp 2113937151 29b85372-eb62-4b20-a861-2a7738e2d340.local 51946 typ host generation 0 ufrag ljE5 network-cost 999"
12:16:38.492 TRC [api] ws msg type=webrtc/candidate
12:16:38.475 TRC [streams] check cons=1 media=video, sendonly, VP8, VP9, H264, AV1
12:16:38.501 TRC [streams] dial cons=0 prod=0 error="SetRemoteDescription called with no ice-ufrag"
12:16:38.501 TRC [streams] check cons=0 media=audio, sendonly, MPEG4-GENERIC, PCMA, PCMU, L16, PCML, OPUS
12:16:38.501 TRC [streams] skip cons=0 prod=0
12:16:38.501 DBG [mp4] add consumer error="streams: SetRemoteDescription called with no ice-ufrag"
12:16:38.507 TRC [api] ws msg type=mjpeg
12:16:38.507 TRC [streams] check cons=1 media=video, sendonly, JPEG, RAW
12:16:38.530 TRC [api] ws msg type=webrtc/candidate
12:16:38.530 TRC [webrtc] remote candidate="candidate:710308951 1 udp 1677729535 85.167.51.36 51946 typ srflx raddr 0.0.0.0 rport 0 generation 0 ufrag ljE5 network-cost 999"
12:16:38.543 TRC [streams] dial cons=1 prod=0 error="SetRemoteDescription called with no ice-ufrag"
12:16:38.543 TRC [streams] check cons=1 media=audio, sendonly, OPUS/48000/2, G722/8000, PCMU/8000, PCMA/8000, L16, PCML
12:16:38.543 TRC [streams] skip cons=1 prod=0
12:16:38.544 TRC [streams] skip stop pending producer
12:16:38.574 TRC [streams] skip stop none producer

[bradyemerson]

@pissten , I'm getting the same error as well after making the change. I don't know much about rtc, but I'm trying to read up. So far I've found that the error is related to the username fragment https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidate/usernameFragment, but not sure what to do with that yet.

[bradyemerson]

The error is being generated by pion (https://github.com/pion/webrtc/blob/1ee02999eb6ce157c291fc2dbf0d43bf5c700c71/errors.go#L115), and that's referenced here

go2rtc/pkg/hass/client.go

Line 57 in 199fdd6

conf := pion.Configuration{}

, so my best guess is something needs to be changed in how pion is being instantiated or something else is needed after line 57, but that's as far as I'm going to be able to make it today.

[ac1dburnz]

Anyone got any updates? I wanted to set this up but I am running into the same issue. Going to the previous version won't work for me either. I tried to set it up from scratch and the new protocols stop you from creating new integrations.

[felipecrs]

The solution is to use nest source, no?

[bradyemerson]

@felipecrs , I don't think using the nest source is a solution. It could be considered a workaround for those accessing Nest cameras via HA, but that's presumably not 100% of the use case for the HASS source. Also the documentation directs people to use the HASS source in favor of the NEST source. https://github.com/AlexxIT/go2rtc?tab=readme-ov-file#source-nest

[felipecrs]

The documentation can be fixed to not suggest Hass source over nest.

You mentioned other use cases, but I haven't seen anyone complaining about Hass source not working for something other than nest. Did you?

[bradyemerson]

@felipecrs , to reframe your question, I think what you're asking is whether the HASS source is still needed. I don't feel like I'm knowledgeable enough in this project to answer that. I haven't been asking folks how they are using the HASS source, the thread here is just informing that a documented source is no longer working with some attempts to troubleshoot.

I don't know anything about the RTC protocol, so the progress is quite slow. I suspect for someone knowledgeable in the handshakes, the effort to get it working again isn't too bad. The alternative would be to mark the source deprecated and no longer supported for HA versions 2024.11 or later.

[felipecrs]

Yeah. For sure the issue is legit. My reasoning is that if I were affected by it, I'd move to the nest source and not look back. It does not need HA to be running, thus it should be more reliable, and that's why I think it's better.

And given there's this alternative solution, I'd say it's best to focus on some other item of the backlog.

Anyway, this is still an issue of course.

But I don't recommend anyone to wait for its resolution, and instead move to nest source.