I’ve closely compared the latest versions of the Dahua and Amcrest API’s, and at least from the documentation standpoint, they do appear to be identical, and lower case for the commands is required for Dahua as well.
For a direct connection to a camera, channel is not required, but if given, either channel=0 or channel=1 is OK to use for snapshots. Specifying channel=2, 3,4… fails with a error message (unless the connection was to an NVR with mupltiple cameras). Specifying a capitalized “Channel=” anything, is just ignored so it is the same thing as not specifying a channel at all.
For RTSP, channel 0 is not supported for either a direct camera connection or NVR.
For the past 2 years or so, Dahua firmware (and probably Amcrest as well) started requiring Digest authentication, replacing Basic. So issues like @Melkor82 reported are maybe be due to older firmware? Or maybe the Amcrest authentication code first tries Basic Auth for backward compatibility and if it gets back an HTTP 401 Basic Realm error, it then tries Digest Auth?
I conducted these tests on both Amcrest and Dahua cameras, all updated with mid 2017 vintage firmware.
I just bought a very new IPC-HFW1831C-PIR, guess the firmware is pretty new. I got V2.800.0000002.0.R, Build Date: 2019-01-11
by quering the camera settings.
Now i get it to work with the generic camera. I can confirm that digest auth is required since the basic was not working.
this is my settings
The error shown (for a snapshot) really has nothing to do with authorization. As I said above, if the credentials weren’t accepted, it would never have gotten that far. In my experience (with my two different Amcrest cameras), if two snapshot requests come too close together (even if they don’t overlap in time), it often results in that error, no matter how misleading. (It should probably be returning a status of 200, but with an error message. Oh well.)
The amcrest package will attempt using Basic Authentication, and if that fails it will then try Digest Authentication. And if that doesn’t work you’ll get a LoginError.
It doesn’t really matter to me personally if you use the generic camera or amcrest camera platform. If it’s working for you with this new configuration, then that’s great.
But you are kind of leaving us hanging here. What works and what doesn’t work when using the amcrest platform? Does nothing work? Do you get errors over and over again? Just the one type or others, too? Or do you just get the error you showed every once in a while but things generally work ok anyway? And if you enable the new stream component, do those errors go away?
If there’s really a problem, but it works mostly and there’s something simple I can do to make it work better for you, I’m happy to do that. But you’re not providing the details I’ve asked for. On the other hand, if you no longer want help with that, then please say so.
Sorry I implemented this generic camera just to confirm @GaryOkie theory that possibly is the auth fault, since my url with basic auth are not working, only digest ones does. I am really looking forward in trying to help to get this component to work for dahua users too because setting things up with command line switches is a pain in the a**
Nothing works, i got this error
Trying again due to error 401 Client Error: Unauthorized for url: http://192.168.1.51:80/cgi-bin/snapshot.cgi?channel=0
what i’ve tried is to pass this link directly from my browser and as already stated is not even working because of Case sentiveness. But i think this is an auth fail problem.
P.s.I forgot to say that stream: is already enabled and this is my configuration right now
As I think I’ve already stated, if you’re getting to the point where it’s sending the snapshot command (probably for the thumbnail picture in the frontend), then it’s not a credentials problem. It would have failed earlier with a different error if that was the case. Also, if you only see this error once in a while, that’s also not unexpected. If you see it many, many times, then that’s another story.
Then after HA is running a bit, search home-assistant.log for “amcrest” and see what you get. This should give you a better idea of what’s really happening.
Also, it’s still not clear to me – are you using the standard HA amcrest component, or are you using my custom version of it (i.e., copied into the custom_components folder)?
Just a quick update on the status of the amcrest component…
I believe I mentioned before PR #22418 which added support for the turn_on & turn_off services. This PR was accepted and will hopefully make the 0.92 beta. Note that this is considered a breaking change because it removes a few “static” sensor attributes that should not exist in the entity.
I also submitted PR #22703 which added a new motion_detected binary_sensor (and deprecated the motion_dectector sensor.) This PR has also been accepted and will hopefully make the 0.92 beta.
And I just submitted PR #22949 which adds several new camera services and associated attributes. It also deprecates the switches.
If/when these PRs are accepted and make a release I will stop supporting my custom version of the amcrest component.
Note that I do have a list of other fixes/enhancements to the amcrest component I plan to work on, but I probably won’t bother posting about them to this forum. Feel free to ask, though, if you’re interested.
Hopefully we see the PR’s accepted soon, the current HA component is totally broken. Running 5 IP8M-2493EB on the latest firmware. Very interested in what other enhancements you’re working on.
What HA version are you on and when was the last time you tried the amcrest component with your cameras? The changes made in 0.90 & 0.91 should have fixed some of the more pressing issues and it should at least work now, especially if you use the new stream component with it. If you’ve tried 0.91 and are still having issues, I’d like to know what they are. Have you filed a github issue?
Regarding future changes:
Looks like 22418 & 22703 made it into the 0.92 beta.
I’m still working on 22949. It took about a week before it was reviewed, and there were extensive requests for changes. I’ve finished most of those changes and still have one to complete. Then we’ll see if I completed them satisfactorily. I’m sure this won’t see the light of day until at least 0.93.
The to-do list is briefly:
Change implementation of sdcard sensor so it only sends one command to camera instead of four. (Already done and ready for PR.)
Significantly improve error handling, especially when camera goes “offline”, so log isn’t flooded with errors (Mostly done.)
Fix scan_interval (if possible. See architecture issue #194. Unfortunately I’ve received no responses yet.)
Implement shutdown/reboot command(s.)
Add ability to play audio on camera.
At some point remove deprecated sensors and switches, and fix improper attribute names. This, of course, will be a breaking change.
Also there have been some requests (with offers of help) to somehow add support for Amcrest NVRs.
Went ahead and updated everything. I’m now able to view all cameras without a hiccup locally, but due to ISP limitations (1gbps down/50mbps up) I can’t stream them off-site in full res. If I have resolution set to default, will it attempt to stream full 4k (currently main stream on cameras) or cap at 1080P?
I read through the GIT comments, they seem very picky about things. Thank you for taking the time to update this component, excited to see the changes in HA!
The original documentation for the Amcrest component which refers to specific resolutions for High and Low is undoubtedly out of date.
From what I have experienced, this component (both the official and Phil’s custom version) will attempt to stream at whatever resolution/frame rate you have your camera’s main stream configured to by default. I’m not aware of any cap’s or dynamic adjustments.
If you configure your camera’s secondary stream to H264 with a lower resolution/frame rate you can select it via the Amcrest component’s resolution: low to help with your off-site streaming.
This seems to work as you described. It would be nice to have some sort of logic that automatically displays the lower res stream when viewing remotely (I’m using the Nabu Casa implementation) and the high res stream when viewing locally. I suppose adding the camera twice might accomplish this.
I only ask because I’ve implemented 6 wall tablets around my house (via HAdashboard). I’ve created a camera menu to stream any camera to any requesting tablet. I’d prefer a higher res stream locally, and a low res stream remotely.
Yep, that’s what I needed to do - create multiple cameras - an HD and SD version for each camera for local or offsite.
I did have to chuckle at your ISP “limitations”. My remote HA location has a 1mbit upload “broadband speed” (recently doubled from .5). So having a limited ISP that is 50x faster must be nice
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.
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.
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.
