Have your own NTP server, no worry about DST anymore!

[grovkillen]

Hi,

Not long ago many countries set the clock forward (reverting from DST). When this happened I found out that the ESPeasy is not very friendly to me since I need to uncheck every units setting to obey DST. That type of job makes my skin curl and multiple veins pop. So I need to fix this, found out that if you have a windows computer this is not a big deal. You may just activate this, I followed this guide, worked just fine! Remember that using this approach is making the DST option in ESPeasy obsolete since the local NTP server take care of this, SO LEAVE THE DST UNCHECKED. I use my MQTT/NTP servers IP address but it should be possible to add host name under the NTP settings in ESPeasy.

But I also made sure that my computer synced to a global NTP server (I use NetTime but multiple other software solutions is out there). So now my windows computer (which also act as my MQTT broker) take care of the DST. Windows has great support for DST!

I hope someone else might find this helpful.

[lucaberta]

While I appreciate the angle this solution comes, this is not how things work in real life with NTP. Let me explain what I mean by that.

By definition, NTP works *always* in UTC time, Universal Time Coordinate. UTC never changes, it stays the same regardless of one's position on the planet and the local winter or summer time conventions.

Any changes from UTC to the local timezone, including DST adjustments, has to be performed *client* side.

This makes sense as you "connect" to an NTP server from wherever on the internet, and you don't need to know what is the local timezone or, worse, DST convention.

Having said all that, if you set up your own *private* NTP server and you serve local time with the DST correction already applied, things works well AS LONG AS YOUR SERVER IS THE ONLY ONE CONFIGURED!

On simple devices and firmwares where there is room for only one NTP server configuration, this is not a big deal.

But on systems where you have a more complete Linux implementation of NTP such as OpenWRT, for example, you can run into horrible problems should you decide to configure different NTP servers and mixing YOUR PRIVATE NTP server with public NTP server which, as I said above, by definition ALL run on UTC.

The issue will be huge, in that your client machine will not know which NTP server to trust the most, and you will run into issues. It's even a little more complicated than that, but suffice it to say that MIXING NTP servers with your own "special" server can very much lead to quite some confusion...

Another way to solve the issue is to leave all the node devices with ESPEasy on UTC, and keep it like that. It be a bit awkward at first depending on where in the world you live, but you will get used to it.

Moreover, timestamping of sensor data is typically done when injecting the data in the upstream service such as a database, in most cases.

Hope this makes sense! Any comment is appreciated.

Bye, Luca

[grovkillen]

But no, I only have 1 NTP server presented to the units. So I don't really understand your arguments of not doing what I do. How the units would be confused is above my intelligence I guess.

[Shardan]

It's not a real solution.

First, i don't want to run a Windows box permanently to supply time - it takes far too much energy.
But that's more of a private reason.

Second it would crash timesync at my place definitely.
As Luca said, NTP is defined to give UTC and leave the complete timezone thing including DST to the Client.
Breaking the rules might work for you or not, it's no good general advice.

Example: I'm running my own timeserver, a dedicated linux ntp server, syncronizing to several internet timeservers and a DCF77 radioclock receiver.
Every device in my network relies on this time source, from ESP and several Raspberry Pi's over Android and iOS mobiles, Windows PC's up to several Linux and Windows servers.
(No, not at my company, that network is much bigger. It is my private "test & tinker" disaster area...)
The time server is configured as central time source in DHCP so every device joining the network gets the time automatically from a well defined source.
This is necessary as for example Windows Active Directory Authentication depends on exact time on Server and Client.

Imagine what happens: Windows can set DST automatically - Linux set's DST automatically, Android and iOS do - just ESPEasy does not.
If you now tinker around breaking the NTP'S "NTP = UTC" rule, to get rid of the DST setting in the ESP'S, it would break time on more or
less every other computer.

It is no solution to set Windows to not obey DST. It is no solution to set Android to not obey DST rules (if that's possible at all, I've never tried).
Why not? Smartphone, tablet and notebook are used as mobile devices - when I go for a meeting in a hotel using their WiFi i'd have to change time settings again.

A second time source for those devices is no good idea either. First, time sources are usually distributed via DHCP. Two time sources with different times would break this.
You would have to define different DHCP ranges for getting correct time sources - and then you have to assign devices to the correct DHCP
range manually to make it work? Or never know which time your device gets when logging in the network next time? Ok, we set time source manually - and your notebook
will love you at the hotel next time. That's not what DHCP was intended for.

Definitions of Internet services rely on each other.
Breaking rules of one definition is always followed by trouble with other definitions.

What you did works for you at this moment.

It is far away from a general solution. It is not even sure if it will work for you in the future.

The least it is a solution for users who are unexperienced with Internet protocols like TCP/IP and NTP
as they are unable to anticipate possible consequences and help themselves out.

The solution would be an auto-DST capability in the ESPEasy's NTP client.

To be honest - as i see the web server is broken in ESPEasy 2.0.0dev7 and some other things do not work properly yet
this imho is not number one on the priority list. I use time on ESPEasy for just two of my modules with clock display.
Time driven events and logging incl timestamp are done by the FHEM server, it has it's own exact time.
What needs a temperature sensor, a light switch or a relay time for?

Regards
Shardan

[grovkillen]

I guess different cups of tea. I only use time to trigger rules within the ESPeasy FW. My broker handles the time stamp. I just figured I'd post my solution, you may like it or not but it is a solution for me and probably many more that uses this approach:

ESP <--> MQTT <--> Local Broker / Local NTP <--> Global NTP

If you want the NTP settings to be on the ESP fine, but my solution will only feed time to my ESP units, no other devices connect to that local NTP. The rest goes this way:

Other Device <--> Global NTP
Other Device <--> MQTT <--> Local Broker

[grovkillen]

First, i don't want to run a Windows box permanently to supply time - it takes far too much energy.
But that's more of a private reason.

I don't know about your windows computers but my MQTT/NTP "server" is averaging 1.3-1.5W (with rear peaks at 6W). Just a small OffTopic