search

fuatakgun / eufy_security

Home Assistant integration to manage Eufy Security devices as cameras, home base stations, doorbells, motion and contact sensors.
877 stars 73 forks source link

T8210 Doorbell P2P video stream stuck on PREPARING, yet video queue size increases #672

Closed Freekers closed 1 year ago

Freekers commented 1 year ago

Describe the bug

My T8210 Doorbell's P2P video stream is stuck on PREPARING, yet the video queue size increases after I press Start P2P stream. If I press stop P2P stream, the status properly reverts back to IDLE.

To reproduce

Steps to reproduce the behavior:

  1. Go to Settings
  2. Click on Eufy Security integration
  3. Scroll down to T8210 Doorbell
  4. Click start P2P Stream
  5. See status changing to PREPARING and Video Queue Size increasing
  6. Status does not change to STREAMING

Expected behavior

Status should change to STREAMING and Doorbell should display video stream via P2P.

Additional information

Hardware Information;

Additional context Other camera's, like the Eufycam 2 Pro, work fine via P2P. although sometimes I need to restart the integration because they get stuck on PREPARING as well.

david-b13 commented 1 year ago

+1

Can't get P2P stream running. Manual service call fails, as does call from within doorbell config settings in integration.

Also noticed that, while stuck in PREPARING, the video queue size is cycling round and round (1-8)....

Other cameras (2 x T8142-Z) seem to be working fine.

Eufy security app works OK too....

pdenson commented 1 year ago

+1

I have two S40 cameras that get stuck in the same StreamStatus.PREPARING state. When they get stuck in that state <camera>_video_queue_size seems to just increase indefinitely.

I am able to get the into StreamStatus.STREAMING at least once after restarting HA, but subsequent calls to that service all fail until I again restart HA.

Happy to provide my own logs if that is helpful.

Eufy Security Integration Version: 6.2.0

Beer17HWAM commented 1 year ago

Raspberry Pi4 Home Assistant 2022.12.9 (Docker) Eufy Security Add-on Version: 1.3.0 (Docker) Eufy Security Integration Version: 6.2.0 Aler9/rtsp-simple-server 0.21.1 (Docker)

T8210 Doorbell

Sometimes I have start problems. In that case it stays in Preparing. But most of the time I can start/stop and it's working fine.

Freekers commented 1 year ago

Believe it or not, but this issue resolved 'itself' for me. I didn't change anything related to the Eufy integration but as of today it's working fine for me. However, I do see the Docker container updated itself last night because of an update of the LS.IO HASS Docker Image, but I doubt it's related. I'm leaving this issue open for now, since others are facing the same problem.

Beer17HWAM commented 1 year ago

You run Home Assistant in a docker, me too. Supervised! How did you do that? Updating itself? Please tell me more about this. I have a normal docker install, no supervisor and no auto updates.

Freekers commented 1 year ago

You run Home Assistant in a docker, me too. Supervised! How did you do that? Updating itself? Please tell me more about this. I have a normal docker install, no supervisor and no auto updates.

Let's not hijack this issue and keep it short ;) I use WatchTower to automatically update Docker containers once a new image is available. Check https://containrrr.dev/watchtower/

kaystrobach commented 1 year ago

Non Doorbell cameras work fine. For the doorbell I see this in the logs of the rtsp component:

2023/01/16 15:44:17 I [-2/4] [RTSP] [conn 172.30.32.1:35652] closed
2023/01/16 15:44:17 I [-2/3] [RTSP] [session 116350731] closed
2023/01/16 15:44:17 I [-2/3] [RTSP] [session 887878503] closed
2023/01/16 15:44:18 I [-2/3] [RTSP] [conn 172.30.32.1:35662] opened
2023/01/16 15:44:18 I [-2/3] [RTSP] [session 347114469] opened by 172.30.32.1:35662
2023/01/16 15:44:18 I [-2/3] [RTSP] [session 482483183] opened by 172.30.32.1:35662
2023/01/16 15:44:18 I [-2/4] [RTSP] [session 482483183] is reading from path 'T8210P002021204C', 1 track with TCP

In the UI I get this feedback:

grafik

Freekers commented 1 year ago

Non Doorbell cameras work fine. For the doorbell I see this in the logs of the rtsp component:

2023/01/16 15:44:17 I [-2/4] [RTSP] [conn 172.30.32.1:35652] closed
2023/01/16 15:44:17 I [-2/3] [RTSP] [session 116350731] closed
2023/01/16 15:44:17 I [-2/3] [RTSP] [session 887878503] closed
2023/01/16 15:44:18 I [-2/3] [RTSP] [conn 172.30.32.1:35662] opened
2023/01/16 15:44:18 I [-2/3] [RTSP] [session 347114469] opened by 172.30.32.1:35662
2023/01/16 15:44:18 I [-2/3] [RTSP] [session 482483183] opened by 172.30.32.1:35662
2023/01/16 15:44:18 I [-2/4] [RTSP] [session 482483183] is reading from path 'T8210P002021204C', 1 track with TCP

In the UI I get this feedback:

grafik

I had this one in the past as well. Try upgrading to the latest WebRTC Beta (3.0-beta5) integration in HACS. Also, if your Doorbell streams H265, you cannot use FireFox (try Chrome/Edge etc) due to codec licensing...

kaystrobach commented 1 year ago

2.3.1 let me use 3 cameras, but no doorbell. 3.0-beta5 has errors for all cameras 😅

fuatakgun commented 1 year ago

When using new version of webrtc, use a different browser via incognito mode because custom card content is heavily cached on browser end.

kaystrobach commented 1 year ago

Will try again lateron and collect some logs again, the first try failed.

fuatakgun commented 1 year ago

https://github.com/fuatakgun/eufy_security/discussions/694

kaystrobach commented 1 year ago

I invited you, thanks a lot. The image is also visually broken.

grafik

Eufy Security Addon

2023-01-16 16:13:33.428  INFO  Connected to station T8010P2320171F23 on host 192.168.178.197 and port 12985 
2023-01-16 16:13:42.196  ERROR Message error 
 LivestreamAlreadyRunningError  Livestream for device T8210P002021204C is already running
error stack:
• message_handler.ts:231 handle
    src/lib/device/message_handler.ts:231:31
• task_queues:96 processTicksAndRejections
    node:internal/process/task_queues:96:5
• server.ts:125 receiveMessage
    src/lib/server.ts:125:21
2023-01-16 16:15:02.632  INFO  Client disconnected with ip: 172.30.32.1 port: 47340 code: 1006 reason: Abnormal Closure 
2023-01-16 16:31:09.236  INFO  Client disconnected with ip: 172.30.32.1 port: 34906 code: 1006 reason: Abnormal Closure 
2023-01-16 16:35:55.412  ERROR Message error 
 LivestreamAlreadyRunningError  Livestream for device T8210P002021204C is already running
error stack:
• message_handler.ts:231 handle
    src/lib/device/message_handler.ts:231:31
• task_queues:96 processTicksAndRejections
    node:internal/process/task_queues:96:5
• server.ts:125 receiveMessage
    src/lib/server.ts:125:21
2023-01-16 16:37:28.245  INFO  Client disconnected with ip: 172.30.32.1 port: 56466 code: 1006 reason: Abnormal Closure 
2023-01-16 16:42:35.131  ERROR Message error 
 LivestreamAlreadyRunningError  Livestream for device T8210P002021204C is already running
error stack:
• message_handler.ts:231 handle
    src/lib/device/message_handler.ts:231:31
• task_queues:96 processTicksAndRejections
    node:internal/process/task_queues:96:5
• server.ts:125 receiveMessage
    src/lib/server.ts:125:21

RTSP for version 2.3.1

2023/01/16 16:45:25 I [-7/0] [RTSP] [conn 172.30.32.1:37312] closed
2023/01/16 16:45:25 I [-7/0] [RTSP] [session 391163098] closed
2023/01/16 16:45:25 I [-7/0] [RTSP] [session 277108685] closed
2023/01/16 16:45:26 I [-7/0] [RTSP] [conn 172.30.32.1:58866] opened
2023/01/16 16:45:26 I [-7/0] [path T8210P002021204C] created
2023/01/16 16:45:26 I [-7/0] [path T8210P002021204C] runOnDemand command started
2023/01/16 16:45:30 I [-7/0] [RTSP] [conn 172.30.32.1:58874] opened
2023/01/16 16:45:34 I [-7/0] [RTSP] [conn 172.30.32.1:43730] opened
2023/01/16 16:45:36 I [-7/0] [path T8210P002021204C] runOnDemand command stopped
2023/01/16 16:45:36 I [-7/0] [path T8210P002021204C] destroyed
2023/01/16 16:45:36 I [-7/0] [RTSP] [conn 172.30.32.1:58874] ERR: source of path 'T8210P002021204C' has timed out
2023/01/16 16:45:36 I [-7/0] [RTSP] [conn 172.30.32.1:58874] closed
2023/01/16 16:45:36 I [-7/0] [RTSP] [conn 172.30.32.1:58866] ERR: source of path 'T8210P002021204C' has timed out
2023/01/16 16:45:36 I [-7/0] [RTSP] [conn 172.30.32.1:58866] closed
2023/01/16 16:45:36 I [-7/0] [RTSP] [conn 172.30.32.1:43730] ERR: source of path 'T8210P002021204C' has timed out
2023/01/16 16:45:36 I [-7/0] [RTSP] [conn 172.30.32.1:43730] closed

Will now try to use the beta 5

kaystrobach commented 1 year ago

Ok, with 3.0-beta 5 it works in chrome now (never used that browser before with HASS).

023/01/17 11:07:00 I [-7/0] [RTSP] [conn 172.30.32.1:49018] opened
2023/01/17 11:07:00 I [-7/0] [RTSP] [session 219656145] opened by 172.30.32.1:49018
2023/01/17 11:07:00 I [-6/0] [RTSP] [session 219656145] is publishing to path 'T8210P002021204C', 1 track with TCP
2023/01/17 11:07:00 I [-6/0] [RTSP] [session 527413351] opened by 172.30.32.1:49002
2023/01/17 11:07:00 I [-6/1] [RTSP] [session 527413351] is reading from path 'T8210P002021204C', 1 track with TCP
2023/01/17 11:07:00 I [-6/1] [RTSP] [conn 172.30.32.1:49002] closed
2023/01/17 11:07:00 I [-6/0] [RTSP] [session 527413351] closed
2023/01/17 11:07:00 I [-6/0] [RTSP] [conn 172.30.32.1:49034] opened
2023/01/17 11:07:00 I [-6/0] [RTSP] [session 624856661] opened by 172.30.32.1:49034
2023/01/17 11:07:00 I [-6/0] [RTSP] [conn 172.30.32.1:49036] opened
2023/01/17 11:07:00 I [-6/0] [RTSP] [session 667214595] opened by 172.30.32.1:49036
2023/01/17 11:07:00 I [-6/0] [RTSP] [session 759635651] opened by 172.30.32.1:49036
2023/01/17 11:07:00 I [-6/1] [RTSP] [session 759635651] is reading from path 'T8210P002021204C', 1 track with TCP
2023/01/17 11:07:00 I [-6/2] [RTSP] [session 624856661] is reading from path 'T8210P002021204C', 1 track with TCP
2023/01/17 11:07:00 I [-6/2] [RTSP] [conn 172.30.32.1:49044] opened
2023/01/17 11:07:00 I [-6/2] [RTSP] [session 618526239] opened by 172.30.32.1:49044
2023/01/17 11:07:00 I [-6/3] [RTSP] [session 618526239] is reading from path 'T8210P002021204C', 1 track with TCP
2023/01/17 11:07:02 I [-6/3] [RTSP] [conn 172.30.32.1:49036] closed
2023/01/17 11:07:02 I [-6/3] [RTSP] [session 667214595] closed
2023/01/17 11:07:02 I [-6/2] [RTSP] [session 759635651] closed

Will remove the shared home for now.

kaystrobach commented 1 year ago

Now firefox is complaining:

grafik

Will check fully kiosk browser later today

kaystrobach commented 1 year ago

Strange with no browser it's possible to get a valid preview image for the doorbell. so I will invite you again.

Beer17HWAM commented 1 year ago

Raspberry Pi4 Home Assistant 2022.12.9 (Docker) Eufy Security Add-on Version: 1.3.0 (Docker) Eufy Security Integration Version: 6.2.0 Aler9/rtsp-simple-server 0.21.1 (Docker)

T8210 Doorbell

Please check versions:

Raspberry Pi4 Home Assistant 2022.12.9 (Docker) Eufy Security Add-on Version: 1.3.0 (Docker) Eufy Security Integration Version: 6.2.0 Aler9/rtsp-simple-server 0.21.1 (Docker) WebRTC Camera v3.0-beta.4 T8210 Doorbell

It's working fine.

kaystrobach commented 1 year ago

Browser:

HASS:

So maybe it's a firefox problem ... but I'm pretty sure it worked before.

Hardware

The cameras are connecting slowly, but most of the time they do what I expect. The doorbell is the only device, which feels completely broken (no preview etc.)

Beer17HWAM commented 1 year ago

Aler9/rtsp-simple-server 0.21.1 (Docker) newer but that's not the problem. On Android, in home assistant app, video is playing fine with WebRTC v3.0-beta.4. Chome is not working.

kaystrobach commented 1 year ago

thanks a lot - sounds strange to me.

Freekers commented 1 year ago

Now firefox is complaining:

grafik

Will check fully kiosk browser later today

Like I said above, FireFox does not support H.265 codec: https://bugzilla.mozilla.org/show_bug.cgi?id=1332136

In the UI I get this feedback: grafik

I had this one in the past as well. Try upgrading to the latest WebRTC Beta (3.0-beta5) integration in HACS. Also, if your Doorbell streams H265, you cannot use FireFox (try Chrome/Edge etc) due to codec licensing...

kaystrobach commented 1 year ago

streaming works with the latest updates of webrtc, etc.

But the still image of the doorbell still looks ahh strange.

It looks like just one frame is caught from the camera and stored, where it needs more than one or a keyframe:

grafik

The stream looks good (pixeled by me):

grafik

PV-Web commented 1 year ago

I have the same issue with my T8210 doorbell. Or the picture is grayed with some pixels showing. Or I gto a still frame. but fluent streaming has never happened so far. Following

david-b13 commented 1 year ago

Has anyone managed to get the doorbell working ? I've gone back to a really simple couple of cards in the UI to try and debug a bit. A picture entity card (for the still image) and web-etc for any stream.... and while I seem to be able to stop and start the stream (idle -> streaming -> idle) - i can't seem to get any of it to actually show up in either card... Confused..... PS - other cameras seem to work OK. Just T8210 doorbell. PPS - HA is running on an RPI4/SSD and am using Safari on Mac to configure....

Beer17HWAM commented 1 year ago

Aler9/rtsp-simple-server 0.21.1 (Docker) newer but that's not the problem. On Android, in home assistant app, video is playing fine with WebRTC v3.0-beta.4. Chome is not working.

Like I said before, it's working fine!!

Raspberry Pi4 Home Assistant 2022.12.9 (Docker) Eufy Security Add-on Version: 1.3.0 (Docker) Eufy Security Integration Version: 6.2.0 Aler9/rtsp-simple-server 0.21.1 (Docker) WebRTC Camera v3.0.0 T8210 Doorbell

On Android, in home assistant app, video is playing fine with WebRTC v3.0.0.

I start on motion detection (with Node-Red) and grab video (10 sec) from T8210 RTSP stream and send it directly to Telegram. All without problems. I only miss the first 1-8 seconds because Motion must be detected bij HA and stream must be started.

gerardsyd commented 1 year ago

Working for me too but image is grey. Video stream is fine, can start and stop etc.

Ubuntu server Home Assistant 2023.1.7 (Docker) Eufy Security Add-on Version: 1.3.0 (Docker) Eufy Security Integration Version: 6.2.0 (HACS) Aler9/rtsp-simple-server 0.21.2 (Docker) WebRTC Camera v3.0.1 T8210 Doorbell

I'm using the conditional card per the docs.

kaystrobach commented 1 year ago

Same here.

Can you share your node red „script“?

Beer17HWAM commented 1 year ago

This is how I capture video fragments. I start this command in a bash file with a Home Assistant trigger on doorbell motion:

ffmpeg -y -i rtsp://192.168.1.8:8554/T8210P0020330C10 -c copy -map 0 -f segment -strftime 1 -segment_time 10 -reset_timestamps 1 /home/pi/ha/tmp/mpegcapture-%Y%m%d%H%M%S.mp4

At the same time a node-red flow is handling the rest. It will detect the mp4 files and send those to Telegram.

Beer17HWAM commented 1 year ago

Same here.

Can you share your node red „script“?

What part do you have questions about.

kaystrobach commented 1 year ago

I’m just starting with nodered, so I’m taking every inspiration to get better. A screenshot of the flow would be cool.

Beer17HWAM commented 1 year ago

I’m just starting with nodered, so I’m taking every inspiration to get better. A screenshot of the flow would be cool.

I mailed you.

kaystrobach commented 1 year ago

Thanks a lot - Just learned, i have a lot to learn 😅

erqz0 commented 1 year ago

After upgrading everything I've faced same issue, so after cleaning all tests made 3 months ago. Just resolved by luck by logging the Eufy app with HA dedicated account and refresh the doorbell stream from there. Dunno why but it fixes everything and T8210 now streams well from HA dashboard and stop button works as thumbnail display.

Daneish commented 1 year ago

it fixes everything and T8210 now streams well

Unfortunately that process didn’t fix it for me. My streams were still getting stuck in Preparing.

However, I did find out that I was having a port conflict between RTSP Add On and the WebRTC integration, both trying the broadcast an RTSP stream on 8554. I changed the port to 8555 in the configuration of the on the RTSP Add-on, and in the configuration of the Eufy Security integration. Now my streams are working again!

Eufy Security Add-on 1.3.0 RTSP Simple Server Add-on 0.17.6 Eufy Security integration 6.2.0 WebRTC Camera integration 3.0.2 Home Assistant 2023.2.2 Home Assistant OS 9.5

Eufy Homebase 2 T8010 Eufy Battery Wireless Doorbell 2K T8210

erqz0 commented 1 year ago

both trying the broadcast an RTSP stream on 8554. I changed the port to 8555

i'm also running on another port than 8554. might be the trick.

rwunsch commented 1 year ago

Similar / same problem?

668 Stream Status stuck on PREPARING (for me on T8200 - Wired Doorbell)

20230201_EufySecurity_Stuck-in-StreamStatus PREPARING-state

https://github.com/fuatakgun/eufy_security/issues/668#issuecomment-1412737871

Daneish commented 1 year ago

Similar / same problem?

Reading the original issue in #668 was from a RTSP native camera, which appears to stream on port 554. In retrospect my solution of changing ports in RSTP Simple Server was not applicable to #668. There are some comments, including yours that mention having issues with P2P, so perhaps this issue is more applicable.

My issue was similar to yours, just with a battery camera rather than wired. Press the Start P2P Stream, stream_status changes to StreamStaus.PREPARING, video_queue_size goes up and doesn’t stop unless it crashes or is manually stopped. I didn’t enable debug so can’t confirm the logs were the same.

In WebRTC v3 the devs enabled by default a RTSP stream broadcast on port 8554. This seems to be the same port that RSTP Simple Server uses by default, or at least it is mentioned in the README of this repository.

To test whether your issues are the same as mine, you can check if RSTP Simple Server Addon will start, or if it is blocked due to port in use.

PV-Web commented 1 year ago

Just leaving here what worked for me. As suggested change the port to something else than 8554. I used 8555 and works great. Next I had a problem with google chrome browser as this doesn't support the H265 codec. So the camera works but just not in google chrome. The android seems to work fine.

As a work around I set the video codec of the eufy doorbell to low (this uses the H264 codes which chrome supports). Next in the HA integration I set the video streaming quality of the eufy to HIGH / LOW Encoding. I then reloaded the integration and it worked.

Still hope to see a fix so that I can use the H265 codec in google chrome. but for now I'm happy that it finally works.

gerardsyd commented 1 year ago

@PV-Web thanks, are you getting the thumbnail generated?

Ascariota commented 1 year ago

Same issue I use p2p and the solution change RSTP port not compatible :(

rb0135 commented 1 year ago

Maybe a bit late, but for anyone else reading this, change on the Eufy App the video encoding format to LOW for the Doorbell device. This encodes in H264 otherwise, it encodes in H265. H265 seems to be the issue why it gets stuck in Preparing. I left my Video Quality on Auto/High. I had the same issue of the Queue either resetting after 10 times or continually growing. Looking at the logs, the video queue is rotating because the RSTP Simple Server cannot find a keyframe in the P2P stream to start creating an RSTP stream (hope that makes sense).

Took me days of trial and error and reading and stumbled across the H265 concern. Has worked flawlessly since I change to H264.

Ulli2k commented 1 year ago

Setting quality to low and restarting everything does not fix it.. ;(

kvanbiesen commented 1 year ago

I have the same problem, well its a 50/50 shot. Sometimes it work, sometimes it doesnt, just get stuck on preparing.

Normally i dont need this, but as the latest image still doesnt update for some reason, i use the snapshot feature but have of the time the stream stays stuck

fuatakgun commented 1 year ago

@kvanbiesen , do you have any data on what might be causing this?

After checking the diagram on readme about P2P, you can see that there are many components involved and I need more information what might be failing?

My general takeaways for this issue;