Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam openbkn TIME_setDST 0 3 1 2 1 0 10 1 3 0 in autoexec.bat doesnt adjust time offset accordingly
Your TIME_setDST 0 3 1 2 1 0 10 1 3 0 line is not obviously wrong in current OpenBeken. In the current autogenerated command documentation, that exact example means: last Sunday of March at 02:00 apply +1 hour DST, and last Sunday of October at 03:00 return to +0 DST. So the leading 0 is not an enable/disable flag; it means “last week of the month.” Also, in this command, the 1 means 1 hour of DST, not 1 minute. (github.com)
The two most likely reasons it does not “adjust accordingly” are:
time_setTZ, and/or time_setDST; the repository is still actively released, with a latest release shown on January 9, 2026. (github.com)A correct modern setup for Germany/CET-CEST should look like this:
startDriver ntp
ntp_setServer pool.ntp.org
time_setTZ +01:00
time_setDST 0 3 1 2 1 0 10 1 3 0
waitFor NTPState 1time_setTZ +01:00 defines the standard time (CET), and time_setDST ... adds the seasonal +1 hour rule on top of it. waitFor NTPState 1 is useful so you do not judge the result before valid time has been acquired. (github.com)
The current OpenBeken command list documents time_setDST as:
Rule# / nthWeek / month / day / hour / DSToffset / ... second ruleTIME_setDST 0 3 1 2 1 0 10 1 3 00 3 1 2 1 → last week, March, Sunday, 02:00, +1 hour DST0 10 1 3 0 → last week, October, Sunday, 03:00, back to 0 DST hours (github.com)So one common explanation you may have seen elsewhere is incorrect: this command does not use the first argument as a DST enable bit. That interpretation comes from older or incorrect third-party explanations, not from the current OpenBeken command definition. The official autogenerated docs are the better reference here. (github.com)
The next important point is architectural: time_setDST defines the DST rule, but time_setTZ defines the base timezone offset. If you only set DST and never set the base timezone, the firmware has no standard local offset to build from. For Germany, standard time is +01:00; DST then makes it effectively +02:00 during the valid interval. (github.com)
There is also a version-history issue. In the older OpenBeken NTP/scheduling discussion from February 2024, the project author explicitly stated that daylight-saving adjustment was not yet supported automatically and recommended changing timezone offset via script. However, the current command list now includes time_setDST and time_setTZ, which indicates the time subsystem has evolved. Therefore, if your device is running an older build, your TIME_setDST line may be accepted syntactically yet not behave as you expect, or you may be mixing old NTP-era commands with newer clock commands. (elektroda.com)
Another practical issue is startup timing. autoexec.bat runs at boot, but the device does not have valid network time until NTP succeeds. OpenBeken documents waitFor NTPState 1 for exactly this type of dependency, and older project guidance notes that usable NTP time typically appears only after startup delay and synchronization. If you inspect the time too early, it can look like DST failed when in reality the clock was simply not valid yet. (github.com)
A further minor point: current docs list the canonical timezone command as time_setTZ, not time_TZ. If you are following fragments copied from forum posts, use the documented command names from the current command list to avoid alias/compatibility surprises. (github.com)
As of the current OpenBeken repository state, the project is still actively maintained, and the releases page shows a latest release dated January 9, 2026. The autogenerated command list in the main branch includes time_setDST, time_setTZ, and time_setLatLong, which is a stronger indicator of current capability than older forum discussions alone. (github.com)
This means older advice such as “OpenBeken has no DST support” is now partly outdated. More precisely: that was true for the older NTP-only behavior discussed in 2024, but the current documented command set includes explicit DST configuration commands. (elektroda.com)
The practical trend in OpenBeken appears to be a transition from older ntp_*-centric time handling toward a more unified time_* interface for timezone, DST, and location. Based on the docs, that is the safer interface to use for new autoexec.bat configurations. This last sentence is an engineering inference from the current command set and the older forum history. (github.com)
For Germany / Central Europe, your rule itself is correct in principle:
time_setTZ +01:00
time_setDST 0 3 1 2 1 0 10 1 3 0Interpretation:
| Field group | Meaning |
|---|---|
0 3 1 2 1 |
Last Sunday in March, 02:00, apply +1 hour DST |
0 10 1 3 0 |
Last Sunday in October, 03:00, remove DST |
time_setTZ +01:00 |
Base timezone = CET |
This should produce CET in winter and CEST in summer. (github.com)
If you are in the United States, the example seen in forum discussion uses a different DST rule because the U.S. transitions occur in different months/weeks than Europe. So reusing the German rule in a U.S. timezone will appear wrong even if the command mechanism is working. (elektroda.com)
A useful mental model is:
\[ \text{Local Time} = \text{UTC} + \text{Base TZ} + \text{DST offset if rule is active} \]
In your case, time_setTZ supplies the Base TZ, and time_setDST decides whether the extra DST term is 0 or +1 hour. This formula is an explanatory engineering abstraction of the documented command behavior. (github.com)
There are no special legal issues in using DST configuration itself. From an engineering and operational standpoint, the relevant concerns are reliability and traceability: use a trusted NTP source, keep the firmware current, and avoid ambiguous copied snippets from old forum posts when the official command list provides a newer interface. That recommendation follows from the documented evolution of OpenBeken’s time commands and release activity. (github.com)
Use this autoexec.bat pattern if you want the modern approach:
startDriver ntp
ntp_setServer pool.ntp.org
time_setTZ +01:00
time_setDST 0 3 1 2 1 0 10 1 3 0
waitFor NTPState 1That gives you:
If it still fails, check these in order:
time_setTZ, DST rules alone are incomplete. (github.com) time_* commands. This is an inference based on the newer command list versus older NTP-only forum guidance. (github.com) One limitation here is that OpenBeken documentation is split across autogenerated command docs and forum discussions, and those sources span multiple firmware generations. Because of that, older posts can be accurate for their build date yet wrong for current firmware. In this case, the older 2024 “DST not supported yet” guidance conflicts with the current documented time_setDST command, so the current command docs should be treated as authoritative for recent builds. (elektroda.com)
I am also inferring that mixing ntp_* and time_* commands can contribute to confusion, because the project appears to have evolved its time subsystem. That is a reasonable engineering inference, but it is still an inference rather than an explicit statement from a single source. (elektroda.com)
If you want to debug this rigorously, the next useful checks are:
autoexec.bat against the current command list names, especially time_setTZ and time_setDST, (github.com) waitFor NTPState 1. (github.com)If you want, I can help you build a known-good autoexec.bat for: