That’s a brilliant idea! I bet a lot more people would use it then!
If I could schedule it in advance I would try to set one to always do a time lapse on Halloween, set one up to always do a time lapse on a certain camera on the 4th of July. There are times I would set a time lapse to happen everyday between certain hours of the day for a week or a month or whatever (Maybe I only want the time lapse to run during daylight hours for example or during work hours or during the hours when I plan to work on it For renovation, rather than have a lot of wasted downtime at night while I’m sleeping and not changing anything, or maybe because I want to richard a certain flower blooming in the daytime).
Recurring Time lapse would be a cool feature!
This is a great question And I have wondered the same thing. Initially I was thinking the difference was the type of operating system they are using. Originally the time lapse feature was included from one of their suppliers named Hualai. They were then able to continue to copy that firmware feature on to Future cameras that were based on the same architecture, Linux. They stopped including it on some of the newer cameras. Initially, I assumed that this was because they switched the architecture from Linux to free rtos. And my assumption was that the code did not easily copy to the new operating system and kernal as easily as they were able to do with all of the cameras that were in Linux and came through Hualai. But then, I think the OG runs on free RTOS instead of Linux, and it still has time lapse. So the problem isn’t with the OS or the kernel foundation like I originally thought. Having said that, I believe that a couple of the cameras that don’t support time lapse are what docker Wyze bridge classified as “Gwell” cameras that don’t use the tutk sdk but are instead using something like lotvid. I don’t think that should really make a difference though, since the whole process should be happening locally on the SD card and it shouldn’t matter what the authentication SDK is. I don’t know, but that’s currently my leading hypothesis.
I haven’t verified who the supplier for the pan V4 is, or whether it’s a Gwell camera or another kind or what kernal or OS or SDK. But It seems like one of those things may in some way have made it more difficult for them to add time lapse to some of the camera models. They had previously told us on some of the others that they were seriously working on adding it for those models and were at one time actively working on trying to get it implemented. Obviously there were some roadblocks that they struggled to overcome. I don’t know what they were or why, but I do know they did want to add it and we’re working on it but it wasn’t a simple integration and it was taking a lot longer than they thought. I think they finally decided that it had taken too much time and resources and so they eventually had to scrap it. My suspicion is that they will probably add Time lapse to some cameras where it’s easy to copy and paste it, and not included on the ones that it’s not easy to do so with.