In Denmark we still have summer/wintertime time change, and perhaps others have been faced with some automations not really automatically adjusting even though other pronations in the sale location actually worked automatically.
I spend a little time investigating and here are some pointers to check to solve it.
Check your router is getting the time from the ISP or potentially run the time locally and automatically adjust for DST.
Reboot your hubs if the problem remains
Go though your automations and make sure the once time controlled all say LOCAL, because if they say CLOUD then that’s the issue.
If it says CLOUD delete the automation and then it will automatically update to LOCAL and problem is solved.
This is only relevant for time programmed automations, all non timers automations will work fine on cloud basis but if course in the network connection is down they won’t work if they are CLOUD based.
Using a nearby or reliable NTP server improves accuracy, reduces delay, and ensures consistent timing across all connected devices. If you can specify multiple servers, redundancy is also increased.
Once set up, the router keeps the correct time and distributes it to connected devices, making your smart home timing much more reliable.
Technical note: NTP always provides time in UTC, which is the same worldwide and does not include daylight saving adjustments.
The hub uses its configured time zone, which includes DST rules, to convert UTC into local time.
Even if a hub doesn’t handle DST perfectly on its own, having accurate NTP-based time in your network often fixes most of the side effects.
If they are cloud based then they will not change DST, so in my case some of my smart plugs didn’t turn on at the correct time after a DST change if they were cloud based but only when they were running Locally.
This is simply a bug and @AqaraOfficial should fix it. @gafich10 can you please raise this to aqara.
All this other business is simply a distraction from @AqaraOfficial considering automations should obviously be in local time. It’s trivial to store date/time in UTC and convert to users local time at point of display/execution, it’s the software engineering norm.
(They know your location and UTC → local(location) is dst aware)
Hello, @Caroline_Zzz , @nzjrs , to make comments about Aqara, you need to understand the time desynchronization. I saw two publications where cloud automations are associated with the sunset/sunrise period (not due to the settings “…”) and therefore this is a real time shift. The user is used to the fact that at 10.00 (for example) the action takes place, but in reality the sunrise has not changed, only our time has changed. As an addition, many users (especially Europe) do not even think that the time transition has occurred (all gadgets and home devices automatically switch) and the questions “but it didn’t work for me, it’s a mistake!” begin. I write about the time transition from my own experience, my son found out that there was a transition to a new time only a week later when we started talking about it. I can also confirm that my automation (test, from the previous control of cloud processes) worked ~ for one hour of shift.
Conclusion: to analyze the comments, at least you need to have an example where there was a time zone failure, all comments at the moment are only theoretical assumptions.
As I already changed them I cannot provide more screenshots than I already posted. It is indeed specific time like 10AM that was set but didn’t follow the DST change as the automation was run in the cloud. So I’m my opinion it really is a bug, but only happened do to an automation 1.0 to 2.0 conversion (is my best guess) as all new automations do run as local and not cloud hence the DST works just fine.
Hope it makes sense
