Telegram Meldung ignoriert, Uhrzeit falsch?

[BananaJoe]

@atomicix du könntest mal das Logging verschärfen, also von Info auf Debug stellen, das ganz noch mal versuchen und die Logs hier einstellen. ist ja schon Debug

Vielleicht kann man dieses etwas entnehmen
Du hast ja oben in Zeile 5 z.B.

2025-01-30 21:54:53.644	debug	{"message_id":38864,"from":{"id":233794520,"is_bot":false,"first_name":"Christian","last_name":"XXX","username":"AtomicIX","language_code":"de"},"chat":{"id":233794520,"first_name":"Christian","last_name":"XXXX","username":"AtomicIX","type":"private"},"date":1738270451,"text":"Status"}

Der Zeitstempel des Log-Eintrags ist 2025-01-30 21:54:53.644. Weiter hinten kommt auch ein Zeitstempel: "date":1738270451. Wenn ich den umrechne, z.B. per https://www.unixtime.de/index.php kommt da 30.01.2025 - 21:54:11 raus, immerhin 42 Sekunden unterschied. Muss nichts bedeuten.
Ein Eintrag bei mir wo ich mir etwas vom Handy sende sieht aber so aus:

2025-02-01 12:45:22.442  - debug: telegram.0 (820625) {"message_id":33511,"from":{"id":643047793,"is_bot":false,"first_name":"Bernhard","last_name":"****","username":"Bernhard****","language_code":"de"},"chat":{"id":643047793,"first_name":"Bernhard","last_name":"****","username":"Bernhard****","type":"private"},"date":1738410322,"text":"Totaler Test"}

Zeitstempel des Logs ist 2025-02-01 12:45:22.442, Zeit aus dem JSON ist "date":1738410322 =>01.02.2025 - 12:45:22, also Abweichung < 1 Sekunde

Wenn du nun die Meldung

2025-01-26 19:29:52.122	warn	Message from undefined ignored, because too old: (32000) Status

steht davor eventuell mehr. Eventuell etwas mit falschen Zeitstempel, eventuell sieht man auch etwas anderes.

Und ein

iob diag

kann auch nicht schaden, da könnte man deine Version etc. sehen.

[Homoran]

@bananajoe sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

immerhin 42 Sekunden unterschied.

@AtomicIX

Das wäre jetzt sehr interessant wie groß die differenz ist
so etwas hatte ich vermutet, dass es gar nicht sooo viel sri.
Sieh zu dass du deine ntp Synchronisation hinbekommst und gut ist.

[AtomicIX]

Hier noch mal der Log, mit Neustart und senden von Befehlen:

telegram.0
2025-02-01 13:23:46.092	warn	Message from undefined ignored, because too old: (32000) Alarm Ein

telegram.0
2025-02-01 13:23:46.092	debug	{"message_id":38969,"from":{"id":233794520,"is_bot":false,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","language_code":"de"},"chat":{"id":233794520,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","type":"private"},"date":1738412583,"text":"Alarm Ein"}

telegram.0
2025-02-01 13:23:46.092	debug	Received message: {"message_id":38969,"from":{"id":233794520,"is_bot":false,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","language_code":"de"},"chat":{"id":233794520,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","type":"private"},"date":1738412583,"text":"Alarm Ein"}

telegram.0
2025-02-01 13:23:42.293	warn	Message from undefined ignored, because too old: (32000) Temp

telegram.0
2025-02-01 13:23:42.293	debug	{"message_id":38967,"from":{"id":233794520,"is_bot":false,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","language_code":"de"},"chat":{"id":233794520,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","type":"private"},"date":1738412580,"text":"Temp"}

telegram.0
2025-02-01 13:23:42.293	debug	Received message: {"message_id":38967,"from":{"id":233794520,"is_bot":false,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","language_code":"de"},"chat":{"id":233794520,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","type":"private"},"date":1738412580,"text":"Temp"}

telegram.0
2025-02-01 13:23:37.308	warn	Message from undefined ignored, because too old: (32000) Status

telegram.0
2025-02-01 13:23:37.308	debug	{"message_id":38965,"from":{"id":233794520,"is_bot":false,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","language_code":"de"},"chat":{"id":233794520,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","type":"private"},"date":1738412575,"text":"Status"}

telegram.0
2025-02-01 13:23:37.307	debug	Received message: {"message_id":38965,"from":{"id":233794520,"is_bot":false,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","language_code":"de"},"chat":{"id":233794520,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","type":"private"},"date":1738412575,"text":"Status"}

tuya.0
2025-02-01 13:23:22.813	info	bfec618747cb2be16fqyt8: Error on Reconnect (7): connection timed out

tuya.0
2025-02-01 13:23:22.808	info	bfb57ca31a04d31ee0uqcx: Error on Reconnect (7): connection timed out

tuya.0
2025-02-01 13:23:22.808	info	bf6e3bf664db95b0b563pv: Error on Reconnect (7): connection timed out

tuya.0
2025-02-01 13:23:20.939	info	bfd00e48eac1982331wna0: Error on Reconnect (7): connect EHOSTUNREACH 192.168.221.171:6668

tuya.0
2025-02-01 13:23:19.057	info	bfefff66b01e1b11c4ifow: Error on Reconnect (7): connection timed out

tuya.0
2025-02-01 13:23:19.017	info	bf6ca8fbf11f2b48fegk2u: Error on Reconnect (7): connect EHOSTUNREACH 192.168.221.174:6668

tuya.0
2025-02-01 13:23:15.196	info	bff281bf90a49cd191hbxi: Error on Reconnect (7): connect EHOSTUNREACH 192.168.222.182:6668

telegram.0
2025-02-01 13:23:10.393	debug	Message sent

telegram.0
2025-02-01 13:23:10.392	debug	Request [saveSendRequest]: {"message_id":38964,"from":{"id":702553359,"is_bot":true,"first_name":"GartenBot","username":"AtomicGarten_Bot"},"chat":{"id":233794520,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","type":"private"},"date":1738412548,"text":"_Gartenbot Online"}

telegram.0
2025-02-01 13:23:10.392	debug	Message sent

telegram.0
2025-02-01 13:23:10.391	debug	Request [saveSendRequest]: {"message_id":38963,"from":{"id":702553359,"is_bot":true,"first_name":"GartenBot","username":"AtomicGarten_Bot"},"chat":{"id":369356584,"first_name":"Jasmin","last_name":"xxxx","username":"atoemchenIX","type":"private"},"date":1738412548,"text":"_Gartenbot Online"}

telegram.0
2025-02-01 13:23:10.319	debug	Send message to [atoemchenIX]: "_Gartenbot Online"

telegram.0
2025-02-01 13:23:10.319	debug	Send message to [AtomicIX]: "_Gartenbot Online"

telegram.0
2025-02-01 13:23:10.318	debug	getMe: {"id":702553359,"is_bot":true,"first_name":"GartenBot","username":"AtomicGarten_Bot","can_join_groups":true,"can_read_all_group_messages":false,"supports_inline_queries":false,"can_connect_to_business":false,"has_main_web_app":false}

telegram.0
2025-02-01 13:23:10.048	debug	Start polling with: 2000(number) ms interval

telegram.0
2025-02-01 13:23:09.887	info	starting. Version 4.0.0 in /opt/iobroker/node_modules/iobroker.telegram, node: v20.18.1, js-controller: 7.0.6

telegram.0
2025-02-01 13:23:09.765	debug	Plugin sentry Initialize Plugin (enabled=true)

telegram.0
2025-02-01 13:23:09.750	debug	States connected to redis: 127.0.0.1:9000

telegram.0
2025-02-01 13:23:09.696	debug	States create User PubSub Client

telegram.0
2025-02-01 13:23:09.696	debug	States create System PubSub Client

telegram.0
2025-02-01 13:23:09.689	debug	Redis States: Use Redis connection: 127.0.0.1:9000

telegram.0
2025-02-01 13:23:09.674	debug	Objects connected to redis: 127.0.0.1:9001

telegram.0
2025-02-01 13:23:09.672	debug	Objects client initialize lua scripts

telegram.0
2025-02-01 13:23:09.558	debug	Objects create User PubSub Client

telegram.0
2025-02-01 13:23:09.558	debug	Objects create System PubSub Client

telegram.0
2025-02-01 13:23:09.558	debug	Objects client ready ... initialize now

telegram.0
2025-02-01 13:23:09.543	debug	Redis Objects: Use Redis connection: 127.0.0.1:9001

host.ioBroker
2025-02-01 13:23:09.114	info	instance system.adapter.telegram.0 in version "4.0.0" started with pid 190323

host.ioBroker
2025-02-01 13:23:05.906	info	instance system.adapter.telegram.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)

Hier noch mal der Auzug aus dem iob diag:

========== Start marking the full check here ===========

```bash
Script v.2024-10-19

*** BASE SYSTEM ***
 Static hostname: ioBroker
       Icon name: computer-container
         Chassis: container ☐
  Virtualization: lxc
Operating System: Ubuntu 24.10
          Kernel: Linux 6.8.12-4-pve
    Architecture: x86-64
OS is similar to: debian

model name      : Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz
Docker          : false
Virtualization  : lxc
Kernel          : x86_64
Userland        : 64 bit

Systemuptime and Load:
 13:25:33 up 3 days, 20:44,  2 users,  load average: 0.13, 0.35, 0.28
CPU threads: 4


*** LIFE CYCLE STATUS ***
Operating System codenamed 'oracular' is an aging Ubuntu release! Please upgrade to the latest LTS release 'noble' in due time!

*** TIME AND TIMEZONES ***
               Local time: Sat 2025-02-01 13:25:33 CET
           Universal time: Sat 2025-02-01 12:25:33 UTC
                 RTC time: n/a
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

*** Users and Groups ***
User that called 'iob diag':
iobroker
HOME=/home/iobroker
GROUPS=iobroker tty dialout sudo audio video

User that is running 'js-controller':
iobroker
HOME=/home/iobroker
GROUPS=iobroker tty dialout sudo audio video

A default user should be created! This user will be enabled to temporarily switch to root via 'sudo'!
A root login is not required in most Linux Distributions.
Run 'iobroker fix' or use the system tools to create a user.
*** DISPLAY-SERVER SETUP ***
Display-Server: false
Desktop:
Terminal:       tty

System is booting into 'graphical.target'. Usually a server is running in 'multi-user.target'. Please set BootTarget to 'multi-user.target' or run 'iobroker fix'

*** MEMORY ***
               total        used        free      shared  buff/cache   available
Mem:            6.4G        2.1G        2.1G        163K        2.2G        4.3G
Swap:           1.1G        4.1K        1.1G
Total:          7.5G        2.1G        3.2G

Active iob-Instances:   35

         6144 M total memory
         2038 M used memory
         2009 M active memory
         1935 M inactive memory
         2007 M free memory
            0 M buffer memory
         2097 M swap cache
         1024 M total swap
            0 M used swap
         1023 M free swap

*** top - Table Of Processes  ***
top - 13:25:33 up 3 days, 20:44,  2 users,  load average: 0.13, 0.35, 0.28
Tasks:  69 total,   1 running,  68 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   6144.0 total,   2005.4 free,   2040.7 used,   2098.1 buff/cache
MiB Swap:   1024.0 total,   1024.0 free,      0.0 used.   4103.3 avail Mem

*** FAILED SERVICES ***

  UNIT                    LOAD   ACTIVE SUB    DESCRIPTION
* run-rpc_pipefs.mount    loaded failed failed RPC Pipe File System
* sys-kernel-config.mount loaded failed failed Kernel Configuration File System

Legend: LOAD   -> Reflects whether the unit definition was properly loaded.
        ACTIVE -> The high-level unit activation state, i.e. generalization of SUB.
        SUB    -> The low-level unit activation state, values depend on unit type.

2 loaded units listed.


*** DMESG CRITICAL ERRORS ***

@Homoran ja das werde ich probieren. Aber alles was ich dazu gefunden habe, hat bis jetzt nicht funktioniert.

Mir ist eben aufgefallen, das die Web Version von Telegram nicht mehr geht. Ist das nur bei mir so, oder wurde die abgeschaltet?

[Homoran]

@atomicix sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

die Web Version von Telegram

was soll das sein?
Telegram für Win?

[Homoran]

@atomicix sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

2025-02-01 13:23:42.293 debug {"message_id":38967,"from":{"id":233794520,"is_bot":false,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","language_code":"de"},"chat":{"id":233794520,"first_name":"Christian","last_name":"xxxx","username":"AtomicIX","type":"private"},"date":1738412580,"text":"Temp"}

[AtomicIX]

@homoran sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

1738412580

Ich bekomme das einfach nicht hin.
Egal ob auf dem System im Garten, das jetzt lange Zeit ohne Probleme lief, sowohl auch das relativ neue System 2 Monate alt, das hier zuhause steht, laufen nicht mit dem Bot und Commandos.
Die Zeit Sync soll wohl aus dem Hauptsystem von Proxmox kommen und dann an den LXC weitergereicht werden.

Ich habe echt keine Ahnung was/wie/warum das zusammen hängt.

Werde gleich mal iobroker auf nen Raspaberry installieren und gucken ob es da läuft.

Es gibt sonnst Telegram direkt übern Browser: https://web.telegram.org/ aber das geht scheinbar auch nicht mehr.

[BananaJoe]

@atomicix also wie @Homoran auch feststellen konnte sind da 42 Sekunden Abweichung.
Meistens ist bis 30 Sekunden Abweichung egal bzw. wird noch toleriert (ob das bei Telegram auch so ist weis sich nicht).

Beruflich muss ich mich auch um Zeit-Synchronität in den Netzen kümmern - wobei dabei wichtiger ist das alle die gleiche Zeit haben, auch wenn die vielleicht daneben liegt.

Also wäre ein Ansatz dafür zu sorgen das alle den gleichen Zeitserver nehmen.

Dein Host läuft mit Proxmox. Da gibt es diese Anleitung:
https://pve.proxmox.com/wiki/Time_Synchronization
Den Einträgen nach läuft da noch der "klassische" ntp.service

Bei mir ist in der Datei

/etc/chrony/chrony.conf

der Debian-Pool voreingestellt:

# Include configuration files found in /etc/chrony/conf.d.
confdir /etc/chrony/conf.d

# Use Debian vendor zone.
pool 2.debian.pool.ntp.org iburst

# Use time sources from DHCP.
sourcedir /run/chrony-dhcp

# Use NTP sources found in /etc/chrony/sources.d.
sourcedir /etc/chrony/sources.d

Die anderen Optionen greifen bei mir nicht, /etc/chrony/conf.d ist bis auf eine README leer, die IP des Proxmox ist fest eingestellt so das es das Verzeichnis /run/chrony-dhcp nicht gibt und /etc/chrony/sources.d ist auch leer bis auf die README.

Der benutzt bei mir also nur den Pool 2.debian.pool.ntp.org

Ok, nutzen wir eine gemeinsame Zeitquelle für alle Geräte. Das kann die FRITZ!Box sein oder z.B. meine Lieblinge zeit.fu-berlin.de und time.fu-berlin.de, siehe https://www.zedat.fu-berlin.de/Time-Service (ja, das sind 2 verschiedene Server)
Also ändern wir das in der Datei /etc/chrony/chrony.confwie folgt ab:

# Use Debian vendor zone.
#pool 2.debian.pool.ntp.org iburst
server zeit.fu-berlin.de iburst
server time.fu-berlin.de iburst

und den Dienst neu starten:

systemctl restart chronyd

und nach einiger Zeit prüfen ob das klappt:

root@proxmox01:~# journalctl --since -1h -u chrony
Feb 02 14:26:26 proxmox01 chronyd[1148]: chronyd exiting
Feb 02 14:26:26 proxmox01 systemd[1]: Stopping chrony.service - chrony, an NTP client/server...
Feb 02 14:26:26 proxmox01 systemd[1]: chrony.service: Deactivated successfully.
Feb 02 14:26:26 proxmox01 systemd[1]: Stopped chrony.service - chrony, an NTP client/server.
Feb 02 14:26:26 proxmox01 systemd[1]: Starting chrony.service - chrony, an NTP client/server...
Feb 02 14:26:26 proxmox01 chronyd[922074]: chronyd version 4.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
Feb 02 14:26:26 proxmox01 chronyd[922074]: Frequency -40.622 +/- 0.028 ppm read from /var/lib/chrony/chrony.drift
Feb 02 14:26:26 proxmox01 chronyd[922074]: Using right/UTC timezone to obtain leap second data
Feb 02 14:26:26 proxmox01 chronyd[922074]: Loaded seccomp filter (level 1)
Feb 02 14:26:26 proxmox01 systemd[1]: Started chrony.service - chrony, an NTP client/server.
Feb 02 14:26:31 proxmox01 chronyd[922074]: Selected source 160.45.10.8 (zeit.fu-berlin.de)
Feb 02 14:26:31 proxmox01 chronyd[922074]: System clock TAI offset set to 37 seconds

Interessanterweise hatte ich wohl ein Offset von 37 Sekunden .....

So, nun noch die ioBroker VM (oder Container?).
Ein Container sollte die Zeit des Hosts übernehmen. Hier sollte also nichts zu tun sein. Außer das ggf. die richtige Zeitzone eingestellt werden muss.

timedatectl set-timezone Europe/Berlin

Wenn es eine VM ist, dann müsste man schauen welchen Zeitprovider diese benutzt.
Neuere System sollten den systemd-timesyncd.service nutzen, das prüfst du per

systemctl status systemd-timesyncd.service

Läuft der Dienst kannst du diese Datei bearbeiten:

nano /etc/systemd/timesyncd.conf

und setzt folgende 2 Einträge bzw. änderst die vorhandenen:

[Time]
NTP=zeit.fu-berlin.de
FallbackNTP=time.fu-berlin.de

Wichtig ist auch den Fallback zu setzen, der steht sonst auch auf einer Pool-Adresse
Dann den Dienst neu starten

systemctl restart systemd-timesyncd.service

und nach einer Weile prüfen:

timedatectl show-timesync

Wenn es den Dienst nicht gibt / der nicht läuft, prüfe ob der NTP läuft:

systemctl status ntp.service

ist der es, so bearbeite folgende Datei:

nano /etc/ntp.conf

Die Einträge sind wie auf dem Proxmox-Host,
also alle Zeilen die mit pool oder server anfangen, auskommentieren und nur diese beiden setzen:

server zeit.fu-berlin.de iburst
server time.fu-berlin.de iburst

Dann den Dienst neu starten:

systemctl restart ntp.service

und nach einer Weile mit

ntpq -p

prüfen.

Ggf. prüfst bei einem Container ob da nicht trotzdem etwas läuft.
Wie beschrieben hatte ich 37 Sekunden Abweichung meines Proxmox-Host ...

[BananaJoe]

Nachtrag: Also bei mir zu Hause ist alles was den Ubuntu-Pool, die FRITZ!Box oder die TU-Berlin Server nutzt im Millisekunden-Bereich auseinander.
Alle 3 Proxmox-Server aus dem Cluster (auch der eine der als VM unter VMware auf einem ESXi läuft), wichen um 37 Sekunden davon ab.
Die Proxmox-Backup-Appliance die auf dem ESXi läuft hatte die richtige Zeit.

Wobei ich bei meiner Recherche irgendwo meine gelesen zu haben das die Proxmox-System in einem Cluster peinlich genau ihre untereinander abstimmen weil es sonst Probleme gibt

[AtomicIX]

Das ist ja Wahnsinn was du da zusammen getragen hast. Vielen dank dafür.
Ich habe gestern Abend einen Raspi3 mit iobroker aufgesetzt und dort ein aktueller Backup eingespielt.
(Wusste gar nicht mehr, wie langsam son Rapsi ist )
Hat natürlich alles funktioniert, mit Telegram ect.
Also nachdem ich noch noch einiges an Zeit in einem Proxmox System gesteckt habe und damit auch gescheitert bin, habe ich auf meinem Test/Ersatzsystem ein sauberes Proxmox aufgesetzt und alles neu eingerichtet. Jetzt läuft alles.
Wenn ich jetzt die nächsten Tage in Garten komme, werde ich die Systeme tauschen und das fehlerhafte Gartensystem hier zuhause mal mit deinen Informationen füttern bzw. probieren woran es gelegen hat. Vielleicht komme ich ja mit deiner Anleitung weiter.
Da ich eh die NVE tauschen wollte, kann ich das jetzt umsetzten. Nach 3 Jahren 24/7 kann man das mal machen.
Also vielen dank @BananaJoe , ich werde die nächsten Tage berichten, was ich geworden bin.

[Thomas Braun]

@atomicix sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

(Wusste gar nicht mehr, wie langsam son Rapsi ist )

Der 3er ist mittlerweile mit seinem 1GB RAM zu klein. Die aktuellen Versionen 4&5 mit mehr RAM sind deutlich performanter.

[AtomicIX]

@bananajoe
nun habe ich es mal geschafft, die Systeme zu tauschen.
Habe mein Ersatzsystem mit neuer NVE und alles frisch aufgesetzt in Garten gepflanzt. Es ist sehr gut angewachsen .
Läuft alles super.
Nun habe ich also mein altes Gartensystem mit den Uhrzeit Fehler zuhause.
Habe es einmal alles frisch upgedatet, also das Proxmox/Linux System.
Nun läuft es wieder einwandfrei mit der Uhrzeit
Vielleicht hat sich beim letzten Update im Garten ( I-Net über Sim) vielleicht irgendetwas verschluckt, wobei mein relativ frisches Ersatzsystem (was ich ja jetzt noch mal neu gemacht habe und jetzt im Garten läuft) hier zuhause ja auch Probleme hatte.
Also es läuft, leider konnte ich jetzt keinen Fehler feststellen und muss es hinnehmen, das es wieder geht.

Ich bedanke mich jedenfalls für die Unterstützung.

[AtomicIX]

@thomas-braun
meine 2x Rpi4 mit 4Gb Ram hatte ich zur Kriese ( vor 2 Jahren oder so) für einen sehr guten Preis verkauft.
Habe ja eigentlich mit den 2 NUC's eine sehr gute alternative. Für kleine Bastelprojekte reichen mir die 3er noch.
War hat nur erschrocken, wie langsam das ist, im Gegensatz zum NUC Gen10 mit i7 und i3 und 32GB Ram

[BananaJoe]

@atomicix ich habe vor ein paar Monaten mal einen Pi 1 und Pi 2 mal wieder in Betrieb genommen ... die hatte ich früher als Eigenbau AccessPoint genutzt, und jetzt um ein Relais zu schalten. Habe es dann gelassen.

Nö, da ist man inzwischen verwöhnt ...

[Homoran]

@atomicix was sagt denn das System zum ntp?

[AtomicIX]

@homoran
Also im Proxmox Root System habe ich:

root@Proxmox:~# timedatectl status
               Local time: Wed 2025-02-05 15:05:15 CET
           Universal time: Wed 2025-02-05 14:05:15 UTC
                 RTC time: Wed 2025-02-05 14:05:15
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

und im LXC Container:

iobroker@ioBroker:~$ timedatectl status
               Local time: Mi 2025-02-05 15:07:04 CET
           Universal time: Mi 2025-02-05 14:07:04 UTC
                 RTC time: n/a
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: yes

So scheint es jedenfalls zu funktionieren.

[Homoran]

@atomicix sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

So scheint es jedenfalls zu funktionieren.

Noch!??

@atomicix sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

NTP service: inactive

bis die Zeiten wiedrr auseinander driften

[Thomas Braun]

@atomicix sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

  RTC in local TZ: no

und

  RTC in local TZ: yes

Da es aber nur eine RTC/RealTimeClock gibt sollten da auch die Einstellungen imho gleich sein.

[AtomicIX]

@homoran
Mein Fehler, das war das alte Garten System, das jetzt hier zuhause steht, das Livesystem im Garten hat:

               Local time: Mi 2025-02-05 15:12:25 CET
           Universal time: Mi 2025-02-05 14:12:25 UTC
                 RTC time: n/a
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: yes

[AtomicIX]

Ich brauche noch mal Hilfe.
Das Problem ist wieder da.
Ich habe gestern das Proxmox System neu gestartet und Telegram läuft wieder nicht.

In Proxmox habe ich:

                 RTC time: Wed 2025-02-19 14:53:03 UTC
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

und im LXC

                 RTC time: n/a
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Das scheint aber auch nur im Garten zu sein. Zuhause läuft das alles.
Zuhause hängt der NUC über ein USB -> LAN Adapter direkt an meiner FB 6690
im Garten hängt der NUC direkt am LAN an einer FB 4060 und als Modem habe ich ein Zyxel FWA 505 5G Router.
Die 5060 ist aber der DNS im Netzwerk.
Vor meinem ganzen Umbau, als es sehr lange ohne Probleme lief, hatte ich eine FB 6850LTE.
Ich habe die Vermutung, das durch die Kombi FB und Zyxel vielleicht irgendetwas blockiert wird?
Kann ich das irgendwie prüfen?
Das aktuelle Proxmox System ist quasi auf Standard was die NTP/RTC Einstellung betrifft, was zuhause auch läuft.
Somit schien die Config ok zu sein.
Ich hatte ja am Anfang, als ich die Probleme hatte, schon einmal die alte 6850 wieder eingebaut und es lief auch nicht, aber vielleicht habe ich auch nicht lange genug gewartet?
Dazu kommt momentan ist es halt sehr kalt und ich habe jetzt nicht die Lust, Stunden im Garten zu sitzen und rum zu stochern um eine Lösung zu finden.
Über Remote komme ich nur auf den LXC vom iobroker und auf die FB, aber nicht auf das Proxmox System. Das war schon immer so und muss an der Mobilfunkverbindung liegen. Von daher würde ich mich über Ergebnisse freuen, die ich Vorort im Schrebergarten probieren kann.
Noch mal die alte 6850 verbauen und warten? Wie lange?

Über Unterstützung wäre ich sehr dankbar.

[BananaJoe]

Naja, NTP scheint an, synchronisiert aber nichts.
Da oben hatte ich eine längere Anleitung gepostet was man machen kann: https://forum.iobroker.net/post/1245092
Die vor eingestellten Debian-Zeitserver waren bei mir da auch Mist. Ist bei mir nur nicht aufgefallen weil ich nur Ubuntu und Windows-VMs habe, und die holen sich die Zeit separat von woanders - und nur beim Start die vom Virtualisierungshost