Yealink Telefone erneut 1 Woche zu früh in der Sommerzeit

patrickb

Platinum Partner
Advanced Certified
Mitglied seit
6. Februar 2021
Beiträge
928
Leider ist es auch dieses Jahr so, dass Yealink Telefone scheinbar wieder am vierten Sonntag im März (gestern) auf Sommerzeit umgestellt haben, trotz das ein NTP Server hinterlegt ist und die Zeitzonen-Config auf automatisch steht.

Wir haben gerade die Lösung von letztem Jahr getestet und sie funktioniert scheinbar auch in der V20.

Sofern man also von den Usern genötigt wird, etwas zu tun, statt abzuwarten: Hier eine mögliche, schnelle Lösung:


Hinweis: Parameter ist in der V20 unter Erweitert -> Parameter -> "Benutzerdefinierte Parameter" zu finden.

@SaschaA_3CX @avraammich_3CX @MarcusK_3CX
@MarcosV_3CX
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Voipinator
Top, Danke für den Post. Genau das, was ich brauche :D

Allerdings ziemlich mühsam, dies bei allen Kunden (On Prem) zu machen und anschliessend wieder zu ändern.
 
Top, Danke für den Post. Genau das, was ich brauche :D

Allerdings ziemlich mühsam, dies bei allen Kunden (On Prem) zu machen und anschliessend wieder zu ändern.
Ja, leider. Das Template anzupassen und neu zu provisionieren oder es an allen Telefonen manuell auf 5. Wochenende einzustellen wäre noch mühseliger. Ab nächstem Jahr ist es dann zum glück für die nächsten 5 kein Problem mehr weil das 4. Wochenende dann wieder das korrekte ist.
 
  • Like
Reaktionen: rezott
Weiteres Update: Die Telefone müssen in der 3CX auf globale Zeitzone stehen (sonst bringt das ändern des Parameters nichts -> geht im User in den Optionen bei "IP Telefon") und ggf. einmal neugestartet / provisioniert werden.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: rezott
Da dieses Problem schon vor einem Jahr bestanden hat liegt der Ball entweder bei 3CX oder bei Yealink.
Die Zeitumstellung ist CET immer der letzte Sonntag vom März bzw. Oktober (zumindest kenne ich es nicht anders in CET).

Gemäss Vorlage "yealinkT5x.ph.xml" wird der Start bzw. Ende der Sommerzeit durch Variablen ausgelöst, hier die wichtigsten aus der Provisionierungsvorlage

----------------------------------
#Configure the daylight saving time feature; 0-Disabled, 1-Enabled, 2-Automatic (default);
local_time.summer_time = 2

#Configure the DST type when the DST feature is enabled; 0-By Date (default), 1-By Week;
local_time.dst_time_type = 0
local_time.start_time = %%param::time_dst_start_month%%/%%param::time_dst_start_day%%/%%param::time_dst_start_hour%%
----------------------------------

und korrekt wäre es, wenn es von 3CX generiert würde:
----------------------------------
local_time.summer_time = 1
local_time.dst_time_type = 1
local_time.start_time = 3/5/7/2:0
----------------------------------
3. Monat [März] / 5. [bzw. letzter Tag] / 7 Tag [also Sonntag] 2 [Uhr]:0 [Minuten]. sprich 02:00


Wenn ich jedoch mir die Konfiguration des Yealinks anschaue überlässt 3CX die Zeiteinstellung dem Endgerät, z.B. meinem Yealink T54W, auszug aus der Konfiguration:
----------------------------------
#Configure the daylight saving time feature; 0-Disabled, 1-Enabled, 2-Automatic (default);
local_time.summer_time = 2

#Configure the DST type when the DST feature is enabled; 0-By Date (default), 1-By Week;
local_time.dst_time_type = 0
local_time.start_time = 3/28/2
local_time.end_time = 10/25/3
----------------------------------

Dass die Start- bzw. Enddaten falsch sind (28.03 bzw. 25.10) ist hier irrelevant da "local_time.summer_time = 2" ist, sprich Yealink macht hier den Fehler.

Fix 1: Yealink fixt dies intern dass "local_time.summer_time = 2" korrekt ist
Fix 2: 3CX ändert die Provisionierung von "local_time.summer_time = 2" auf "local_time.summer_time = 1", ändert "local_time.dst_time_type = 0" auf "local_time.dst_time_type = 1" und generiert die korrekten Sommer- bzw. Winterzeitumstellungen anhand "letzter Sonntag" etc. und muss dafür keine absoluten Daten berechnen.

Vorrangig sollte Yealink den Fix machen, wenn Yealink das nicht hinkriegt dann sollte 3CX dies evtl. in Betracht ziehen.

Grüsse aus der Schweiz - Josip Meglaj.
 
  • Like
Reaktionen: timmbo
Manchmal ist es auch von Nöten, den Standort des Telefons anzupassen von "Germany" auf "KEINE" in den Vorlagen wäre das der Parameter "local_time.time_zone_name = None" aus local_time.time_zone_name = %%TimeZoneName%%

Das Anpassen des Templates an sich auch Seitens 3CX @LogitComputer bringt in dem Sinne nur was für dieses Jahr, da im nächsten Jahr das vierte Wochenende das korrekte ist/wäre. Das ist nur in diesem und letztem Jahr relevant.
 
Da dieses Problem schon vor einem Jahr bestanden hat liegt der Ball entweder bei 3CX oder bei Yealink.
Die Zeitumstellung ist CET immer der letzte Sonntag vom März bzw. Oktober (zumindest kenne ich es nicht anders in CET).

Gemäss Vorlage "yealinkT5x.ph.xml" wird der Start bzw. Ende der Sommerzeit durch Variablen ausgelöst, hier die wichtigsten aus der Provisionierungsvorlage

----------------------------------
#Configure the daylight saving time feature; 0-Disabled, 1-Enabled, 2-Automatic (default);
local_time.summer_time = 2

#Configure the DST type when the DST feature is enabled; 0-By Date (default), 1-By Week;
local_time.dst_time_type = 0
local_time.start_time = %%param::time_dst_start_month%%/%%param::time_dst_start_day%%/%%param::time_dst_start_hour%%
----------------------------------

und korrekt wäre es, wenn es von 3CX generiert würde:
----------------------------------
local_time.summer_time = 1
local_time.dst_time_type = 1
local_time.start_time = 3/5/7/2:0
----------------------------------
3. Monat [März] / 5. [bzw. letzter Tag] / 7 Tag [also Sonntag] 2 [Uhr]:0 [Minuten]. sprich 02:00


Wenn ich jedoch mir die Konfiguration des Yealinks anschaue überlässt 3CX die Zeiteinstellung dem Endgerät, z.B. meinem Yealink T54W, auszug aus der Konfiguration:
----------------------------------
#Configure the daylight saving time feature; 0-Disabled, 1-Enabled, 2-Automatic (default);
local_time.summer_time = 2

#Configure the DST type when the DST feature is enabled; 0-By Date (default), 1-By Week;
local_time.dst_time_type = 0
local_time.start_time = 3/28/2
local_time.end_time = 10/25/3
----------------------------------

Dass die Start- bzw. Enddaten falsch sind (28.03 bzw. 25.10) ist hier irrelevant da "local_time.summer_time = 2" ist, sprich Yealink macht hier den Fehler.

Fix 1: Yealink fixt dies intern dass "local_time.summer_time = 2" korrekt ist
Fix 2: 3CX ändert die Provisionierung von "local_time.summer_time = 2" auf "local_time.summer_time = 1", ändert "local_time.dst_time_type = 0" auf "local_time.dst_time_type = 1" und generiert die korrekten Sommer- bzw. Winterzeitumstellungen anhand "letzter Sonntag" etc. und muss dafür keine absoluten Daten berechnen.

Vorrangig sollte Yealink den Fix machen, wenn Yealink das nicht hinkriegt dann sollte 3CX dies evtl. in Betracht ziehen.

Grüsse aus der Schweiz - Josip Meglaj.
Manchmal ist es auch von Nöten, den Standort des Telefons anzupassen von "Germany" auf "KEINE" in den Vorlagen wäre das der Parameter "local_time.time_zone_name = None" aus local_time.time_zone_name = %%TimeZoneName%%

Das Anpassen des Templates an sich auch Seitens 3CX @LogitComputer bringt in dem Sinne nur was für dieses Jahr, da im nächsten Jahr das vierte Wochenende das korrekte ist/wäre. Das ist nur in diesem und letztem Jahr relevant.

Das Anpassen der Yealink Konfiguration würde etwas bringen, denn es ist ja immer der "letzte" Sonntag, egal ob das der vierte oder fünfte ist. So steht es jedenfalls im Yealink drin: 1 = erster / 2 = zweiter / 3 = dritter / 4 = vierter / 5 = letzter.

Ob der "letzte" Sonntag der vierte oder fünfte ist spielt keine Rolle, denn beim deaktivieren der Sommerzeit steht bei Yealink ja auch "letzter", und das ist korrekt.

3CX könnte dies ebenfalls abfangen, ist halt der grössere Aufwand.
 
  • Like
Reaktionen: timmbo
Kleines Update: Yealink hat für mein T54W ein Firmware Update am 14.03.2025 rausgegeben, Version 96.87.0.15.
ist von 3CX nicht frei gegeben und hat zwei Bug-Fixes:

1 Fixed the issue of abnormal daylight saving time zones on the phone.
2 Fixed the issue of the phone dropping the network with EEE (Energy Efficient Ethernet).

Könnte sein dass es mit der zwei Wochen alten Firmware geht, ich teste es mal.
 
  • Like
Reaktionen: fxbastler
leider nein :-(

Firmwareaktualisierung fehlgeschlagen!
ROM ungültig
Neustart, bitte warten ...
 
  • Sad
Reaktionen: fxbastler
leider nein :-(

Firmwareaktualisierung fehlgeschlagen!
ROM ungültig
Neustart, bitte warten ...
Richtig, die Firmware habe ich an einem unabhängigen Yealink-Telefon ebenfalls schon mal versucht zu installieren.
Funktioniert nicht.
Ein Downgrade auf die angegebene Urversion 96.86.0.70 klappt, aber auch von dort ist ein Upgrade nicht möglich.
Keine Ahnung, ob Yealink die eigene Software nicht erstmal testet bevor man diese online stellt, aber der Kontakt zu Yealink ist ebenfalls äußerst schwierig.
 
So hat es ein Kunde von mir gelöst! ;)
2025-03-26 08.16.33.jpg
Gut das ich in letzter Zeit nur mehr sn.m verkaufe.
 
Zuletzt bearbeitet:
Hier mal meine Lösung.
Vorab: Wir haben eine OnPremise-Anlage und setzen custom-templates ein, weil die mitgelieferten einige benötigte Funktionen nicht bieten.

Hoffentlich schlägt hier keine Zensur zu.

Wir haben im Time-Block die Einstellungen so gesetzt:
local_time.dst_time_type = 0
local_time.start_time = %%param::time_dst_start_month%%/%%param::time_dst_start_day%%/%%param::time_dst_start_hour%%
local_time.end_time = %%param::time_dst_end_month%%/%%param::time_dst_end_day%%/%%param::time_dst_end_hour%%

Und in der 3CX die folgenden Parameter korrekt gesetzt.
time_dst_end_month
time_dst_end_day
time_dst_start_day
time_dst_start_month

Dann ziehen sich die Telefone Beginn und Ende der Sommerzeit aus den Parametern der 3CX.
Funktioniert bei uns super, allerdings hat die Anpassung bei uns alle Custom-Templates aus den Telefonen rausgekegelt.
Wundervolles "Feature" der 3CX-Anlage.
Freundlicherweise hat mich der 3CX-Support durch ein Zurückweisen des Supports für Custom-Templates und Probleme damit dazu ermutigt die Anlage ein wenig tiefer zu betrachten.

Hier entsprechend eine Anleitung wie man die Template-Verknüpfung in der 3CX-Anlage korrigiert (oder einfach komplett ändert).
Viel Spaß.

Templates korrigieren
Schritt 1: Verbinden
Lokal pgAdmin installiert. (https://www.pgadmin.org/download/)

SSH-Verbindung mit Port-Tunnel 5432 auf den 3CX-Server.
(Port-Ziel 127.0.0.1:5432 weil man auf den Server getunnelt wird und dann dort auf den Localhost will) .
(Alternativ kann für die DB-Verbindung auch die SSH-Tunnel-Funktion von pgAdmin genutzt werden)

Schritt 2: Datenbankcredentials
Auf dem Server (in der SSH-Session):

cat /var/lib/3cxpbx/Bin/3CXPhone S ystem.ini
(Wenn ich das zusammenschreibe schmeißt das Forum einen Fehler)

Unter dem Block [CfgServerProfile] finden sich die Einträge mit den Zugangsdaten für die Datenbank:

MasterDBUser = phonesystem
MasterDBPassword = **********************

Diese entsprechend herauskopieren.

Schritt 3: Daten auflisten

Dann mit pgAdmin4 mit diesen Daten auf die Datenbank verbinden (bei nicht-PGAdmin-SSH-Tunnel auf 127.0.0.1:5432) verbinden.
Datenbank ist bei uns „database_single“, bei euch vermutlich ebenfalls.

Navigieren nach
Schemas -> Public -> Tables

Hier findet sich die Tabelle „extdevice“
Rechtsklick->View/Edit Data->All rows

Schritt 4: Korrekte Werte herausfinden

Per MAC-Adresse nach einem Gerät suchen, wo das Template korrekt verknüpft ist.
SELECT * FROM public.extdevice WHERE macaddress='001122334455'

Gegebenenfalls eines dafür einrichten.
Wichtig sind hier meinem Test nach dann die Werte templateused, filename1 und filename2

Schritt 5: Korrektur

Entsprechend bei den Geräten, wo das Template nicht korrekt ist, die Einträge korrigieren.
Mein Custom-Template nannte sich z.B. Custom_T57W
Folgende Suche hat mir dann entsprechende Geräte gelistet:

SELECT * FROM public.extdevice WHERE templateused like '%t57w%'

Das war auch bei den inkorrekt Verknüpften Geräten noch als 'Custom_T57W' in der Spalte 'templateused' hinterlegt.
Entsprechend habe ich die Werte dann so gesetzt:

UPDATE public.extdevice SET filename1 = null WHERE templateused = 'Custom_T57W'
UPDATE public.extdevice SET filename2 = 'Custom_T57W-custom_t57w.ph.xml' WHERE templateused = 'Custom_T57W'
UPDATE public.extdevice SET templateused = 'custom_T57W.ph.xml' WHERE templateused = 'Custom_T57W'

Klar, man kann das auch in einem Update zusammenfassen, ich habe es so gemacht.
Man kann auch unten in der Liste die Werte manuell anpassen und mit F6 abspeichern.

Schritt 6: Dienste neu starten
Danach dann die Dienste „...Configuration Server“ und „...Management Console” neu starten.
Man kann auch den Server neu starten.

Telefone neu Provisionieren
Die Telefone sollten nun mit korrektem Template gelistet sein und können neu provisioniert werden.

Anmerkungen
Die Spalte pv_settings enthält scheinbar die Einstellungen die man für das Gerät unter den Nebenstelle setzen kann.
Hier sollte man beim Kopieren aber wohl drauf achten, dass da die Firmware mit drin steht.
Ob er bei Geräten, die eine andere Version haben, eine Anpassung vornimmt, die Geräte flasht oder was sonst passiert… nicht geprüft.
Also sicherheitshalber vorher alle auf identischen Stand bringen.
So könnte man dann aber in der Theorie alle Geräte eines Typs umstellen… eins als Template, den Wert aus der Spalte dann in die anderen rein… Dienste neu starten, Geräte neu Provisionieren über die 3CX-Gui…
 
Richtig, die Firmware habe ich an einem unabhängigen Yealink-Telefon ebenfalls schon mal versucht zu installieren.
Funktioniert nicht.
3CX bietet seit heute die 96.87.0.16 an, also +01 am Ende, die ROM lässt sich wohl auch installieren.
Komischerweise ließ sich nur ein T57W direkt aktualisieren, ein T54W musste manuell am Telefon neu
gestartet werden und hat erst danach mit dem Update begonnen.
 
Hier mal meine Lösung.
Vorab: Wir haben eine OnPremise-Anlage und setzen custom-templates ein, weil die mitgelieferten einige benötigte Funktionen nicht bieten.

Hoffentlich schlägt hier keine Zensur zu.

Wir haben im Time-Block die Einstellungen so gesetzt:
local_time.dst_time_type = 0
local_time.start_time = %%param::time_dst_start_month%%/%%param::time_dst_start_day%%/%%param::time_dst_start_hour%%
local_time.end_time = %%param::time_dst_end_month%%/%%param::time_dst_end_day%%/%%param::time_dst_end_hour%%

Und in der 3CX die folgenden Parameter korrekt gesetzt.
time_dst_end_month
time_dst_end_day
time_dst_start_day
time_dst_start_month

Dann ziehen sich die Telefone Beginn und Ende der Sommerzeit aus den Parametern der 3CX.
Funktioniert bei uns super, allerdings hat die Anpassung bei uns alle Custom-Templates aus den Telefonen rausgekegelt.
Wundervolles "Feature" der 3CX-Anlage.
Freundlicherweise hat mich der 3CX-Support durch ein Zurückweisen des Supports für Custom-Templates und Probleme damit dazu ermutigt die Anlage ein wenig tiefer zu betrachten.

Hier entsprechend eine Anleitung wie man die Template-Verknüpfung in der 3CX-Anlage korrigiert (oder einfach komplett ändert).
Viel Spaß.

Templates korrigieren
Schritt 1: Verbinden
Lokal pgAdmin installiert. (https://www.pgadmin.org/download/)

SSH-Verbindung mit Port-Tunnel 5432 auf den 3CX-Server.
(Port-Ziel 127.0.0.1:5432 weil man auf den Server getunnelt wird und dann dort auf den Localhost will) .
(Alternativ kann für die DB-Verbindung auch die SSH-Tunnel-Funktion von pgAdmin genutzt werden)

Schritt 2: Datenbankcredentials
Auf dem Server (in der SSH-Session):

cat /var/lib/3cxpbx/Bin/3CXPhone S ystem.ini
(Wenn ich das zusammenschreibe schmeißt das Forum einen Fehler)

Unter dem Block [CfgServerProfile] finden sich die Einträge mit den Zugangsdaten für die Datenbank:

MasterDBUser = phonesystem
MasterDBPassword = **********************

Diese entsprechend herauskopieren.

Schritt 3: Daten auflisten

Dann mit pgAdmin4 mit diesen Daten auf die Datenbank verbinden (bei nicht-PGAdmin-SSH-Tunnel auf 127.0.0.1:5432) verbinden.
Datenbank ist bei uns „database_single“, bei euch vermutlich ebenfalls.

Navigieren nach
Schemas -> Public -> Tables

Hier findet sich die Tabelle „extdevice“
Rechtsklick->View/Edit Data->All rows

Schritt 4: Korrekte Werte herausfinden

Per MAC-Adresse nach einem Gerät suchen, wo das Template korrekt verknüpft ist.
SELECT * FROM public.extdevice WHERE macaddress='001122334455'

Gegebenenfalls eines dafür einrichten.
Wichtig sind hier meinem Test nach dann die Werte templateused, filename1 und filename2

Schritt 5: Korrektur

Entsprechend bei den Geräten, wo das Template nicht korrekt ist, die Einträge korrigieren.
Mein Custom-Template nannte sich z.B. Custom_T57W
Folgende Suche hat mir dann entsprechende Geräte gelistet:

SELECT * FROM public.extdevice WHERE templateused like '%t57w%'

Das war auch bei den inkorrekt Verknüpften Geräten noch als 'Custom_T57W' in der Spalte 'templateused' hinterlegt.
Entsprechend habe ich die Werte dann so gesetzt:

UPDATE public.extdevice SET filename1 = null WHERE templateused = 'Custom_T57W'
UPDATE public.extdevice SET filename2 = 'Custom_T57W-custom_t57w.ph.xml' WHERE templateused = 'Custom_T57W'
UPDATE public.extdevice SET templateused = 'custom_T57W.ph.xml' WHERE templateused = 'Custom_T57W'

Klar, man kann das auch in einem Update zusammenfassen, ich habe es so gemacht.
Man kann auch unten in der Liste die Werte manuell anpassen und mit F6 abspeichern.

Schritt 6: Dienste neu starten
Danach dann die Dienste „...Configuration Server“ und „...Management Console” neu starten.
Man kann auch den Server neu starten.

Telefone neu Provisionieren
Die Telefone sollten nun mit korrektem Template gelistet sein und können neu provisioniert werden.

Anmerkungen
Die Spalte pv_settings enthält scheinbar die Einstellungen die man für das Gerät unter den Nebenstelle setzen kann.
Hier sollte man beim Kopieren aber wohl drauf achten, dass da die Firmware mit drin steht.
Ob er bei Geräten, die eine andere Version haben, eine Anpassung vornimmt, die Geräte flasht oder was sonst passiert… nicht geprüft.
Also sicherheitshalber vorher alle auf identischen Stand bringen.
So könnte man dann aber in der Theorie alle Geräte eines Typs umstellen… eins als Template, den Wert aus der Spalte dann in die anderen rein… Dienste neu starten, Geräte neu Provisionieren über die 3CX-Gui…
Der einfachere Weg hier wäre, wenn du via SSH auf den Server gehst, dort das Standard-Template anpasst und die Anlage rebootest. Hat denselben Effekt und wird nicht als Custom-Template angezeigt. Musst nur ein Auge drauf haben, dass es beim nächsten Update nicht überschrieben wird.

Für eine Anlage mag das oben ein Weg sein, der passt. Wenn du das aber über 150× machst, kostet das erstens eine Menge Zeit, dadurch indirekt eine Menge Geld (das kein Kunde bezahlen will, weil es ja ein Fail von Yealink ist), und drittens jede Menge Nerven, weil du stumpf immer wieder dasselbe machst – abgesehen davon, dass die DB zum "Schreiben" eigentlich tabu sein sollte.

Eine weitere Alternative wäre der Export/Import der User, da du hier das verwendete Template in der CSV direkt anpassen (suchen, ersetzen) kannst. Zudem werden SIP-ID, SIP-Auth, Kennwort, MAC usw. auch gleich mit exportiert – genau wie die DID- und Outbound-CID-Zuweisungen und mittlerweile endlich auch die BLFs.

Trotzdem: Super, dass du das hier so umfangreich dokumentiert hast und deine Lösung mit allen teilst – das ist ja auch nicht selbstverständlich und solange es für dich passt ist ja alles fein :)
 
Der einfachere Weg hier wäre, wenn du via SSH auf den Server gehst, dort das Standard-Template anpasst und die Anlage rebootest. Hat denselben Effekt und wird nicht als Custom-Template angezeigt. Musst nur ein Auge drauf haben, dass es beim nächsten Update nicht überschrieben wird.

Für eine Anlage mag das oben ein Weg sein, der passt. Wenn du das aber über 150× machst, kostet das erstens eine Menge Zeit, dadurch indirekt eine Menge Geld (das kein Kunde bezahlen will, weil es ja ein Fail von Yealink ist), und drittens jede Menge Nerven, weil du stumpf immer wieder dasselbe machst – abgesehen davon, dass die DB zum "Schreiben" eigentlich tabu sein sollte.

Eine weitere Alternative wäre der Export/Import der User, da du hier das verwendete Template in der CSV direkt anpassen (suchen, ersetzen) kannst. Zudem werden SIP-ID, SIP-Auth, Kennwort, MAC usw. auch gleich mit exportiert – genau wie die DID- und Outbound-CID-Zuweisungen und mittlerweile endlich auch die BLFs.

Trotzdem: Super, dass du das hier so umfangreich dokumentiert hast und deine Lösung mit allen teilst – das ist ja auch nicht selbstverständlich und solange es für dich passt ist ja alles fein :)

Naja, wenn aber die Anlage komplett keine Provisionierung der Geräte mehr zulässt, weil die Anlage die Verknüpfung der Telefone mit den Templates nichtmehr macht...
Die Anlage hat zwar den Namen des Custom-Templates angezeigt, aber das Telefon nicht mit dem Template verknüpft.
Es waren keinerlei (Provisionierungs)-Aktionen mit den Telefonen mehr möglich.

Ferner kann man über die GUI nicht das Template anpassen ohne das Gerät zu löschen, geschweige denn dies in einer Sammelaktion zu machen. (Wäre echt mal n geiles neues Feature)
Unsere Alternative war über 300 Telefone manuell zu löschen und neu anzulegen.
Mit oben gezeigter Methode habe ich das bei einem Gerät gemacht und dann alle anderen Geräte auf die gleichen Template-Einträge gesetzt und alles läuft nun wieder reibungslos.

Der einzige Ausfall war, als wir die Dienste der Anlage neu gestartet haben. (Ca. 30 Sekunden)

Export/Import: Auch eine Option, aber bei Strukturierung mit mehreren "Abteilungen" ist hier auch wieder Nacharbeit erforderlich.

PS: lasst uns einfach hoffen, dass sowas nicht öfters nötig wird.
 
Es gibt also KEINE Lösung ohne RESET und neu Provisionierung der Yealink IP-Telefone?
Also in einem Jahr (2026) wieder die Reklamationen der User!
 
Es gibt also KEINE Lösung ohne RESET und neu Provisionierung der Yealink IP-Telefone?
Also in einem Jahr (2026) wieder die Reklamationen der User!
klar, die mit dem Parameter (siehe oben).
 
klar, die mit dem Parameter (siehe oben).
Es sind schon viele Parameter (oben). Welche genau meinst du?
Eine einfachere Lösung nur mit dem aktuellen Firmwareupdate von Yealink OHNE RESET und OHNE neu Provisionierung (Telefon löschen und neu hinzufügen wegen dem RPS request) gibt es nicht?
 
Es sind schon viele Parameter (oben). Welche genau meinst du?
Eine einfachere Lösung nur mit dem aktuellen Firmwareupdate von Yealink OHNE RESET und OHNE neu Provisionierung (Telefon löschen und neu hinzufügen wegen dem RPS request) gibt es nicht?
Ein Provisioning geht ohne das Telefon zu löschen und neu hinzuzufügen, sofern die 3CX-Anlage das Template noch verknüpft hat.
Du kannst also das Standard-Template anpassen und dann die Telefone neu Provisionieren, das passiert eh regelmäßig. Hier ziehen sich die Telefone nur die aktuelle Konfig (ohne Reboot).
Ein Löschen und neu hinzufügen wird (normalerweise) nötig, wenn man das Template wechselt.
Mittels meiner weiter oben beschriebenen (nicht offiziell supporteten) Methode, geht es aber auch.

Code:
local_time.dst_time_type = 0
local_time.start_time = %%param::time_dst_start_month%%/%%param::time_dst_start_day%%/%%param::time_dst_start_hour%%
local_time.end_time = %%param::time_dst_end_month%%/%%param::time_dst_end_day%%/%%param::time_dst_end_hour%%
Und in der 3CX die folgenden Parameter korrekt gesetzt.
Code:
time_dst_end_month
time_dst_end_day
time_dst_start_day
time_dst_start_month
 
Zuletzt bearbeitet:
Es sind schon viele Parameter (oben). Welche genau meinst du?
Eine einfachere Lösung nur mit dem aktuellen Firmwareupdate von Yealink OHNE RESET und OHNE neu Provisionierung (Telefon löschen und neu hinzufügen wegen dem RPS request) gibt es nicht?
Ich meinte den Global Property wie hier beschrieben:
 

Statistik des Forums

Themen
44.500
Beiträge
232.994
Mitglieder
78.370
Neuestes Mitglied
wied