Closed Freekers closed 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....
+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
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.
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.
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.
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/
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:
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:
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...
2.3.1 let me use 3 cameras, but no doorbell. 3.0-beta5 has errors for all cameras 😅
When using new version of webrtc, use a different browser via incognito mode because custom card content is heavily cached on browser end.
Will try again lateron and collect some logs again, the first try failed.
I invited you, thanks a lot. The image is also visually broken.
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
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.
Now firefox is complaining:
Will check fully kiosk browser later today
Strange with no browser it's possible to get a valid preview image for the doorbell. so I will invite you again.
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.
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.)
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.
thanks a lot - sounds strange to me.
Now firefox is complaining:
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:
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...
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:
The stream looks good (pixeled by me):
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
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....
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.
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.
Same here.
Can you share your node red „script“?
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.
Same here.
Can you share your node red „script“?
What part do you have questions about.
I’m just starting with nodered, so I’m taking every inspiration to get better. A screenshot of the flow would be cool.
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.
Thanks a lot - Just learned, i have a lot to learn 😅
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.
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
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.
Similar / same problem?
https://github.com/fuatakgun/eufy_security/issues/668#issuecomment-1412737871
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.
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.
@PV-Web thanks, are you getting the thumbnail generated?
Same issue I use p2p and the solution change RSTP port not compatible :(
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.
Setting quality to low and restarting everything does not fix it.. ;(
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
@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;
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:
Expected behavior
Status should change to STREAMING and Doorbell should display video stream via P2P.
Additional information
Hardware Information;
Camera Model: T8210 Doorbell
Live Streaming Protocol (RTSP/P2P): P2P
Debug Logs from Home Assistant (https://github.com/fuatakgun/eufy_security/discussions/624)
Logs from Eufy Security Add-on (either from Add-ons page of Home Assistant or Docker output): No log was written during this event
Would you share your device with me in case further debugging required? (Yes/No): Yes
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.