Real time motion detection on V5520 firmwares

[darkxst]

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.

13:14:49.536710 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 55)
    localhost.localdomain.15000 > localhost.localdomain.37767: [bad udp cksum 0xfe36 -> 0x9be5!] UDP, length 27
	0x0000:  4500 0037 0000 4000 4011 3cb4 7f00 0001  E..7..@.@.<.....
	0x0010:  7f00 0001 3a98 9387 0023 fe36 4d42 303a  ....:....#.6MB0:
	0x0020:  302d 302d 3139 3230 2d31 3038 302d 3132  0-0-1920-1080-12
	0x0030:  3830 2d37 3230 00                        80-720.

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

12:33:17 [serviceinterface.cpp Call_Service:140] D> ModuleId:5,communicationPort:15000,cmdId:5015
which corresponds too
5015|5|Request Alarm Data|15000|

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?

[roleoroleo]

Only IPC through message queues.

[darkxst]

ok, I will have a play with using libpcap to trigger events.

[roleoroleo]

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.

[darkxst]

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.

[roleoroleo]

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.

[couriersud]

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

[darkxst]

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!

[couriersud]

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.

[couriersud]

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.

[couriersud]

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

[roleoroleo]

Are there other notifications that use the same file?

[couriersud]

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.

[roleoroleo]

https://github.com/roleoroleo/sonoff-hack/issues/144

[github-actions[bot]]

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.