Timezone issues on 4.3

Setup, Configuration and Use Beginners
1

Hi all,

I’ve just upgraded to openHAB 4.3.3 Release Build on OpenHabian on a Raspberry Pi 4.

I seem to be having a couple of common issues but unfortunately the common fixes aren’t working.

Firstly my times are out of whack by 12 hours. I’m in NZ which is GMT+13 at the moment. I’ve checked the time and timezone using the openhabian-config tool and it shows the correct time and Pacific Ocean / Auckland as the timezone.

I used

sudo nano /etc/default/openhab

and changed

EXTRA_JAVA_OPTS from -Duser.timezone=Europe/Berlin to
-Duser.timezone=Pacific/Auckland

I then stopped the openhab service and rebooted the system. After the reboot the Date command shows the correct time, timedatectl shows the correct local time, UTC time and time zone, everything looks fine, except the time in the openhab.log and event.log are still 12 hours out.

Is there yet another file I have to update to get the correct times for my logs and my Astro and Cron rules?

My second major issue is that the AmazonEchoControl Binding is throwing pages and pages of error messages into the Openhab.log. I read somewhere in the forums that this was a known issue with the first relase of 4.3 but had now been fixed. I’ve used the “Update everything” option on Openhabian-config, but it’s still doing the same thing.

Any assistance on these issues would be hugely appreciated.

Here’s the Start of my Openhab.log file created at 9:10 pm NZDT tonight:

2025-03-17 09:10:11.752 [INFO ] [org.openhab.core.Activator ] - Starting openHAB 4.3.3 (Release Build)
2025-03-17 09:10:12.384 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to ‘Pacific/Auckland’.
2025-03-17 09:10:12.395 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Location set to ‘-41.xxxxxxxxxxxxx,174.xxxxxxxxxxxxx’.
2025-03-17 09:10:12.397 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to ‘en_NZ’.
2025-03-17 09:10:12.399 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Measurement system set to ‘SI’.
2025-03-17 09:10:19.547 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘MyItemsRP.items’
2025-03-17 09:10:20.865 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘RuleTest.sitemap’
2025-03-17 09:10:33.417 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2025-03-17 09:10:33.706 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘Operational-RP.rules’
2025-03-17 09:10:43.697 [ERROR] [Events.Framework ] - FrameworkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.smarthomej.binding.amazonechocontrol [247]
Unresolved requirement: Import-Package: org.openhab.core.common; version=“[3.1.0,4.0.0)”

at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1847) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1840) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1783) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1745) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1667) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) [org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345) [org.eclipse.osgi-3.18.0.jar:?]
2025-03-17 09:10:57.929 [INFO ] [ab.ui.habpanel.internal.HABPanelTile] - Started HABPanel at /habpanel
2025-03-17 09:10:58.091 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
2025-03-17 09:11:00.234 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = 08…9b, base URL = http://localhost:8080)
2025-03-17 09:11:01.860 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘hue:room:001788fffeb1da38:b110c6c5-1a9e-4e94-9c9e-6606e81b14c9’ to inbox.
2025-03-17 09:11:06.697 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.smarthomej.binding.amazonechocontrol-3.2.7.jar
org.osgi.framework.BundleException: Could not resolve module: org.smarthomej.binding.amazonechocontrol [247]
Unresolved requirement: Import-Package: org.openhab.core.common; version=“[3.1.0,4.0.0)”

at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.7.4]
2025-03-17 09:11:17.492 [WARN ] [mazonechocontrol.internal.Connection] - Parsing json failed:

2

That change should have done the trick. Run ps -aux | grep openhab from the command line and make sure that the timezone argument is in actually being used. That will show the full command used to run openHAB.

The amazon control issue is complaining about a dependency. Did you install this add-on by dropping the jar file in the addons folder?

3

Hi Rich thanks for the suggestions.
I think you might be right about the AmazonEchoControl .jar file. I’ll check when I’m home tonight but I do recall having some problems quite some time back and someone suggesting to try a jar file with a bug fix that wasn’t in the main release. I might still be using that. I assume the process would be to delete the binding via the web UI, remove the jar file from the addons directory and then reinstall the binding from the standard repository?

With respect to the timezone issue, I ran the command you suggested and got the response below and I see there’s still a reference to Europe/Berlin. Is that coming from the Djava library directory /var/lib/openhab/tmp/lib? I’m wondering about the tmp directory - does that mean java hasn’t installed properly? Out of my depth here I think :frowning:

Cheers,
Pete.

openhabian@openhabian:/boot $ ps -aux | grep openhab
avahi 346 0.0 0.0 6908 2680 ? Ss Mar17 0:28 avahi-daemon: running [openhabian.local]
openhab+ 1025 0.0 0.4 93584 17688 ? S Mar17 0:05 /usr/sbin/smbd --foreground --no-process-group
root 2138 0.0 0.1 14512 6976 ? Ss Mar17 0:00 sshd: openhabian [priv]
openhab+ 2146 0.0 0.1 14408 7148 ? Ss Mar17 0:00 /lib/systemd/systemd --user
openhab+ 2148 0.0 0.0 37200 3752 ? S Mar17 0:00 (sd-pam)
openhab+ 2167 0.0 0.1 14512 4392 ? S Mar17 0:00 sshd: openhabian@pts/0
openhab+ 2168 0.0 0.1 9268 4304 pts/0 Ss Mar17 0:00 -bash
openhab 3303 1.6 8.4 1059044 331880 ? Ssl Mar17 10:47 /usr/bin/java -XX:-UsePerfData -Dopenhab.home=/usr/share/openhab -Dopenhab.con f=/etc/openhab -Dopenhab.runtime=/usr/share/openhab/runtime -Dopenhab.userdata=/var/lib/openhab -Dopenhab.logdir=/var/log/openhab -Dfelix.cm.di r=/var/lib/openhab/config -Djava.library.path=/var/lib/openhab/tmp/lib -Djdk.util.zip.disableZip64ExtraFieldValidation=true -Djetty.host=0.0.0. 0 -Djetty.http.compliance=RFC2616 -Dorg.apache.cxf.osgi.http.transport.disable=true -Dorg.ops4j.pax.web.listening.addresses=0.0.0.0 -Dorg.osgi. service.http.port=8080 -Dorg.osgi.service.http.port.secure=8443 -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Xms192m -Xmx768m -XX:-TieredCom pilation -XX:TieredStopAtLevel=1 -XX:+ExitOnOutOfMemoryError -Dxtext.qn.interning=true -Duser.timezone=Europe/Berlin --add-reads=java.xml=java. logging --add-exports=java.base/org.apache.karaf.specs.locator=java.xml,ALL-UNNAMED --patch-module java.base=/usr/share/openhab/runtime/lib/end orsed/org.apache.karaf.specs.locator-4.4.6.jar --patch-module java.xml=/usr/share/openhab/runtime/lib/endorsed/org.apache.karaf.specs.java.xml- 4.4.6.jar --add-opens java.base/java.security=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAME D --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.naming/javax.naming.spi=ALL-UNNAMED --add-opens java.rmi/sun.rmi.transport.tcp=A LL-UNNAMED --add-opens java.base/java.io=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMED --add-opens java.base/java.text=ALL-UN NAMED --add-opens java.base/java.time=ALL-UNNAMED --add-opens java.desktop/java.awt.font=ALL-UNNAMED --add-exports=java.base/sun.net.www.protoc ol.file=ALL-UNNAMED --add-exports=java.base/sun.net.www.protocol.ftp=ALL-UNNAMED --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED --add-exports=java.base/sun.net.www.protocol.https=ALL-UNNAMED --add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED --add-exports=java. base/sun.net.www.content.text=ALL-UNNAMED --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED --add-exports=jdk.naming.rmi/com.sun.jndi.url. rmi=ALL-UNNAMED --add-exports=java.rmi/sun.rmi.registry=ALL-UNNAMED --add-exports=java.security.sasl/com.sun.security.sasl=ALL-UNNAMED --add-ex ports=java.naming/com.sun.jndi.ldap=ALL-UNNAMED -Dkaraf.instances=/var/lib/openhab/tmp/instances -Dkaraf.home=/usr/share/openhab/runtime -Dkara f.base=/var/lib/openhab -Dkaraf.data=/var/lib/openhab -Dkaraf.etc=/var/lib/openhab/etc -Dkaraf.log=/var/log/openhab -Dkaraf.restart.jvm.support ed=true -Djava.io.tmpdir=/var/lib/openhab/tmp -Djava.util.logging.config.file=/var/lib/openhab/etc/java.util.logging.properties -Dkaraf.startLo calConsole=false -Dkaraf.startRemoteShell=true -classpath /usr/share/openhab/runtime/lib/boot/org.apache.karaf.diagnostic.boot-4.4.6.jar:/usr/s hare/openhab/runtime/lib/boot/org.apache.karaf.jaas.boot-4.4.6.jar:/usr/share/openhab/runtime/lib/boot/org.apache.karaf.main-4.4.6.jar:/usr/sha re/openhab/runtime/lib/boot/org.apache.karaf.specs.activator-4.4.6.jar:/usr/share/openhab/runtime/lib/boot/osgi.core-8.0.0.jar:/usr/share/openh ab/runtime/lib/jdk9plus/istack-commons-runtime-3.0.12.jar:/usr/share/openhab/runtime/lib/jdk9plus/jakarta.xml.bind-api-2.3.3.jar:/usr/share/ope nhab/runtime/lib/jdk9plus/javax.annotation-api-1.3.2.jar:/usr/share/openhab/runtime/lib/jdk9plus/jaxb-runtime-2.3.8.jar:/usr/share/openhab/runt ime/lib/jdk9plus/org.apache.servicemix.specs.activation-api-1.2.1-1.2.1_3.jar:/usr/share/openhab/runtime/lib/jdk9plus/txw2-2.3.8.jar org.apache .karaf.main.Main
openhab+ 7000 0.0 0.0 11200 2700 pts/0 R+ 08:05 0:00 ps -aux
openhab+ 7001 0.0 0.0 7792 544 pts/0 S+ 08:05 0:00 grep --color=auto openhab

4

Answer elsewhere is to add the EXTRA_JAVA_OPTS to /etc/openhab/linux.parameters in order the timezone not to get overridden on every update: openHAB 4.3 Release Discussion - #324 by Oliver2

I cannot confirm it works, though as I just added that file.

5

Did you set the permission and restarted openhab?
The file should look like this:

EXTRA_JAVA_OPTS="-Duser.timezone=Europe/Berlin -Xms1500m -Xmx3000m -XX:+ExitOnOutOfMemoryError"

if you need to add several options

6

Removing the jar file should be sufficient.

Maybe stop OH first and then remove the jar file.

/etc/default/openhab is the file mentioned on other threads so I can’t really say why it’s not working.

There’s an option in openhabian-config to select the timezone. Have you tried setting it that way? That should change it in all the places necessary.

7

Please also check /etc/openhab/ for a file named linux.parameters

See

for reference.

8

I think I’ve finally resolved my timezone issue!

I created /etc/openhab/linux.parameters and added the correct timezone as suggested. I restarted but still got the same result. Then I discovered that the /etc/default/openhab file that I had previously edited had changed back to Europe/Berlin again. Presumably it had been overwritten again after one of my restarts. I fixed that, and then did a grep for all instances of Berlin and found another one in /opt/openhabian/build-image/openhabian.conf. I’m not sure if this file is used after the system is installed but I edited it anyway, restarted and all the logfile entries are now correct and astro rules are running at the right time.

Thanks to everyone for their assistance and patience,
Pete.

9

It does not change on restarts. You probably installed some version of the openhab package.

it’s not.

10

Let’s get back to this after the next update to see if the linux.parameters file worked.

11

Sorry, I was wrong.
See here: /etc/openhab/linux.parameters
Meanwhile you can go for this alternative:

Editing /etc/systemd/system/openhab.service.d/override.conf

1 Like
12

If you need to override the systemd service it would be better to use:

sudo systemctl edit openhab

which creates and edits the file instead of needing to do it manually, using edit automatically calls daemon-reload and can be undone in a quick single command:

sudo systemctl revert openhab
1 Like
13

Deleted, wrong assumption …

14

This worked for me:

  1. Edited /etc/default/openhab and removed -Duser.timezone=Europe/Berlin from the EXTRA_JAVA_OPTS parameter
  2. Created /etc/openhab/linux.parameters and added just EXTRA_JAVA_OPTS=“-Duser.timezone=America/New_York” in it
  3. sudo systemctl edit openhab , then I added EnvironmentFile=-/etc/openhab/linux.parameters to the [Service] section
  4. sudo systemctl stop openhab
  5. sudo systemctl start openhab

(without the last two steps the system didn’t get the correct timezone, meaning the systemctl edit didn’t restart OpenHAB)

Thank you for the pointers. Please inform in the future if any of this needs to be removed with future improvements.

Forgot to mention, just upgraded from 3.4.5 to 4.3.3, and noticed this issue.

15

Your changes are future proof and you do not need to do anything. The change you made is exactly the change which will be available in the next version.

16

Many thanks @Oliver2 :slight_smile: … But just for the avoidance of doubt: @flpaoli mentioned a two part fix with edits to two files /etc/default/openhab and /etc/openhab/linux.parameters with an entry in the former file linking to an entry in the latter file. By contrast my current fix was to make a direct entry in the former file. => Is there anything to argue for @flpaoli 's fix rather than mine?

17

Well… if you overwrite EXTRA_JAVA_OPTS like @flpaoli did, you also lose all other options that used to be in there.
At least if you’re on openHABian and Raspi, there’s quite some and that’s not clever at all.
Plus, you will not be obtaining future changes either. So “future proof”, no this is not.

So at the very least, you should keep the contents like in
EXTRA_JAVA_OPTS=“${EXTRA_JAVA_OPTS} -Dtimezone-blah”

2 Likes
18

I am sure that you guys are aware of this, but if you want OH to be seen as a Global system rather than a German system, then you need to find a solution where the region is properly set during installation, and where it persists across updates.

EDIT: especially since messing around with all those files tanked my system! Aargh!!

1 Like
19

Yes, there are posts out here where users have reported that changes to /etc/default/openhab have been overwritten or reset after a while, probably after an upgrade.

20

Makes total sense. Hadn’t realized this would be used as basic shell script. Fixed.

Thank you!