Awesome, I will try that out!
Haha, well I guess I’m a bit spoiled. I had Google Fiber prior to my new home build, it was far better than Xfinity Fiber. The upload is killing me, but it could be worse 
FYI, you might want to be careful configuring multiple amcrest entities for the same physical camera. There are some things (and more coming) that work in “optimistic mode”, meaning certain camera settings or data may only be retrieved once at startup. Or, when a service is run to change a setting, it’s assumed that the setting won’t change otherwise.
E.g., when HA starts it will determine if the camera is on (aka streaming) or not. Then if you turn it on or off, the state will update, but then it will assume it will stay that way unless the service is called again. So, if you had two amcrest entities for the same physical camera, and let’s say it was off when HA started, the state of both entities would be idle. Then if you turn it on via one of the entities, the state of that entity would change to streaming, but the other wouldn’t know that happened and the state would stay idle.
This situation will worsen with the new services being added. Well, at least, there will be more opportunities for the multiple entities to get out of sync with the physical camera.
If you’ve looked closely, you may have noticed that my custom version had the infrastructure added to run the entity in either optimistic or normal mode (i.e., periodic updating), simply by changing a constant. However, I haven’t added that feature to the standard component. At least not yet. I’ve been thinking maybe I should add that as a new, configurable feature…
EDIT: Hmm, just realized the ability to turn an amcrest camera on or off via the corresponding camera services won’t be available until 0.92. 
1 Like
Thanks for the heads up Phil. So I need to be optimistic that normality will return as a new feature. 
2 Likes
Hey, I don’t know if this is a problem with your component or my camera, but I seem to be having trouble streaming my one camera I have.
After the first time looking at the more_info side of the camera stream, it never is able to do it again. It updates the cover picture just fine, so it’s able to get that snapshot, it just cannot put together the stream after the first time…
I do seem to get a number of retrying errors and I’ve gotten “Max retries exceeded with url” and “Query failed due to error 401 Client error: Unauthorized for url: camerIP:port/cgi-bin/snapshot.cgi?channel=0”. But it would seem strange to still have the snapshot to still work (as does the motion binary sensor). If you have any direction or questions that would be awesome. I’ve already got homeassistant.custom_components.amcrest: debug running (nothings really coming up though)
I’ve seen the same 401 error. To fix this I restarted my camera, then shutdown (not restarted) HassOS. I haven’t seen the problem since. Not using the custom component yet, though.
Did you do all of that by just power cycling everything?
What version of HA are you on? Are you using my custom component, or the standard component? If the former, what version?
FYI, it’s not uncommon to sometimes see error 401 when the snapshot is being updated (which happens every 10 seconds while the thumbnail picture is shown in the frontend.) As I’ve explained previously, although snapshot commands to the camera have been serialized, sometimes the camera won’t accept a new snapshot command, even though the previous one has completed, if it comes too soon. When this happens it returns an error 401 (which, to me, is misleading.) There isn’t a whole lot that can be done about that, other than forcing a minimum time between snapshot commands. Unfortunately, I don’t know what that minimum time needs to be, and might be very model/version/network dependent. At least, this is what I’ve found through experimentation.
I reset the camera through the Amcrest web UI settings (logged in via the browser and IP address). I have HassOS installed on a virtual machine on my Windows server, I shutdown the instance in Virtualbox. I was flooded with errors before doing that.
I’m on the most recent of all of it. I’m on 0.91.4 of hassio on a pi and 1.3.1 of your custom component.
And again, the snapshot is fine. The binary sensor is fine. It is the stream that does not work unfortunately.
What version of HA are you on?
If the camera is on, and streaming (meaning the video stream output is enabled), when HA starts, it will start periodically capturing snapshots to update the thumbnail image in the frontend. If the camera video stream then stops for any reason, those snapshot commands will result in error 401 (and the underlying urllib warnings/errors.)
Could something like this be what happened?
FYI, as I think I explained somewhere, the current implementation of the amcrest component is written to function (well, except for the sensors and switches) to operate in an “optimistic” mode. That means it doesn’t periodically check the status of things. Rather, it assumes whatever it first read from the camera at startup will remain true unless it changes it itself. Therefore, it doesn’t work very well in a scenario where something else is changing the camera.
I do have on my to-do list potentially adding support to enable/disable optimistic mode. It’s actually not very difficult. The reason I haven’t done it yet is twofold: first, the standard component never worked that way, and second, there were more pressing things to fix/enhance.
Also note that I already have most of the work done to add better overall error handling to the component so when, for example, the camera goes “offline”, it won’t flood the log with errors.
Hmm, that’s not expected. I haven’t actually used my custom component version with recent HA versions myself lately since I’ve been spending most of my time trying to get all the fixes/features from that folded into the standard component. I’m getting close to achieving that, and will mostly be done when the current PR (#22949) gets approved and makes a release. At that point I think I’ve already mentioned I’ll probably stop supporting the custom component.
But since that might still take a few weeks, I’ll look into why the stream might not be working with the custom component on the latest HA release.
Yep, something like this was happening. Although, sometimes the stream would work, but not the snapshot. Have not seen restarting camera and shutting down HassOS.
Your explanation makes total sense. Very exciting to see you PR’s accepted, you’re building a fantastic component.
1 Like
Thanks! It’s actually interesting, I did a little experiment. First I updated to 1.3.2 for the component, no luck. But I also just removed stream from my configuration.yaml and I got my “real time” back.
So I discovered, in trying to support 0.92 I broke support for older versions. I just released 1.3.3, which I tested with a 0.91.4 installation. Everything seems to work now, including streaming with the stream component enabled. Give it a try and let me know how it works for you. There still may be something else going on, so by all means, let me know.
1 Like
Fixed, you’re the man!
1 Like
Well looks like I spoke a little too soon. Looks like if I leave it alone for long enough it stops working. I’ll just wait for 0.92 though and see if that fixes anything.
What again are the symptoms? Are there any related warnings/errors in the log? If something isn’t working with the custom component, the same issue might exist in the standard release, which I’d like to address sooner rather than later.
After the update to 0.92 I’m seeing the communication errors return and can’t solve them. They appear to be issues retrieving the thumbnail/snapshot for the dashboard. The stream itself loads fine.
Could not get image from Front High camera due to error: Could not communicate with camera
8:35 AM components/amcrest/camera.py (ERROR) - message first occured at 8:35 AM and shows up 3 times
Query failed due to error 401 Client Error: Unauthorized for url: http://999.999.9.9:80/cgi-bin/snapshot.cgi?channel=1
8:35 AM /usr/local/lib/python3.7/site-packages/amcrest/http.py (ERROR) - message first occured at 8:35 AM and shows up 3 times
Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ProtocolError('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))': /cgi-bin/snapshot.cgi?channel=1
8:35 AM /usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py (WARNING) - message first occured at 7:15 AM and shows up 27 timesDo you also see error message “Unable to get image” in the log?
Do you see error message “Attempt to take snaphot when Front High camera is off”?
I see that you’re using channel 1, which should mean you have resolution: low in your amcrest configuration. Is that correct? Is this Sub Stream configured properly in your camera?
FWIW, it looks like there are a lot of retries (way more than just when trying to obtain a snapshot) when it comes to communicating with this particular camera. How good is the network between the system running HA and the camera? Since the snapshot has to return much more data to HA than other basic control commands, if the network is flaky then the snapshot command would be much more susceptible to failing due to network errors.
Do you also see error message “Unable to get image” in the log?
Not seeing that.
Do you see error message “Attempt to take snaphot when Front High camera is off”?
Not sure, I’ll have to test that tonight. It’s never off.
I see that you’re using channel 1, which should mean you have resolution: low in your amcrest configuration. Is that correct? Is this Sub Stream configured properly in your camera?
Correct. Sub Stream is set to defaults, may that’s the issue? Am I meant to assign an another address on my IP range for substreams?
How good is the network between the system running HA and the camera?
My network setup is overkill. Running CAT 6E on everything and directly to each camera (two on currently) from a Edge POE+ switch. My network and equipment are far from being congested or utilized.