Is that the only error you’re seeing? What version of HA are you on? Are you using the stream component?
If you’re not using the stream component, and if stream_source is set to the default of snapshot, it’s still possible, even with the changes I made, for snapshot requests to happen too close together. (More than one should never happen at the same time, which is what used to cause many, many of these errors. But, even though they are now serialized, the camera still doesn’t like it if they come very close together, which can still happen.) If that happens you might see this error once in a while. It’s not anything to worry about. Once you switch to using the stream component (and you’re on a very recent version of HA), you shouldn’t see it anymore.
Groan… well I was close. I thought it would be a simple matter to simply change sensors to binary_sensors but it caused a configuration error, so I changed it back. Now for the first time I see that the condition is not - motion_detectors per the original component, but is now - motion_detected! That was tricky. All is well now - thanks.
IMO, probably the most sensible thing to do is to incorporate a deprecation warning in the log for amcrest sensor - then down the road, remove it. This assumes that the original motion sensing was usable enough for some people to build security systems around it. That’s the kind of thing you don’t want to terminate suddenly.
Agreed. FWIW, both the old sensor and the new binary_sensor use the exact same method for querying the camera. The only difference is the state – on/off vs true/false – and the default scan interval – 5 vs 10 secs.
I’ve never had any luck using stream_source: rtsp, and I haven’t tried to debug or fix it. And now with the new stream component, I’m not sure why that’s even still a choice (but, again, I haven’t put any effort into that path.)
I would suggest removing stream_source: rtsp from your amcrest configuration. I would also strongly suggest enabling the new stream component by making sure you have the following somewhere in your HA configuration:
stream:
That will cause HA to use the stream component, and the camera’s RTSP port, when opening the larger, streaming window (also called “more info”) when you click on the camera thumbnail in the frontend, or when you use the new camera.play_stream service.
But getting back to the snapshot error you saw, you didn’t say, do you see that a lot, or just once in a while? Also, is there anything else possibly trying to pull a snapshot from your camera (other than through HA)?
For what it’s worth, the fact that it has even tried to pull a snapshot from the camera means your credentials were accepted, otherwise you would have gotten a different error when the component was starting up.
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
