OH3x und die Zeit...?

[Steinspiel]

Jepp, das sollte ausreichen.

Dann bedanke ich mich schon mal, wie so oft, fürs kompetente "in`s Ziel führen" !

schönen Abend und bis dann...

[renek74]

Hallo,
ich habe seit dem Update auf 5.0.1 ein ähnliches Problem. Es scheint, dass die Rules, welche durch einen Chron angetriggert werden exakt eine Stunde später laufen. Meine Außenbeleuchtung soll um 4 Uhr eingeschaltet werden. Geht aber erst 5 Uhr an.

timedatectl bringt bei mir aber keine Auffälligkeiten.

Code: Alles auswählen

openhabian@openhabian:~ $ timedatectl
               Local time: Thu 2025-08-28 06:19:16 CEST
           Universal time: Thu 2025-08-28 04:19:16 UTC
                 RTC time: n/a
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Jemand eine Idee? Vor dem Update lief alles ohne Probleme. Danke

[nw378]

Die Zeitzone muss an 3 Stellen richtig eingestellt sein:

* Linux
* openHAB
* Java

Leider wird bei OH 5.0 die Java-Zeit in der Datei /etc/default/openhab für uns "falsch" konfiguriert. Dort steht dann Europe/London.

Prüf bitte mal, ob in der Zeile EXTRA_JAVA_OPTS= der Parameter -Duser.timezone=Europe/Berlin steht. Ansonsten anpassen und neustarten.

[udo1toni]

Tipp am Rande: Da die Datei /etc/default/openhab bei einem Update regelhaft überschrieben wird, kann man die EXTRA_JAVA_OPTS auch über die Datei /etc/openhab/linux.parameters setzen. Die Schreibweise ist dabei identisch zu /etc/default/openhab.

Wie openHAB sich verhält, wenn in beiden Dateien EXTRA_JAVA_OPTS gesetzt wird, habe ich noch nicht ausprobiert, aber vermutlich wird dann eine der beiden Quellen ignoriert

[renek74]

Danke ich teste es mal

[nw378]

Tipp am Rande: Da die Datei /etc/default/openhab bei einem Update regelhaft überschrieben wird, kann man die EXTRA_JAVA_OPTS auch über die Datei /etc/openhab/linux.parameters setzen. Die Schreibweise ist dabei identisch zu /etc/default/openhab.

Wie openHAB sich verhält, wenn in beiden Dateien EXTRA_JAVA_OPTS gesetzt wird, habe ich noch nicht ausprobiert, aber vermutlich wird dann eine der beiden Quellen ignoriert

Guter Hinweis!
Tatsächlich wurde das im englischen Forum auch schon diskutiert: https://community.openhab.org/t/etc-ope ... s/163246/3

Wenn ich es richtig verstehe, überschreibt die Angabe in linux.parameters vorhergehendes.

Ich habe jetzt mittels

Code: Alles auswählen

sudo systemctl edit openhab

und dort

Code: Alles auswählen

[Service]
EnvironmentFile=-/etc/openhab/linux.parameters

geändert.

Dann die Datei /etc/openhab/linux.parameters angelegt.

Mal gucken...

EDIT:

Zum Validieren habe ich die Zeitzone in /etc/default/openhab wieder auf London geändert.
Nach dem oben beschriebenen Prozedere und einem Neustart triggern die Time Cron Regeln trotzdem nach Berliner Zeit

[udo1toni]

Bei mir ist der Hinweis auf die Datei bereits in openhab.service enthalten:

Code: Alles auswählen

[Unit]
Description=openHAB - empowering the smart home
Documentation=https://www.openhab.org/docs/
Documentation=https://community.openhab.org
Wants=network-online.target
After=network-online.target

[Service]
Environment=OPENHAB_HOME=/usr/share/openhab
Environment=OPENHAB_CONF=/etc/openhab
Environment=OPENHAB_RUNTIME=/usr/share/openhab/runtime
Environment=OPENHAB_USERDATA=/var/lib/openhab
Environment=OPENHAB_LOGDIR=/var/log/openhab
Environment=OPENHAB_STARTMODE=daemon
EnvironmentFile=-/etc/default/openhab
EnvironmentFile=-/etc/openhab/linux.parameters

User=openhab
Group=openhab

WorkingDirectory=/usr/share/openhab
ExecStart=/usr/share/openhab/runtime/bin/karaf ${OPENHAB_STARTMODE}
ExecStop=/usr/share/openhab/runtime/bin/karaf stop

SuccessExitStatus=0 143
RestartSec=5
Restart=on-failure
TimeoutStopSec=120

LimitNOFILE=102642

[Install]
WantedBy=multi-user.target

Also zuerst wird der default eingelesen, anschließend werden die Werte aus linux.parameters drüber gebügelt, irgendwie logisch

Ich habe openHAB direkt per apt installiert, das sollte also auf allen apt-basierten Systemen (mit systemd) genauso aussehen, auch bei openHABian, welches openHAB ebenfalls per apt Paketmanager installiert.

[renek74]

Vielleicht wird das in einem neuen Update bereinigt und wieder so arrangiert wie in der 4er Version

[nw378]

Ich habe die aktuelle openHABian Version.

Allerdings habe ich nicht die Datei /etc/systemd/system/openhab.service.

Wenn ich sudo systemctl edit openhab eingebe, wird diese Datei geändert: /etc/systemd/system/openhab.service.d/override.conf

Edit: openhab.service habe ich in folgenden beiden Verzeichnissen:

/lib/systemd/system/openhab.service
/etc/systemd/system/multi-user.target.wants/openhab.service

Verstehe ich das richtig, dass eine von diesen Dateien beim Booten herangezogen wird, und von override.conf überschrieben wird?

[udo1toni]

Allerdings habe ich nicht die Datei /etc/systemd/system/openhab.service.

Die Datei openhab.service ist auch nicht in /etc/systemd/system/ gespeichert, sondern ganz ordentlich unter /lib/systemd/system/, so wie es sich gehört

Der genaue Mechanismus dahinter:

• apt installiert die service-Datei openhab.service in /lib/systemd/system/.
• Nach einem systemctl daemon--reload wird diese Datei als Bestandteil der möglichen Services gelistet.
• systemctl enable openhab.service erzeugt gemäß der Angabe unter [Install] einen Symlink auf die Originaldatei, hier multi-user.wants, entsprechend /etc/systemd/system/multi-user.target.wants/openhab.service -> /lib/systemd/system/openhab.service.
  Multi-User entspricht dem init Level 4 - das System ist vollständig gestartet und es können sich User anmelden (auch mehrere User gleichzeitig, gleich ob der selbe User mehrfach oder unterschiedliche User parallel, eben "Multi-User")
• systemctl edit openhab.service erzeugt eine Kopie der Datei, die in einem passenden Unterordner abgelegt wird. In dieser Datei können Overrides eingetragen werden. Man kann beliebig viele solche Overrides pro Service hinterlegen, die Dateien werden dann anhand ihres alphabetischen Namens zur aktiven Konfiguration gemerged. Damit man weiß, welche Parameter man dem Dienst mitgeben kann, wird die vorhandene Service-Datei kopiert und zeilenweise komplett auskommentiert, so dass man nur noch das Kommentarzeichen entfernen und die Änderung eintragen muss.

Der edit-Mechanismus führt meines Wissens ein ziemliches Schattendasein mir sind jedenfalls noch keine Anleitungen untergekommen, wo jemand davon Gebrauch gemacht hätte. Ich kann mir aber vorstellen, dass man sehr komplexe Setups damit gescriptet bequemer aufsetzen kann, weil die Parameter über mehrere Dateien verstreut sein können. Im privaten Umfeld würde ich stets die Original-Servicedatei bearbeiten, schon um nicht die Übersicht zu verlieren...