When Daylight Saving Time (DST) ends, most of us expect our smart devices to adapt automatically. However, for some eWeLink-supported devices, timers may drift off-schedule due to the unique way that timer settings are handled. This can be a source of frustration, and we understand that users’ concerns are entirely reasonable.
To help clarify why this situation occurs—and to give you guidance on how to adjust timers for smooth operation after DST changes—we’d like to explain the technology behind your devices and share a simple fix that can help you stay on schedule.
Understanding Local and Cloud Timers
eWeLink devices rely on two types of timing mechanisms:
Local Timers : Many devices use an internal oscillator (or “crystal”) to keep track of time without relying on cloud connectivity. This means that once a timer is set, it’s saved locally in the device’s memory. The advantage here is that even if the device loses its network connection, the local timer can still trigger events as scheduled.
However, because these local timers are not connected to any centralized time source, they don’t automatically adjust for DST. The device itself doesn’t “know” when DST begins or ends; instead, it calculates time based on the initial UTC time and timezone when the timer is first set. From there, the internal oscillator (or crystal) keeps track of elapsed time. This approach makes local timers independent, but it also means they aren’t aware of timezone shifts, causing them to trigger tasks an hour off when DST changes.
Cloud-Based Timers : Some timers are run based on eWeLink’s cloud servers, which maintain an accurate, current time. These timers can recalibrate for DST automatically, as long as the device has network connectivity.
However, adjusting all devices to cloud-based timers isn’t as simple as it sounds. For instance, some devices lack geolocation data, which means they can’t always interpret local time shifts. Moving completely to cloud-based timers would also impact users who prefer local-only timing that doesn’t depend on cloud connectivity—a trade-off we’re carefully considering.
Affected Timers and Recommended Adjustment Methods
To make things clearer, we’ve outlined in the table below the specific types of timers that may be affected by DST, along with recommended adjustment methods to help keep everything on schedule.
Affected Item
Description
Adjustment Method for DST
Schedule/Timer/Loop Timer
Schedule/Timer/Loop Timer you have set for a certain device
Adjust Timers for DST with “Edit Timers” Feature.
Timer-Related Scenes
Scenes triggered by specific times of day (using “Time of Day” as a trigger)
Adjust Timers for DST with “Edit Timers” Feature.
Thermostatic Radiator Valve (Model: TRVZB)
Thermostatic valve requires reconfiguration in the app for DST synchronization.
Delete and re-add it in the eWeLink app.
Thermostat (Model: GTTA127)
Custom daily temperature schedule requiring re-saving for each day of the week after DST adjustment.
Reopen and save each day’s temperature schedule to align with DST.
Adjusting Timers for DST with Edit Timers Feature
To help you quickly realign timers after DST changes, we’ve created a simple tool within the eWeLink app: the Edit Timers feature. This allows you to adjust multiple timers at once, by pushing back or advancing schedules with a single adjustment.
Here’s a step-by-step guide on using the Edit Timers feature:
Access Settings : Open the eWeLink app, tap on “Profile,” then tap the gear icon in the upper right corner of the screen.
Select Edit Timers : In the settings menu, tap on “Edit Timers.”
Choose Timer Type : Select the type of timers you want to modify (e.g., for specific devices or scenes).
Select Timers : Check all timers you need to adjust and tap “Next.”
Adjust Timing : You’ll see options like “Timer Forward” or “Timer Back.” For adjusting to standard time from DST, choose either to push back or advance the timers by one hour, as needed.
Confirm Changes : Tap “OK” to confirm, and all selected timers will adjust at once.
Using these steps, you can bring all timers back to the correct schedule quickly, avoiding any unwanted timing shifts.
We’re Here to Help—and Listening to Your Feedback
While we know this feature isn’t a perfect solution, it’s our best option for now as we continue seeking ways to improve. We’re actively working on solutions that might better address these challenges in the future, and welcome your valuable feedback—it often inspires fresh ideas and innovations. If you need any assistance, please reach out to us at support@ewelink.zendesk.com.
Hello, this has been an issue for some years now and frustrating every time DST happens. If this is based purely on the device not knowing, couldn’t the app recognize when DST happens and push a time change to the devices?
Also, currently there is no way of knowing what time the app thinks it is for you as far as I can tell. If you check settings, you can set your timezone, but not see what time the app thinks it currently is for you. So trying to use the manual timer correction option is like taking random guesses.
If this is on a per device basis, please add the ability to see what time the device thinks it is in it’s Device Info and a way to see what time the App thinks it is for you.
Also I tried to report this in the App, but the report function doesn’t work properly and errors out.
It’s not just eWeLink devices. My home assistant does it too. I think it is maybe because summer time ends at different times in different parts of the world. I don’t think it’s happened in USA yet and USA is prioritised by many countries.
There are plenty of devices that handle DST properly, while they’re stating it’s because the devices themselves have their own clocks, the app can definitely push an update to them to update the time of day when appropriate. Knowing time of day is part of localizing something and tons of apps/devices do it. DST isn’t random.
Not being able to see the time on either the device or in the app just makes the confusion worse.
Currently, as eWeLink integrates devices from various brands, the ability to display the time on each device depends on the device’s firmware, which is developed by the device manufacturers. Many devices do not yet support automatic DST adjustments, which can make it difficult to ensure the correct time display.
To help manage schedules, we recommend using the “Edit Timers” feature, which lets you adjust multiple timers at once by advancing or delaying schedules with a single update. This allows for quicker alignment with DST changes.
If you encounter any additional issues or if the problem persists, please don’t hesitate to reach out to us at support@ewelink.zendesk.com.
There are so many problems with the current implementation. Mainly you can’t tell what time the device has set currently, which makes this a lot of guessing.
Last two years DST worked sorta, you’d restart the app a few times and it’d push the correct time. Now this is all over the place. For some reason Chicago is registered as -5 right now instead of -6. I tried mountain time, which was also messed up. Tried Chicago > apply DST to regular time (which is what just happened on the 2nd) and it didn’t change anything. Finally applied regular to DST and it fixed it, which isn’t what time we’re currently even in.
I know supporting a lot of devices is a huge undertaking, but please find a better way to implement this. You could even make a tick box to take the time from the device which the app is installed on on the day of DST. It really shouldn’t matter whether or not the device supports DST functionality, ewelink could push it’s own time when DST happens to make sure it’s correct.
Summer time isn’t the same dates on all places. They’d need to know where you were to know the date. Most of the world doesn’t change to summer time at all, including (I think) China. Europe changed near the end of October. USA just Changed. I don’t think it is simple as it may appear with everyone changing on the same day. Assume Canada and Mexico use the USA timing, but where does it end as South America doesn’t do it. Here in U.K. we’re thinking of using summer time all year and lots of places used to have a summer time but don’t now. If U.K. changes will Ireland or will one side of the border be different to hundreds of meters away, plus Christ Church College in Oxford has a different time again. If you’re in that college I’d bet nothing ever shows the right time.
As Mirko says there is no mention of TRVZB in “Edit Timers” and eweLink staff say above that each TRV should be deleted and re-added. This in itself is not a reasonable solution twice each year!
In my case, deleting and re-adding TRVZB does not fix the problem - all scheduled events occur 1 hour early in the UK.
The UK changed from DST to GMT (0 hours) some weeks ago, but I notice that London is still shown as “+1” in “Time Zone”.
As an experiment I changed Time Zone to “Greenwich Mean Time Africa 0hours” and then also “US Eastern Time -5hours” and the TRVZBs ignore this and still switch 1 hour early in the UK so “Time Zone” seems to have no effect.
All other Schedules such as Sonoff Basic and S26 work correctly. I have also tried full battery removal/reset with the TRVZBs.
As other have said it would be useful to know exactly what the TRVZB uses as the current time.
Any other UK TRVZB users having problems? I’m out of ideas with this.
Customer service told me that I have to delete and re-add zigbee bridge pro because it sends time to zigbee devices. That’s absurd. I have 25 devices and I would have to reconfigure them all.
I added brand new valves yesterday and they are working on summer time.
To use the word of nbrezovec this situation with TRVZBs is completely absurd and eweLink really should sort this out right now for future changes to summer/winter time.
I tried reset of Zigbee Bridge Pro by using a pin in the reset hole and the valves still used UK Summer time (ie. scheduled events 1 hour early) and even reset a valve again with no improvement.
However, with reset of Zigbee Bridge Pro with the pin and then disconnect power for a minute followed by reconnection of power and reinstallation of the devices in the app, it now appears to be correct.
(Incidentally there was also a firmware update for the Zigbee Bridge Pro - I had done that first and this did not fix it so I think this is unrelated.)
