Set device time zones, update from time server

Well, I wouldn’t say they suck, but they seem to be more interested in coming out with silly new products that don’t really fit into their original smart home positioning, like floor lamps, handheld vacuums, nightlights, etc., instead of improving and expanding their existing products and their app. I think most of us early adopters assumed that although the functionality was pretty bare-bones when products were first launched, Wyze would listen to their users and continually improve their products through firmware and app updates. There’ve been a few improvements, like the sensor chime for the HMS, but they’re few and far between.

I have a Ring doorbell and am delighted with it, so may end up switching to them for everything despite the higher cost.

Wyze, please consider the international time zone as well. It is a simple thing to fix for the developer.
“GMT+5:45”

3 Likes

NTP support (with global time zone & DST indicator) per camera would be a dream!

Being able to specify a time server (and have that work properly) would be great. I don’t travel all that much, so the timezone part does not affect me much, but I certainly understand that request!
As an FYI, I set up a forwarding rule in my router so that the Wyze NTP requests would forward to my NTP server. The result was that all 30 cameras were making a NTP request ever 3.6 seconds. Insane!

1 Like

This was only an issue whilst travelling when the app used to ask you to sync time with your phone when you where travelling in a different time zone.

Now it doesn’t do that so no problem when travelling.

I reported the NTP port forwarding issues over a year ago for any Cam Pan firmware after 4.10.5.111. I always had NTP forwarding enabled on my firewalls and any time I tried to update firmware after 5.111 my cameras would never fully boot. I was able to trace the problem to the NTP forwarding. Once I excluded my cameras from that rule they updated properly. Since then, I check after firmware updates to see if it ever gets addressed and so far they haven’t. I didn’t test yesterday’s release yet. But the current symptom for running cameras is the continuous hits against the hardcoded list of NTP addresses built-in to the firmware. I assume it will still screw up firmware updates but haven’t specifically check recently. The camera’s completely ignore DHCP NTP addresses and whatever code they use reject NTP port forwarding as well. Of all the IoT devices I have worked with, Wyze has been the only one with this issue for whatever reason.

1 Like

Lots of IoT devices ignore the DHCP option 42 which tells what NTP server to use. After installing a NTP server, I enabled option 42 in the DHCP server and then watched to see what would and would not use my NTP server. None of my Amazon echo devices used the NTP server (and annoyingly, they also do not respond to a ping). Neither do my non-Wyze power switches. Only a few devices used the NTP server based on the DHCP Option 42 NTP setting.

1 Like

Say what? I thought I was savvy regarding this shxT. You blew that assumption.

Very true. Just like many of them ignore DHCP DNS settings too. At least DNS port forwarding doesn’t screw up the Wyze devices like NTP forwarding does.

I suppose if you really want you could reroute / spoof the relevant IP addresses too.

PLEASE add time zone support! I get that all of the Wyze employees live in a single time zone and use their Wyze toys accordingly and so don’t really care about this basic feature – given it was requested almost 4 years ago now.

I have cameras looking after my ailing mother and the time is always wrong. Also, when looking at recordings, its confusing in that the recordings seems to have the correct time information, but the app is out of sync because it is in a different time zone. Thank you.

3 Likes

Why is wyze not fixing this basic issue? That app is practically useless when one travels. Why can’t the app just stay in the local timezone of the camera like Nest does?

2 Likes

Can’t believe this is still an issue nearly 5 years later

2 Likes

Set time on cameras to NOT sync with app/phone (while traveling)

When a user travels outside their home time zone it would be great to have the option of syncing time with where they are (the current default / only option) OR leaving the time as local to the camera.

I recently took a trip and was struggling to figure out what time events were happening at home because the time sync’d to my local time.

This recently happened to me, and to my knowledge I did not tap the Change Time Zone button or whatever the pop-up window asks. So is it no automatic without any user input? I would really like to disable this.

This bug was raised in 2018 (at least on this particular thread; maybe even earlier elsewhere). There are over 100 votes to fix it. We are now in 2023, and the hermit programmer kids at wyze who never left their moms’ skirts and never visited a different time zone can’t seem to comprehend how this is an issue. What does it take to get it fixed??

1 Like

100% agree. Fix this!

This is the craziest consistent oversight I’ve ever seen. And it’s also crazy how wrong their support people are. They tell us that it goes by the time that the device was set up in, which is untrue because it changes later. Then they say it’ll update when you click sync time, which is also not true because I don’t do that and half my cameras end up displaying another time zone when I travel.

Also to clarify we are talking time zone issues here, not daylight saving issues.

This is just such a basic thing I can’t wrap my head around why this is an issue.

Wyze knows my address via the home settings. They know also via IP where the device is. This is crazy!

Devices should allow you to set the timezone where they are physically located. This seems like a no brainer.

I ran into a similar issue recently with the lock keypad: The keypad programming allows you to set the date and time for entry. Currently the time it shows adjusts to your current time zone, which is confusing if you are remotely managing a lock. Instead, it should remain in its local timezone always, so in the interface you are always programming relative to the lock itself.

1 Like