I’m using the FFMPEG camera, not Amcrest component (even though I have contributed enhancements to it). I will switch to HA Amcrest if we can ever find a way for it to support snapshots.
The red zone is supposed to be the blocked area according to the docs, but I think it’s wrong. If I enable it, my motion sensors went batshit crazy today… Triggering several times a minute! This did not use to be the case. This was coincident with the SmartHome app being very slow to connect to the camera and sometimes failing to connect, even though the wifi signal shows good.
So I disabled the red zone and the motion detect craziness went away. I still need to do more tests to see how close to the door people get before it will trigger, and set the distance accordingly.
I will also reboot the doorbell, but for now, sanity returns.
done that, thanks. I’m beginning to suspect the doorbell processor got bogged down somehow causing it to not being able to process the detection zone properly. Adding to this suspicion is that for the past 3 weeks I’ve had it installed, I’ve not had any app connection problems, but now I am getting intermittent failures to connect. These two issues coincide. And after completely clearing the detection zone, no false alerts since.
I’ll need to recheck the transformer voltage as that can lead to weird problems if not sufficient, but it was fine before.
This is what I thought too. The official Amcrest support info for motion detection says otherwise. I registered and left a comment for the author to confirm or correct this (mis)information.
I’m using the FFMPEG camera, not Amcrest component (even though I have contributed enhancements to it). I will switch to HA Amcrest if we can ever find a way for it to support snapshots.
The workarounds I have at this point:
camera.snapshot (jpg) works with the MJPEG camera with stream from TinyCam server of the doorbell cam.
camera.record (mp4) works with the HA Amcrest integration camera directly.
Needed 2 cameras since either neither can do both snapshot and record for me.
I brought up this error when I was working with Amcrest support and guess they haven’t fixed it yet. This is what support told me:
The red shaded areas are the parts that the camera will use for motion detection and the clear squares are the areas you want blocked from being used as detection zones.
Thanks @baize That’s one thing I haven’t ever done - contact Amcrest Support directly. It will be interesting to see how the author of that incorrect support info responds, or even if my “pending approval” comment ever gets posted.
After I cleared the entire motion zone, no more false alerts - and LOL - no more alerts period. So there must be some area highlighted to capture motion. And apparently, the “simpler” the better. A complex zone pattern may just be too much for the AD110 processor to handle at times (I’m guessing).
I needed to handle snapshots is a different and unique way. I did not like the fact that the lag in my HA/ AD110 video stream is at least 8 seconds, so a camera.snapshot would often capture the movement too late to be useful.
On the other hand, camera.record has the ability to specify a “lookback” to start recording back in time which I use to account for the lag. It is this resulting mp4 file that I use to grab a single frame for a snapshot, using the ffmpeg “-frame 1” option. You can also use ffmpeg’s “-ss n” option to specify how many seconds into the mp4 file to begin the snapshot.
I’m interested to hear what sort of lag others are seeing. Just compare a real time clock with seconds to the doorbell live stream. With the SmartHome app and VLC on Windows, I have 2 seconds lag. With HA running on an RPi4, I have 8-12 seconds of lag.
The lag I’m seeing between VLC stream (on Windows) and the snapshot almost do not exists, between SmartHome (Android) and snapshot is around 1-2s, based on the timestamps.
The record, for 30s, lookup 4s, takes couple minutes of show up though.
Thanks for the info on your lag times. I discovered that my real-time clock on Windows hadn’t synchronized in a while, so it was 2 seconds behind.
Also, a clarification I made earlier about capturing snapshots from the AD110. It turns out if you use the FFMPEG camera with the RTSP command as input, it will automatically grab a frame from the stream and provide a snapshot every 10 seconds for viewing in lovelace Picture_Elements (Auto mode).
So you were talking about the “snapshot” as the auto mode in picture_elements, then yes, that is also refreshed every 10s for my MJPEG camera/TinyCam/AD110 setup, not possible with the Amcrest integration.
correct - we’re on the same page, just different camera setups that do the essentially the same thing. So is TinyCam running on your personal phone or dedicated on some other device so it’s not dependent on your phone always having a connection?
On a different note - the RTSP cam/playback command is working great to stream specific clips from my Dahua NVR, including the AD110 which is recording 24x7. Once I get the automation worked out with the start/end timestamps, I can convert the stream to MP4 via ffmpeg command. Then I can play back doorbell/motion events in lovelace. This actually will solve my AD110 video lag and not even need to run camera.record.
Too bad the same technique can’t be used to read the AD110 SD-Card directly without fear of locking it up.
I hear you
Still waiting for AD110 to be properly integrated with HA.
Most of my workaround is done with the TinyCam on a spare wifi galaxy tab, quite amazed how much it can handle, 7 cams on that server.
Do you see extra spike on CPU with the HA rtsp camera? I tried HA rtsp camera setup before and that created extra process for each rtsp stream and took 10-15% CPU load each.
I have been trying to do I believe exactly what you have done on my tab as well.
Can you share a tutorial on how you accomplished it.
I have 6 cameras plus doorbell. All work great on a server running blueiris.
But I am interested in something portable that I can keep with me in tv room at night.
Tried doing it in a kiosk style but failed.
Any help greatly appreciated.
carltonb
I have it working in BI in HA fairly well. Hangs once in a while though, but I can live with it.
Just would love to get it set up on my tablet to carry around the house.
Appreciate all the work you have done with us amateurs.
No, not at all. Just retested this, and on the lovelace page showing 5 cameras, all in auto/snapshot-every-10-seconds mode, CPU was at 5%. Then I live streamed the Amcrest Doorbell video in HD, CPU jumped up to a whopping 6%
All my cams use TinyCam predefined cam settings based on the brand/model.
For AD110, it’s not officially support by TinyCam yet.
I just used the same setting of my Amcrest cam (model IPM-HX1), on-camera motion detection not working though, you will need to set up in-app motion detection or 3rd party app.
TinyCam will display your cams in all kinds of arrangement you want so you can use it as a display on your desk/bedside/wall.
In Settings>Web Server, you can choose port to use, username, password for stream access. https does not work with HA due to certification(?) though.
The server will run in the background once you enable it on the sidebar menu.
You can also set it to auto start on boot in the Settings>UI & behavior.
For HA integration, you can set each of the stream from TinyCam server up as a camera, or use the url directly in camera cards.
A typical stream url without username/password:
http:///axis-cgi/mjpg/video.cgi?camera=[camera number in TinyCam]&fps=5
(not 100% sure the fps= does anything in HA)
You will have to test how many cams can be served smoothly given your tablet/wifi connection/etc., YMMV.
Also, keep an eye on the temperature and power usage of the server-enabled tablet.
What we’re really waiting on is for Amcrest to properly document their API for Doorbell connectivity beyond their SmartHome app - as well as fix a number of omissions (especially snapshot) and fix firmware freezing and/or bricking the doorbell from existing API commands that apparently aren’t supported properly.
I think there’s little chance of fully integrating the doorbell into Home Assistant (without workarounds) until:
Amcrest cooperates/fixes firmware/documents the API;
Feature updates added to the Amcrest component or a new component developed.
…in that order. Can’t really do #3 without the others first, unless some brilliant reverse engineering discovers another path to snapshots, doorbell presses, etc. That’s just my view.
I’ve pleaded this very case for firmware/API improvements to the Amcrest doorbell product team, but I’m not holding my breath.
EDIT (May 6): today I received a reply from the Amcrest AD110 Product team saying they were forwarding my review and request for updated API docs to the R&D team. Hope they respond.
