RPi Cam Web Interface

[btidey]

HI Robert,

I finally limited the issue of not converting h264 to MP4 to two PI B+ 256MB. All the other 3 PI B+ 512MB are working fine. Therefore, I swapped these two 256MB model out for two 512MB model; and it works fine.

I would attribute this issue to some possible "not enough memory" cause. I was wondering whether you have some insights from your code that this RPI CAM might dictate minimum 512MB to work fine. FYI, I did have 128MB carved out for PI CAM in both 256MB model and 512MB model.

Hope you can confirm that this might be the issue.
Thanks a lot.

OK. That makes sense, I hadn't considered memory as an issue as I've only run on 512M units. It is probably MP4Box running out of memory and bailing out during its conversion, so .mp4 never gets produced and the .h264 is cleaned up. I'll do a bit of further checking on this.

Edit: Below are a couple of screenshots with the top command. These are on a B+ (Pi1) 512MB unit with standard raspbian.
First is normal background with one browser client attached, motion detection active and no recording / MP4Box.
Second is just after a manual recording is stopped so MP4Box is operational. Note that motion was off in this case so freeing up some memory.

Most interesting part is KiB Used which indicates MP4Box may be using quite a bit which in turn may take it over the top on an 256MB machine particularly if 128MB is reserved.

I can't see any MP4Box options to control memory usage. First thing to check would be if you can reduce the 128MB reserve a bit.

[piecam]

HI Robert,
Any ideas of how much Memory pi CAM actually needs, at least?
Based on forums and pi foundation, and raspbian, it defaults to 128MB reserved for pi CAM;although, it can goes lower to 64MB, etc.

some forums suggests that two low memory on Pi CAM may affect cam.

Not sure.
thanks

[RR4711]

Hi all, I installed the WebInterface and really love it. Great job!

What I couldn't find out yet: what is the easiest solution for auto-starting up the Time Lapse function on each reboot?
And where am I supposed to set the time lapse interval then? I didn't find any entries in the /etc/raspimjpeg that sound like archiving this functionality.

I mount my NAS to /var/www/media on each boot and just want to have timelapse to automatically save me a pic every 60s or so. If for any reason the raspi reboots, it should automatically go back into timelapse.

All hints appreciated.

Markus

[jarrah31]

The wiki you put together helped me a lot getting going and I appreciate that otherwise it can be tough for people faced with 65 pages plus of material to know how to set things up so it suits them.

Adding in some material to the wiki to cover my modifications sounds good. Below is a summary plus references. If you think more detail is needed then let me know.

Summary

Modifications of original code at https://github.com/roberttidey/RPi_Cam_Web_Interface

This is installed and updated in the same way as the original, just do the initial git clone from this repository.

Code: Select all

git clone https://github.com/roberttidey/RPi_Cam_Web_Interface.git

It extends the functionality in following ways

• Download Video and Images (preview) page shows thumbnails and capture details. Thumbnail and preview sizes may be customised per browser. Extra buttons allows for selective deletes and zip downloads directly from thumbnails. Time lapse recordings are grouped together into batches. A time lapse batch will download as a zip containing all the captured data.
• Scheduling page allows automation of capture settings and config split into daily periods based on sunrise and sunset. Enter latitude and longtitude and time zone to set up sunrise/set calculation, then put capture commands and operating mode for four daily periods. Schedule can also automate old capture purging.
• Motion page gives access to viewing and editing motion detection settings from the browser. Changes are applied immediately with no restarts required.
• Main page Camera settings shows current values and changes are remembered across stops, starts, reboots. Extra settings added for annotation and MP4Box control.
• Core software changes include more flexible file naming, subfolder support, v3 annotation, background MP4Boxing, user config support. It finds video and image indexes on start instead of installer script. More tolerant to on-line errors and formatting of commands.

Detailed description and screenshots at https://github.com/roberttidey/RPi_Cam_ ... RPiCam.pdf

Thanks!!

Just to verify so I can be clear on the wiki, is this a replacement installation or do we install this over the original? If the original is already installed, can yours be installed over the top or do we need to start from fresh?

b.t.w. it sounds even better than I originally thought due to the scheduling feature you have. I came back to this thread so I could set up a time-lapse outside, and being able to schedule this on and off will be really useful!

P.S. Your PDF instructions and the architecture diagram are brilliant!

[btidey]

Thanks!!

Just to verify so I can be clear on the wiki, is this a replacement installation or do we install this over the original? If the original is already installed, can yours be installed over the top or do we need to start from fresh?

b.t.w. it sounds even better than I originally thought due to the scheduling feature you have. I came back to this thread so I could set up a time-lapse outside, and being able to schedule this on and off will be really useful!

P.S. Your PDF instructions and the architecture diagram are brilliant!

It is a full fork of the silvanmelchior install, so one doesn't need that on first; one can just do it from github direct. If one has the silvanmelchior on already then it is probably easiest to delete or rename that RPI_Cam_Web_Interface folder and then git clone from mine.

The scheduler is currently geared to outside operation around sunrise and sunset so that it automatically adjusts through the year. I have been thinking of adding fixed time events as well which would be useful for either indoor operation or a fixed time lapse period like you mentioned.

[btidey]

HI Robert,
Any ideas of how much Memory pi CAM actually needs, at least?

Memory usage is always a tricky question as there are lots of factors.

Here are four measurements. All have memory total 381 MB total (512 - 128 GPU)

1) Pi running but raspimjpeg and Apache stopped. I.e no camera ops. 125MB used 255MB free
2) Apache and raspimjpeg running with motion detect active 147MB used 234MB free
3) As 2 but doing a video capture. 161MB used 219MB free
4) As 3 but MBoxing a previous capture + recording the next. 276MB used 104MB free

MBox is taking quite a lot. Probably should be done inline rather than background if one is tight on memory.

[Pitouk]

Hi there,

thanks for this wonderful interface! I had some fun trying it out, but did not get it to work when using a reverse proxy. I have Apache2 running on a RPi as a webserver to outside world, sitting between two firewalls. The apache2 accesses my internal lan by some port forwarding on the "inner" firewall (no direct route to outside world for the webcam streams).
To grant access from outside the apache2 works as a reverse proxy for some defined urls. Thus my webcam streams are password protected by the webserver, where you only have to log in once (and it _feels_ more secure this way).

When streaming just with "motion" this setup works well. When installing the RPi Cam Web Interface the shown page is incomplete. Reason seems to be that the scripts can't be found when proxiing. I guess it would need a fully qualified address in the webpage when calling the java scripts etc., but I cannot imagine how this should look like, because the adress varies when accessing from outside.
Anyone got a clue?

Thanks in advance!

[jarrah31]

Thanks - I've updated the wiki now, please let me know if anything needs changing.

Regarding the scheduler, I've noticed that the Current Time is incorrect.

For example, my Pi is set to the London timezone (which is now BST), and my time is 19:53. The date command shows 19:53, the timestamp on the video feed shows 19:53, the GMT Offset is 1, yet Current Time shows 18:53.

I basically want the scheduler to turn time-lapse off at night and back on again in the morning, yet I'm not fully clear on which fields I need to use. Looking at the PDF manual I think I have to use Dawn and Dusk fields right? My initial thought was to use Day thinking that this would turn the commands on/off just for day time, but I guess it means all day?

I'm still not sure though because Sunset is listed as 19:21, yet despite entering "tl 0" in the Dusk Commands_Off field, my camera is still taking time-lapse photos. Am I doing something wrong? (I have a Stop button so scheduler is running, and have Saved Settings too).

Thanks

[piecam]

HI Robert,

Just to report an observation that it seems two of pis (all are 512MB Pi B+) are still stuck in this mode for more than one hour. I had to ssh to the box and reboot the box. I checked memory usage with top and its around 300mb.

I manually converted the unfinished .h264 file using MP4Box. It looks that MP4Box might cause box stuck in this situation for unknown reasons. Any info that I can get from box to help figure out why?

thanks

[dutchronnie]

Thanks for this application, it is working well.
But i have one problem.
I always use chrome as browser, but there is always a thick black part in my screen with the text "RPi Cam Control v4.4.2R: mycam@raspberrypi" and it covers the top of the video image, and the buttons on the "download and video pages"

I it possible to change this?
Or is it an setting in the chrome browser

[btidey]

Thanks - I've updated the wiki now, please let me know if anything needs changing.

Regarding the scheduler, I've noticed that the Current Time is incorrect.

For example, my Pi is set to the London timezone (which is now BST), and my time is 19:53. The date command shows 19:53, the timestamp on the video feed shows 19:53, the GMT Offset is 1, yet Current Time shows 18:53.

I basically want the scheduler to turn time-lapse off at night and back on again in the morning, yet I'm not fully clear on which fields I need to use. Looking at the PDF manual I think I have to use Dawn and Dusk fields right? My initial thought was to use Day thinking that this would turn the commands on/off just for day time, but I guess it means all day?

I'm still not sure though because Sunset is listed as 19:21, yet despite entering "tl 0" in the Dusk Commands_Off field, my camera is still taking time-lapse photos. Am I doing something wrong? (I have a Stop button so scheduler is running, and have Saved Settings too).

Thanks

My time was 1 hour out this morning as well. I believe this is because the Pi defaults to UTC which is correct for GMT but does not include daylight time settings. I went into raspi-config and explicitly selected Europe/London (which I hadn't done before) and it then knew which zone to use for daylight saving and correctly reported the time without me touching the clock. If this doesn't work for you we will have to dig further.

The Commands On and Off are what the scheduler sends in response to motion detection start stops. If motion is off then there will be no start stops so they have no effect. The mode commands are sent when first entering that period. So if you had tl 1 as Day mode command and tl 0 as Dusk mode command then time lapse should be running from start of Day to start of Dusk.

[btidey]

Thanks for this application, it is working well.
But i have one problem.
I always use chrome as browser, but there is always a thick black part in my screen with the text "RPi Cam Control v4.4.2R: mycam@raspberrypi" and it covers the top of the video image, and the buttons on the "download and video pages"

I it possible to change this?
Or is it an setting in the chrome browser

The black bar is a title bar which is at the top of all screens and also acts as a back link. All other page content should be below this. I use Chrome on Windows as my main browser and I don't get this problem. It is probably a problem loading the css style sheets.

The other possibility is the screen resolution. What device are you running Chrome on?

If you view page source in chrome then it should start

Code: Select all

<!DOCTYPE html>
<html>
   <head>
      <meta name="viewport" content="width=550, initial-scale=1">
      <title>RPi Cam Control v4.4.2R: mycam@tideypicam1</title>
      <link rel="stylesheet" href="css/style_minified.css" />
      <link rel="stylesheet" href="css/extrastyle.css" />
      <script src="js/style_minified.js"></script>
      <script src="js/script.js"></script>
      <script src="js/pipan.js"></script>
   </head>
   <body onload="setTimeout('init();', 100);">
      <div class="navbar navbar-inverse navbar-fixed-top" role="navigation"style="display:block;">
         <div class="container">
            <div class="navbar-header">
               <a class="navbar-brand" href="#">RPi Cam Control v4.4.2R: mycam@tideypicam1</a>
            </div>
         </div>
      </div>

If you use Chrome developer tools, set to network and load main page again then you should see style_minified.css file being fetched straight after the index.php. If that looks OK then it could be some local Chrome setting. Try Firefox as an experiment to check out if this is the case.

[btidey]

HI Robert,

Just to report an observation that it seems two of pis (all are 512MB Pi B+) are still stuck in this mode for more than one hour. I had to ssh to the box and reboot the box. I checked memory usage with top and its around 300mb.

I manually converted the unfinished .h264 file using MP4Box. It looks that MP4Box might cause box stuck in this situation for unknown reasons. Any info that I can get from box to help figure out why?

thanks

That status says that it is a motion detected start video state. I.e it has received a motion start command but has not yet received a motion stop command. Scheduler log should show the start and stop requests being received and the outward commands sent to raspimjpeg. Also scheduler should send a stop after max_capture even if no stop is received from motion.

So some possibilities are

1) No stop request received from motion, and no max_capture set up

2) Scheduler has a translate for On to ca 1 but not a corresponding ca 0 for off, and no max_capture set up. Note that it uses the off command for the same period as the start even if the period changes during the capture.

3) Bug

[piecam]

Hi Robert,
here's the schedule log, the last part pertaining to this "stuck" issue.

from first pi with issue:
[2015/Mar/29 15:19:25] Stop capture requested
[2015/Mar/29 15:19:25] Send ca 0
[2015/Mar/29 15:19:27] Ignore FIFO char

[2015/Mar/29 15:59:10] Scheduled management tasks
[2015/Mar/29 17:00:55] Scheduled management tasks
[2015/Mar/29 18:02:39] Scheduled management tasks

From 2nd pi with issue:
[2015/Mar/29 16:04:19] Send ca 1
[2015/Mar/29 16:04:58] Stop capture requested
[2015/Mar/29 16:04:58] Send ca 0
[2015/Mar/29 16:57:21] Scheduled management tasks
[2015/Mar/29 17:58:49] Scheduled management tasks

From 3rd pi without issue:
[2015/Mar/29 16:04:21] Start capture requested
[2015/Mar/29 16:04:21] Send ca 1
[2015/Mar/29 16:04:32] Ignore FIFO char

[2015/Mar/29 16:04:34] Stop capture requested
[2015/Mar/29 16:04:34] Send ca 0
[2015/Mar/29 16:04:36] Ignore FIFO char

[2015/Mar/29 16:37:31] Scheduled management tasks
[2015/Mar/29 17:39:21] Scheduled management tasks

Just did a "reboot system" in GUI and it came back as same status.... Not sure whether it's something wrong with browser cache, but the clock ticking correctly on the screen.

Did a ssh reboot, it seems coming back at correct state.
Any possible chance of being a bug? Let me know if you need more info.

thanks

[jarrah31]

My time was 1 hour out this morning as well. I believe this is because the Pi defaults to UTC which is correct for GMT but does not include daylight time settings. I went into raspi-config and explicitly selected Europe/London (which I hadn't done before) and it then knew which zone to use for daylight saving and correctly reported the time without me touching the clock. If this doesn't work for you we will have to dig further.

The Commands On and Off are what the scheduler sends in response to motion detection start stops. If motion is off then there will be no start stops so they have no effect. The mode commands are sent when first entering that period. So if you had tl 1 as Day mode command and tl 0 as Dusk mode command then time lapse should be running from start of Day to start of Dusk.

The time on my Pi was originally out as well, but I had already gone into rasps-config to set Europe/London before posting about the error, so it must be something else for me I'm afraid. It is very odd because everywhere has the correct time except the scheduler:

Code: Select all

pi@raspberrypi ~ $ cat /etc/timezone
Europe/London
pi@raspberrypi ~ $ date
Mon Mar 30 08:41:31 BST 2015
pi@raspberrypi ~ $

Current Time on scheduler: 07:41

Edit - rebooting the Pi fixed the Current Time issue!

Regarding the scheduler, thanks for the tip about entering the tl commands in Modes. I'll see if that turns off time-lapse this evening.

Quick question, what's the difference between the Day and Dawn start times? I guess they both will always start at Sunrise right? Except if DawnStart_Minutes was -60 then the entered commands in Dawn would start 1 hour before Sunrise?

Once I understand all this I'll add a section in the wiki.

Another Quick question, in the PDF manual it says the following about time-lapse commands:

tl 0/n Stop/Start timelapse.

Should it be 0/1?

[Sephiron]

Robert, thanks for the continued work on the project. After updating to your version I have two main questions:
-First: How do I enable servos? I renamed pipan_off to pipan_on, but servo-buttons on the server don't work (they worked on silvanmelchiors version). Do I need to do something else in addition to that?
- Secondly: About the motion.conf parameters visible on the web. There are two parameters I would want to be visible in addition to the ones already there: post_capture and pre_capture. What do I need to do to add them?

Thanks again for the great work!

P.S. What is the best place to make the camera flip picture vertically by default and take the video at 720p instead of 1080? So that I don't have to change it from browser every time I reboot.

[btidey]

Robert, thanks for the continued work on the project. After updating to your version I have two main questions:
-First: How do I enable servos? I renamed pipan_off to pipan_on, but servo-buttons on the server don't work (they worked on silvanmelchiors version). Do I need to do something else in addition to that?
- Secondly: About the motion.conf parameters visible on the web. There are two parameters I would want to be visible in addition to the ones already there: post_capture and pre_capture. What do I need to do to add them?

Thanks again for the great work!

P.S. What is the best place to make the camera flip picture vertically by default and take the video at 720p instead of 1080? So that I don't have to change it from browser every time I reboot.

The pipan_on file just enables showing the buttons on the web interface and links them to the panpio.js script. This is to avoid having to do this if you update the web site which would lose those changes. Previously you had to edit web files and those would have been lost when www was updated. You still have to do the rest of the panpio support (python etc) as detailed on the wiki http://elinux.org/RPi-Cam-Web-Interface but once done and working then www updates should not overwrite stuff. If you have done all that and it still isn't working, let me know as I haven't tried it myself with panpio.

motion settings displays a shortened version by default but you can get to every setting by using the show all button. The shortened list is defined at the top of the motion.php file so could be changed to show other stuff if required. I didn't include post_capture and pre_capture in the short list as I don't think they will have any effect. They apply if motion is doing the actual capture but that is not the case here where it is just used to provide stop and start triggers and then raspimjpeg does the capture. post_capture can be achieved by increasing Gap (the period of non-motion before a stop is sent). pre_capture is something we'd all like to get as there can be some lost time at the start. This needs some changes to raspimjpeg itself so that it is continuously capturing into a buffer that can then be used when a start occurs. I have plans to do this at some point but it is quite a complex change.

Changes to camera settings from the web interface like flip and resolution should be preserved to a file called uconfig in the www folder and reloaded every time the camera starts like at reboot. They can also be put permanently into the default settings file /etc/raspimjpeg but that shouldn't be necessary. If that is not working for you first check uconfig (nano /var/www/uconfig) after setting flip to vertical. You should see a setting called vflip true in there. The only other thing I can think of is that the main /etc/raspimjpeg config file should have a setting user_config /var/www/uconfig that tells it to use this user settings file. If you had an old config without this in then these settings from the web would not be reloaded.

[btidey]

Scheduler change to allow fixed times to be used instead of sunrise/sunset based times.
There are now 3 period change modes. Sun based like the original, All day which used to be a check box, and the new Fixed times. Only one is in operation you can't mix sun based and Fixed times. The command/ mode table is reworked to accommodate the new periods.

Fixed times gives up to 6 absolute times during the 24 hour period set in HH:MM format (24 hour). They do not have to be defined in any order and if left blank will be ignored. They operate in same way as Sun based; motion triggers are translated by the on and off commands, and modes are sent at the start of each period. If you want to define a capture lasting between 2 times then define the 2 times and put a capture start (e.g. ca 1) in the mode field of the first and a capture stop in the mode field of the second.

[btidey]

Quick question, what's the difference between the Day and Dawn start times? I guess they both will always start at Sunrise right? Except if DawnStart_Minutes was -60 then the entered commands in Dawn would start 1 hour before Sunrise?

Once I understand all this I'll add a section in the wiki.

Another Quick question, in the PDF manual it says the following about time-lapse commands:

tl 0/n Stop/Start timelapse.

Should it be 0/1?

Scheduler calculates sunrise and sunset every Mode_Poll check interval. A dawn start is then calculated by adding DawnStart_Minutes to sunrise (normally negative to make Dawn start before sunrise). Similarly a Day start is sunrise + DayStart_Minutes. Dawn is then the period from Dawn start till Day start. Day then begins until sunset + DayEndMinutes. Dusk then starts and continues to sunset + DuskEnd_Minutes. Night then starts until the following Dawn.

Yes, thanks, tl should now be 0 (stop) and 1 (start). The interval is separately stored and used (tv command). I've corrected the PDF for the next time I push to Git.

[Sephiron]

motion settings displays a shortened version by default but you can get to every setting by using the show all button. The shortened list is defined at the top of the motion.php file so could be changed to show other stuff if required. I didn't include post_capture and pre_capture in the short list as I don't think they will have any effect. They apply if motion is doing the actual capture but that is not the case here where it is just used to provide stop and start triggers and then raspimjpeg does the capture. post_capture can be achieved by increasing Gap (the period of non-motion before a stop is sent). pre_capture is something we'd all like to get as there can be some lost time at the start. This needs some changes to raspimjpeg itself so that it is continuously capturing into a buffer that can then be used when a start occurs. I have plans to do this at some point but it is quite a complex change.

It seems I am blind, since I didn't notice that button at all. Thanks for pointing it out.

Changes to camera settings from the web interface like flip and resolution should be preserved to a file called uconfig in the www folder and reloaded every time the camera starts like at reboot. They can also be put permanently into the default settings file /etc/raspimjpeg but that shouldn't be necessary. If that is not working for you first check uconfig (nano /var/www/uconfig) after setting flip to vertical. You should see a setting called vflip true in there. The only other thing I can think of is that the main /etc/raspimjpeg config file should have a setting user_config /var/www/uconfig that tells it to use this user settings file. If you had an old config without this in then these settings from the web would not be reloaded.

Yep this works and is just what I required.

The pipan_on file just enables showing the buttons on the web interface and links them to the panpio.js script. This is to avoid having to do this if you update the web site which would lose those changes. Previously you had to edit web files and those would have been lost when www was updated. You still have to do the rest of the panpio support (python etc) as detailed on the wiki http://elinux.org/RPi-Cam-Web-Interface but once done and working then www updates should not overwrite stuff. If you have done all that and it still isn't working, let me know as I haven't tried it myself with panpio.

I actually followed these steps. The only change I made is that I moved pipan.js into /var/www/ instead of /var/www/js and modified index.php accordingly. The servos work (I tested it with test scripts), but the buttons don't do anything, even though all the necessary scripts are enabled according to instructions. I just don't see what is wrong there.

[piecam]

test

[piecam]

Yes, thanks, tl should now be 0 (stop) and 1 (start). The interval is separately stored and used (tv command). I've corrected the PDF for the next time I push to Git.

HI Robert,
We used to have on GUI, night command on (tl 20) command off (tl 0). Do you mean that this has to be changed to tl1 and tl0?

If so, the interval is defined by tv? where's tv field in GUI. Couldn't find it.

Hope you can help clear this confusion for me. Thanks

[ludespeedny]

What is the best FPS I can achieve from a normal camera board running in night mode?

[btidey]

HI Robert,
We used to have on GUI, night command on (tl 20) command off (tl 0). Do you mean that this has to be changed to tl1 and tl0?

If so, the interval is defined by tv? where's tv field in GUI. Couldn't find it.

Hope you can help clear this confusion for me. Thanks

Previously the time lapse button used to send tl + whatever the delay set under camera settings in the browser to start it, and tl 0 to stop it. raspimjpeg took the delay value of the tl command. The problem with this was that delay setting was not remembered from one browser session to the next.

I did initially separately capture the value set but it was messy, so I decided to treat the delay value like all the other settings. raspimjpeg has it as a new internal value and changes from the web are stored in uconfig like all the others. It uses the tv command to do this. So when you change the delay setting under camera settings it uses the tv command to store the new value. This does not trigger a time lapse recording, just sets the value like all the other parameters.

tl is still used to start and stop time lapse recordings but now the delay value is whatever was last set by the tv command. So tl 1 starts a recording and tl 0 stops it, just like ca 1 and ca 0 for video. Actually any non zero value starts a recording so tl 20 will still work but the delay will be set by the last tv command and not by the 20. To avoid confusion I recommend changing any tl start command to 1 so that it is clear it is just a trigger and nothing to do with the delay used.

If you want to change the delay value according to the time of day in the scheduler then you can do that by using the tv command before the tl in the scheduler.

[btidey]

What is the best FPS I can achieve from a normal camera board running in night mode?

I believe some of the exposure modes including night set their own frame rate and the video fps would get ignored. MP4Box fps would still be applied though.

I think night is around 4fps.

One could use normal expose and set one's own frame rate but I'm not sure whether that achieves the same thing.