Nice! If you look at the device page, there are attributes that are populated. For example, crossLineDetected.
Look at the events history, and you should see "Rule1" when it became active and "waiting" when it became inactive again. You could use events on those attributes as triggers for your automations.
Yep those are there
I just pushed v0.9.1 to GitHub and HPM, which has some improvements for connection reliability.
Only the "cameraDriver" file was updated. After you update the driver code, hit Initialize on your camera devices or just reboot Hubitat.
You will see some additional debug prints that include the term "heartbeat". I am still fine-tuning for performance, and there are some differences across the different camera systems that I have seen so far. I welcome any feedback or issues via PM (with verbose debug prints!).
I will check it out when I get a chance to. Been really busy this week with work.
Thanks again for working through these issues. It appears these last changes have had a positive effect on the issue I was seeing with free memory as well. Here's the stats on my hub after 14 hours of uptime.
Here is an important update for anyone that uses the Image Server app. A new version will be required for compatibility with my next driver update.
Please have a look and update if you are using the take command with your virtual devices from my Dahua integration.
Thank you creating this driver, and the Image Server app.
I am using:
Dahua camera discovery v0.9.1 (app)
Dahua/Amcrest Camera v0.9.1 (driver)
Image Server v0.9.0 (app)
I have the logical device working for an Amcrest IP3M-943W. (This model was discontinued ~3 years ago and firmware was not updated to what is currently on Amcrest cameras – just an fyi.) The camera’s image is displayed on the logical device page.
When I paste the URL into Firefox, I receive “pastedURL cannot be displayed as it contains errors.” I’m assuming I should be able to view the image in a browser.
The heartbeat is every 30 seconds. Will this be configurable in the future?
Is username/password sent to the camera in cleartext?
Sorry for the trouble; I introduced a bug with some last-minute cleanup. (Congratulations, you were evidently the first user of the new code 
).
I checked in a fix, so please 'repair' in HPM or just grab the code again from GitHub if you installed manually. This only affected the Image Server app code.
Actually, that part of the code is going away all together. I worked out a better scheme for maintaining the connection.
Just to be clear, this is just about keeping the EventStream active, which is necessary because if it is dropping all the time you may miss events, and we also noticed that the Hubitat performance could be affected if the connection was closed and reopened repeatedly over time. The "heartbeat" behavior is not something that should be user-visible or particularly useful in general.
Is there something you were hoping to utilize it for, or could you explain more about why you wanted it to be configurable?
It is possible that the password is sent in cleartext at least once when connecting, as well as during the discovery process if you use the app. Is there an HTTPS option for your cameras? I could make that a configurable option.
Fixed. Thank you. (For testers, viewing in a browser is simply a check that the image file is accessible.)
If the heartbeat were configurable, it could be increased (more time between beats) to lessen the load on the hub. Currently I am not using motion settings on the camera, so the heartbeat could be burdensome. My plan was to create a rule and update the image periodically. If the heartbeat is removed then this issue is irrelevant.
I am unsure if there is an HTTPS option on my current camera, but at some point I will be upgrading. (My camera’s firmware requires a plugin (Amcrest/Dahua’s webplugin.exe) to view the live feed via a browser. Only Internet Explorer supports the plugin.) I assume a currently produced camera has an HTTPS option, so the option would be valuable.
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. 
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.
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!
Awesome! I'm glad it worked for you. I'll try to remember your Pushover suggestion when I next touch the app.
Download the Hubitat app
