Closed darkxst closed 1 month ago
Only IPC through message queues.
ok, I will have a play with using libpcap to trigger events.
Did you try the standard output of the Sonoff processes? Maybe a process writes some output when there is a motion detection. You could try to kill a process, run it again from command line and check the output. If you find some string that the process writes when a motion detection occurs, you can write a program that reads it form stdin. For example AVRecorder or AlarmServer.
It was a while ago, since I looked at this, however I didnt find anywhere events are written to stdout. If I enable debug logging, they do end up in syslog, but that ends up writing a lot of noise to the sdcard.
There is a pretty complex web of udp communications going on between all the sonoff processes.
One thing I possibly didnt check was if the recording creates a temporary file that we could pick up, prior to details being written into the db on completion.
I compiled a little example to capture an UDP packet. cap_udp.tar.gz
The archive contains both libpcap and the example. You will find two go scripts to build the sources.
Let me know if it can be useful.
One thing I possibly didnt check was if the recording creates a temporary file that we could pick up, prior to details being written into the db on completion.
The recorded files are created once the motion was detected:
/mnt/mmc/alarm_record/20230402/17/ARC20230402174023.mp4
Perhaps using something like inotifywait -r /mnt/mmc/alarm_record
may be an option?
Firmware Version | 0.1.5 |
---|---|
Base Version | V5520.2053.0504build20230103 |
Model | S-CAM |
The recorded files are created once the motion was detected:
/mnt/mmc/alarm_record/20230402/17/ARC20230402174023.mp4
Is this file created in real-time as the motion event is detected? or does it have the same 30-40sec lag as the current database trigger has?
I still plan to implement udp packet detection, but havent had a chance to look at it yet!
Is this file created in real-time as the motion event is detected? or does it have the same 30-40sec lag as the current database trigger has?
As soon as the motion event is detected.
I have added inotifyd to busybox. The directory structure of alarm_record is a challenge, since sub folders are created.
However, I made some observations in /tmp
:
[root@ipcam_dgf]# inotifyd ./test.sh /tmp:n
Mon Apr 3 23:31:05 EST 2023
n /tmp colinkPushNotice
-rw-r--r-- 1 root root 0 Apr 3 23:31 /tmp/colinkPushNotice
Mon Apr 3 23:31:38 EST 2023
n /tmp file8h6tEf
-rw-r--r-- 1 root root 116211 Apr 3 23:31 /tmp/file8h6tEf
Mon Apr 3 23:31:44 EST 2023
n /tmp colinkPushNotice
-rw-r--r-- 1 root root 0 Apr 3 23:31 /tmp/colinkPushNotice
Mon Apr 3 23:32:17 EST 2023
n /tmp fileOqxQ1i
-rw-r--r-- 1 root root 122330 Apr 3 23:32 /tmp/fileOqxQ1i
/tmp/colinkPushNotice
is created when a motion alarm is triggered. The /tmp/fileXXXXX
files are created 30 to 40 seconds later.
The following proof-of-concept code immediately notifies about a motion event on my S-CAM. It uses the inotifyd implementation from busybox.
inotifyd ./mos.sh /tmp:n
with mos.sh
being
#!/bin/sh
date
echo $1 $2 $3
if [ "$3" = "colinkPushNotice" ]; then
mosquitto_pub -h 192.168.11.5 -u openhab_iot -P PASSWORD -t cam/fast_motion -m ON
/mnt/mmc/sonoff-hack/bin/snapshot -f /tmp/snapfast.jpg
mosquitto_pub -h 192.168.11.5 -u openhab_iot -P PASSWORD -t cam/motion_detection_image -f /tmp/snapfast.jpg
rm -f /tmp/snapfast.jpt
sleep 5
mosquitto_pub -h 192.168.11.5 -u openhab_iot -P PASSWORD -t cam/fast_motion -m OFF
fi
Are there other notifications that use the same file?
I am not aware of any other notifications - I am running this now for a week and did not receive "false" alarms.
One test outstanding is to disable the cloud-connection and see if the file still is being created.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I poked around with tcpdump today, there are a few UDP packets triggered in real time when motion is detected on these cams, which then signal to avencode to start recording.
Further on the same 15000 port there seems to be an api for getting alarm data however have not been able to trace any packets for this one yet :( however those calls dont seem to be in direct relation to motion events
Could probably link in libpcap and monitor for those first packets though, to get real time detection, rather than waiting ~35-40secs for the sqlite db to update after recording is finished.
@roleoroleo do any of the other yi-hack projects have code monitoring UDP packets that you have seen? or is all just using the message queue IPC, which doesnt appear to exist on this camera?