What the firmware version with which the button press event is working? I can then try the same version...
I am attempting to install this app and connect to my Dahua NVR (I have 7 cameras on the NVR). I'm getting the following error when I try to install the app and initialize the login.
app:1492023-12-04 06:55:34.246 AMdebugdevs to create = null
app:1492023-12-04 06:55:29.942 AMdebugdiscovered devs = [:]
app:1492023-12-04 06:55:29.928 AMerrordiscovery failed: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I disabled HTTPS, and now am able to login without issue. Is there a tip/trick to using this with HTTPS (or at least allowing HTTPS to still be enabled on my NVR)?
Also, I have noticed (now that I got past the issue above by disabling HTTPS) - that I have my NVR setup in NAT mode, and with this mode - Hubitat can not seem to reach the cameras. Is it safe to assume that for this app to work, I need to setup my NVR in passthrough mode?
I'm sending you a PM to discuss options on the HTTPS issue.
With that said, the camera driver does indeed require a direct connection between each camera and Hubitat. So unfortunately a NAT in between will not work.
Hi All @tomw
I just found this app and was hoping to use the AI portion of my AD410 to notify me when I had a human detection. I would assume this would be under the smart detection type? Now, I am trying this in webCoRE, and the smart detection is an option, but how do I configure the Compairison and then its respective Valve? Thanks Shaun
I haven't used webcore, so I can't give specific advice there. But the smartDetectType attribute is a string, so you probably should just test detection from the device page to see what values may show up there and then just compare against those same values in your automation logic.
I got past the issues - turned off HTTPS, don't really need it within my home - and moved my NVR to bridge mode - so that I now have all 7 of my Cameras on the same subnet as the Hubitat C8 hub. It now detects the NVR & all 7 cameras when I run the discovery tool - and seems to work for most.
Two questions:
I have one camera that is throwing a lot of the following errors and seemingly missing events (which makes sense if it isn't connected to the Hub):
dev:1262024-01-01 10:48:20.595 AMdebuginitialize() failed: failed to connect
dev:1262024-01-01 10:48:20.593 AMerrorqueryDeviceInfo() failed: java.net.SocketTimeoutException: Read timed out
dev:1262024-01-01 10:38:01.885 AMdebuginitialize() failed: failed to connect
dev:1262024-01-01 10:38:01.883 AMerrorqueryDeviceInfo() failed: java.net.SocketTimeoutException: Read timed out
I have tried to reboot the camera, but still seeing that issue. I've confirmed the password and all - and it did pick up some events, but just seems one camera is more problematic than the others. Have you seen issues with the cameras having CPU/Memory issues and being slow to process things or overloaded to the point that they can't work with this App?
Second -- I am trying to use the SmartMotion detection on the cameras, and I see the following messages in the logs:
dev:1212024-01-01 10:50:05.494 AMdebug[Code:SmartMotionVehicle, action:Stop, index:0, data:[RegionName:[Region1], WindowId:[0], object:[[Rect:[7896, 896, 8152, 1504], VehicleID:88854]]]]
dev:1212024-01-01 10:50:03.875 AMdebug[Code:SmartMotionVehicle, action:Start, index:0, data:[RegionName:[Region1], WindowId:[0], object:[[Rect:[7896, 896, 8152, 1504], VehicleID:88854]]]]
dev:1212024-01-01 10:49:37.431 AMdebug[Code:SmartMotionVehicle, action:Stop, index:0, data:[RegionName:[Region1], WindowId:[0], object:[[Rect:[7496, 576, 8072, 1184], VehicleID:88852]]]]
I also have the following Rule built:
But I don't see that rule being triggered. Am I missing something, or should that Rule pick up on the "smartDetectType" and trigger?
All in all -- this is working great on 5 of the 7 Dahua cameras I have. I am seeing the following on two of the cameras, and wondering if this is cause for concern -- or if there's a reason why these cameras are showing timeouts and more importantly issues when re-activating the EVENTSTREAM. The cameras seem to be operating ok in that I can view them in the Dahua apps and they are sending notifications to my phone on motion detection, etc.
Has anyone seen the same or have any thoughts?
dev:1262024-01-02 04:17:48.280 PMdebugeventStreamStatus: START: EventStream Started
dev:1262024-01-02 04:15:24.481 PMdebuginitialize() failed: failed to connect
dev:1262024-01-02 04:15:24.476 PMerrorqueryDeviceInfo() failed: java.net.SocketTimeoutException: Read timed out
dev:1262024-01-02 04:14:03.885 PMdebuginitialize() failed: failed to connect
dev:1262024-01-02 04:14:03.881 PMerrorqueryDeviceInfo() failed: java.net.SocketTimeoutException: Read timed out
dev:1262024-01-02 04:13:16.764 PMdebuginitialize() failed: failed to connect
dev:1262024-01-02 04:13:16.760 PMerrorqueryDeviceInfo() failed: java.net.SocketTimeoutException: Read timed out
dev:1262024-01-02 04:12:36.508 PMdebuginitialize() failed: failed to connect
dev:1262024-01-02 04:12:36.502 PMerrorqueryDeviceInfo() failed: java.net.SocketTimeoutException: Read timed out
dev:1262024-01-02 04:12:14.682 PMdebuginitialize() failed: failed to connect
dev:1262024-01-02 04:12:14.678 PMerrorqueryDeviceInfo() failed: java.net.SocketTimeoutException: Read timed out
dev:1262024-01-02 04:11:52.978 PMdebugeventStreamStatus: STOP: EventStream Stopped
dev:1262024-01-02 04:11:52.905 PMdebugeventStreamStatus: ERROR: Exception during EventStream Request: java.net.SocketTimeoutException: timeout
dev:1262024-01-02 04:02:47.666 PMdebugeventStreamStatus: START: EventStream Started
dev:1262024-01-02 04:02:03.862 PMdebuginitialize() failed: failed to connect
dev:1262024-01-02 04:02:03.854 PMerrorqueryDeviceInfo() failed: java.net.SocketTimeoutException: Read timed out
dev:1262024-01-02 04:01:25.718 PMdebuginitialize() failed: failed to connect
dev:1262024-01-02 04:01:25.714 PMerrorqueryDeviceInfo() failed: java.net.SocketTimeoutException: Read timed out
dev:1262024-01-02 04:00:53.657 PMdebuginitialize() failed: failed to connect
dev:1262024-01-02 04:00:53.652 PMerrorqueryDeviceInfo() failed: java.net.SocketTimeoutException: Read timed out
dev:1262024-01-02 04:00:34.943 PMdebugeventStreamStatus: STOP: EventStream Stopped
dev:1262024-01-02 04:00:34.881 PMdebugeventStreamStatus: ERROR: Exception during EventStream Request: java.net.SocketTimeoutException: timeout
These are normal and expected, so no cause for concern there. These will show up if a long period of time goes by without events, and the driver should recover automatically after this. Think of this debug print as purely informational.
However, these are not normal, and they likely lead to downtime for events. For example, between about 4:00:34 and 4:02:47, you wouldn't have had an active event stream, and you'd be missing events.
Can you tell whether the impacted cameras are rebooting or something else strange at that time? For example, can you check whether they have an uptime value that you can check? My theory is that they're crashing or something. Another possibility would be network congestion or network reliability issues of some sort. Are either of those a possibility?
I am a Dahua fanboy ...
You mentioned you have a NVR hooked up to it. Check on that camera in the NVR and look at the timeline. Is there a empty gap in the timeline? If so then that camera is going offline for some reason at 4am your time.
I have a very simple question: I was able to set up an Amcrest camera pretty easily. What I'd like to do is publish it as a tile on a dashboard and have the image update periodically. Or, if it is possible to imbed a live stream, that would even be better.
When I look at the events log for the camera, there is one image file in the list and that's it. If I go to the device page and push the "Take" menu, it'll capture another image.
I am starting to wonder if I need to create a rule that runs periodically to update the image so the dashboard will stay reasonably current.
Perhaps the whole thing is based on motion detection or whatever, in which case that would be OK. I suppose if there is no event, then having the image static would be fine until an event happens.
Thanks in advance
Here's how I recommend doing it, from earlier in this same thread: Dahua and Amcrest integration for cameras and doorbells - #4 by tomw
Thanks for the info! I was able to create the virtual device and add it to a dashboard using the url created by the image server. I used the url for the camera shown at the top versus the latest image url.
I have motion sensing enabled on the camera and am receiving motion emails via the camera. I set up a rule identical to your example that if motion is sensed, do a take on the virtual device. I also picked the "take" menu on the device and looked at the event history, and the image is being created, so the take menu is working.
What is not happening is the image updating on the dashboard tile from motion sensed on the camera. The image seems to be stuck on the last "take" command.
Any ideas as to what is going on?
Set your image tile to refresh periodically and it should pick up the updated image contents.
I should have been more specific - the rule does not seem to be executing the “take” command. Also, I set the refresh interval on the tile in the dashboard, but that has no effect.
Hey @tomw, we have so loved this app with our Amcrest doorbell that this weekend we bought a second unit (AD410) for our second home. No problem with the physical install and the setup in the Amcrest mobile app went fine...but then I think I fell victim to the warning in your github readme:
- Note that some recent firmware versions have removed or disabled local API access.
- If your camera does not respond correctly, try another firmware version and/or camera.
I get this error message in the log--is this how a local API access prob would behave?
discovery failed: URI does not specify a valid host name: http://****REDACTED****@10.0.0.***:80/cgi-bin/deviceDiscovery.cgi?action=attach
Ugh. So I dutifully went to the Amcrest website here looking for earlier firmware versions. This site says the latest firmware is V1.000.00AC002.0.R.20230810, so I downgraded to the only older version they have online which is 1.000.0000012.0.R.221201. Still couldn't connect via your discovery app or manually with your driver.
So then, ever the glutton for punishment, I called their customer support number which was surprisingly open on Sunday. Once I got to someone who marginally knew the product, they claimed that discontinued local API support was "just a rumor" and that it wasn't true. I tend not to believe that they know what they are saying. Still, they suggested I hard reset the device, so I did. Still no joy with connecting.
Curious if you or anyone has figured out which products or which firmware releases work and don't work? Wonder if I would've been safer just buying the AD110, for example. Appreciate any ideas.
I have a copy of the first firmware when AD410 was first released that was sent over to me by Amcrest support. You can request for it from them but I received mine back years ago from them so I am not sure if they are still offering it to those who request for one.
Thanks @techbill, but I am embarrassed to tell you that I was the problem. I was using the wrong username. For those that follow, you can't use the username from their mobile app -- you have to use the username for the camera/doorbell itself. Amcrest defaults to "admin" at shipping. Duh.
That said, I'm still having a problem, just a smaller one -- getting the doorbell child device to show up. Per instructions and my memory of getting it working in my other house, I just pressed the doorbell manually, and the child device showed up after reloading. It won't for me. Any ideas?
Ding Dong…..
I got my Amcrest AD410 doorbell fully working thanks to @tomw and @techbill. Thought I’d share what I learned for those that follow. The first item probably only applies to morons like me….
-
When you provide your username and password to the driver or discovery app, make sure you use the device/doorbell’s username, not the username/email address you created in their mobile app. The AD410 is shipped with a default username of “admin”. Others will have to comment whether the same is true for AD110–I dunno. Just don’t do what I did by using the username you setup when adding your doorbell to the Amcrest mobile app. It won’t work.
-
Amcrest has had an on-again, off-again, now on-again affair with support for their local API. You must use the proper firmware on the doorbell for @tomw’s awesome integration to work as follows:
- the latest AD410 firmware, 1.000.0000002.1.R,build:2023-08-19), works
- the 2022 firmware does not work
- the 2021 firmware reportedly works but I haven’t independently validated this.
You can find out what firmware the device is current using by going to the Amcrest mobile app, selecting your device, clicking on the gear in the upper right corner, then clicking the “Firmware Update” option a little more than halfway down the page. You’ll get a chance to see what version of firmware you are on currently prior to upgrading or downgrading if you so choose.
Follow the instructions here to get and apply different firmware to your doorbell. Changing firmware on your device is very simple and quick if you just follow the instructions — so don’t get intimidated.
That’s all — hope this helps folks avoid my mistakes!
