My pleasure it works well on my system don’t forget the whitelist_external_dirs part of the setup
in the configuration.yaml in the basic information section.
whitelist_external_dirs:
- /config/www/doorbell
- /config/www/frontdoor
1 Like
@sherrell Hi, have you changed something regarding the setting mode services (alarm_control_panel.alarm_disarm / alarm_arm_night etc…) because I have an automation putting my aarlo alarm control panel in different mode at different time of the day that haven’t worked since yesterday I guess (not sure but that might be after I updated to the last version of your snapshot branch).
Actually, I tried the services directly from the dev-service panel too and they are not responsive neither.
Also, I see a alarm_control_panel.aarlo_set_mode but didn’t find any documentation in your github regarding which parameters it takes to set it up.
Let me know please when you get time 
edit. Well, weird, I just restart Hassio and it works … any ideas why?
In theory, nothing has changed! But I did merge all the updates into the snapshot branch so maybe something got mangled. Next time it happens can you try changing the mode manually and checking the logs? I improved the mode name checking to make the case insensitivity invisible to users, maybe that screwed up.
The aarlo_set_mode allows to to set any custom mode you might have created. There is one guy who has an extra mode and wanted to get at it. The parameters are entity_id - device id - and mode - name of mode in Arlo app . I’ll add some documentation for the services.
I will for sure - Actually I just activated debug for the module.
Also, regarding the long delay for the snapshot to be notify, I might have been too fast saying my setup was working flawlessly. After having received the arlo app notification on my phone, I counted how long it took for receiving the notification : about 15/17 seconds… It’s far too long for me… looking at the debug, it looks like it even closer to 20 seconds…
Let me know if you need me to investigate closer / share logs…
I need to try @vjmindlab solution as well.
I will give a try to this aarlo_set_mode service, I might be interested Thanks for the details.
hi,
I’m still experiencing the camera that stays in ‘taking snapshot’ state and an error is showing up when this occured - any thought ? :
Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/aiohttp/web_protocol.py", line 418, in start
resp = await task
File "/usr/local/lib/python3.7/site-packages/aiohttp/web_app.py", line 458, in _handle
resp = await handler(request)
File "/usr/local/lib/python3.7/site-packages/aiohttp/web_middlewares.py", line 119, in impl
return await handler(request)
File "/usr/local/lib/python3.7/site-packages/homeassistant/components/http/real_ip.py", line 33, in real_ip_middleware
return await handler(request)
File "/usr/local/lib/python3.7/site-packages/homeassistant/components/http/ban.py", line 68, in ban_middleware
return await handler(request)
File "/usr/local/lib/python3.7/site-packages/homeassistant/components/http/auth.py", line 216, in auth_middleware
return await handler(request)
File "/usr/local/lib/python3.7/site-packages/homeassistant/components/http/view.py", line 114, in handle
result = await result
File "/usr/local/lib/python3.7/site-packages/homeassistant/components/camera/__init__.py", line 475, in get
return await self.handle(request, camera)
File "/usr/local/lib/python3.7/site-packages/homeassistant/components/camera/__init__.py", line 511, in handle
return await camera.handle_async_mjpeg_stream(request)
File "/config/custom_components/aarlo/camera.py", line 163, in handle_async_mjpeg_stream
from haffmpeg import CameraMjpeg
ImportError: cannot import name 'CameraMjpeg' from 'haffmpeg' (/usr/local/lib/python3.7/site-packages/haffmpeg/__init__.py)The stuck taking snapshot is an issue I’m looking at. I tried to speed the snapshots up but forgot the case of things not working.
You’re the 3rd person to see the Mjpeg issue and right now I don’t know what’s causing it. The problem is async def handle_async_mjpeg_stream is being called, as part of the stream code I think, but the Mjpeg code has been removed so it’s falling over.
Can I ask:
- what version of HA?
- what branch of AArlo code?
- which lovelace card are you using for the cameras?
HA 0.91.0, snapshot-to-file branch and I’ve been using your custom lovelace card so far.
Hi! is custom_updater added to the latest version?
@Christian_Hollbjar Not yet. Home/work has been hectic the last couple of weeks. I’ll oook tonight.
@woodmoose I’ll do some more digging on this issue.
1 Like
@grantc @woodmoose The cameraMjpeg issue should be fixed. They moved the location of the import.
@woodmoose I just updated the snapshot branch to better handle errors and to provide a websocket call to retrieve a snapshot image. Snapshot speed is always going to be slow if you aren’t streaming when you take the snapshot.
@sherrell thanks - I’m gonna try that soon - what do you mean when you say it will always be slow if not streaming ? how can I improve it ?
(This is based on my observations and could be way off.)
If you take a snapshot while a camera is recording it is a lot faster than if the camera is idle. My theory is that the snapshot taken while recording is a frame from the stream already in the cloud. Whereas, the idle camera has to start up, take a picture, upload it to the cloud…
If you want to try this, turn on recording for motion detection and see if the image is faster.
@sherrell oh I see what you mean, but the camera are already in a mode with recording on motion… so it’s probably not the problem here…
Regarding your update with the websocket, do I need to change something in my setup and is it theoretically going to make any change in term of speed ?
edit. I’m trying your new update - I haven’t noticed any change in term of speed but the taking snapshot bug is fixed.
Also, I’ve setup hassio on a server for testing purpose (hassio installed manually in docker, ubuntu). Your streaming function is working well (when clicking on the lovelace card). I was curious then and tried the camera.play_stream service, media_player is an Apple TV 4K. When running the service, it turns on my Apple TV+TV and I can see that the arlo is on “streaming” state but I don’t any stream showing up on my screen, it just stays with the spinning loading roll… Any idea why ? (it might be because of the apple tv, not sure…)
edit/2. Quick test, the snapshot took 13 seconds to be created in my local folder on my testing server (old samsung notebook / Core i3-2365M / HDD / Wifi) and 24 seconds on my raspberry PI 3B+ (ethernet) … So definitely, the host seems partially guilty.
Also I have noticed that all my 4 arlo are on Streaming state during a few seconds when hassio is restarted ? Is it a normal behavior ?
edit/3. Arghh sorry for the multi-edit … 
Just realized something very strange - the 24 seconds snapshot (RPI) is 186ko/1980x1080 when the 13 seconds snapshot (Server i3) is 86ko/640x360 AND are not the same snapshot (it seems actually that the one on RPI is not the current snapshot but older one, I will need to investigate more though regarding this point, just did a quick test with my son.
Apple TV: I’m not sure about that one. The way it works is I just give a URL to the stream subsystem and it tells the Apple TV about it. I don’t have an Apple TV to test it on but I know it will work with a Chromecast and Google Hub. I would look in the logs, see if something died. Does it work on an iPad/iPhone? I would imagine they are similar to the TV in what they support.
Streaming state on restart: This is a ‘feature’ of the latest stream code. It does a pre-load on startup. Apparently you can turn it off per camera but I haven’t worked out how to do it. I think things like this should be opt-in. (Which reminds me, I need to work on a ‘stop streaming’ mechanism.)
The web socket’s big advantage is it returns the snapshot image to the caller so, in theory, it’s a little bit faster. It’s also a little bit easier to use because you don’t have to check for a state change you just look at a return value. The aarlo-glance card in the snapshot branch now uses it to update the snapshot - look for callWS functions in the code. I think you can get to it through Node Red but I have limited experience with that - I’m old school and prefer appDaemon.
I think with snapshot we are always going to be bound by the Arlo servers to some degree. I’ve got a couple of cameras that refuse to even take a snapshot, and even refuse to do it from the Arlo web page. There’s a chunk of code dedicated to catching failed snapshots.
Thanks Sherrell
I will need to test more regarding the Apple TV thing, I don’t have any other media_player so it’s hard to see how it will work with another device… iPad/iPhone ? Is that possible to make them a media_player ? I will look for it and let you know.
Would be great if you can find a way to fix the stop streaming thing, for now I need to restart my instance each time I’m testing the streaming service.
As for the snapshot itself, I have a bigger problem… the snapshot saved is a wrong one - actually I can see in the files properties that the file is correctly modified each time my automation is triggered BUT the image remains the same (probably last snapshot from yesterday before updating to the latest version of aarlo)… Also, why do you think there is a difference in term of file size, image dimension (cf. my edit/3 of my previous post) between my two instance of hassio (RPI vs Server i3) ?
Thanks for your great work anyway, this is very exciting to test
@sherrell: In the last couple of days I had multiple internet downtimes due to maintenance activities of my internet provider. I noticed that the aarlo component always stopped working and didn’t recover after the internet was back online. So I had to restart Home Assistant after every internet downtime for the aarlo component to work again. Is this to be expected?
@ffm777 I thought I had code in to restart but looking at it I don’t, it catches socket errors but not socket inactivity. I’ll take a look at fixing it.
@woodmoose The stream-stop should now work. There is a service and web-socket call to stop the stream. On aarlo-glance card clicking the stream will stop it.
Great, I’ll test it.
What about my problem that I have pointed out in my previous message?
I’m still looking at those! I do know you get different snap shot size depending on the state of the camera - a recording camera gives a smaller snapshot.
Do you have the logs around the time of the snapshot, if you do look for ‘streaming snapshot’ or ‘idle snapshot’. Were you running the 2 servers together? Maybe asking for a snapshot when one is already happening will cause differences.