Oh, and as a nice side effect, since urllib3 will no longer be retrying, it also won’t be able to spam the log with warnings!
3 Likes
2 of the cameras are being accessed by Synology Surveillance Station, and 1 of the cameras is also being accessed periodically by the Amcrest app (being used as a baby monitor). At some point soon I’ll disable Synology and see if that makes a difference.
As for HA config, I removed both camera platforms and now only have the amcrest.yaml. It’s now put me in the following state:
- 1 of 4 cameras is properly showing preview snapshot via Picture Entity.
- 1 of 4 cameras is properly showing thumbnail preview circle (in screenshot below it should have a round preview image in the list on the left).
- Getting the same errors as before regarding “could not get image”, “query failed due to error 401”, and “retrying”.
- If I click on one of the broken snapshot Picture Entity cards, it starts streaming as expected after a few moments (however I try not to do this long as it appears to be freezing my HA instance…another thing to troubleshoot later).
I’ve tried lowering the snapshot quality, but that didn’t appear to make a difference. All 4 are set up identically.
Here are two screenshots of the UI issues I see in the current state. I would really just like to get back to preview snapshots working as expected. Any other ideas/suggestions?
So I’m looking into this. Again, I think it would be easy to add a service that changes the resolution setting. The question is how the rest of the system would handle that. How do you envision this working? E.g., once a stream starts it may not ask for the RTSP URL again, and that situation may be made “worse” if using preload stream. Also this won’t affect thumbnail images, which come from the snapshot command, because the snapshot resolution cannot be changed that way. No matter which resolution you pick, the snapshot will always be the resolution of the camera’s main stream. (I.e., the snapshot command does not have a substream parameter, just a channel parameter, which selects the video channel, not the substream.)
Try setting logger like this:
logger:
default: info
logs:
amcrest: debug
homeassistant.components.amcrest: debug
Then after a bit grab some log output and share that with me via PM. E.g., you might try:
grep -e '\[amcrest.*]' -e '\[homeassistant\.components\.amcrest.*]' home-assistant.log
Since I don’t know what the Synology Surveillance Station might be doing I would definitely try without that. If it’s grabbing snapshots then that will definitely be a problem. The Amcrest app probably isn’t an issue. I use that, too. It pretty much just grabs RTSP output.
I have considered making the async_camera_image method retry. It already uses a lock so that two things within HA trying to grab a snapshot shouldn’t collide, but if an external system is also grabbing snapshots, that can cause async_camera_image to fail. If it were to retry then, depending on how frequently the other system is getting snapshots, it might be able to succeed after a second or third try. BTW, the recent version of my error-handling branch should already be doing one retry the correct way, so that might solve the problem in most cases.
1 Like
That’s a good question what impact selecting video stream might have. I have no idea, but isn’t it worth testing to find out? If there were new services, such as amcrest.set_main_stream or set.secondary_stream, they could be invoked from the developer tool UI for a quick test.
The ultimate goal is to have an integrated video player that dynamically allows selection of not just the video stream, but toggles audio, provides PTZ presets and direction movement arrows. Later on, other services might be useful to control zoom, brightness, image size, IR toggle, etc. I don’t know what the road map is for the HASS video streamer, but the community will likely leverage these services to overlay option buttons on the picture elements card or some other new custom card.
My current use case for selecting stream is quite a bit simpler than this. By using presence detection to determine remote versus local access to the cameras, create an automation that selects an appropriate stream. I think you had once mentioned this might be possible to do automatically if a slow connection was detected somehow. BTW – I have removed my duplicate cameras for specifying high and low res variants and am just having to live with low quality only for now. This has indeed drastically reduced the comm errors.
As to the camera snapshot not supporting stream – yep, that’s understood. Just hardcoding the quality setting a bit lower is good enough for now.
The cameras are really responsive and update immediately when selected. There used to be some delay and the image would update only once every 5-10 seconds. Really appreciate all the time that went into investigating and optimising the component and underlying python package. With this kind of integration component for Home Assistant it would be silly to buy anything other than Amcrest cameras. Unfortunately they are definitely on the pricey side especially when living outside the US. (I’m in Australia.)
amcrest uses the dahua api as I believe they are made by dahua. If you find a dahua camera is a better price then it should work the same as it is the same api.
Thanks.
Will add this to logger and send you the info as soon as I can carve out some time to do the necessary reboots and ensure my system comes back fully (have a separate Z-wave issue where battery powered devices disappear after reboot…).
In the meantime, I just wanted to circle back and note that I may have resolved the 3 cameras with “broken” preview images in HA. I had to “reset to default” the snapshot menu and then set the interval to “2S.” The image returned for each camera I set this to. And then if I set it back to “1S,” the images continue to update every 10 seconds. Set one of them back to “1S” as a test and will see if it maintains.
As for your error-handling branch, would you still recommend installing this? Or will this come through a future HA upgrade?
FWIW, the only setting on the Snapshot page that I’ve found that can affect HA is the Quality setting. If it’s too high the camera doesn’t seem to be able to complete the snapshot command. Maybe by resetting the values the Quality setting returned to a value that works. The time setting, I think, only affects the camera’s built-in feature for recording/sending snapshots based on motion.
That’s the plan, but it depends on the core team to accept it.
I’ll test lowering the quality of my snapshots and the intervals. I am seeing thousands of snapshot errors, crashing HA on a server system, when I add more than 2 cameras. Strange behavior, see setup below.
ffmpeg:
amcrest:
host: 192.168.2.10
username: ###
password: ###
name: F_High
resolution: high
stream_source: rtsphost: 192.168.2.9
username: ###
password: ###
name: F_Low
resolution: high
stream_source: rtsphost: 192.168.2.8
username: ###
password: ###
name: R_High
resolution: high
stream_source: rtsp
If you have stream_source set to rtsp then it shouldn’t even be attempting snapshots (I think. 
)
It’s taking snapshots for a lovelace view I have setup (I think). It streams only when selected.
Yeah, you may be right. I forget.
Sorry, can’t remember who I asked and who I didn’t anymore. Are these cameras being accessed by anything besides the amcrest HA component? E.g., is there an external system, and/or another HA component, that might be trying to grab snapshots at the same time the HA amcrest component is?
Ideally I would like my Hadashboard setup to pull in screenshots/streams for different cameras. It’s not currently set to do that, but it was.
@pnbruckner
It’s for sure due to multiple snapshot requests. I’d really like to stream cameras to my hadashboard panels, but attempting this crashes HA quickly. Anyone have an alternative (this works with cheap $25 cameras, but not Amcrest)?
Sorry, but I don’t think you’ve answered the question. For a given camera, is there anything besides the HA amcrest component that is accessing it? If there is something else trying to grab snapshots at the same time, then that will cause problems. If it’s just the HA amcrest component, then it should work (and certainly should not cause HA to crash), even if you get 401 errors. Again, the 401 errors are due to retrying at the wrong level and should be fixed once the error handling enhancement is released.
Nothing but the Amcrest component accessing it (each camera is recording motion to SD card, though). The issue only seems to occur when I try to pull the Amcrest component entity to Hadashboard and view it.
Awesome! I discovered that recording to an SD card conflicts with snapshot retrieval to HA. Not sure if this was known or not. When I turned motion based recording off, I no longer received the 401 errors (no image with error) when viewing my stream in lovelace.
Recording to the SD card by itself doesn’t seem to conflict with snapshot retrieval, at least not on my cameras. One of my cameras is always constantly recording (manual recording, not motion-based recording) and snapshots work just fine. And I used to use motion detection, with recording and e-mail notifications (although I don’t anymore) and never had an issue with snapshots (at least not that I was aware of.) Now I use a different mechanism for detecting motion, and have an automation that calls the camera.snapshot service when motion is detected (whether or not the camera is recording, as long as it’s not “idle”), and that works fine, too. So not sure why you’re experiencing those problems.
With the latest PR retrying should work better than it has in the past. It’s possible this may solve the problem that you’ve experienced, if not completely, then at least somewhat. Before, if a snapshot command was received when the camera did not want to respond to it, it would cause the error 401 because the retrying was done improperly. Now it should actually retry, and if whatever was preventing the snapshot command from succeeding has finished, then the retry should actually work.
One thing I’m considering doing is to add more retrying, especially for services. Even in the latest PR, there’s only one retry. But it might make sense, at least under certain circumstances, to let it retry more. At the very least it might make it more compatible with scenarios where other things are querying the same physical camera. I have to think about this some more.
Any chance you could try the code in the PR?