Yealink Uhrzeit falsch - Sommerzeit eine Woche zu früh

Soweit ich weiß: nein.

Lustig wird das vor allem bei den AX83H. Factory Reset - klar doch - und tschüß ...
yep das war auch mein Gedanke, wir haben da auch einige im Einsatz..bin gespannt ob sich da noch was tut. Da ist noch das Thema wie komm ich auf alle Telefone drauf :) die stehen lokal beim Kunden..und das mit Kunden durchzuspieln puh
 
  • Like
Reaktionen: Ben04 und fxbastler
... Da ist noch das Thema wie komm ich auf alle Telefone drauf :) die stehen lokal beim Kunden..und das mit Kunden durchzuspieln puh
Factory Reset geht ganz schnell wenn man remote Zugang hat.
Aber danach: lokales Passwort vergeben, den blöden Tastenpieps deaktivieren und WLAN anbinden - das bei den meisten unserer Kunden schlicht unmöglich.
 
  • Like
Reaktionen: avido_3cx
Kleiner Tip den ich gern mache.
Alle User filtern die ein betroffenes Telefon haben. Alle anhaken und eine Kleinigkeit ändern in den Optionen.... z.B. Leuchtdauer Display von 20 auf 30sekunden ändern. Oder...wenn die Option nicht greift.... eine BLF Taste die ganz hinten liegt neu belegen. Wenn dann gespeichert wird gibt es eine neue Konfig die zum RPS Server übertragen wird und nach dem Werksreset zum abrufen bereit liegt. Einzige Lösung um Bestandsanlagen gesammelt mit neuen RPS Daten zu versorgen.
Bleibt nur noch der nervige Werksreset..... Remote oder fix ne Sammelmail rausgeben das jeder mal lange auf die OK Taste drücken soll. Ist das RPS File dann verfügbar geht wenigstens alles automatisch. Vorher prüfen !
VG!
 
  • Like
Reaktionen: fxbastler
  • Like
Reaktionen: mbehrens
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…
 
So, es ist wieder ein Jahr vergangen und scheinbar wurde das Problem noch immer nicht gelöst. In jedem Fall melden sich mal wieder etliche Kunden mit T3,T4 und T5 Yealink Telefonen, auf denen die Zeit schon auf Sommerzeit umgestellt wurde. Betroffen sind ca. 200 3CX Systeme mit ca. 2-3000 Telefonen. Ich möchte also nicht irgendwelche Workarounds, sondern eine funktionierende Dauerlösung. Grundsätzlich egal ist es mir auch, wer dafür verantworlich ist. 3CX und Yealink müssen einfach mal so zusammenarbeiten, das dieses Problem endlich gelöst wird.
 
So, es ist wieder ein Jahr vergangen und scheinbar wurde das Problem noch immer nicht gelöst. In jedem Fall melden sich mal wieder etliche Kunden mit T3,T4 und T5 Yealink Telefonen, auf denen die Zeit schon auf Sommerzeit umgestellt wurde. Betroffen sind ca. 200 3CX Systeme mit ca. 2-3000 Telefonen. Ich möchte also nicht irgendwelche Workarounds, sondern eine funktionierende Dauerlösung. Grundsätzlich egal ist es mir auch, wer dafür verantworlich ist. 3CX und Yealink müssen einfach mal so zusammenarbeiten, das dieses Problem endlich gelöst wird.
Ja zum kotzen! Gerade auch den ersten Anruf gehabt...
 
  • Like
Reaktionen: HansHansHans
@avraammich_3CX kannst du bei Yealink das Problem noch mal einkippen? Das kann ja nicht sein das dies immer noch ein Thema ist.
 
  • Like
Reaktionen: HansHansHans
Hi!
Bei uns hat sich bis jetzt nur ein Kunde mit einem T42 gemeldet.
Als das Thema hier wieder aufploppte hab ich mal in alle Testtelefone rein gesehen auf die ich schnell Zugriff als Testgerät habe.
i.O. = in der Oberfläche steht jeweils beginn und Ende auf "Last Sunday"
T73/ 74 U+W i.O. FW 185.87.0.15
T53/ 54 (W) i.O. FW 96.87.0.22
T48 S i.O. FW 96.86.0.180
T46 G i.O. FW 28.83.0.136 (Edit: generisch Template T46 (ohne Zusatz)

T42S nicht i.O. "4th" of March ABER "last" of October ; Steht auch auf Automatisch, komische Konfiguration.....
Edit: FW 66.86.0.180

Schaut mal bitte genau rein welches Modell mit welcher Firmware Betroffen ist. VG!
 
Zuletzt bearbeitet:
Habe gerade die Rückmeldung von einem Kollegen bekommen das zumindest bei den T54w mit der 22er Firmware das Problem behoben ist. Das T46s (96.86.0.180) hier ist allerdings auf der neuesten und hat weiterhin das Problem.
 
Hab nun die offizielle Info, T54w usw da ist das Problem mit dem aktuellen 22er Firmware Update behoben. T46s usw bekommen keine Updates mehr da EOL und somit auch nicht den Fix für die DST Problematik.
 

Statistik des Forums

Themen
44.414
Beiträge
232.721
Mitglieder
78.331
Neuestes Mitglied
b2daniel