Snapshots are disabled. The tags on the picture are “camera” “latest” and sometime “zone”.
I do not fully unterstand “attempts” So maybe can give me a good hint on there settings.
1 Like
is there a chance to get this working on HASSIO running on RPi4 with 4GB Memory?
I’m also using Compreface. Now I re-read your config I can see you do have snapshot: 0.
Regarding the attempts value, this is from the double-take gitub:
attempts : ‘number of times double take will request a frigate latest.jpg for facial recognition’
I don’t think this should cause duplicate images regardless of what it’s set too.
Could it be the fact you have zones setup in Frigate? Wonder if double take is picking up one image from the camera and then a second duplicate which is flagged as a zone. You could try disabling zones in frigate to test?
I disabled zones and will test.
Can you connect to the webinterface of compreface? There it should be possible to change the name.
It should be reachable at port 8000
It supports arm, so it should be possible. If it will perform good is another question.
I made the experience that the raspi starts struggling with frigate, even with a tpu. So I think for testing it could perform, but not for production.
diasbled zones, problem still persists.
Yesterday I got a series of pictures with less than a second between the pictures. So double take is requesting the latest picture to often. I thought as soon as it recognized a face sucessfully, it stops requesting a new picture. Isnt it?
Your processor does not support AVX2. If that is not true then i’m not sure what would cause it, but compreface needs AVX2. There’s a way to check using an intel website but I don’t have a link handy sorry. It was a while ago i found the same issue.
1 Like
@Jako
Can you please consider this request for next release? the proposed solution resolves the problem and I noticed your latest version is unchanged.
Thank you
1 Like
I’m having an issue where double-take keeps crashing/stopping after a few seconds of me starting the addon. Running HAOS on a bare NUC, double-take is installed as an addon. I’m normally able to open the UI, navigate around to look at the logs or config, but after a few seconds it dies.
In fairness I have had the exact same issue since v.7, as a result been running V.6 quite happily. However, there are a couple of features in v.9 I really like so now trying to get to the bottom of things.
I suspect something changes in v.7 which is incompatible with my setup/config but cannot see anything wrong. There are very few errors, nothing in the home-assistant.log.
supervisor log
22-05-24 10:16:14 ERROR (MainThread) [supervisor.api.ingress] Ingress error: Cannot connect to host 172.30.33.10:3000 ssl:default [Connect call failed ('172.30.33.10', 3000)]
double-take log:
22-05-24 10:13:05 info: Double Take v1.9.0-24bdcef
22-05-24 10:13:05 verbose: {
auth: false,
detect: {
match: {
save: true,
base64: false,
confidence: 97,
purge: 36,
min_area: 1000
},
unknown: {
save: true,
base64: false,
confidence: 40,
purge: 8,
min_area: 0
}
},
time: { timezone: 'UTC' },
frigate: {
attempts: { latest: 5, snapshot: 0, mqtt: true, delay: 0 },
image: { height: 500 },
labels: [ 'person' ],
update_sub_labels: false,
url: 'http://192.168.1.166:5000'
},
mqtt: {
topics: {
frigate: 'frigate/events',
matches: 'double-take/matches',
cameras: 'double-take/cameras',
homeassistant: 'homeassistant'
},
host: '192.168.1.166:1883',
username: 'MQTTDoubleTake',
password: '********'
},
logs: { level: 'debug' },
ui: {
path: '',
theme: 'bootstrap4-dark-blue',
editor: { theme: 'nord_dark' },
logs: { lines: 500 },
pagination: { limit: 50 },
thumbnails: { quality: 95, width: 500 }
},
server: { port: 3000 },
purge: { matches: 24, unknown: 24 },
detectors: {
compreface: {
det_prob_threshold: 0.8,
timeout: 15,
url: 'http://192.168.1.166:8000',
key: '********'
}
},
storage: {
path: '/config/double-take',
config: { path: '/config/double-take' },
secrets: { path: '/config', extension: 'yaml' },
media: { path: '/media/double-take' },
tmp: { path: '/dev/shm/double-take' }
},
version: '1.9.0-24bdcef'
}
22-05-24 10:13:06 info: MQTT: connected
22-05-24 10:13:06 info: MQTT: subscribed to frigate/events, frigate/+/person/snapshot
22-05-24 10:13:10 verbose: 1653351175.291872-ay2fwo - car label not in (person)
22-05-24 10:13:10 verbose: 1653351175.291872-ay2fwo - car label not in (person)
I notice several people reported a similar problem with v.7, there is also a report of it in git, but I’ve been unable to find anyone posting a solution.
Any suggestions?
I’m 100% certain I’m making some (silly and embarrassing) error, but after 2 weeks of looking I just can’t find it…
I’m running HA on a Raspberry Pi (long time installation – works well). I have frigate running on a separate Pi with a USB Coral attached (to offload HA Pi), and have just added a Jetson running DeepStack.
Double Take reports a problem with DeepStack:
and is deeply unhappy with Deep Stack:
info: processing cubecam: 1653865731.143156-cq4aeb
error: AxiosError: deepstack process error: timeout of 10000ms exceeded
warn: sleeping for 0.5 second(s)
error: AxiosError: deepstack process error: timeout of 10000ms exceeded
warn: sleeping for 0.5 second(s)
error: AxiosError: deepstack process error: timeout of 10000ms exceeded
warn: sleeping for 1 second(s)
error: AxiosError: deepstack process error: timeout of 10000ms exceeded
warn: sleeping for 1.5 second(s)
error: AxiosError: deepstack process error: timeout of 10000ms exceeded
warn: sleeping for 2 second(s)
error: AxiosError: deepstack process error: timeout of 10000ms exceeded
warn: sleeping for 2.5 second(s)
error: AxiosError: deepstack process error: timeout of 10000ms exceeded
warn: sleeping for 3 second(s)
error: AxiosError: deepstack process error: timeout of 10000ms exceeded
warn: sleeping for 3.5 second(s)
error: AxiosError: deepstack process error: timeout of 10000ms exceeded
warn: sleeping for 4 second(s)
error: AxiosError: deepstack process error: timeout of 10000ms exceeded
warn: sleeping for 4.5 second(s)
error: AxiosError: deepstack process error: timeout of 10000ms exceeded
warn: sleeping for 5 second(s)
info: done processing cubecam: 1653865731.143156-cq4aeb in 128.34 sec
info: {
id: '1653865731.143156-cq4aeb',
duration: 128.34,
timestamp: '2022-05-29T23:40:54.457Z',
attempts: 11,
camera: 'cubecam',
zones: [],
matches: [],
misses: []
}
And ultimately does not process anything:
The Double Take config is simple:
mqtt:
host: !secret mqtt_broker_address
username: !secret mqtt_broker_username
password: !secret mqtt_broker_password
frigate:
url: http://192.168.0.117:5000
detectors:
deepstack:
url: http://192.168.0.115:80
timeout: 10
Frigate events are visible in MQTT
DeepStack itself seems to be OK:
DeepStack: Version 2022.01.01
/v1/vision/face
---------------------------------------
/v1/vision/face/recognize
---------------------------------------
/v1/vision/face/register
---------------------------------------
/v1/vision/face/match
---------------------------------------
/v1/vision/face/list
---------------------------------------
/v1/vision/face/delete
---------------------------------------
---------------------------------------
v1/backup
---------------------------------------
v1/restore
[GIN] 2022/05/28 - 16:26:12 | 500 | 1m0s | 192.168.0.202 | POST "/v1/vision/face/recognize"
[GIN] 2022/05/28 - 16:26:45 | 500 | 1m0s | 192.168.0.202 | POST "/v1/vision/face/recognize"
[GIN] 2022/05/28 - 16:27:45 | 500 | 1m0s | 192.168.0.202 | POST "/v1/vision/face/recognize"
[GIN] 2022/05/28 - 16:28:45 | 500 | 1m0s | 192.168.0.202 | POST "/v1/vision/face/recognize"
tcpdump shows packets flowing back and forth between HA (DT?) and DS, though many show 500 Internal Server Error (note that these are not showing up in DT or DS logs)
So why can’t Double Take seem to communicate with Deep Stack effectively?
Did you find a solution for that ?
I’ve tried to get the same type setup running and have abandoned the idea at this point. My conclusion is that my 2gb Jetson Nano is simply unable to handle the face recognition, hence the constant timeouts.
If you SSH into your Jetson, I think you’ll find that it is extreeeemly slow, almost unresponsive, with face processing enabled. If you enable only object processing, you’ll likely see sub- 300-400ms processing times like we’d expect from the Jetson. Of course without face, Deepstack (for the purposes of Double-Take) is useless.
If you have other information or find a solution, I’m keen to hear about it. Right now my Jetson is sitting there all pretty but doing absolutely nothing. 
@terryhonn Interesting, and thanks for the data point. I do now see that all 4 cores are running 60-ish% idle which seems low idle time given that the box is doing mostly nothing. But swap use is 0% and GPU use (shown via tegrastats) is also essentially zero. And unlike yours, my jetson still has quick command line response. I think I’d like to keep looking. Maybe I can get @robmarkcole to render an opinion… Are you running deepstack anywhere now or completely gave up on it all?
I am friends with the maintainers of deepstack and confirm it is under active development. I think Jetson 2GB is touch-and-go performance wise, 4GB option is safer
I’m not currently running Deepstack for anything. I somehow lucked into getting a Coral USB before they disappeared, and it is getting passed through into the Proxmox DXC that is running Frigate, which is doing my object detection/identification.
I’ve played around with running face detection on a couple different platforms with no GPU processing, but with 3-4 second inference times, there’s no value in it for me that way.
I’d still love to use my 2GB Jetson for something worthwhile; still looking for what that might be.
No, still looking for a solution
did you managed to do this in the end?
Replying for anyone else that gets here via google: from the readme you have to set the min_area value to something small enough to fit your matched images into it. I am using 500.
1 Like
Is there anyway I could speed up the detection process ?
using frigate, compreface, double-take.
when i’m right in front of my doorbell , it takes 5 seconds to detect me, 11 attempts.
using the example on the double-take github for HA notifications.
first attempt at 90+% seems good enough ?