Streaming and Sensor Issues

[kylepyke]

Hi @twrecked!

Fantastic job with this integration. Thanks for all your work!

Over the last couple of days, I did a pretty deep dive into the resources available online for hass-aarlo, and I believe I've run out of options to get this working. I'm hoping it'll be useful to document my issues here.

System RPi 4 8gb

Home Assistant 2022.8.7 Supervisor 2022.08.3 Operating System 8.5 Frontend 20220802.0 - latest

HACS 1.26.2 Arlo Camera Support v0.7.2b8.3

Accessed through Firefox on MacOS

Arlo Wired Doorbell Firmware 1.14.0.0_1189_4e1d685

Sensors I have yet to get the motion and sound sensors working. The connectivity sensor seems to work. I haven't tested the ding sensor since it's not my biggest priority, and it calls my phone everytime it’s pushed.

I know Arlo is (was?) in the middle of changing their backend from sse to mqtt, but I've tried several combinations of config.yaml settings with both backends to no avail. The motion entity (binary_sensor.aarlo_motion_front_door) is recognized, but never triggers. Should I also have a sound entity? It doesn't appear in my entities list.

Adding the monitored_conditions: statment, and listing all of the binary sensors made each sensor visible, but unavailable in HA. Commenting out that entire clause under both binary sensor: and sensor: made the entities appear functional, although it seems only connectivity is actually reporting its state.

Streaming mpeg-dash streaming works on my laptop, but not on my iPhone. I understand this is expected since it's not a supported protocol on iOS.

Behavior with the image_view: direct (mpeg-dash) tag:

The first time I playback after a HA restart, the stream and status follow perfectly and immediately. On every consecutive playback, it works with a couple delays:

On stream start: -Items in image_top disappear. -Frame freezes for about five seconds. -Frame goes black for about five seconds. -Live stream appears.

On stream stop: -Frame immediately reverts back to screencap of last recorded video. -image_top reappears with camera status as "streaming" for about five seconds. -Camera status returns to "Idle".

Note: If I watch the camera status on my phone while playing/stopping on the laptop, it correctly follows the streaming status on the FIRST playback after restart. Every consecutive playback, the status only changes to “streaming” for a few seconds when playback is stopped before reverting to “idle”.

Behavior without the image_view: direct tag defaulting to HLS:

The first time I playback after a HA restart, the stream and status follow perfectly after a short delay. On stop, the camera status changes to “unavailable” for about six seconds before reverting back to idle.

After the first playback, the camera status changes back and forth between “idle” and “unavailable” every ~30-45 seconds, indefinitely. If I try to playback while the camera is on “idle”, it immediately plays 1-2 seconds of video from the LAST stream. Then it freezes until I hit stop.

Watching my iPhone, the camera status never changes from idle.

This behavior is the same whether or not I have the ffmpeg_arguments in config.yaml, with the exception that when the ffmpeg arguments are present, the oscillation from unavailable to idle begins before I hit stop on the stream. Every time the status flips to idle, it repeats playback of the same 1-2 seconds from the last livestream.

In the system logs, I also get the following error:

Logger: homeassistant.components.stream.stream.camera.aarlo_front_door
Source: components/stream/init.py:416 
Integration: Stream (documentation, issues) 
First occurred: 11:45:02 AM (6 occurrences) 
Last logged: 11:50:03 AM • Error from stream worker: Stream ended; no additional packets • Error from stream worker: Error opening stream (INVALIDDATA, Invalid data found when processing input) rtsps://arlostreaming3362-z2-prod.wowza.arlo.com:443/vzmodulelive/XXXXXXXXXXXXXXXXXX?egressToken=XXXXXXXXXXXXXXXXXX&userAgent=iOS&cameraId=XXXXXXXXXXXXXXXXXX&txnId=XXXXXXXXXXXXXXXXXX

I'm not sure if the sse/mqtt backend affects streaming, but I've verified the behaviors above to be the same under both variables.

Apologies for the long-winded report, and thank you again for all of your work on this integration!