Yealink Uhrzeit falsch - Sommerzeit eine Woche zu früh

[4786]

Hallo,
ich habe bei verschieden gehosteten Anlagen, verschiedenen Telefonmodellen (T54W, T57W, T48U mit aktueller Firmware) und verschiedenen Anlagenversionen (V18 und V20) dass sich die Telefone bereits an diesem Wochenende auf "Sommerzeit" umgestellt haben.

In den Provisionierungs Einstellungen ist die selbe Zeitzone wie auch bei der Anlage eingestellt.
Die Uhrzeiten in den Berichten passen auch.

Ein Händlerkollege hat das gleiche Problem.

Gibt es hier noch weitere betroffene?
Die Telefone alle manuell umzustellen halte ich für wenig sinnvoll da mit der Umstellung im Herbst die Probleme vermutlich wieder auftreten werden.

Danke schonmal für die Unterstützung!

 

[cx_Tom]

Scheint ein globales Problem zu sein. Ist bei uns auch so.

 

[Bodo]

Hallo,
wir haben das gleiche Probleme. Im Webinterface von Yealink findet sich die Ursache für den Fehler. Yealink möchte gerne schon am 4. Sonntag im März auf Sommerzeit umschalten. Das passt natürlich dieses und die nächsten zwei Jahre nicht. Man kann im Webinterface der Telefone unter Sommerzeit auf "Aktiviert" umstellen und dann manuell den richtigen Sonntag eintragen.
Wir können das aber ja schlecht bei jedem Telefon manuell einstellen. Viel zu viel Aufwand.

Letztendlich ist Yealink gefordert, eine korrigierte Firmware rauszugeben.

Liest jemand von 3CX mit, um diesen Fehler bei Yealink zu eskalieren?

Euch trotzdem einen guten Start in die Woche.

 

[MarcosV_ 3CX]

Hallo zusammen,

am besten ein Support Ticket öffnen...


VG,

Marcos

 

[4786]

Ticket wurde erstellt.
Links zu den beiden Forum Posts habe ich beigefügt.

LG

 

[zeeb]

ja hier auch bei allen Kunden mit Yealink Apparaten. @Marcos_3CX soll ich für jeden Kunden ein Ticket aufmachen oder ist das sinnlos?

 

[Tommy]

Das ist einer der Gründe warum wie immer öfters "Benutzerdefinierte Vorlagen" einsetzen.
Es sollte aber auch für alle anderen funktionieren.
In der Vorlage nach

local_time.summer_time = 2

suchen und die 2 durch eine 0 ersetzen. Dann alle Telefone neu provisionieren und nächste Woche wieder alles Rückgänig machen.

Wer keine eigenen Vorlagen nutzt, muss die offiziellen Vorlagen anpassen. Das ist von 3CX NICHT erwünscht, aber bevor die Kunden einen schlagen...

Unter Linux hier zufinden:
/var/lib/3cxpbx/Instance1/Data/Http/Templates/phones

 

[patrickb]

Ich habe gerade ein wenig rumprobiert, da mich heute morgen zahlreiche Kunden angerufen haben.

Ein schneller einfacher Workaround ist es - sofern man eine On-Prem Anlage oder eine selbstgehoste Anlage betreibt, den Global Property "TIMEZONE_GLOBAL_ID" anzupassen. Von 46 zu 33. (Alternativ: 34, 35, 36, 126)

Um Ihn anzupassen navigiert man in die Einstellungen -> Parameter -> und wählt dort den Reiter "Benutzerdefinierte Parameter" aus. In der Suche wird nach "TIMEZONE_GLOBAL_ID" gesucht und der Wert dann von 46 auf 33 (Deutschland zu Irland) angepasst. Zusätzlich muss im jeweiligen Telefon (wenn nicht ohnehin schon so eingestellt) die Zeitzone auf "Standard-Zeitzone verwenden" eingestellt werden.

Die Telefone zeigen anschließend die korrekte Uhrzeit an und auch in den Anrufberichten und auch den Logs stimmt die Uhrzeit noch. Das sollte vorübergehend helfen - hat es zumindest bei zahlreichen meiner Kunden.

PS: Nächste Woche zurückstellen nicht vergessen.

@MarcosV_ 3CX @SaschaA_3CX @avraammich_3CX @MarcusK_3CX

 

[patrickb]

Mittlerweile scheint das Problem über den Zeitserver gelöst worden zu sein. Stelle gerade alle 33er zu 46er zurück.

 

[4786]

Bei mir ist der Status leider unverändert.

 

[Bodo]

Der Workaround über die TIMEZONE_GLOBAL_ID hat hier funktioniert. Beim Zurückstellen auf 46 zeigt sich bei uns aktuell noch die falsche Uhrzeit.

 

[zeeb]

Mittlerweile scheint das Problem über den Zeitserver gelöst worden zu sein. Stelle gerade alle 33er zu 46er zurück.

Kann ich so leider nicht nachvollziehen - hab gerade testweise ein Yealink komplett zurück gesetzt und neu provisioniert: noch immer eine Stunde zu früh. Config die im Provisioning File steht ist schlichtweg falsch.

in der Provisionierung steht:

#Configure the DST type when the DST feature is enabled; 0-By Date (default), 1-By Week;
local_time.dst_time_type = 0

#Configure the start time of DST. The default value is 1/1/0.
#If the DST type is configured as By Date, the value format is Month/Day/Hour. For example, the value 5/20/10 means the start time is at 10:00 on May 20.
#If the DST type is configured as By Week, the value format is Month/Day of Week/Day of Week Last in Month/Hour of Day.
#For example, the value 1/4/2/5 means the start time is at 5 o'clock on Tuesday of the 4th week in January.
local_time.start_time = 3/28/2

#Configure the end time of DST. The default value is 12/31/23. The value format is the same to the start time.
local_time.end_time =  10/25/3

nach der manuellen Korrektur direkt auf dem Telefon habe ich aber:

local_time.dst_time_type = 1
local_time.end_time = 10/5/7/3:0
local_time.ntp_server1 = pool.ntp.org
local_time.start_time = 3/5/7/2:0
local_time.summer_time = 1
local_time.time_zone = +1

 

[patrickb]

Der Workaround über die TIMEZONE_GLOBAL_ID hat hier funktioniert. Beim Zurückstellen auf 46 zeigt sich bei uns aktuell noch die falsche Uhrzeit.

Cool das es auch bei dir läuft mit dem TIMEZONE_GLOBAL_ID Workaround.

Ich habe hier teilweise unterschiedliche Ergebnisse beim zurückstellen: Bei manchen Kunden scheint es zu laufen, bei manchen nicht. Evtl. funkt da auch noch der Cache, DNS oder irgendetwas anderes dazwischen. ggf. auch mal die Dienste oder die Anlage rebooten? Würde mich interessieren was dann passiert mit korrekter 46er ID.

Ansonsten würde ich erstmal die 33er Lösung nutzen.

 

[patrickb]

Kann ich so leider nicht nachvollziehen

Klappt denn der Workaround mit der 33er Zeitzone von oben bei dir? Ich hatte noch vergessen, das teilweise die Telefone 1 x neu provisioniert werden müssen.

 

[patrickb]

Ich habe gerade ein wenig rumprobiert, da mich heute morgen zahlreiche Kunden angerufen haben.

Ein schneller einfacher Workaround ist es - sofern man eine On-Prem Anlage oder eine selbstgehoste Anlage betreibt, den Global Property "TIMEZONE_GLOBAL_ID" anzupassen. Von 46 zu 33. (Alternativ: 34, 35, 36, 126)

Um Ihn anzupassen navigiert man in die Einstellungen -> Parameter -> und wählt dort den Reiter "Benutzerdefinierte Parameter" aus. In der Suche wird nach "TIMEZONE_GLOBAL_ID" gesucht und der Wert dann von 46 auf 33 (Deutschland zu Irland) angepasst. Zusätzlich muss im jeweiligen Telefon (wenn nicht ohnehin schon so eingestellt) die Zeitzone auf "Standard-Zeitzone verwenden" eingestellt werden.

Die Telefone zeigen anschließend die korrekte Uhrzeit an und auch in den Anrufberichten und auch den Logs stimmt die Uhrzeit noch. Das sollte vorübergehend helfen - hat es zumindest bei zahlreichen meiner Kunden.

PS: Nächste Woche zurückstellen nicht vergessen.

@MarcosV_ 3CX @SaschaA_3CX @avraammich_3CX @MarcusK_3CX

Kleiner Nachtrag: Ggf. müssen die Telefone nach der Anpassung noch einmal neu gestartet bzw. neu provisioniert werden.

 

[4786]

Ich habe sieben eine Antwort auf mein Ticket erhalten.
Am Problem wird gearbeitet.
Wir werden Informiert sobald das Update verfügbar ist.

 

[zeeb]

Ich habe auch eine Antwort von 3cx erhalten: der Support meint das sei die Schuld von Yealink, da sich die T4X Serie ja mit den selben Settings normal verhält. ich habe jetzt auch mal ein Ticket bei Yealink aufgemacht...

 

[HXS Office]

Also ich seh das so: die Provisionierung der Telefone erfolgt über die PBX - in der Provisionierung wird offensichtlich die Info geschickt, dass es der 4. Sonntag im März ist - und nicht der letzte Sonntag. Hier kann ich aber keine Fehler bei Yealink erkennen sondern nur in der Provisionierung.



Beim Enddatum machen Sie es ja dann richtig...

 

[Rolf Grunert]

Wir haben hier mal am Yealink ein Werksreset gemacht und dann über die WebGUI +1, Berlin und automatisch eingestellt.
Hier zeigt sich ohne Provisionierung durch die 3CX der Fehler schon.

 

[zeeb]

Nur der Vollständigkeit halber - hier die Forenbeiträge aus anderen Foren zu diesem Thema:

https://www.reddit.com/r/3CX/comments/1bnara9

Do anyone else's Yealink phones have messed up daylight savings time (UK) today?

@ I'm in france. as the timezone has made the time change early. Is the time wrong only on the phones or also on the server? If yes for the server, does this affect the office hours for incoming calls in the current configuration. Hi there. The issue has only to do with the endpoint and...

www.3cx.com

DST a week early

Good morning, we've got 2 instances (that im aware of atm) running 18.0 U9 B20 The phones have gone in to BST a week early. The time on the OS is the correct time, using yealinks on the latest supported FW with supported template.

www.3cx.com

UK Timezone