Drag0n64
commented
3 days ago Where you able to resolve? Exact same problem here.
Open bugale opened 1 week ago
Drag0n64
commented
3 days ago Where you able to resolve? Exact same problem here.
System Health details
System Information
Home Assistant Community Store
GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok GitHub API Calls Remaining | 4990 Installed Version | 1.34.0 Stage | running Available Repositories | 1390 Downloaded Repositories | 30Home Assistant Cloud
logged_in | true -- | -- subscription_expiration | July 11, 2024 at 03:00 relayer_connected | true relayer_region | eu-central-1 remote_enabled | true remote_connected | true alexa_enabled | true google_enabled | true remote_server | eu-central-1-7.ui.nabu.casa certificate_status | ready instance_id | e6f318c99a8f4ca38ff45902bee413f1 can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | okHome Assistant Supervisor
host_os | Home Assistant OS 12.4 -- | -- update_channel | stable supervisor_version | supervisor-2024.06.2 agent_version | 1.6.0 docker_version | 26.1.4 disk_total | 93.8 GB disk_used | 43.8 GB healthy | true supported | true host_connectivity | true supervisor_connectivity | true ntp_synchronized | true virtualization | kvm board | ova supervisor_api | ok version_api | ok installed_addons | Terminal & SSH (9.14.0), File editor (5.8.0), Samba share (12.3.1), Mosquitto broker (6.4.1), ESPHome (2024.6.2), Home Assistant Google Drive Backup (0.112.1), SQLite Web (4.1.2), HiSense Air Conditioners (0.3.17)Dashboards
dashboards | 7 -- | -- resources | 19 views | 8 mode | storageRecorder
oldest_recorder_run | September 21, 2022 at 10:26 -- | -- current_recorder_run | June 26, 2024 at 14:56 estimated_db_size | 17066.18 MiB database_engine | sqlite database_version | 3.44.2Xiaomi Miot Auto
component_version | 0.7.18 -- | -- can_reach_server | ok can_reach_spec | pending logged_accounts | 1 total_devices | 21Checklist
Describe the issue
Yesterday, suddenly all of the cameras stopped working for me in this integration. They do work in the official Android app.
Looking at the logs, it's possible to see:
Restarting, reinstalling, re-logging-in, and even installing and logging-in with SMS to my account on a different Home Assistant instance of a friend - they all didn't solve the issue.
To debug this, I tried taking one of the RTSP URL from my
core.config_entriesfile (e.g.rtsp://ak:<password>@52.58.161.16:554/0C11051DE41A), and it works perfectly fine both in VLC, and usingffplay -i rtsp://ak:<password>@52.58.161.16:554/0C11051DE41A -v 9 -loglevel 99. I did notice that trying the commandffplay -rtsp_transport tcp -i rtsp://ak:<password>@52.58.161.16:554/0C11051DE41A -v 9 -loglevel 99fails with a similar error:(using UDP or nothing works).
I tried adding a Generic Camera device in my Home Assistant with the RTSP URL and with its default settings, and it failed with the same error (
INVALIDDATA). Setting it explicitly to UDP though works!I tried adding
"rtsp_transport": "udp"to theGenericCamerasetup of this integration in my local copy ofcamera.py, and indeed it worked! I am not sure what changed from yesterday (is it something in all Akuvox? Something in the configuration of the cameras in our building?).Ideally, like
ffmpegthe Generic Camera could understand/auto-negotiate the transport internally and everything would work. Less ideally, this integration could do that internally and pass the correct transport toGenericCamera.Since that doesn't happen, I think a reasonable workaround would be the ability to manually choose the transport for the cameras in this integration, which I believe currently is impossible (is it?).
If this affects all of Akuvox, maybe it should just be hardcoded, but I have no way to check if that's true.
Reproduction steps
Debug logs
Diagnostics dump
No response