[Support]: Disabling camera through UI or MQTT doesn't disconnect Tapo camera connection in 0.16.1 #20111
Replies: 1 comment 4 replies
-
Disabling a camera in Frigate via MQTT or the UI should stop Frigate from processing that camera. You can use the MQTT topic If you are using restreaming with go2rtc, ensure that the camera's stream management in go2rtc matches your expectations, as some configurations may keep the RTSP connection alive for other clients or processes(2). There is no documented Frigate setting to explicitly force go2rtc or ffmpeg to close the stream when a camera is disabled from Frigate. Check out these potentially useful sources: Restream, MQTT, Full Reference Config Would you like a general answer based on my knowledge instead? 📚 Sources: Have another question? Just tag @inkeep. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the problem you are having
After switching the setup in Proxmox from an LXC with Docker and Frigate 0.16.0-RC1 (+ Coral) to a VM running Docker and Frigate 0.16.1 Release (+ Hailo8) I noticed, that the connection to my Tapo cameras (Tapo C212 and C410) are kept active even if the cameras are disabled through MQTT or the UI. Since the C410 is battery / solar powered, the battery drains quickly.
I first noticed this due to the battery drain (usually the camera looses about 2% overnight, now its almost empty in the morning (>50% drain). Later I noticed that the two-way-audio call function in the Tapo app is not available and when a call is initiated it says the line is busy / blocked and to try again later ("Die Leitung ist besetzt. Bitte versuchen Sie es später.").
Disabling the camera through MQTT worked with 0.16.0-RC1 without any issues. Testing with 0.16.0 RC1 through RC4 and 0.16.0 Release this works fine (when disabled no battery drain and voice call possible), starting with 0.16.1 Release the connection to Tapo doesn't seem to be disabled entirely anymore I guess...
The go2rtc log output shows a timeout for the stream of the C410 (aviary_front_sub), but both work fine when streaming to VLC through the frigate rtsp stream...
The FFprobe below is from the restream since tapo:// is not directly supported.
Any idea where this might be coming from or if this might even be a bug?
Version
0.16.1-e664cb2
What browser(s) are you using?
Firefox 142.0.1 (64-Bit)
Frigate config file
Relevant Frigate log output
Relevant go2rtc log output
2025-09-17 09:59:01.452733475 [INFO] Preparing new go2rtc config... 2025-09-17 09:59:01.809106695 [INFO] Starting go2rtc... 2025-09-17 09:59:01.897668477 09:59:01.897 INF go2rtc platform=linux/amd64 revision=fa580c5 version=1.9.9 2025-09-17 09:59:01.897672235 09:59:01.897 INF config path=/dev/shm/go2rtc.yaml 2025-09-17 09:59:01.898178859 09:59:01.898 INF [rtsp] listen addr=:8554 2025-09-17 09:59:01.898333463 09:59:01.898 INF [api] listen addr=:1984 2025-09-17 09:59:01.899043799 09:59:01.898 INF [webrtc] listen addr=:8555 2025-09-17 09:59:07.996018950 09:59:07.995 WRN [rtsp] error="streams: dial tcp 192.168.230.98:8800: i/o timeout" stream=aviary_front_sub 2025-09-17 09:59:10.774463403 [INFO] Starting go2rtc healthcheck service...
FFprobe output from your camera
Frigate stats
No response
Install method
Docker Compose
docker-compose file or Docker CLI command
Object Detector
Other
Network connection
Wired
Camera make and model
Tapo C410
Screenshots of the Frigate UI's System metrics pages
No response
Any other information that may be helpful
No response
Beta Was this translation helpful? Give feedback.
All reactions