Hope you take your Wyze cam and capture some video from your off-net adventure in the woods:-). Now you’ve got us all wondering about your character…
1 Like
I have a very fancy ocelot mask now! And not supposed to show tech so probably no videos. But hopefully I’ll be full of tales to regale you with! Logging off now (I was planning to hours ago but I’m BAD at days off). See you next week! 
2 Likes
I agree @kyphos, I think Wyze is making a mistake by disabling offline use. I “was” planning on buying several more cameras, and SD Cards, to use in a location that has no internet service. I believe Wyze would open a whole new customer base if they made it easier to use the camera and app offline. It would be WONDERFUL if it were easy to record to record locally (to SD card) and view the recordings (local to the camera) on the SD card with the app (without having to pull the SD card).
2 Likes
What were the latest versions of app and firmware that it worked with?
I’d like to try and dedicate a cam for off-line recording.
kyphos doesn’t have access to any signal at all where he goes, but if you have access to a cell signal you may be able to get operational with a hotspot. I am always in range of a signal, so I have a travel cam that can be used for things like this using such a setup.
Unfortunately hotspots aren’t always available and often create their own set of issues, so yes, if we know with what combo of software and firmware this last worked with, please share!
A good question - I don’t know. I’ve not kept track of which versions of apps and firmware were installed in my cams and iPhone, nor when. On a sporadic schedule, Wyze pushes firmware out to the cams; Apple App Store pushes new app versions to iOS. In retrospect, I should have been keeping notes, but who knew functionality would regress?!
One new finding that might be of interest to you or others: if I connect my Wyze V2 to iPhone’s Hotspot (iPhone has LTE data connection to internet), the cam goes on-line, as expected. Blue status light goes on. The app can connect to the camera, view Live feed, enable or disable local recording to SDcard, and specify a TL recording. The hotspot can then disappear (i.e., iPhone leaves the area), and the cam continues to record even though it’s isolated.
However, when iPhone/hotspot returns, the app refuses to download the TL recording. The familiar ‘please connect your device to the same network’ error message appears. But the cam and the iPhone ARE on the same network. The cam is connected directly to the iPhone over the iPhone’s own WiFi. It’s obvious from the IP addresses that the two are on the same subnet (iPhone = 172.20.10.1, V2 = 172.20.10.4). IMHO, there’s no good reason why the app shouldn’t be able to download the TL recording from the camera when it’s directly connected to the iPhone.
I filed a bug report with Wyze.
Yeah, I don’t think anyone can download a time lapse at the moment. Always says “can’t find file” or some such.
The solution at the moment is to pull the card and read it with a computer.
Actually, I can download TL recordings**. With iPhone hotspot active and V2 cam connected to it, I connected my iPad to the hotspot as well. Launched Wyze app on the iPad, and it happily downloaded the TL. The app running on the iPad does not complain that it’s not on the same network. Whereas the app running on the iPhone isn’t happy, even though ALL THREE DEVICES ARE ON THE SAME NETWORK. (emphasis added to point out to Wyze_Dev the shortcoming of their design).
It’s only a solution if one has a computer handy. When I travel, I don’t.
I have tried another approach: pull the microSD card from the cam, insert it in a SDcard adaptor, insert adaptor into SDcard-to-Lightning dongle, plug dongle into iOS adaptor, and… it doesn’t work. Ms Google tells me that Apple botched support for their SDcard-to-Lighting adaptor in iOS 10.12.
This has all become too complicated.
** UPDATE: I don’t have the latest version of the app nor the V2 firmware. Having read all the reports about TL recordings vanishing, I decided not to upgrade to the latest-and-not-greatest.
Boy, you’re not kidding there, lol.
I’ve one V2 that I regressed to FW 4.9.3.64 (available on the Release Notes page [https://support.wyzecam.com/hc/en-us/articles/360024852172] ) that is again running time lapse using Beta app Android 2.3.80.
I’ve another V2 running time lapses using FW 4.9.4.33, probably Beta, since it is not listed on the Release Notes page.
When I was trying multiple FW versions yesterday I got “please connect your device to the same network” on several versions, when like @kyphos I was on the same network.
I see that you’re using the Android app. I’m using iOS. I had thought that perhaps the ‘not-on-same-network’ error was specific to the iOS variant, but since you’re getting the same thing, it’s clear it’s fundamental to design of the app, not a side-effect of iOS hotspot networking.
“…a whole new customer base” - that should be music to the ears of Wyze executives. What start-up venture wouldn’t be keen to extend their product reach to a new profitable market segment?! Perhaps @UserCustomerGwen will bring this opportunity to their attention…
Just one more thing (ha! As if…).
If you have TL recordings running again on a V2 without network connectivity, take a very close look at the recording about 1.5 hours after loss of WiFi. On recent experiments, On a couple of occasions, I’ve found dropouts - while the camera appeared to record continuously, it did not. It lost about two minutes of capture, and the realtime clock (RTC) in the cam also lost two minutes. And 1.5 hours into the recording, I’ve found a single frame captured without the timestamp in the lower-right corner.
What I think is happening is that the cam reboots 1.5 hours after loss of signal. I’ve heard it doing so, making the familiar click-click as it starts up. During the reboot, the internal clock stops running. Once it’s back up and running, the RTC gets set to the time it had before it rebooted. Since the cam is off-line, it has no way to query NTP server to get accurate time again. Hence the RTC has lost a couple of minutes. Fortunately, the programmed TL recording picks up where it left off, and then completes at the designated end-time, more or less (since the RTC is no longer accurate).
<end of my guess about what’s happening>
I took a very close look at the recording of my time lapse of the other day from before the “1-1/2 hour after start” mark to after the “1-1/2 hour after hotspot loss” mark, and found no lapse in frames. The time was continuous, with no loss in time stamp.
I also watched the recorded playback. Smooth.
So hopefully the “1-1/2 hour after loss of network” bug is dead (fingers crossed!)
I verified the same operation before to after the 3-hour marks.
I hope so.
I may have been mistaken about the reboot-90-minutes-after-loss-of-network issue. During a test this afternoon, I heard the camera go through the start-up sequence (click-click-pause-click), but it was about 1.5 hours after it had been powered up, not after loss of WiFi. At the time, the camera was not recording anything, so I don’t have any video to examine for dropouts.
I’ll keep an eye on it (and an ear, listening for what I think are reboots). Will update this thread if anything new comes up.
I was wondering about that. That’s why I looked before the “1-1/2 hour after start” mark to after the “1-1/2 hour after hotspot loss” mark to be sure. So, I still think we are covered, unless you come up with a different time.
Depends on how they fixed it before they could have broken it again 
Release software hasn’t changed in the 3 days or so since I did the test. Unless kyphos is using Beta?
Not using beta. My V2 has 4.9.4.28. Not the latest, I know, but I’ve read so many reports about TL recordings resulting in ‘file not found’, I decided to stick with something that (sort of) works.
I have some more results, and a disturbing finding.
This morning, I re-ran my test of TL recording on a V2 that had no network connectivity (no internet and no WiFi). Timeline:
6:15 am - power up camera
6:20 am - activate hotspot on iPhone. (note that iPhone had LTE internet connection, so the camera could go on-line). After a minute or so, the cam associated with the WiFi – the status LED stoped blinking and turned solid blue. The Wyze app could access the camera. I then programmed a TL recording: start=6:30, end=8:30, interval =30s.
6:25am - turned hotspot off.
just before 8:00am - I heard the cam go click-click-pause-click, the sound of it booting up.
8:50am - I turned hotspot back on.
The TL recording was listed in the album, but – no surprise – the app refused to download it (‘not on same network’). As before, I associated my iPad with the hotspot and downloaded the TL recording.
The results were the same as my previous tests. The TL started at 6:30am. Then there’s an anomaly at 7:57, about 90 minutes after loss of WiFi. There are frames captured from 6:30, every 30 seconds, up to 07:56:31. The next frame has no time-stamp in the lower-right corner, and the exposure is dim with a yellow cast. The next frame is stamped 07:57:22. However, the timestamp incorrect. The correct time is about 7:59:00. I know that because what the camera is pointing at is a real-world analog table clock. That’s how I can determine that the cam’s RTC has lost about 2 minutes.
The time-lapse recording continues until the programmed end time. The timestamp on the last frame is 08:30:21. However, real-world time is about 08:33. The camera keeps recording until it thinks it’s 8:30, but in real life it’s actually a bit later.
These results are the same as my previous tests. I’m pretty sure the cam rebooted shortly after 7:56:31. It took a couple of minutes to restart. When it did, the firmware is smart enough to resume the TL recording (6:30-8:30) that I had programmed. Good for Wyze programmers! However, since it had no network connectivity, it was unable to obtain the time from NTP, so the internal RTC continued with the time it had had before the cam restarted. The explains the loss of a couple minutes.
So why did it decide to restart at 7:57?? It could be a bug in the code - the lack of WiFi, (or lack of connectivity to China Inc) caused it to get confused, so it crashed then restarted. But I wouldn’t be surprised if Wyze has programmed a 90 minute watchdog timer to try to guard against runaway code. That’s a common programming practice in embedded systems. After 90 minutes without a check-in with HQ, the watchdog expires and forces a reboot.
Moving on, I did a second test, and the results of this one are troubling. Instead of seeing if the Wyzecam would handle a TL recording when it’s off-line, I was curious to see if it would properly deal with motion-triggered recording to the SD card.
The start for this test was with the camera powered up and the hotspot on.
9:55am - I enabled local recording of events.
9:56am - wandered in front of the camera, waving at it.
10:00am - Turned hotspot off. Waved at the camera some more. Went out to do some yard work.
11:40am - Returned to the camera and waved at it yet again.
11:42am - turned hotspot on.
The cam connected to it, and thence to the internet.
I viewed the Playback screen with the app. It had captured me waving (9:56-9:58). But the next capture was 11:43-11:46, after the hotspot had been turned back on.
It did not capture any motion events while the hotspot was turned off.
That’s not what I was expecting. If I find some time, I may re-run this test. I can’t see any good reason that the camera would require connectivity to WyzeHQ to do local recording to SD card.
1 Like