js-controller 3.0/3.1 jetzt im Latest!

[apollon77]

@oFbEQnpoLKKl6mbY5e13 Issue im GitHub beim Adapter ist angelegt?

[oFbEQnpoLKKl6mbY5e13]

@apollon77
Es gab ja eines, was wohl vorschnell geschlossen wurde. Aber abgesehen davon bringt das wohl eh nichts, denn Jogibear macht ja am Adapter nichts mehr, was kein Vorwurf ist.

[LJSven]

@foxriver76 sagte in js-controller 3.0 jetzt im Latest!:

Na du meinst doch oben dass dein Router neu gestartet wird. Währenddessen verlieren die Hosts logischerweise die Verbindung zueinander wenn sie über diesen verbunden sind.

Der Host ist ja online, wenn ich auf Hosts gehe - trotzdem erscheint diese Meldung. Ebenso sind alle Adapter GRÜN, die auf den Host installiert sind. Die Meldung kommt über einige Stunden, da ist der Router längst neu gestartet.

[apollon77]

@oFbEQnpoLKKl6mbY5e13 Leg es bitte an bzw reopen wenn falsch geschlossen. Kriegen wir alles irgendwie hin

[crunchip]

ich habe gerade meinen proxmox Server neu gestartet und wollte das iobroker log im Anschluss betrachten, welche (Warn/Fehler-Meldungen) bei einem Neu-Start auftauchen, jedoch finde ich nun dieses vor

bin im latest
admin 4.1.1
js-controller 3.0.20

der Inhalt von diesem log besteht aus

2020-05-01 00:00:52.952 - info: host.IoBroker iobroker.js-controller version 3.0.20 js-controller starting
2020-05-01 00:00:52.962 - info: host.IoBroker Copyright (c) 2014-2020 bluefox, 2014 hobbyquaker
2020-05-01 00:00:52.964 - info: host.IoBroker hostname: IoBroker, node: v10.20.1
2020-05-01 00:00:52.967 - info: host.IoBroker ip addresses: xx.xx.xx.xx fe:xx:xx:xx:xx:xx
2020-05-01 00:00:57.407 - info: host.IoBroker connected to Objects and States
2020-05-01 00:00:58.974 - info: host.IoBroker 110 instances found
2020-05-01 00:00:59.138 - info: host.IoBroker starting 71 instances
2020-05-01 00:00:59.315 - info: host.IoBroker instance system.adapter.admin.0 started with pid 905
2020-05-01 00:01:04.320 - info: host.IoBroker instance system.adapter.alexa2.0 started with pid 916
2020-05-01 00:01:07.278 - info: host.IoBroker instance system.adapter.backitup.0 started with pid 923
2020-05-01 00:01:07.525 - info: admin.0 (905) starting. Version 4.1.1 in /opt/iobroker/node_modules/iobroker.admin, node: v10.20.1, js-controller: 3.0.20
2020-05-01 00:01:07.762 - info: admin.0 (905) requesting all states
2020-05-01 00:01:07.766 - info: admin.0 (905) requesting all objects
2020-05-01 00:01:14.281 - info: host.IoBroker instance system.adapter.ble.0 started with pid 943
2020-05-01 00:01:15.172 - info: host.IoBroker instance system.adapter.broadlink2.0 started with pid 950
2020-05-01 00:01:18.289 - info: alexa2.0 (916) starting. Version 3.1.2 in /opt/iobroker/node_modules/iobroker.alexa2, node: v10.20.1, js-controller: 3.0.20

edit: gerade noch entdeckt

[apollon77]

Bist Deiner Zeit voraus, hä Zeitzohne prüfen?

[crunchip]

@apollon77 was soll sich da geändert haben? war doch nur ein Neustart!?

root@IoBroker:~# date
Do 30. Apr 23:09:06 CEST 2020
root@IoBroker:~# cat /etc/timezone
Europe/Berlin

[apollon77]

@crunchip Interessant ... Ich hatte einen Bericht von einem befreundeten user das irgendwie die Zeiteinstellung des iobroker user ne andere war oder so ... bei dem ist das gestern passiert. Keine Idee warum

[crunchip]

@apollon77 auch wenn ich mich mit meinem user einlogge, stimmt die Zeit, oder meintest du etwas anderes?
Habe den Rechner auch nochmal neu gestartet, jedoch das gleiche wieder.
Das richtige log ist ja vorhanden, siehe screen von oben, da steht auch alles korrekt drin, nur das zusätzlich diese 2020 -05-01.gz aufgelistet ist
naja mal abwarten, was nach 0:00 Uhr passiert

[Thomas Braun]

@crunchip

date -u

[crunchip]

@Thomas-Braun kommt aufs gleiche raus wie oben

root@IoBroker:~# date -u
Do 30. Apr 21:49:35 UTC 2020

jedenfalls stimmt seit dem erneuten Neustart die Betriebszeit wieder

[Thomas Braun]

@crunchip
Was fährst du da für ein System?

timedatectl status

macht dich evtl. auch schlauer.

[wendy2702]

@crunchip wie das gleiche wie oben?

Hier steht „UTC“ oder habe ich was verpasst

[crunchip]

@wendy2702 ja UTC, oben CEST(2Std weiter) ist schon korrekt so

[wendy2702]

War nur verwundert weil die Differenz keine 2 Stunden ist. Liegt aber wohl an der Differenz der Abfragen.

[crunchip]

@Thomas-Braun ne Debian Vm in Proxmox

root@IoBroker:~# timedatectl status
      Local time: Fr 2020-05-01 00:05:43 CEST
  Universal time: Do 2020-04-30 22:05:43 UTC
        RTC time: Fr 2020-05-01 00:05:43
       Time zone: Europe/Berlin (CEST, +0200)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

zumindest geht das log richtig weiter,

[Thomas Braun]

@crunchip
Ich glaube da liegt der Hund begraben:

RTC in local TZ: no

Und in der Oberfläche von Proxmox steht sinngemäß:

RTC in local TZ: yes

Ich vermute das beißt sich irgendwie.

[crunchip]

@Thomas-Braun ja, das habe ich schon gesehen, deswegen den screen mit angefügt, aber wie gesagt, es war nur ein Neustart

[Thomas Braun]

@crunchip Ich denke die beiden Einstellungen sollten gleich sein.
Hab nur keinen Idee ob man besser im System anfängt oder in den Proxmox-Einstellungen.

[crunchip]

@Thomas-Braun ich werd es in Proxmox mal ausschalten, in meiner anderen VM ist es auch aus, glaub die Standardeinstellung ist ...lokale Zeit für RTC -->Nein.
unabhängig aber davon, die Einstellung besteht schon ewig, und bis jetzt hatte ich solch einen Fehler (LOG) noch nie