PiKrellCam: motion vector detect + OSD web interface

[lassiko]

Next question regarding commands from shell: how can i start/stop motion detection from a shell?

I haven't tried it, but does this work?

Code: Select all

echo 'motion_enable on' >> /home/pi/pikrellcam/www/FIFO
echo 'motion_enable off' >> /home/pi/pikrellcam/www/FIFO

That did worked, thank you again.

[billw]

i have maged to install this to three raspi's one works fine, two of them not. The ones not working let me go to the webpage but the system / start wont work. Any ideas?

Run pikrellcam from a terminal window and see if there are any errror messages.
For one thing, it won't run if there is some other app using the camera.

[billw]

There's an upgrade ready that has a new detect method (I call it burst detect) that does not
filter for direction. It's described in the help page.

[jbeale]

There's an upgrade ready that has a new detect method (I call it burst detect) that does not
filter for direction. It's described in the help page.

Great stuff! Working well here so far with the default values (and it is actually raining at the moment). In situations where the camera is always far away from the action, you don't need the burst detect, but in other cases it can be very useful. I see that the help page now has an impressive amount of detail, thanks for that.

[tomtgrp]

Hello,
got it running, attached the patches against actual version 2.0.4.

patches.zip

Stream runs now for several hours in full hd, a real live stream , delay ~ 1 sec, cpu load ~10% on a 4 core pi2.
No side effects seen on live preview, motion and all the other features.

Br
Tom

Thanks for this! I'll apply the patches to pikrellcam for the next update.

Attached a setup Instruction for the rtsp live video stuff:
Remember: Only works for Jessie.

Code: Select all

##################################################################
# gstreamer & rtsp summary & install, effective 02/2016
# tested on a fresh 2015-11-21-raspbian-jessie-lite.img
# must use jessie, no succes on wheezy!!!

#become root:
sudo /bin/bash
cd ~

#to be checked: disable ipv6, otherwise rtsp live doesn't work!! still to figure out why....
echo "net.ipv6.conf.all.disable_ipv6=1" > /etc/sysctl.d/disableipv6.conf
reboot

#install gstreamer & libs & tools
apt-get install -y libgstreamer1.0-0 libgstreamer1.0-0-dbg \
  libgstreamer1.0-dev liborc-0.4-0  liborc-0.4-doc \
  gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0 \
  gstreamer1.0-alsa gstreamer1.0-doc gstreamer1.0-omx \
  gstreamer1.0-plugins-bad gstreamer1.0-plugins-bad-dbg \
  gstreamer1.0-plugins-bad-doc gstreamer1.0-plugins-base \
  gstreamer1.0-plugins-base-apps gstreamer1.0-plugins-base-dbg \
  gstreamer1.0-plugins-base-doc gstreamer1.0-plugins-good \
  gstreamer1.0-plugins-good-dbg gstreamer1.0-plugins-good-doc \
  gstreamer1.0-plugins-ugly gstreamer1.0-plugins-ugly-dbg \
  gstreamer1.0-plugins-ugly-doc gstreamer1.0-pulseaudio \
  gstreamer1.0-tools gstreamer1.0-x \
  libgstreamer-plugins-bad1.0-0 libgstreamer-plugins-bad1.0-dev \
  libgstreamer-plugins-base1.0-0 libgstreamer-plugins-base1.0-dev \
  git
 
gst-launch-1.0 --version
#shows:
#gst-launch-1.0 version 1.4.4
#GStreamer 1.4.4
#http://packages.qa.debian.org/gstreamer1.0

gst-inspect-1.0 | grep omx
#shows:
#omx:  omxmpeg2videodec: OpenMAX MPEG2 Video Decoder
#omx:  omxmpeg4videodec: OpenMAX MPEG4 Video Decoder
#omx:  omxh263dec: OpenMAX H.263 Video Decoder
#omx:  omxh264dec: OpenMAX H.264 Video Decoder
#omx:  omxtheoradec: OpenMAX Theora Video Decoder
#omx:  omxvp8dec: OpenMAX VP8 Video Decoder
#omx:  omxmjpegdec: OpenMAX MJPEG Video Decoder
#omx:  omxvc1dec: OpenMAX WMV Video Decoder
#omx:  omxh264enc: OpenMAX H.264 Video Encoder


#install gst-rtsp-server:
#here you can play with steaming & auth, look at test-auth in examples
#necessary for building gst-gateworks-apps
wget http://gstreamer.freedesktop.org/src/gst-rtsp/gst-rtsp-server-1.4.4.tar.xz
tar xfvv gst-rtsp-server-1.4.4.tar.xz
cd gst-rtsp-server-1.4.4
./configure
make -j 4
make install
ldconfig
cd ~


#install gst-gateworks-apps:
git clone https://github.com/Gateworks/gst-gateworks-apps.git
cd gst-gateworks-apps
make
cd ~


##################################################################
put this in /etc/rc.local after pikrellcam start code:
sleep 15 && /root/start-gst-variable-rtsp-server.sh &


#content of the script start-gst-variable-rtsp-server.sh:
#start rtsp server service gst-gateworks-apps
/root/gst-gateworks-apps-master/bin/gst-variable-rtsp-server -d 99 -p 8555 -m /stream.high  \
  -u "( tcpclientsrc port=3000 do-timestamp=true blocksize=262144 \
  ! video/x-h264,stream-format=byte-stream,profile=high \
  ! h264parse \
  !  rtph264pay name=pay0 pt=96 )" \


#access stream with e.g. vlc player: rtsp://YOUR_PI:8555/stream.high

##################################################################




#optional, install gst-rpicamsrc:
git clone https://github.com/thaytan/gst-rpicamsrc
cd gst-rpicamsrc
./autogen.sh --prefix=/usr --libdir=/usr/lib/arm-linux-gnueabihf/
make -j 4
sudo make install
Test
gst-launch-1.0 rpicamsrc bitrate=1000000 ! filesink location=test.h264
gst-launch-1.0 rpicamsrc bitrate=1000000 ! h264parse !  rtph264pay config-interval=1 pt=96 ! gdppay ! tcpserversink host=0.0.0.0 port=5000


##################################################################

Br
Tom

[tomtgrp]

Some thoughts about security:

1. the .htpasswd shouldn't reside inside the www root

Code: Select all

      auth_basic_user_file /home/pi/pikrellcam/www/.htpasswd;

2. the access to the .htpasswd should be denied by nginx configuration:

Code: Select all

        # deny access to .ht* files, if Apache's document root
        # concurs with nginx's one
        #
        location ~ /\.ht {
                deny all;
        }

Br
Tom

[jbeale]

Any idea what happened here? This Pi has been working normally, but the video event named "motion_2015-12-15_11.14.01_4437.mp4" was truncated at the moment motion was detected (in other words, it contained only the "pre-event" portion of the video). Relevant part of log below, seems like it was trying to process the video twice? This is version PiKrellCam 2.0.3

Code: Select all

11:14:01 : Video record: /home/pi/pikrellcam/media/videos/motion_2015-12-15_11.14.01_4437.mp4.h264 ...
11:14:01 : event preview save: copy /run/pikrellcam/mjpeg.jpg -> /run/pikrellcam/motion_2015-12-15_11.14.01_4437.jpg
11:14:31 : Video motion record stopped. Header size: 28  h264 file size: 3105089
11:14:31 : execl:[(MP4Box -quiet -tmp /tmp -fps 24 -add /home/pi/pikrellcam/media/videos/motion_2015-12-15_11.14.01_4437.mp4.h264 /home/pi/pikrellcam/media/videos/motion_2015-12-15_11.14.01_4437.mp4 2> /dev/null && rm /home/pi/pikrellcam/media/videos/motion_2015-12-15_11.14.01_4437.mp4.h264)]
11:14:31 : event_motion_end_cmd(); running $C/motion-end $v $P $G
11:14:31 : execl:[/home/pi/pikrellcam/scripts/motion-end /home/pi/pikrellcam/media/videos/motion_2015-12-15_11.14.01_4437.mp4 /home/pi/pikrellcam/www/FIFO /tmp/pikrellcam.log]
11:14:31 : execl:[/home/pi/pikrellcam/scripts-dist/_thumb /run/pikrellcam/motion_2015-12-15_11.14.01_4437.jpg /home/pi/pikrellcam/media /home/pi/pikrellcam/www/FIFO /tmp/pikrellcam.log 142 146 497 231]
UPLOADED motion_2015-12-15_11.14.01_4437.jpg
  convert /run/pikrellcam/motion_2015-12-15_11.14.01_4437.jpg -crop 146x146+424+158 -resize 150x150\! /home/pi/pikrellcam/media/thumbs/motion_2015-12-15_11.14.01_4437.th.jpg
11:14:31 : execl:[/home/pi/pikrellcam/scripts/preview-save  /run/pikrellcam/motion_2015-12-15_11.14.01_4437.jpg /home/pi/pikrellcam/media /home/pi/pikrellcam/www/FIFO /tmp/pikrellcam.log 142 146 497 231]
cp /run/pikrellcam/motion_2015-12-15_11.14.01_4437.jpg /home/pi/pikrellcam/media/stills
convert /run/pikrellcam/motion_2015-12-15_11.14.01_4437.jpg -crop 146x146+424+158 -resize 150x150\! /home/pi/pikrellcam/media/thumbs/motion_2015-12-15_11.14.01_4437.th.jpg
11:14:31 : event_preview_dispose(); removing /run/pikrellcam/motion_2015-12-15_11.14.01_4437.jpg
11:14:34 : event_motion_end_cmd(); running $C/motion-end $v $P $G
11:14:34 : execl:[/home/pi/pikrellcam/scripts/motion-end /home/pi/pikrellcam/media/videos/motion_2015-12-15_11.14.01_4437.mp4 /home/pi/pikrellcam/www/FIFO /tmp/pikrellcam.log]
UPLOADED motion_2015-12-15_11.14.01_4437.jpg

[billw]

Any idea what happened here? This Pi has been working normally, but the video event named "motion_2015-12-15_11.14.01_4437.mp4" was truncated at the moment motion was detected (in other words, it contained only the "pre-event" portion of the video). Relevant part of log below, seems like it was trying to process the video twice? This is version PiKrellCam 2.0.3

The event_motion_end_cmd is not supposed to run until the MP4Box process exits, and the
first time it is run it is the same second MP4Box is started. By itself I would think
MP4Box failed for some reason, but then the motion_end_cmd is run again 3 seconds
later and that seems maybe reasonable for the size of the h264 video. So I'm not sure
what actually happened.

I'll look at adding more info about the MP4Box pid and exit event to the log file in case
it happens again.

[jbeale]

Thanks billw for some extra debug info. Another question. Most of my units are working great, but on just one of my units (on which I need to set a fast shutter speed, to capture fast events) it mostly works but has some occasional hiccups (maybe some autoexposure adjustment effect?) Below are some of the *.csv files including two valid and four false-positive readings. Each false detect has a single line in the CSV file, the count is pretty low, the (x,y) location is nearly the same, and it always has dx=0. I may miss some valid triggers if I remove that (x,y) area from a motion region, require a 2nd detect, or raise the count threshold. Is there way to reject an event when dx = 0 ?

Code: Select all

time, x, y, dx, dy, magnitude, count
# width 82 height 61
 2.125,  69,  24,   0,  21,  21,  101              # <- FALSE
time, x, y, dx, dy, magnitude, count
# width 82 height 61
 2.208,  20,  20,  56,  -4,  56,  351              # <- valid
 2.542,  39,  20,  44,  11,  45,  493
 2.708,  48,  22,  57,  13,  58,  488
time, x, y, dx, dy, magnitude, count
# width 82 height 61
 2.042,  68,  24,   0,  23,  23,  112              # <- FALSE
time, x, y, dx, dy, magnitude, count
# width 82 height 61
 2.375,  48,  12,  56,  -8,  57,   91              # <- valid
 2.542,  28,  23,  66,  -1,  66,  236
 2.708,  20,  24,   7,  -9,  11,  227
 2.875,  29,  21, -20,   4,  20,  410
 3.208,  69,  24,  60,  51,  79,  106
time, x, y, dx, dy, magnitude, count
# width 82 height 61
 2.458,  68,  23,   0,  23,  23,  114               # <- FALSE
time, x, y, dx, dy, magnitude, count
# width 82 height 61
 2.208,  68,  23,   0,  24,  24,   93                # <- FALSE

[jbeale]

also, this camera missed a real event just now at 12:05:26 with the -vm information below. I'm not sure how to tune this so it would have been detected. I presume I could increase the "burst" sensitivity, but by how much? I had Burst_Count = 200 and Burst_Frames=3. For now, I will set Burst_Count to 70 and Burst_Frames to 2 and see how that works.

Code: Select all

cvec[1]: x,y(30,21) dx,dy(-52,-1) mag2,count(2705,116) reject:342 box:16x16
   in_box[count:63 rej:190] motion:0 vetical:0 sparkle:1 limit_count:75
frame:   x,y(30,21) dx,dy(-52,-1) mag2,count(2705,116) any_expma: 29.3 burst:0
any:1255 reject:1011 sparkle:2 sparkle_expma:0.2
12:05:26 [9486] motion count:0 fail:1 window:0

cvec[1]: x,y(31,23) dx,dy(-59,-1) mag2,count(3482,125) reject:347 box:16x16
   in_box[count:86 rej:177] motion:0 vetical:0 sparkle:1 limit_count:75
cvec[2]: x,y(50,20) dx,dy(-56,4) mag2,count(3152,87) reject:375 box:14x14
   in_box[count:35 rej:177] motion:0 vetical:0 sparkle:0 limit_count:75
frame:   x,y(40,21) dx,dy(-57,1) mag2,count(3250,212) any_expma: 29.3 burst:0
any:1118 reject:844 sparkle:10 sparkle_expma:0.3
12:05:26 [9487] motion count:0 fail:2 window:0

cvec[2]: x,y(46,20) dx,dy(-47,38) mag2,count(3653,76) reject:383 box:12x14
   in_box[count:32 rej:135] motion:0 vetical:0 sparkle:0 limit_count:75
frame:   x,y(46,20) dx,dy(-47,38) mag2,count(3653,76) any_expma: 29.3 burst:0
any:1354 reject:1134 sparkle:0 sparkle_expma:0.3
12:05:26 [9488] motion count:0 fail:1 window:0

[billw]

Thanks billw for some extra debug info. Another question. Most of my units are working great, but on just one of my units (on which I need to set a fast shutter speed, to capture fast events) it mostly works but has some occasional hiccups (maybe some autoexposure adjustment effect?) Below are some of the *.csv files including two valid and four false-positive readings. Each false detect has a single line in the CSV file, the count is pretty low, the (x,y) location is nearly the same, and it always has dx=0. I may miss some valid triggers if I remove that (x,y) area from a motion region, require a 2nd detect, or raise the count threshold. Is there way to reject an event when dx = 0 ?

There's a vertical test I was going to use for rain but it did not work for that. The test is
still in the code but using it is disabled. I can add the option to enable it back in and you
can try it. It would be interesting to know for sure why that happens.

[billw]

also, this camera missed a real event just now at 12:05:26 with the -vm information below. I'm not sure how to tune this so it would have been detected. I presume I could increase the "burst" sensitivity, but by how much? I had Burst_Count = 200 and Burst_Frames=3. For now, I will set Burst_Count to 70 and Burst_Frames to 2 and see how that works.

Code: Select all

cvec[1]: x,y(30,21) dx,dy(-52,-1) mag2,count(2705,116) reject:342 box:16x16
   in_box[count:63 rej:190] motion:0 vetical:0 sparkle:1 limit_count:75
frame:   x,y(30,21) dx,dy(-52,-1) mag2,count(2705,116) any_expma: 29.3 burst:0
any:1255 reject:1011 sparkle:2 sparkle_expma:0.2
12:05:26 [9486] motion count:0 fail:1 window:0

cvec[1]: x,y(31,23) dx,dy(-59,-1) mag2,count(3482,125) reject:347 box:16x16
   in_box[count:86 rej:177] motion:0 vetical:0 sparkle:1 limit_count:75
cvec[2]: x,y(50,20) dx,dy(-56,4) mag2,count(3152,87) reject:375 box:14x14
   in_box[count:35 rej:177] motion:0 vetical:0 sparkle:0 limit_count:75
frame:   x,y(40,21) dx,dy(-57,1) mag2,count(3250,212) any_expma: 29.3 burst:0
any:1118 reject:844 sparkle:10 sparkle_expma:0.3
12:05:26 [9487] motion count:0 fail:2 window:0

cvec[2]: x,y(46,20) dx,dy(-47,38) mag2,count(3653,76) reject:383 box:12x14
   in_box[count:32 rej:135] motion:0 vetical:0 sparkle:0 limit_count:75
frame:   x,y(46,20) dx,dy(-47,38) mag2,count(3653,76) any_expma: 29.3 burst:0
any:1354 reject:1134 sparkle:0 sparkle_expma:0.3
12:05:26 [9488] motion count:0 fail:1 window:0

With those counts it should have detected as a burst with a count limit of 200.
So I looked and to my surprise it seems the rejects are not being included in the
test as I was sure they were... At least I made sure the docs are correct!

I'm tied up tomorrow but should be able to get to this and adding the vertical
filter option soon. Plus I probably should have a beer or two anyway before I try
any more coding.

[jbeale]

Actually today I'm seeing similar false detects but this time nearly horizontal motion, instead of exactly vertical as yesterday. So I can't filter these out as the expected events go horizontally also. One example .csv data is below: the recorded video looks almost perfectly static to my eye, except there is a small step-change in overall brightness about 2 seconds in (auto-exposure step?)

Code: Select all

cat motion_2015-12-18_12.17.10_269.csv     
 time, x, y, dx, dy, magnitude, count
# width 82 height 61
 2.083,  18,  39, -42,  -1,  42,  140

... Plus I probably should have a beer or two anyway before I try any more coding.

Not a bad idea... anyway the software is already great and please let me know how to contribute to the billw beer fund!
cheers,
John

[billw]

Actually today I'm seeing similar false detects but this time nearly horizontal motion, instead of exactly vertical as yesterday. So I can't filter these out as the expected events go horizontally also. One example .csv data is below: the recorded video looks almost perfectly static to my eye, except there is a small step-change in overall brightness about 2 seconds in (auto-exposure step?)

Code: Select all

cat motion_2015-12-18_12.17.10_269.csv     
 time, x, y, dx, dy, magnitude, count
# width 82 height 61
 2.083,  18,  39, -42,  -1,  42,  140

Now I'm not sure I should enable the vertical filtering since it's not really getting at the problem.

From the overall frame dimming I saw in your video, I'm wondering
if this is actually a large count event over the frame that somehow shows up as horizontal
or vertical. I need to get a fixed burst motion version up for you to use and from there it
would be useful to know if these events are initiated as burst or direction events by checking
the log file.
If they are direction events, is there no confirm gap? If so maybe they are camera glitches
that would not get through if there was a confirm. One thing I'm getting at is if you want fast
detection, maybe the way to do it would be to have a confirm gap for direction events
and a burst frames/count setting to get the fast detection (which, again, needs the fix)
If that's the right track, then the final tuning would be to adjust the burst frames as a
tradeoff between the fast detection you want versus what it takes to cut down on the
brightness adjustment that is generating the horizontal/vertical events.

.. I'm not sure of all your settings, so just thinking about it.

... Plus I probably should have a beer or two anyway before I try any more coding.

Not a bad idea... anyway the software is already great and please let me know how to contribute to the billw beer fund!
cheers,
John

Thanks for thinking about it and that's good enough!

[dmurphydrtc]

Help required..(noob)

Great software and all working as hoped.

I have the following setup (dirs from pikrellcam.conf listed below) and want to archive data end of everyday..I have looked at the last page where this is discussed but am confused about the dir naming used. Using supplied dirs can someone help us exit the maze. Thanks in advance.

install_dir /home/pi/pikrellcam
tmpfs_dir /run/pikrellcam
media_dir /dev/media
archive_dir /picam

[jbeale]

If they are direction events, is there no confirm gap? If so maybe they are camera glitches
that would not get through if there was a confirm. One thing I'm getting at is if you want fast
detection, maybe the way to do it would be to have a confirm gap for direction events
and a burst frames/count setting to get the fast detection (which, again, needs the fix)
If that's the right track, then the final tuning would be to adjust the burst frames as a
tradeoff between the fast detection you want versus what it takes to cut down on the'
brightness adjustment that is generating the horizontal/vertical events.

Right, I had set 'motion_confirm_gap 0' because I noticed that some valid events generated only a single detect frame, so that's part of the problem. I think the brightness step changes are almost always a single frame event so your tuning suggestions sound good. I changed my confirm_gap to 1 for now. I am using 24 fps and 'mjpeg_divider 4' which should give me effective 6 fps detection (? because I didn't think any faster was reliable.) Could we get better granularity on confirm_gap like 0.5 seconds or less? Do you think, if we could have the option to switch off the on-screen display text etc. the detect process could go faster than 6 fps ? I am using RP2, not overclocked, and pikrellcam currently reports only 8% cpu usage so I guess the bottleneck is bandwidth between GPU and CPU ?

[billw]

Help required..(noob)

Great software and all working as hoped.

I have the following setup (dirs from pikrellcam.conf listed below) and want to archive data end of everyday..I have looked at the last page where this is discussed but am confused about the dir naming used. Using supplied dirs can someone help us exit the maze. Thanks in advance.

install_dir /home/pi/pikrellcam
tmpfs_dir /run/pikrellcam
media_dir /dev/media
archive_dir /picam

I'm confused why you have the media_dir in /dev? But anyway, assuming you are mounting
these directories with a USB flash drive or NAS, then having the media_dir and archive_dir
pointing somewhere in the filesystem should be fine as long as there are no permission issues,
and I haven't tested doing something in /dev...

As far as archiving goes, I just pushed an upgrade with the archiving scripts now able to
handle archiving for today or yesterday. In at-commands you can have for example:

Code: Select all

daily    08:00  "@archive_video day yesterday"

That should just work for whatever dirs you have configured.

If you still want to use the do-archive script to get something additionally done,
the script should work I think for the archiving part but it uses a hardwired media directory
for deleting oldest and should be modified to use the $m etc variables.
And you would put in at-commands.conf a line like:

Code: Select all

daily 08:00 "$C/do-archive $m

As far as hardwiring in scripts goes, it's OK to hardwire things like the script directory or FIFO,
but media and archive directories for general use should not be hardwired. This does make
it problematic for use in a cron job vs an at-command. Maybe I could add the media and archive
dir to /var/run/pikrellcam/state

[billw]

Right, I had set 'motion_confirm_gap 0' because I noticed that some valid events generated only a single detect frame, so that's part of the problem. I think the brightness step changes are almost always a single frame event so your tuning suggestions sound good. I changed my confirm_gap to 1 for now. I am using 24 fps and 'mjpeg_divider 4' which should give me effective 6 fps detection (? because I didn't think any faster was reliable.) Could we get better granularity on confirm_gap like 0.5 seconds or less? Do you think, if we could have the option to switch off the on-screen display text etc. the detect process could go faster than 6 fps ? I am using RP2, not overclocked, and pikrellcam currently reports only 8% cpu usage so I guess the bottleneck is bandwidth between GPU and CPU ?

I just pushed an upgrade that should fix the burst detect mode to properly use the rejects. So
now you can use the right baseline for your testing. If you had set your burst_count lower, it
might now need some adjusting back higher.

Over the holidays, it may be sporadic, but I still will be looking at the extra debug we talked
about, the .htaccess that tomtgrp mentioned, and I'll look at a higher confirm gap resolution.

I think at least the bottleneck is inside the GPU as we found before but I'm not sure if it is
just inside the GPU or includes the CPU callbacks. As mjpeg_divider goes lower, the GPU
preview jpeg encoder is running more and begins to lose ground wrt the video h264 path.
To find out if this is just GPU bandwidth limitation or is also affected by time in the callback
I would have to run some tests. At some point I'm also curious to try some GPU overclocking
to see how that affects everything. So far I've never overclocked the GPU.

Edit: By the way, confirm_gap means it looks for the first motion confirm within the
gap period and not that it waits until after the confirm period to look for a confirm.
So having a gap of 0.5 is actually less likely to confirm than 1.0. For fast detection
it's just an issue that direction detect naturally is geared towards rejecting noise for
low count event reliability. Which is why I'm suggesting that for your fast detect
purposes, the burst detect is better. So maybe higher resolution confirm_gap
would not help.

[shh200]

Hi,

I cannot get automatic night mode to work even after several reinstalls
What I am doing wrong?
I added these lines at at-commands.conf

Code: Select all

# Adjust camera parameters in the evening: sunset{+-offset}
daily sunset "@exposure_mode night"
daily sunset+10 "@video_fps 4"
daily sunset+10 "@video_mp4box_fps 4"
daily sunset+10 "@mjpeg_divider 1"

# Adjust camera parameters in the morning sunrise{+-offset}
daily sunrise-10 "@video_fps 24"
daily sunrise-10 "@video_mp4box_fps 24"
daily sunrise-10 "@mjpeg_divider 4"
daily sunrise "@exposure_mode auto"

edited lat and lon also that I can get correct time

sunrise/sunset times: valid dawn/dusk times: valid
dawn: 8:25
sunrise: 9:23
sunset: 15:14
dusk: 16:12

Also from log:

========================================================
2015-12-19 21:23:43 ===== PiKrellCam 2.1.1 started =====
========================================================
at_command_add [daily] at: sunset command: [@exposure_mode night]
at_command_add [daily] at: sunset+10 command: [@video_fps 4]
at_command_add [daily] at: sunset+10 command: [@video_mp4box_fps 4]
at_command_add [daily] at: sunset+10 command: [@mjpeg_divider 1]
at_command_add [daily] at: sunrise-10 command: [@video_fps 24]
at_command_add [daily] at: sunrise-10 command: [@video_mp4box_fps 24]
at_command_add [daily] at: sunrise-10 command: [@mjpeg_divider 4]
at_command_add [daily] at: sunrise command: [@exposure_mode auto]

Is there something I have not noticed?

[billw]

Hi,

I cannot get automatic night mode to work even after several reinstalls
What I am doing wrong?

Your lines look right to me. At those sun times what do you get in the log file?
There should be lines like:

Code: Select all

07:12:00 : command_process: video_fps 24
07:12:00 : command_process: video_mp4box_fps 24
07:12:00 : command_process: mjpeg_divider 4
07:12:00 : command_process: exposure_mode auto

If you have a config up on the OSD it should change immediately when the at
commands are run. So if you are showing the mjpeg_divider on the OSD menu, does
it change when you change it with:

Code: Select all

echo mjpeg_divider 1 > ~/pikrellcam/www/FIFO
...
echo mjpeg_divider 4 > ~/pikrellcam/www/FIFO

[shh200]

full log after reboot:

========================================================
2015-12-19 23:13:38 ===== PiKrellCam 2.1.1 started =====
========================================================
at_command_add [daily] at: sunset command: [@exposure_mode night]
at_command_add [daily] at: sunset+10 command: [@video_fps 4]
at_command_add [daily] at: sunset+10 command: [@video_mp4box_fps 4]
at_command_add [daily] at: sunset+10 command: [@mjpeg_divider 1]
at_command_add [daily] at: sunrise-10 command: [@video_fps 24]
at_command_add [daily] at: sunrise-10 command: [@video_mp4box_fps 24]
at_command_add [daily] at: sunrise-10 command: [@mjpeg_divider 4]
at_command_add [daily] at: sunrise command: [@exposure_mode auto]
using FIFO: /home/pi/pikrellcam/www/FIFO
using mjpeg: /run/pikrellcam/mjpeg.jpg
23:13:38 : execl:[/home/pi/pikrellcam/scripts-dist/_init /home/pi/pikrellcam /home/pi/pikrellcam/media/archive /home/pi/pikrellcam/media /run/pikrellcam/mjpeg.jpg /home/pi/pikrellcam/www/FIFO /tmp/pikrellcam.log]
www/media link is already set to /home/pi/pikrellcam/media
www/archive link is already set to /home/pi/pikrellcam/media/archive
/home/pi/pikrellcam/www/config.php: LOG_FILE not changed.
/home/pi/pikrellcam/www/config.php: MJPEG_FILE not changed.
/home/pi/pikrellcam/www/config.php: FIFO_FILE not changed.
/home/pi/pikrellcam/www/config.php: PIKRELLCAM not changed.
/home/pi/pikrellcam/www/config.php: VERSION not changed.
23:13:38 : execl:[/home/pi/pikrellcam/scripts/startup /home/pi/pikrellcam /home/pi/pikrellcam/media /tmp/pikrellcam.log]
MOUNT_DISK is not set.
23:13:38 : execl:[sudo chown pi.www-data /tmp/pikrellcam.log]
23:13:38 : execl:[sudo chmod 664 /tmp/pikrellcam.log]
23:13:38 : execl:[sudo mkdir -p /run/pikrellcam]
23:13:38 : execl:[sudo chown pi.www-data /run/pikrellcam]
23:13:38 : execl:[sudo chmod 775 /run/pikrellcam]
23:13:38 : circular buffer allocate: 26.25 MBytes (35 seconds at 6.0 Mbits/sec)
23:13:38 : Server: error binding
23:13:38 : Server running...waiting for connections.
sunrise/sunset times: valid dawn/dusk times: valid
dawn: 8:25
sunrise: 9:23
sunset: 15:14
dusk: 16:12
23:13:40 : execl:[/home/pi/pikrellcam/scripts-dist/_log-lines 1000 /tmp/pikrellcam.log]

this worked correctly:

If you have a config up on the OSD it should change immediately when the at
commands are run. So if you are showing the mjpeg_divider on the OSD menu, does
it change when you change it with:

Code: Select all

    echo mjpeg_divider 1 > ~/pikrellcam/www/FIFO
    ...
    echo mjpeg_divider 4 > ~/pikrellcam/www/FIFO

[billw]

full log after reboot:

========================================================
2015-12-19 23:13:38 ===== PiKrellCam 2.1.1 started =====
========================================================
at_command_add [daily] at: sunset command: [@exposure_mode night]
at_command_add [daily] at: sunset+10 command: [@video_fps 4]
at_command_add [daily] at: sunset+10 command: [@video_mp4box_fps 4]
at_command_add [daily] at: sunset+10 command: [@mjpeg_divider 1]
at_command_add [daily] at: sunrise-10 command: [@video_fps 24]
at_command_add [daily] at: sunrise-10 command: [@video_mp4box_fps 24]
at_command_add [daily] at: sunrise-10 command: [@mjpeg_divider 4]
at_command_add [daily] at: sunrise command: [@exposure_mode auto]
...
sunrise/sunset times: valid dawn/dusk times: valid
dawn: 8:25
sunrise: 9:23
sunset: 15:14
dusk: 16:12
23:13:40 : execl:[/home/pi/pikrellcam/scripts-dist/_log-lines 1000 /tmp/pikrellcam.log]

this worked correctly:

If you have a config up on the OSD it should change immediately when the at
commands are run. So if you are showing the mjpeg_divider on the OSD menu, does
it change when you change it with:

Code: Select all

    echo mjpeg_divider 1 > ~/pikrellcam/www/FIFO
    ...
    echo mjpeg_divider 4 > ~/pikrellcam/www/FIFO

According to your sun times, we have to wait until sunrise-10 or 9:13 to see
anything about it in the log (or wait until sunset). So, sorry, but I should have
said for you to run a test this way:

Keep the mjpeg_divider displaying up on the OSD and edit the at-commands.conf file.
If the divider is currently 4, add the line:

Code: Select all

daily minute "@mjpeg_divider 1"

After you write the file, wait until the next system time minute rolls over and the
mjpeg_divider value should change. Edit it back to 4, and it should change back
at the next minute rollover.

If this works, then things should be working (and these will appear in the log file), but
to be sure you have to wait until the sun time.
Keep in mind though, you should see the effect, but it won't be dramatic
because the camera still has the shutter open for a short period. The night mode
settings can only help a little if there is already some night lighting, or prolong the
twilight view a bit.

Edit: could this be a misunderstanding? The at-commands don't look back when
you start the program. At commands are executed only for times that pass while
pikrellcam is running. If you want an initial condition set regardless of when pikrellcam
is started, you need to have your own script that you can run with a "start" time
in the at-commands file. In that script you can check the /var/run/pikrellcam/state
file to test for times.

[shh200]

Edit: could this be a misunderstanding? The at-commands don't look back when
you start the program. At commands are executed only for times that pass while
pikrellcam is running. If you want an initial condition set regardless of when pikrellcam
is started, you need to have your own script that you can run with a "start" time
in the at-commands file. In that script you can check the /var/run/pikrellcam/state
file to test for times.

Yep, misunderstanding it was. Sorry for any inconvience. Works as intented.
I thougt that at commands are exexuted every time when I restart.

Anyways thanks for great job!
Moved my project to this from rpi cam.

[billw]

Yep, misunderstanding it was. Sorry for any inconvience.

Things like this let me know where I can clarify or add to the help page.
So there's a benefit.

[jbeale]

In case anyone else is interested. I made a simple tool to compare recorded events from five different PiKrellCam devices looking at the same general area. They are shown below as cameras [01234]. In many cases all five cameras detect the event, defined as a video starting within 8 seconds of another camera. So far today, camera [2] with the longer lens (more troublesome, as objects pass through field of view quickly) is working ok. That is to say, it is generally not missing any events that a majority of the other cameras detect (except for a few cases which are due to slight differences in the different cameras' field of view). Before the latest PiKrellCam update to enable the "burst" mode detect, it wasn't as consistent. I'll keep an eye on it. The last two columns show the device name and filename of the first camera to detect a specific event.

Code: Select all

   #  camera  Cam   video_filename
   1 [01234]  rp23  motion_2015-12-20_00.02.05_115.mp4
   2 [01234]  rp22  motion_2015-12-20_00.04.11_216.mp4
   3 [0 234]  rp27  motion_2015-12-20_01.02.49_998.mp4
   4 [0 234]  rp23  motion_2015-12-20_01.02.55_118.mp4
   5 [0 2 4]   rp2  motion_2015-12-20_01.07.52_5350.mp4
   6 [0 234]  rp22  motion_2015-12-20_02.00.11_220.mp4
   7 [0 23 ]  rp27  motion_2015-12-20_02.03.55_1001.mp4
   8 [0 234]  rp27  motion_2015-12-20_02.07.52_1002.mp4
   9 [0 2 4]  rp22  motion_2015-12-20_02.14.25_223.mp4
  10 [0 2 4]  rp22  motion_2015-12-20_02.40.48_224.mp4
  11 [0123 ]  rp27  motion_2015-12-20_02.49.40_1004.mp4
  12 [0 234]  rp27  motion_2015-12-20_03.50.15_1005.mp4
  13 [012 4]  rp22  motion_2015-12-20_03.52.23_227.mp4
  14 [012  ]  rp22  motion_2015-12-20_04.22.09_228.mp4
  15 [01234]  rp23  motion_2015-12-20_06.37.25_125.mp4
  16 [012  ]  rp22  motion_2015-12-20_06.38.39_1.mp4
  17 [01234]   rp2  motion_2015-12-20_07.08.28_5357.mp4
  18 [01234]  rp22  motion_2015-12-20_07.08.44_5.mp4
  19 [012  ]  rp30  motion_2015-12-20_07.12.37_181.mp4
  20 [0 234]  rp27  motion_2015-12-20_07.14.21_1010.mp4
  21 [01234]  rp23  motion_2015-12-20_07.25.03_131.mp4
  22 [01 34]  rp23  motion_2015-12-20_07.25.32_133.mp4
  23 [0 23 ]  rp23  motion_2015-12-20_07.35.45_135.mp4
  24 [0 234]  rp22  motion_2015-12-20_07.40.03_12.mp4
  25 [ 1234]  rp23  motion_2015-12-20_07.41.02_138.mp4
  26 [01234]  rp23  motion_2015-12-20_08.00.15_139.mp4
  27 [01234]  rp23  motion_2015-12-20_08.12.16_140.mp4
  28 [01234]  rp30  motion_2015-12-20_08.16.57_190.mp4
  29 [01234]  rp22  motion_2015-12-20_08.23.04_20.mp4
  30 [01234]  rp23  motion_2015-12-20_08.28.40_145.mp4
  31 [01234]  rp27  motion_2015-12-20_08.38.14_1022.mp4
  32 [01234]  rp27  motion_2015-12-20_08.41.33_1023.mp4
  33 [01234]  rp22  motion_2015-12-20_08.54.50_25.mp4
  34 [0123 ]  rp30  motion_2015-12-20_08.55.10_197.mp4
  35 [01234]  rp23  motion_2015-12-20_08.55.32_152.mp4
  36 [0 234]  rp23  motion_2015-12-20_08.55.49_153.mp4
  37 [0  34]  rp27  motion_2015-12-20_09.00.37_1030.mp4
  38 [01234]  rp30  motion_2015-12-20_09.00.43_200.mp4
  39 [01234]  rp22  motion_2015-12-20_09.13.16_32.mp4
  40 [01234]  rp27  motion_2015-12-20_09.22.18_1033.mp4
  41 [01234]  rp22  motion_2015-12-20_09.34.37_34.mp4
  42 [01234]  rp23  motion_2015-12-20_09.36.07_160.mp4
  43 [01234]  rp22  motion_2015-12-20_09.39.41_36.mp4
  44 [012  ]  rp22  motion_2015-12-20_09.41.20_37.mp4
  45 [01234]   rp2  motion_2015-12-20_09.45.04_5380.mp4
  46 [01234]  rp22  motion_2015-12-20_09.47.17_39.mp4
  47 [01234]  rp22  motion_2015-12-20_09.49.34_40.mp4
  48 [012  ]  rp30  motion_2015-12-20_09.50.47_211.mp4
  49 [  234]  rp22  motion_2015-12-20_09.58.23_42.mp4
  50 [01234]  rp27  motion_2015-12-20_10.08.14_1042.mp4
  51 [01234]  rp27  motion_2015-12-20_10.08.38_1043.mp4
  52 [01234]  rp27  motion_2015-12-20_10.17.41_1045.mp4
  53 [01234]  rp22  motion_2015-12-20_10.19.00_46.mp4
  54 [01234]  rp30  motion_2015-12-20_10.21.16_217.mp4
  55 [012  ]  rp22  motion_2015-12-20_10.22.43_49.mp4
  56 [01234]  rp22  motion_2015-12-20_10.23.12_50.mp4
  57 [01234]  rp27  motion_2015-12-20_10.25.02_1049.mp4
  58 [01234]  rp22  motion_2015-12-20_10.38.56_52.mp4
  59 [01234]  rp27  motion_2015-12-20_10.41.32_1051.mp4
  60 [01234]   rp2  motion_2015-12-20_10.47.04_5394.mp4
  61 [01234]   rp2  motion_2015-12-20_10.54.24_5395.mp4
  62 [01234]  rp27  motion_2015-12-20_10.55.58_1054.mp4
  63 [01234]   rp2  motion_2015-12-20_10.58.40_5397.mp4
  64 [01234]   rp2  motion_2015-12-20_10.59.37_5398.mp4
  65 [01234]   rp2  motion_2015-12-20_11.01.47_5399.mp4
  66 [01234]   rp2  motion_2015-12-20_11.02.56_5400.mp4
  67 [01 3 ]  rp22  motion_2015-12-20_11.03.40_61.mp4
  68 [0 234]  rp23  motion_2015-12-20_11.03.53_184.mp4
  69 [0 23 ]  rp23  motion_2015-12-20_11.06.47_185.mp4
  70 [01234]  rp22  motion_2015-12-20_11.08.04_64.mp4
  71 [  234]   rp2  motion_2015-12-20_11.10.55_5402.mp4
  72 [01234]   rp2  motion_2015-12-20_11.12.56_5403.mp4
  73 [01234]  rp27  motion_2015-12-20_11.13.30_1063.mp4
  74 [01234]  rp27  motion_2015-12-20_11.17.12_1064.mp4
  75 [01234]   rp2  motion_2015-12-20_11.18.55_5406.mp4
  76 [01234]  rp27  motion_2015-12-20_11.19.23_1066.mp4
  77 [01234]  rp27  motion_2015-12-20_11.20.28_1067.mp4
  78 [01234]  rp22  motion_2015-12-20_11.21.10_75.mp4
  79 [01234]   rp2  motion_2015-12-20_11.21.19_5410.mp4
  80 [0123 ]  rp22  motion_2015-12-20_11.31.36_77.mp4
  81 [01234]  rp27  motion_2015-12-20_11.38.12_1070.mp4
  82 [01234]  rp23  motion_2015-12-20_11.45.45_199.mp4
  83 [0123 ]  rp27  motion_2015-12-20_11.48.30_1073.mp4
  84 [01234]  rp22  motion_2015-12-20_11.51.03_82.mp4
  85 [012  ]  rp30  motion_2015-12-20_11.56.32_248.mp4
  86 [  234]  rp27  motion_2015-12-20_11.56.52_1075.mp4
  87 [0123 ]  rp23  motion_2015-12-20_11.57.28_208.mp4
  88 [01234]  rp30  motion_2015-12-20_12.02.13_251.mp4
  89 [01234]   rp2  motion_2015-12-20_12.09.24_5420.mp4
  90 [01234]  rp23  motion_2015-12-20_12.09.32_213.mp4
  91 [01234]   rp2  motion_2015-12-20_12.12.52_5422.mp4
  92 [0123 ]  rp27  motion_2015-12-20_12.16.25_1081.mp4
  93 [01234]  rp23  motion_2015-12-20_12.18.04_217.mp4
  94 [01234]   rp2  motion_2015-12-20_12.19.55_5425.mp4
  95 [01234]  rp27  motion_2015-12-20_12.26.26_1084.mp4
  96 [0 234]  rp23  motion_2015-12-20_12.27.37_220.mp4
  97 [01234]  rp22  motion_2015-12-20_12.32.11_102.mp4
  98 [01234]  rp27  motion_2015-12-20_12.36.53_1087.mp4
  99 [01234]  rp27  motion_2015-12-20_12.37.07_1088.mp4
 100 [01234]  rp27  motion_2015-12-20_12.37.53_1089.mp4
 101 [01234]  rp30  motion_2015-12-20_12.38.00_266.mp4
 102 [01234]  rp22  motion_2015-12-20_12.40.03_107.mp4
 103 [01234]  rp22  motion_2015-12-20_12.41.07_108.mp4
 104 [01234]  rp30  motion_2015-12-20_12.41.48_270.mp4
 105 [01234]  rp27  motion_2015-12-20_12.46.47_1095.mp4
 106 [01234]  rp23  motion_2015-12-20_12.50.50_233.mp4
 107 [01234]  rp30  motion_2015-12-20_12.51.04_274.mp4
 108 [01234]  rp27  motion_2015-12-20_12.53.46_1099.mp4
 109 [01234]  rp22  motion_2015-12-20_12.56.13_115.mp4
 110 [01234]  rp23  motion_2015-12-20_12.57.44_238.mp4
 111 [01234]  rp23  motion_2015-12-20_12.58.56_239.mp4
 112 [0 234]  rp23  motion_2015-12-20_12.59.33_240.mp4
 113 [0 234]   rp2  motion_2015-12-20_12.59.54_5443.mp4
 114 [012  ]  rp30  motion_2015-12-20_13.00.06_282.mp4
 115 [ 1234]  rp27  motion_2015-12-20_13.07.09_1105.mp4
 116 [01234]  rp22  motion_2015-12-20_13.11.54_121.mp4
 117 [01234]  rp22  motion_2015-12-20_13.12.36_123.mp4
 118 [01234]  rp22  motion_2015-12-20_13.14.46_124.mp4
 119 [01234]  rp27  motion_2015-12-20_13.22.24_1109.mp4
 120 [01234]  rp27  motion_2015-12-20_13.31.27_1111.mp4
 121 [01234]  rp27  motion_2015-12-20_13.32.04_1112.mp4
 122 [0 234]  rp27  motion_2015-12-20_13.32.04_1112.mp4

In case of interest, it's a shell script to fetch the videos/ filenames, and a python program to analyze them.
https://github.com/jbeale1/PiCam1/blob/ ... adfiles.sh
https://github.com/jbeale1/PiCam1/blob/ ... l/proc1.py