search

AndreaFavero71 / timelapse

Timelapse based on Raspberry Pi 4b and PiCamera V3 wide
MIT License
7 stars 0 forks source link

Recovery from power outage and shoot above a lux threshold (Construction Cam) #2

Open weedy171 opened 1 month ago

weedy171 commented 1 month ago

Love the project. Not really an issue, but wondering if you have any suggestion in setting it up so it only records during the daylight between sunrise and sunset. I would like to use your project for a small construction project that is going to last about 3 months.

Thanks !

AndreaFavero71 commented 1 month ago

Hi, the code Is not linked with a calendar, therefore it isn't possible to start shooting at sunrise and stop at sunset. The code accepts a start time, a stop time, and eventually the number of days to repeat the shooting between start and stop. During the construction, I would recommend to approach the Raspberry Pi from time to time, and discharge the pictures or the video clips. This to backup the data, preventing total loss in case of a any issue, for instance the microSD getting corrupted.

weedy171 commented 1 month ago

Appreciate the suggestions. I did find a script that will look at images and determine if they are black. I think I am having some trouble though with my settings. I am hoping to set my timelapse to run every day and take a picture at 600 seconds for three months. I was thinking about rebooting the device nightly as well(or might change it to the week) Thinking about recovery if a power outage was to occur and where it could pick up where its at.

{ "preview": "False", "erase_pics": "False", "erase_movies": "False",

"local_control": "False", "start_now": "True", "period_hhmm": "01:00", "start_hhmm": "00:01", "end_hhmm": "23:59", "interval_s": "600", "days": "120",

"rendering": "False", "fix_movie_t": "False", "movie_time_s": "20", "fps": "24", "overlay_fps": "False", "overlay_text": "",

"camera_w": "1920", "camera_h": "1080", "hdr": "True", "autofocus": "True", "focus_dist_m": "0.1", "date_folder": "True", "folder": "timelapse_pics", "parent_folder": "/home/weedy/shared", "pic_name": "picture", "pic_format": "jpg", "rotate_180": "False",

"display": "True", "modified_disp": "False", "disp_preview": "False", "disp_image": "False", "disp_rotation": "90", "disp_bright": "100", "disp_width": "240", "disp_height": "240", "disp_offsetL": "0", "disp_offsetT": "0" }

AndreaFavero71 commented 1 month ago

Hi, getting the code starting automatically at the boot is rather easy, I'll follow up. The current code is not meant to restart from where it left, but it makes a lot of sense in case of power outage. Once back from holiday I'll modify the code. When is the construction going to start? When will you have the setup ready for testing?

Considering the expected large variation of light condition, strongly suggested a camera with HDR function, so the V3 normal or the V3 wide.

Also recommended to set a couple of wifi addresses at the Raspberry Pi, one of them with your laptop hotspot (Windows allows it if the PC has a wifi connection, that could be to your phone hotspot)

For the settings, there is a bit more explanation at the Instructables project page. Considering your scope, I'd set start_hhmm when the daily activities are expected to start, let say 0700. Similarly, the stop__hhmm when the daily activities are supposed to stop, let say 1900. I'd also reduce the interval_s to 300 seconds, and eventually double the frames per second of the video clip, for a smoother result. Total quantity of images are still manageable, so the memory. I have a few more notes about settings, but those will come later

weedy171 commented 1 month ago

Thanks again for your replies. My construction project is starting the end of next month. I was starting to play around with it to get a feel for the size of pictures and how often I would need to get grab them and how well it would work on recovery of power loss if their was any(don’t have a way to put a UPS outside)

I am using this camera https://www.adafruit.com/product/5658 -- I tried a higher resolution 4608 × 2592 pixels but it was not happy about that.

From: Andrea @.> Sent: Sunday, July 28, 2024 3:10 PM To: AndreaFavero71/timelapse @.> Cc: weedy171 @.>; Author @.> Subject: Re: [AndreaFavero71/timelapse] Construction Cam (Issue #2)

Hi, getting the code starting automatically at the boot is rather easy, I'll follow up. The current code is not meant to restart from where it left, but it makes a lot of sense in case of power outage. Once back from holiday I'll modify the code. When is the construction going to start? When will you have the setup ready for testing?

Considering the expected large variation of light condition, strongly suggested a camera with HDR function, so the V3 normal or the V3 wide.

Also recommended to set a couple of wifi addresses at the Raspberry Pi, one of them with your laptop hotspot (Windows allows it if the PC has a wifi connection, that could be to your phone hotspot)

For the settings, there is a bit more explanation at the Instructables project pagehttps://www.instructables.com/Timelapse-With-Raspberry-Pi-4b-and-PiCamera-V3-wid/. Considering your scope, I'd set start_hhmm when the daily activities are expected to start, let say 0700. Similarly, the stop__hhmm when the daily activities are supposed to stop, let say 1900. I'd also reduce the interval_s to 300 seconds, and eventually double the frames per second of the video clip, for a smoother result. Total quantity of images are still manageable, so the memory. I have a few more notes about settings, but those will come later

— Reply to this email directly, view it on GitHubhttps://github.com/AndreaFavero71/timelapse/issues/2#issuecomment-2254631191, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQNONYQLIIPCLAEK6HCL73ZOVF3FAVCNFSM6AAAAABLLMXR5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJUGYZTCMJZGE. You are receiving this because you authored the thread.Message ID: @.**@.>>

AndreaFavero71 commented 1 month ago

Hi, that camera supports the HDR (strongly suggested to use it) by reducing the resolution to the HD format. Depending on the subject, the JPG file might take from 250Kb (large uniform areas) to 600Kb (small uniform areas). I believe, by mid of August, I'll be able to add the info for the automatic start after booting, and the code change to proceed with pictures' names from where it was before an eventual power outage....

AndreaFavero71 commented 1 month ago

Hi, commit https://github.com/AndreaFavero71/timelapse/commit/446d9d87d2f314cf2838b3b48ed6f066d5fe37ee should prevent pictures from being overwritten after a recovery from power outage. This feature requires two mandatory settings: "date_folder" : "False" and "erase_pics" : "False" After recovering from power outage, the code checks:

  1. the incremental suffix of the latest picture, as starting reference for the upcoming picture.
  2. how many days were already done (partial or full days without power are also counted as done).



Some notes on the settings: { "preview": "False", (I would consider True: you can check the scene by approacing the Raspberry Pi with a laptop) "erase_pics": "False", (Must remain False, to prevent pictures from being overwritten after a recovery from power outage) "erase_movies": "False", (ok)

"local_control": "False", (ok) "start_now": "True", (Must be changed to False, for multi days shooting) "period_hhmm": "01:00", (not relevant when start_now is set False) "start_hhmm": "00:01", (I woul consider 06:00 or a realistic time when operations start at the construction) "end_hhmm": "23:59", (I woul consider 1900 or a realistic time when operations stop at the construction) "interval_s": "600", (I would consider 300, or 180, to increase video smootness, You can increase FPS to shorten the video) "days": "120", (ok)

"rendering": "False", (ok) "fix_movie_t": "False", (not relevant when rendering is set False) "movie_time_s": "20", (not relevant when rendering is set False) "fps": "24", (not relevant when rendering is set False) "overlay_fps": "False", (not relevant when rendering is set False) "overlay_text": "", (not relevant when rendering is set False)

"camera_w": "1920", (ok) "camera_h": "1080", (ok) "hdr": "True", (ok) "autofocus": "True", (ok) "focus_dist_m": "0.1", (not relevant when autofocus is set True) "date_folder": "True", (Must be set as False, to allow recovery from power outage) "folder": "timelapse_pics", (ok. This folder will contain the pictures. This older will be appended to the parent_folder) "parent_folder": "/home/weedy/shared", (ok) "pic_name": "picture", (ok) "pic_format": "jpg", (ok) "rotate_180": "False", (depends if the camera is suspended upside down)

"display": "True", (depends if you have added the display to the Raspberry Pi) "modified_disp": "False", "disp_preview": "False", "disp_image": "False", "disp_rotation": "90", "disp_bright": "100", "disp_width": "240", "disp_height": "240", "disp_offsetL": "0", "disp_offsetT": "0" }



For the automated start of the code, after the Raspberry Pi boot, check this part https://github.com/AndreaFavero71/timelapse#automatic-script-starting-at-boot Of course, you have to adjust your user name if no 'pi'

Recommended to set a couple of wifi addresses at the Raspberry Pi, one of them with your laptop hotspot (Windows allows it if the PC has a wifi connection, that could be to your phone hotspot).

Please run some multi days test, with and without power outage.

To limit damages ad the microSD, a power interruption can be made by killing the timelapse processes. To check the processes involved, from the terminal type: ps aux | grep timelapse Kill first the bash process, by using its process number (number on the second column, after the user): sudo kill -9 followed by one space and the process number (i.e. sudo kill -9 456) Kill after the python proces, again by using its process number (number on the second column, after the user): sudo kill -9 followed by one space and the process number (i.e. sudo kill -9 678)



I'm holiday, and I've tested this commit with a Zero 2W and Picamera V1.3: It seems working fine. Please feedback is it works fine at your end too.

weedy171 commented 1 month ago

Thanks for looking into this while you are on holiday. I updated the latest py and updated my settings to the following. I noticed it created the folder "timelapse_pics" inside my shared but don't see any pictures in it. I was able prior to get the autostart the py while and the old py was generating images.

{ "preview": "True", "erase_pics": "False", "erase_movies": "False",

"local_control": "False", "start_now": "False", "period_hhmm": "8760:00", "start_hhmm": "06:00", "end_hhmm": "19:00", "interval_s": "180", "days": "120",

"rendering": "False", "fix_movie_t": "False", "movie_time_s": "20", "fps": "24", "overlay_fps": "False", "overlay_text": "",

"camera_w": "1920", "camera_h": "1080", "hdr": "True", "autofocus": "True", "focus_dist_m": "0.1", "date_folder": "False", "folder": "timelapse_pics", "parent_folder": "/home/weedy/shared", "pic_name": "picture", "pic_format": "jpg", "rotate_180": "False",

"display": "False", "modified_disp": "False", "disp_preview": "False", "disp_image": "False", "disp_rotation": "90", "disp_bright": "100", "disp_width": "240", "disp_height": "240", "disp_offsetL": "0", "disp_offsetT": "0" }

AndreaFavero71 commented 1 month ago

Hi, when the code is started at the boot (crontab), all the prints will be saved in the text file timelapse_terminal.log.

Everytime the Raspberry Pi boots, the same file will be used (over written) Please boot the system again, and check the content of that file within the expected shooting period of the day. In case or errors indications, share the complete file to @.*** Perhaps good to share it anyhow.

I'm going to be driving the coming days, therefore I'll be rather limited ... yet good for me to start thinking what goes grong and why.

On Thu, 8 Aug 2024, 03:30 weedy171, @.***> wrote:

Thanks for looking into this while you are on holiday. I updated the latest py and updated my settings to the following. I noticed it created the folder "timelapse_pics" inside my shared but don't see any pictures in it. I was able prior to get the autostart the py while and the old py was generating images.

{ "preview": "True", "erase_pics": "False", "erase_movies": "False",

"local_control": "False", "start_now": "False", "period_hhmm": "8760:00", "start_hhmm": "06:00", "end_hhmm": "19:00", "interval_s": "180", "days": "120",

"rendering": "False", "fix_movie_t": "False", "movie_time_s": "20", "fps": "24", "overlay_fps": "False", "overlay_text": "",

"camera_w": "1920", "camera_h": "1080", "hdr": "True", "autofocus": "True", "focus_dist_m": "0.1", "date_folder": "False", "folder": "timelapse_pics", "parent_folder": "/home/weedy/shared", "pic_name": "picture", "pic_format": "jpg", "rotate_180": "False",

"display": "False", "modified_disp": "False", "disp_preview": "False", "disp_image": "False", "disp_rotation": "90", "disp_bright": "100", "disp_width": "240", "disp_height": "240", "disp_offsetL": "0", "disp_offsetT": "0" }

— Reply to this email directly, view it on GitHub https://github.com/AndreaFavero71/timelapse/issues/2#issuecomment-2274740743, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZYVQEYTX2DXMNLROQVE6J3ZQLCZZAVCNFSM6AAAAABLLMXR5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZUG42DANZUGM . You are receiving this because you commented.Message ID: @.***>

weedy171 commented 1 month ago

I just checked this morning and it started taking pictures at the start period. I will have to play with it later in the day to see if a reboot of the device makes it still work.

weedy171 commented 1 month ago

I think I figured it out, I had the end time set earlier in the night compared to when i was working on the script. It appears to be working. I will play around with it some more. Do you think the resolution I have set could be any better or you think that is good for the Camera 3?

AndreaFavero71 commented 1 month ago

Hi, sounds good. 1920x1080 is the max resolution for the V3 camera, when HDR is set True. The video clip will be HD.

AndreaFavero71 commented 1 month ago

Hi, the just release commit (https://github.com/AndreaFavero71/timelapse/commit/f435cf39e1a4b105b8052582787631e12a74205c) solves a couple of bugs from the previous commit. Additionally, it adds the possibility to only shoot when the camera estimated Lux is above a threshold; This should answer the original request, based on illuminance instead of sunrise and sunset time. Below snippet is from the top part of the "main" function:

    ################    mix lux level check (optional)   ###########################################

    # Lux levels from https://en.wikipedia.org/wiki/Daylight
    # 120000        Brightest sunlight
    # 111000        Bright sunlight
    # 109880        AM 1.5 global solar spectrum sunlight (= 1,000.4 W/m2)[3][circular reference]
    # 20000         Shade illuminated by entire clear blue sky, midday
    # 1000 – 2000   Typical overcast day, midday
    # 400           Sunrise or sunset on a clear day (ambient illumination)
    # <200          Extreme of thickest storm clouds, midday
    # 40            Fully overcast, sunset/sunrise
    # <1            Extreme of thickest storm clouds, sunset/rise

    lux_check = False                          # flag to suject the shooting to a min Lux value
    min_lux_threshold = 30                     # minimum Lux threshold, when lux_check is set True
    # ##############################################################################################

If the lux_check is set True (default is False) the code only grabs a picture if the camera's estimated Lux is above the min_lux_threshold. Remaining functionality does not change.

I don't have experience to judge how well the PiCamera V3 estimates the Lux. As a test, yesterday evening I set the camera to start shooting today from 3.00am and it started at 5:40am ... literally when half sun was above the horizion, according to internet sunrise info where I live. The min_lux_threshold was set to 30. The min_lux_threshold also works to stop shooting once the illuminance drop at sunset.

For the Contruction Cam I'd advise to set the start_hhmm not too much earlier than the expected time there will be construction activity (let's say 7.00), and the stop_hhmm not too much later than the expected time the construction activity are going to finish (let's say 21.00). This will prevent to have excess of similar pictures .... Of course, the Lux control can be used to take pictures as long as the camera sees enough illuminance.

weedy171 commented 4 weeks ago

I noticed powering off the device and powering it back on it did not recover. I am guessing tomorrow it will start over.

Local control is disabled Picture resolution: 1920x1080 Picture format: jpg Picture file size 0.28 Mb (picture size varies on subject and light!) Free disk space: 111297 Mb Rough max number of pictures: 397489 Day 4 of 120 Shooting starts: 10:13:00 Shooting ends: 21:00:00 Shooting starts in: 0:00:17 Shooting every: 180 seconds Camera will take: 216 pictures today Timelapse video render not activated Display at Raspberry Pi not activated ############################################################################## ##############################################################################

14 Aug 2024 10:12:55 frame: 00000 ***** 14 Aug 2024 12:42:53 frame: 00050 **

AndreaFavero71 commented 4 weeks ago

Hi, could you elaborate a bit more? Was the power off within your time 10:13:00 and 21:00:00? Any chance the powering on happened at about your time 10:13:00? I'd expect this as a start_hhmm 10:13:00 seems defined by the code when powered after the intended start_hhmm (i.e. 07:00). Was the power off a hardware disconnection?

weedy171 commented 4 weeks ago

Looks like around 1:24PM. I unplugged the cable. The last picture was taken on 8/14/2024

The start and stop isn't different from my last settings I posted but whats interesting is I rebooted normally and I was going to review the settings and now it says its open by a PID 1447. I ran top but could not find the process tied to it.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Andrea @.> Sent: Wednesday, August 14, 2024 4:45:41 PM To: AndreaFavero71/timelapse @.> Cc: weedy171 @.>; Author @.> Subject: Re: [AndreaFavero71/timelapse] Recovery from power outage and shoot above a lux threshold (Construction Cam) (Issue #2)

Hi, could you elaborate a bit more? Was the power off within your time 10:13:00 and 21:00:00? Any chance the powering on happened at about your time 10:13:00? I'd expect this as a start_hhmm 10:13:00 seems defined by the code when powered after the intended start_hhmm (i.e. 07:00). Was the power off a hardware disconnection?

- Reply to this email directly, view it on GitHubhttps://github.com/AndreaFavero71/timelapse/issues/2#issuecomment-2289973715, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQNON5KUDTKVQMQ3EOOP2DZRPFYLAVCNFSM6AAAAABLLMXR5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBZHE3TGNZRGU. You are receiving this because you authored the thread.Message ID: @.***>

AndreaFavero71 commented 4 weeks ago

Have you checked if picture were saved in folder, from 1.25pm onward, and the terminal.log file?

On Thu, 15 Aug 2024, 00:36 weedy171, @.***> wrote:

Looks like around 1:24PM. I unplugged the cable. The last picture was taken on 8/14/2024

The start and stop isn't different from my last settings I posted but whats interesting is I rebooted normally and I was going to review the settings and now it says its open by a PID 1447. I ran top but could not find the process tied to it.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Andrea @.> Sent: Wednesday, August 14, 2024 4:45:41 PM To: AndreaFavero71/timelapse @.> Cc: weedy171 @.>; Author @.> Subject: Re: [AndreaFavero71/timelapse] Recovery from power outage and shoot above a lux threshold (Construction Cam) (Issue #2)

Hi, could you elaborate a bit more? Was the power off within your time 10:13:00 and 21:00:00? Any chance the powering on happened at about your time 10:13:00? I'd expect this as a start_hhmm 10:13:00 seems defined by the code when powered after the intended start_hhmm (i.e. 07:00). Was the power off a hardware disconnection?

- Reply to this email directly, view it on GitHub< https://github.com/AndreaFavero71/timelapse/issues/2#issuecomment-2289973715>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ACQNON5KUDTKVQMQ3EOOP2DZRPFYLAVCNFSM6AAAAABLLMXR5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBZHE3TGNZRGU

. You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/AndreaFavero71/timelapse/issues/2#issuecomment-2290036002, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZYVQE42CSC7GINO3WI3QQDZRPLW5AVCNFSM6AAAAABLLMXR5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJQGAZTMMBQGI . You are receiving this because you commented.Message ID: @.***>

weedy171 commented 4 weeks ago

In pervious days yes they were onwards after 1:25pm. The terminal log is what I posted prior. It appears after a couple a sudo reboots its started working on its own last night.

From: Andrea @.> Sent: Wednesday, August 14, 2024 11:10 PM To: AndreaFavero71/timelapse @.> Cc: weedy171 @.>; Author @.> Subject: Re: [AndreaFavero71/timelapse] Recovery from power outage and shoot above a lux threshold (Construction Cam) (Issue #2)

Have you checked if picture were saved in folder, from 1.25pm onward, and the terminal.log file?

On Thu, 15 Aug 2024, 00:36 weedy171, @.<mailto:@.>> wrote:

Looks like around 1:24PM. I unplugged the cable. The last picture was taken on 8/14/2024

The start and stop isn't different from my last settings I posted but whats interesting is I rebooted normally and I was going to review the settings and now it says its open by a PID 1447. I ran top but could not find the process tied to it.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Andrea @.<mailto:@.>> Sent: Wednesday, August 14, 2024 4:45:41 PM To: AndreaFavero71/timelapse @.<mailto:@.>> Cc: weedy171 @.<mailto:@.>>; Author @.<mailto:@.>> Subject: Re: [AndreaFavero71/timelapse] Recovery from power outage and shoot above a lux threshold (Construction Cam) (Issue #2)

Hi, could you elaborate a bit more? Was the power off within your time 10:13:00 and 21:00:00? Any chance the powering on happened at about your time 10:13:00? I'd expect this as a start_hhmm 10:13:00 seems defined by the code when powered after the intended start_hhmm (i.e. 07:00). Was the power off a hardware disconnection?

- Reply to this email directly, view it on GitHub< https://github.com/AndreaFavero71/timelapse/issues/2#issuecomment-2289973715>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ACQNON5KUDTKVQMQ3EOOP2DZRPFYLAVCNFSM6AAAAABLLMXR5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBZHE3TGNZRGU

. You are receiving this because you authored the thread.Message ID: @.<mailto:@.>>

— Reply to this email directly, view it on GitHub https://github.com/AndreaFavero71/timelapse/issues/2#issuecomment-2290036002, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZYVQE42CSC7GINO3WI3QQDZRPLW5AVCNFSM6AAAAABLLMXR5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJQGAZTMMBQGI . You are receiving this because you commented.Message ID: @.<mailto:@.>>

— Reply to this email directly, view it on GitHubhttps://github.com/AndreaFavero71/timelapse/issues/2#issuecomment-2290534809, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQNONYOFAWUP2MKZ7CXCG3ZRQSZDAVCNFSM6AAAAABLLMXR5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJQGUZTIOBQHE. You are receiving this because you authored the thread.Message ID: @.**@.>>

AndreaFavero71 commented 3 weeks ago

Hi, after a power outage, the code is started automatically at the boot, and if you reconnect to the Raspberry Pi you won't see the prints made by code to the terminal ... yet prints are redirected to a text file: /timelapse/timelapse_terminal.log (this is what I meant as "terminal.log file"). So you can open that text file, to see what kind of feedback the code is printing out, further than checking the timestamp of the pictures in folder.

Be aware the boot takes a couple of minutes and the first picture will be taken at about the next minute change; When waiting, without doing anything else, this time seems even longer and it might let you think the code not being active .... Having the mini display on the Raspberry Pi makes life easier :-)

On the tests I performed, everything was working fine. Overall, I have hard time to follow the chain of events at your end, I'm afraid it requires more detailed and clear info from you.

weedy171 commented 3 weeks ago

Thanks for the replies. I was playing around with it tonight and doing a couple of power outage simulations and do not see the same results like I reported prior. I haven’t had a chance to play around with the daylight setting. I might just leave it alone. I plan on checking the camera at least once a week and grab the pictures and feel comfortable with what I have setup. Appreciate the code fix and the contributions for this project. I know some linux stuff but I am not around it lot, so its fun to play around this stuff too.

From: Andrea @.> Sent: Thursday, August 15, 2024 1:37 PM To: AndreaFavero71/timelapse @.> Cc: weedy171 @.>; Author @.> Subject: Re: [AndreaFavero71/timelapse] Recovery from power outage and shoot above a lux threshold (Construction Cam) (Issue #2)

Hi, after a power outage, the code is started automatically at the boot, and if you reconnect to the Raspberry Pi you won't see the prints made by code to the terminal ... yet prints are redirected to a text file: /timelapse/timelapse_terminal.log (this is what I meant as "terminal.log file"). So you can open that text file, to see what kind of feedback the code is printing out, further than checking the timestamp of the pictures in folder.

Be aware the boot takes a couple of minutes and the first picture will be taken at about the next minute chance; When waiting, without doing anything lse, this time seems even longer and it might let you think the code not being active .... Having the mini display on the Raspberry Pi makes life easier :-)

On the tests I performed, everything was working fine. Overall, I have hard time to follow the chain of events at your end, I'm afraid it requires more detailed and clear info from you.

— Reply to this email directly, view it on GitHubhttps://github.com/AndreaFavero71/timelapse/issues/2#issuecomment-2291944073, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQNON6MISIL4IRKD366MNLZRTYMLAVCNFSM6AAAAABLLMXR5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJRHE2DIMBXGM. You are receiving this because you authored the thread.Message ID: @.**@.>>

AndreaFavero71 commented 3 weeks ago

Hi, I think I've discovered the reason we have different results after recovering from a power outage. Background: The timing methd used to take the pictures is based on the EPOCH time, to prevent shifting over time. In my case, once the Pi boots it will also find a network and an NTP (Network Time Protocol) and this might not be always the case or your case. When the Pi boots and does not find a NTP, the internal clock proceeds from where it left: The pictures won't be taken as per intended schedule.

To overcome this issue, I see two options: 1) Adding a RTC module, with backup battery, to the the Pi (i.e. search for 'DS3231 Real Time Clock Module RTC Clock Memory Module 3.3V/5V for Raspberry Pi'). 2) Changing the shootting approach (settings) to "start_now": "True" with a very long period "period_hhmm": "3000:00" (covers 125 days) and by bounding the shooting to the illuminance level.

Option 1 is rather clean yet, further than the hardware, it requires to properly set the Pi in order to use the hardware clock after a power outage. Time alignment with NTP happen once the Pi will connect to a network. I don't have personal experience with these modules. With this option the pictures time stamp are always correct.

Option 2 should work too, yet with some caviets. In case of power outage and booting without a network available (no NTP), the pictures will be tken as per interval_s and Lux but the timestamp will be wrong.

I have now available a Pi with a screen alowing for tests with and without network connection: Tests on option 2 confirms the above notes.

weedy171 commented 3 weeks ago

I just installed the device last night and noticed the issue of the time changing and I had to manually set it. I will find out in a couple days how things are going.

From: Andrea @.> Sent: Wednesday, August 21, 2024 3:47 PM To: AndreaFavero71/timelapse @.> Cc: weedy171 @.>; Author @.> Subject: Re: [AndreaFavero71/timelapse] Recovery from power outage and shoot above a lux threshold (Construction Cam) (Issue #2)

Hi, I think I've discovered the reason we have different results after recovering from a power outage. Background: The timing methd used to take the pictures is based on the EPOCH time, to prevent shifting over time. In my case, once the Pi boots it will also find a network and an NTP (Network Time Protocol) and this might not be always the case or your case. When the Pi boots and does not find a NTP, the internal clock proceeds from where it left: The pictures won't be taken as per intended schedule.

To overcome this issue, I see two options:

  1. Adding a RTC module, with backup battery, to the the Pi (i.e. search for 'DS3231 Real Time Clock Module RTC Clock Memory Module 3.3V/5V for Raspberry Pi').
  2. Changing the shootting approach (settings) to "start_now": "True" with a very long period "period_hhmm": "3000:00" (covers 125 days) and by bounding the shooting to the illuminance level.

Option 1 is rather clean yet, further than the hardware, it requires to properly set the Pi in order to use the hardware clock after a power outage. Time alignment with NTP happen once the Pi will connect to a network. I don't have personal experience with these modules. With this option the pictures time stamp are always correct.

Option 2 should work too, yet with some caviets. In case of power outage and booting without a network available (no NTP), the pictures will be tken as per interval_s and Lux but the timestamp will be wrong.

I have now available a Pi with a screen alowing for tests with and without network connection: Tests on option 2 confirms the above notes.

— Reply to this email directly, view it on GitHubhttps://github.com/AndreaFavero71/timelapse/issues/2#issuecomment-2302984075, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQNON5AU7QC37PQWJPVST3ZST4CPAVCNFSM6AAAAABLLMXR5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBSHE4DIMBXGU. You are receiving this because you authored the thread.Message ID: @.**@.>>

AndreaFavero71 commented 2 weeks ago

Hi, I've just released an update, that includes: 1) Recovering from power outage also when the shooting approach is based on "start_now" and related "period_hhmm". 2) Moved the "lux_check" and "lux_threshold" to the settings.txt. 3) Some minor improvements. Wrt your target, I think you'll benefit from setting "start_now" as True, a very long "period_hhmm" (i.e 3000:00 will cover 125 days) and by bounding the shooting to the illuminance level: Set "lux_check" as True and "lux_threshold" to 30. In case the system is not into a network nor having a RTC module, by setting "start_now" as True and the illuminance control, the shooting schedule won't mess up in case a power outage will happen.

weedy171 commented 2 weeks ago

I was able to grab three days worth prior to the start of the construction and everything looked great. Then it appeared it worked for a day after then stopped. I missed two important destruction so kinda bummed about that. Not sure what happened. I tried to implement some of your suggestions below and now I did not see it try to take pictures after a reboot. Can you look at the settings I posted above and make sure I am not missing anything. Do you think because I am not rendering the file that is an issue?

From: Andrea @.> Sent: Sunday, August 25, 2024 7:11 AM To: AndreaFavero71/timelapse @.> Cc: weedy171 @.>; Author @.> Subject: Re: [AndreaFavero71/timelapse] Recovery from power outage and shoot above a lux threshold (Construction Cam) (Issue #2)

Hi, I've just released an update, that includes:

  1. Recovering from power outage also when the shooting approach is based on "start_now" and related "period_hhmm".
  2. Moved the "lux_check" and "lux_threshold" to the settings.txt.
  3. Some minor improvements. Wrt your target, I think you'll benefit from setting "start_now" as True, a very long "period_hhmm" (i.e 3000:00 will cover 125 days) and by bounding the shooting to the illuminance level: Set "lux_check" as True and "lux_threshold" to 30. In case the system is not into a network nor having a RTC module, by setting "start_now" as True and the illuminance control, the shooting schedule won't mess up in case a power outage will happen.

— Reply to this email directly, view it on GitHubhttps://github.com/AndreaFavero71/timelapse/issues/2#issuecomment-2308806980, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQNONZDAFI2VEXEEF2EXHLZTHCWFAVCNFSM6AAAAABLLMXR5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYHAYDMOJYGA. You are receiving this because you authored the thread.Message ID: @.**@.>>

AndreaFavero71 commented 2 weeks ago

Hi, I can understand the frustration from getting a system not working when it counts. The issue is not related to the render process, but without the timelapse_terminal.log file content is difficult to assess what went wrong. I think the problem relates to the Pi time as not reflecting the reality when it doesn't find a network (NPT).

Anyway, I have one timelapse system that keeps working consistently after restoring power.

It uses a slightly different shooting approach: It uses of "start_now", "period_hhmm" and "lux_check". By setting "start_now" as True, it won't anymore relate to start_hhmm and stop_hhmm, but it will shooting every ïnterval_s"as long as there is enough light.

This system has the release V0.5. After updating the python file, you have to run it once first to get the additional parameters added to the settings ("lux_check" and "lux_threshold") and afterward you can edit the settings (change the "lux_check" to True). To change the shooting process you have to change 3 parameters to below values:

Here all the settings with some comments: { "preview": "False", "erase_pics": "False", (Must remain False, to prevent pictures from being overwritten after a recovery from power outage) "erase_movies": "False", (ok)

"local_control": "False", (ok) "start_now": "True", (Must be changed to True) "period_hhmm": "3000:00", (Must cover the hours of the complete period, therefore 24h x days. 3000h =125 days) "start_hhmm": "00:01", (this time is not taken into account when "start_now"is set True) "end_hhmm": "23:59", (this time is not taken into account when "start_now"is set True) "interval_s": "600", (I would consider 300, or 180, to increase video smootness, You can increase FPS to shorten the video) "days": "120", (this time is not taken into account when "start_now"is set True)

"rendering": "False", (ok) "fix_movie_t": "False", (not relevant when rendering is set False) "movie_time_s": "20", (not relevant when rendering is set False) "fps": "24", (not relevant when rendering is set False) "overlay_fps": "False", (not relevant when rendering is set False) "overlay_text": "", (not relevant when rendering is set False)

"camera_w": "1920", (ok) "camera_h": "1080", (ok) "hdr": "True", (ok) "autofocus": "True", (ok) "focus_dist_m": "0.1", (not relevant when autofocus is set True) "lux_check": "True", "lux_threshold": "30", (on my system 30 lux is about when pubblic street lights are turned on/off where i live) "date_folder": "False", (Must be set as False, to allow recovery from power outage) "folder": "timelapse_pics", (ok. This folder will contain the pictures. This older will be appended to the parent_folder) "parent_folder": "/home/weedy/shared", (ok) "pic_name": "picture", (ok) "pic_format": "jpg", (ok) "rotate_180": "False", (depends if the camera is suspended upside down)

"display": "True", (depends if you have added the display to the Raspberry Pi) "modified_disp": "False", "disp_preview": "False", "disp_image": "False", "disp_rotation": "90", "disp_bright": "100", "disp_width": "240", "disp_height": "240", "disp_offsetL": "0", "disp_offsetT": "0" }

I hope this is clear enough.

weedy171 commented 2 weeks ago

Do you have any recommendations on how I should take pictures off, I left the last picture on so it would keep with the numbering. It seems to work for another day. Since I don’t use a display do you think I need that to be true. I noticed that was on last night.

From: Andrea @.> Sent: Tuesday, August 27, 2024 12:46 PM To: AndreaFavero71/timelapse @.> Cc: weedy171 @.>; Author @.> Subject: Re: [AndreaFavero71/timelapse] Recovery from power outage and shoot above a lux threshold (Construction Cam) (Issue #2)

Hi, I can understand the frustration from getting a system not working when it counts. The issue is not related to the render process, but without the timelapse_terminal.log file content is difficult to assess what went wrong. I think the problem relates to the Pi time as not reflecting the reality when it doesn't find a network (NPT).

Anyway, I have one timelapse system that keeps working consistently after restoring power.

It uses a slightly different shooting approach: It uses of "start_now", "period_hhmm" and "lux_check". By setting "start_now" as True, it won't anymore relate to start_hhmm and stop_hhmm, but it will shooting every ïnterval_s"as long as there is enough light.

This system has the release V0.5. After updating the python file, you have to run it once first to get the additional parameters added to the settings ("lux_check" and "lux_threshold") and afterward you can edit the settings (change the "lux_check" to True). To change the shooting process you have to change 3 parameters to below values:

Here all the settings with some comments: { "preview": "False", "erase_pics": "False", (Must remain False, to prevent pictures from being overwritten after a recovery from power outage) "erase_movies": "False", (ok)

"local_control": "False", (ok) "start_now": "True", (Must be changed to True) "period_hhmm": "3000:00", (Must cover the hours of the complete period, therefore 24h x days. 3000h =125 days) "start_hhmm": "00:01", (this time is not taken into account when "start_now"is set True) "end_hhmm": "23:59", (this time is not taken into account when "start_now"is set True) "interval_s": "600", (I would consider 300, or 180, to increase video smootness, You can increase FPS to shorten the video) "days": "120", (this time is not taken into account when "start_now"is set True)

"rendering": "False", (ok) "fix_movie_t": "False", (not relevant when rendering is set False) "movie_time_s": "20", (not relevant when rendering is set False) "fps": "24", (not relevant when rendering is set False) "overlay_fps": "False", (not relevant when rendering is set False) "overlay_text": "", (not relevant when rendering is set False)

"camera_w": "1920", (ok) "camera_h": "1080", (ok) "hdr": "True", (ok) "autofocus": "True", (ok) "focus_dist_m": "0.1", (not relevant when autofocus is set True) "lux_check": "True", "lux_threshold": "30", (on my system 30 lux is about when pubblic street lights are turned on/off where i live) "date_folder": "False", (Must be set as False, to allow recovery from power outage) "folder": "timelapse_pics", (ok. This folder will contain the pictures. This older will be appended to the parent_folder) "parent_folder": "/home/weedy/shared", (ok) "pic_name": "picture", (ok) "pic_format": "jpg", (ok) "rotate_180": "False", (depends if the camera is suspended upside down)

"display": "True", (depends if you have added the display to the Raspberry Pi) "modified_disp": "False", "disp_preview": "False", "disp_image": "False", "disp_rotation": "90", "disp_bright": "100", "disp_width": "240", "disp_height": "240", "disp_offsetL": "0", "disp_offsetT": "0" }

I hope this is clear enough.

— Reply to this email directly, view it on GitHubhttps://github.com/AndreaFavero71/timelapse/issues/2#issuecomment-2313169840, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQNON35KKRVWLJLVPRWCMLZTS3NBAVCNFSM6AAAAABLLMXR5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJTGE3DSOBUGA. You are receiving this because you authored the thread.Message ID: @.**@.>>

AndreaFavero71 commented 2 weeks ago

1) Yes, keeps at least the last picture in folder. 2) Keeps "display" : "False" to prevent issues in case you don't have installed the driver for the display.

AndreaFavero71 commented 1 week ago

Hi, just released one more update: Solved a bug that in V0.5 was preventing shooting, when start_now=true and lux_check=false.

weedy171 commented 1 week ago

So it was working good for two whole day(plus the night before a couple hours before ) then it stopped taking pictures around 7:30 pm. I went to check it tonight and I have noticed it does not want to connect to the access point. I have to power cycle for it to connect to the access point that I bring over. Then i notice it starts taking pictures. Not sure what to check for on that issue. I am debating creating a nightly reboot.

AndreaFavero71 commented 1 week ago

Hi, any chances it stopped at about 7.30pm because of too low illuminance? Sometimes the Raspberry Pi boards aren't often searching for the AP, requiring quite some waiting time; In a few cases I went for a power disconnection, as my patience was over. It isn't a good idea to disconnect the power, without a proper shut down, as there are open files than can get corrupted ... and could cause the Pi to don't boot or not toworking as expected.

weedy171 commented 1 week ago

Based on the last picture it took, their was plenty of light I am more concerned it didn’t turn back up the following days. I couldn’t really put the battery option because I had it already sealed up and mounted on a high pole.

How long do you think I should wait for the AP? I am thinking maybe the pi froze up and that’s why it stopped because I noticed as soon as I power cycled it started taking pictures.

From: Andrea @.> Sent: Tuesday, September 3, 2024 4:06 PM To: AndreaFavero71/timelapse @.> Cc: weedy171 @.>; Author @.> Subject: Re: [AndreaFavero71/timelapse] Recovery from power outage and shoot above a lux threshold (Construction Cam) (Issue #2)

Hi, any chances it stopped at about 7.30pm because of too low illuminance? Sometimes the Raspberry Pi boards aren't often searching for the AP, requiring quite some waiting time; In a few cases I went for a power disconnection, as my patience was over. It isn't a good idea to disconnect the power, without a proper shut down, as there are open files than can get corrupted ... and could cause the Pi to don't boot or not toworking as expected.

— Reply to this email directly, view it on GitHubhttps://github.com/AndreaFavero71/timelapse/issues/2#issuecomment-2327436516, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQNON7627JKRATVXJVRLCTZUYQCPAVCNFSM6AAAAABLLMXR5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRXGQZTMNJRGY. You are receiving this because you authored the thread.Message ID: @.**@.>>

AndreaFavero71 commented 6 days ago

Hi, if the Pi freezes .... waiting for the connection to the Ap is not a good strategy. It might be helpfull to add a led, and blinking it via the timelapse code as feedback it is working: This approach is informative, but again not resolving a frozen Pi. Differently, it looks like the Raspberry Pi can be set to automatically switch off and on in case it freezes. I didn't know about this feature, and just read about it at https://raspberrypi.stackexchange.com/questions/99584/rpi-freezes-every-now-and-then-how-to-fix-it-with-a-watchdog.

I've just followed Berto's instruction and it works :-) sudo nano /etc/systemd/system.conf Uncomment these two rows: RuntimeWatchdogSec=10 ShutdownWatchdogSec=10min Ctrl + X, then Y, then Enter to save with the same name by overwriting the file .....And you're done.

If the Pi gets unresponsive for 10seconds, it will automatically power off and reboot. Setting the WatchDog is really easy, the difficult part for me it has been for force it unresponsive.... Anyhow, after many differen attempts, I managed to get the py unresponsive and the Watchdog does foce OFF and ON the Pi: it works well. By using this technic, the Pi reboots only in case it freezes