Dahua and Amcrest integration for cameras and doorbells

That makes sense. The way I was doing it was a request to the camera to try to get it to respond with an event, which introduced minimal overhead but did indeed create some unnecessary traffic. The new way is done correctly at the internal Hubitat level and should introduce no overhead. If you're interested in the technical details, hit me up via PM.

I'd be happy to add that as soon as anyone has a camera that supports HTTPS is willing to test it out. Thanks for the suggestion. :slight_smile:

I checked the configuration of my camera and it supports HTTPS. I’d be willing to help. Here’s an Amcrest video demonstrating the steps on the camera. https://www.youtube.com/watch?v=gkjlaf-Iuso

Also, a small suggestion. Consider including a log entry for the four Commands. For the drivers and apps I’ve written, doing so helped me know that when I tapped “refresh”, something actually happened.

I'll send you a modified version to try once I get my other in-flight changes in. Probably in a day or so.

I am still receiving the warnings:
Excluded attribute displayImage size of attribute > 1024 characters
Excluded attribute image size of attribute > 1024 characters.

The logical device, the dashboard tile, and the rule I created to run the “take” command (via a custom command – take()) every five minutes are working correctly. The warnings seem to be only generated when I click on the dashboard that contains the image tile, or when I manually refresh that dashboard via the checkmark in the upper right corner of the DB frame.

Just use the URLs from the Image Server app with an Image tile.

It sounds like you're trying to use an Attribute tile with the attributes directly, which doesn't work because of dashboard limitations on the attribute length.

I am using the image tile, but also have the camera device selected. I created a tile w/o the device selected, and the warning is not generated.

Edit: When I add any devices to the DB via the Dashboard app, the size error occurs. (My fault for not seeing the correlation – I originally thought it was because the device was selected.)

Oh, that's interesting. They must be indexing all of the attributes for the selected device (or at least their sizes?) and then throwing that error. Thanks for sharing.

Important note -- if you are using the take command for snapshots, this driver update requires Hubitat version 2.3.4.132 or later and my hubitat_imageServer app in order to display and use the images.


I just posted v0.9.2 to HPM and GitHub. This version moves the take image files to the File Manager in Hubitat.

This will reduce size and stress on the Hubitat database. Any previous users will notice that the snapshot no longer appears on the device page. Instead, a timestamp of the most recent snapshot will provide a visual indication that the snapshot was successful.

If you want to use the snapshot contents for dashboards, web viewing, or notifications, you will need to also install and use my Image Server app.



This version has some further improvements to ensure connection reliability between Hubitat and your camera. Please let me know if you see any incorrect or confusing behaviors.

2 Likes

Tom, made it back and installed this awesome app (actually, both apps). Works fabulously for my use-case -- full button and motion integration of a Amcrest AD110/AD410 doorbell cam. Mega-props to you!

One really sophomoric suggestion. You might want to flip the order of the Pushover API key and Pushover user key in the Image Server app UI, for the simple reason that, in the built-in Pushover device driver, they are in the opposite order. For simpletons like me who just copied and pasted quickly, it didn't work and I couldn't figure it out for the life of me -- until I slowed down and checked carefully. FWIW.

The fact that this is my only not-so-substantive feedback is quite a commentary on your awesome work. Again, thank you!

2 Likes

Awesome! I'm glad it worked for you. I'll try to remember your Pushover suggestion when I next touch the app.

2 Likes

It’s working well. Thank you.

I copied & pasted the image URl from the Image Server to the tile as the URL changed.

I still receive the warning: Excluded attribute displayImage size of attribute > 1024 characters. It seems it’s generated if any dashboard includes the camera device.

What is the purpose of the tile option Refresh Interval?

Thanks for removing the heartbeat.

Excellent idea to move the image file so it can be accessed in the File Manager. The file does not have an extension – maybe it has to be that way.

1 Like

Yes, this is an unfortunate side effect of the old attributes being so large and the dashboard apparently indexing them in the history even though they're removed from the driver declaration in the new version.

There doesn't appear to be a way to remove the previous values from the Events history, so if that warning is problematic you may have to delete and re-create the virtual devices to really make them go away. I can provide a driver hack to help the old events "age out" if re-creating the devices is too painful. Let me know.

It literally goes and re-pulls the image from its URL again when the dashboard view is open. So, if you have a take that occurs while the dashboard is displayed you will get the new image without having to refresh the dashboard.

Nope, I can totally add the extension. I didn't realize that some browsers would be able to parse the raw bytestream and possibly display the image without me being able to control the headers or other metadata sent with it.

I'll consider adding the file extension in future updates, but I also don't want people to become reliant on the file manager filename directly, because I may change the naming (for example, for different channels or lenses), and the Image Server app will insulate users from that sort of change. Anyway, thanks for the tip that this is an option.

May want to try

device.deleteCurrentState("attributeName")

I tried that as well, but unfortunately it didn't delete the previous events even though it removed the current state. Thanks for the suggestion, though.

Added a second camera as a test with face detection first and then IVS second and I'm getting "motion" events (active/inactive) but not getting other events like my other cam with tripwires/etc. I've tried both IVS and Face detection.

Do you see the impact of those triggers happening in the Dahua app?

Will you turn on debug logging on the virtual device and then try to capture some Logs output? Just PM me what you are getting and we can try to figure out how it is different.

That region seems to correspond with the Face detection region

The AI object detection tends to come in through a CrossRegionDetection event. But this face-specific one could be different. Can you get a capture of the raw event for face detection? If it's sending a different or additional event, I can add it but need to see the event log for the format.

I've got a Lorex Fusion x16 DVR and I cannot get this to work. Not sure what I'm doing wrong..

What have you tried, and what is not working?

I haven't used a Lorex NVR, but another user did and had issues because the cameras were on a different network subnet provided by the NVR, which makes it impossible for Hubitat to connect to the cameras without some clever networking configuration.

@Rxich was working through some challenges along those lines. I'm curious if you are seeing the same thing or something unrelated, @schwarzman.shane