go2rtc icon indicating copy to clipboard operation
go2rtc copied to clipboard

hass protocol not working after 2024.11

Open bradyemerson opened this issue 1 year ago • 2 comments

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: https://github.com/home-assistant/core/commit/675ee8e813c1da3046d1b688180d61873558501d#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: https://github.com/home-assistant/core/commit/675ee8e813c1da3046d1b688180d61873558501d#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: https://github.com/AlexxIT/go2rtc/blob/25145f72e56560666e6718740442d16a8c5127bb/pkg/hass/api.go#L59

bradyemerson avatar Nov 20 '24 05:11 bradyemerson

This is a duplicate of https://github.com/AlexxIT/go2rtc/issues/1440, but https://github.com/AlexxIT/go2rtc/issues/1440 is closed already.

felipecrs avatar Nov 26 '24 20:11 felipecrs

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.

bradyemerson avatar Nov 26 '24 23:11 bradyemerson

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 avatar Dec 13 '24 20:12 pissten

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

pissten avatar Dec 21 '24 08:12 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:

https://github.com/AlexxIT/go2rtc/blob/25145f72e56560666e6718740442d16a8c5127bb/pkg/hass/api.go#L59

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

pissten avatar Dec 25 '24 12:12 pissten

@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 avatar Jan 03 '25 19:01 bradyemerson

The error is being generated by pion (https://github.com/pion/webrtc/blob/1ee02999eb6ce157c291fc2dbf0d43bf5c700c71/errors.go#L115), and that's referenced here https://github.com/AlexxIT/go2rtc/blob/199fdd6728eb932d3a34e5cebdfc00326a44ced8/pkg/hass/client.go#L57, 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.

bradyemerson avatar Jan 03 '25 19:01 bradyemerson

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.

ac1dburnz avatar Feb 06 '25 00:02 ac1dburnz

The solution is to use nest source, no?

felipecrs avatar Feb 06 '25 00:02 felipecrs

@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

bradyemerson avatar Feb 08 '25 07:02 bradyemerson

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?

felipecrs avatar Feb 08 '25 14:02 felipecrs

@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.

bradyemerson avatar Feb 08 '25 19:02 bradyemerson

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.

felipecrs avatar Feb 08 '25 22:02 felipecrs

HASS source is not working with other devices also(HA Core 2025.2.1) Would use the NEST source but i have no idea where to find parameters. They seem hard to find, even though the readme says "if you can somehow get the below parameters"

Can someone help with this?

Matuuu96 avatar Feb 10 '25 17:02 Matuuu96

HASS source is not working with other devices also(HA Core 2025.2.1)

What other devices?

felipecrs avatar Feb 10 '25 18:02 felipecrs

HASS source is not working with other devices also(HA Core 2025.2.1)

What other devices?

My IMOU IP cam for example.

Matuuu96 avatar Feb 10 '25 20:02 Matuuu96

Are you sure it was working before? For such device I believe you need my integration:

https://github.com/felipecrs/hass-expose-camera-stream-source

felipecrs avatar Feb 10 '25 20:02 felipecrs

Im not, i tried it after i tried with Nest Doorbell cam. Can u help me with Nest intregration?

Matuuu96 avatar Feb 11 '25 16:02 Matuuu96

More details on how to get credentials for Nest can be found here.

felipecrs avatar Feb 11 '25 16:02 felipecrs

HASS protocol still not working? Any updates?

Matuuu96 avatar Mar 14 '25 21:03 Matuuu96

BTW @dairefinn wrote good instructions on how to make nest protocol work here https://github.com/AlexxIT/go2rtc/pull/1628.

felipecrs avatar Mar 14 '25 21:03 felipecrs