Openhab using UTC instead of local time after move to openhabian 1.9 and upgrade to openhab 4.2.1

Setup, Configuration and Use Migration
1

Last week I upgraded openHAB to 4.2.1. I then started with a clean openHABian 1.9 (64 bit from the Raspberry Pi Etcher) to move to the new version. Since I did this, openHAB is using UTC time instead of local time. My dear wife asked me why the outside lights turned on at 2 AM local time and didn’t turn on in the evening, which caused me to look into it.

The entries in the events and openhab logs are time stamped with UTC times. The Astro binding is using these times, which has messed up my triggers.

I’m running on a Pi 4B. Here is the Technical Information from openHAB

runtimeInfo:
  version: 4.2.1
  buildString: Release Build
locale: en-US
systemInfo:
  configFolder: /etc/openhab
  userdataFolder: /var/lib/openhab
  logFolder: /var/log/openhab
  javaVersion: 17.0.12
  javaVendor: Debian
  osName: Linux
  osVersion: 6.6.31+rpt-rpi-v8
  osArchitecture: aarch64
  availableProcessors: 4
  freeMemory: 139532664
  totalMemory: 628097024
  uptime: 245
  startLevel: 100
addons:
  - automation-jsscripting
  - binding-astro
  - binding-denonmarantz
  - binding-exec
  - binding-harmonyhub
  - binding-icalendar
  - binding-icloud
  - binding-ipcamera
  - binding-logreader
  - binding-mail
  - binding-mqtt
  - binding-network
  - binding-networkupstools
  - binding-openweathermap
  - binding-remoteopenhab
  - binding-tplinksmarthome
  - binding-zwave
  - misc-openhabcloud
  - transformation-jsonpath
  - transformation-regex
clientInfo:
  device:
    ios: false
    android: false
    androidChrome: false
    desktop: true
    iphone: false
    ipod: false
    ipad: false
    edge: false
    ie: false
    firefox: false
    macos: false
    windows: true
    cordova: false
    phonegap: false
    electron: false
    nwjs: false
    webView: false
    webview: false
    standalone: false
    os: windows
    pixelRatio: 1.5
    prefersColorScheme: light
  isSecureContext: false
  locationbarVisible: true
  menubarVisible: true
  navigator:
    cookieEnabled: true
    deviceMemory: N/A
    hardwareConcurrency: 8
    language: en-US
    languages:
      - en-US
      - en
    onLine: true
    platform: Win32
  screen:
    width: 1707
    height: 1067
    colorDepth: 24
  support:
    touch: false
    pointerEvents: true
    observer: true
    passiveListener: true
    gestures: false
    intersectionObserver: true
  themeOptions:
    dark: light
    filled: true
    pageTransitionAnimation: default
    bars: light
    homeNavbar: default
    homeBackground: default
    expandableCardAnimation: default
    blocklyRenderer: null
  userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
    like Gecko) Chrome/128.0.0.0 Safari/537.36
timestamp: 2024-09-09T03:08:36.686Z

On the Pi, timedatectl show the correct local time:

openhabian@oh-m:~ $ timedatectl
               Local time: Sun 2024-09-08 21:15:21 MDT
           Universal time: Mon 2024-09-09 03:15:21 UTC
                 RTC time: n/a
                Time zone: America/Denver (MDT, -0600)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
openhabian@oh-m:~ $

The settings in the openHAB UI, Settings, Regional Settings shows Local Time Zone as GMT-7, which is correct.

I tried rebooting the Pi, but it didn’t change anything.

openHABian-config System Setting 33 displays the correct local time.

Any suggestions?

Thanks in advance

2

Try adding this line

EXTRA_JAVA_OPTS="-Duser.timezone=America/Denver"

to the file

/etc/default/openhab

and restart openhab

3

That’s the right hint but bad advice as-is because you would overwrite all the required java opts.
Check the options java process is running with first. It should already have the string.

If not, there should already be a line for that variable. Append the string there.

4

Could the process of setting this be streamlined somehow?

5

it should happen on install already.
@BigGeorgeTx check first-boot.log

6

Thanks for the advice.

This is what the EXTRA_JAVA_OPTS line looked like before I appended the timezone parameter

EXTRA_JAVA_OPTS="-Xms192m -Xmx768m -XX:-TieredCompilation -XX:+ExitOnOutOfMemoryError -Dxtext.qn.interning=true"

after editting

EXTRA_JAVA_OPTS="-Xms192m -Xmx768m -XX:-TieredCompilation -XX:+ExitOnOutOfMemoryError -Dxtext.qn.interning=true -Duser.timezone=America/Denver"

Restarted openHAB with systemctl restart openhab

Timezone is now as expected. Thanks for the help

7

@mstormi
Here is the firstboot.log where this should have happened:

2024-09-03_21:38:46_UTC [openHABian] Setting timezone based on openhabian.conf... 
$ timedatectl set-timezone America/Denver 
OK (Europe/London)

Not sure how it got Europe/London out of America/Denver

8

Wow, those memory limits are soooooo tiny!

9

I don’t believe I did anything to change the defaults. And I don’t know much about memory limits. Can you please tell me more about this?

10

Well, if you have, say, 4GB or RAM, I’d increase that -Xmx to 1.5g or 2g.

11

Thanks. Here are the results of free -m

openhabian@oh-m:/boot $ free -m
               total        used        free      shared  buff/cache   available
Mem:            3841        1963         598           2        1357        1878
Swap:           3071           0        3071

Is it better to limit the memory used to the free RAM memory, or is it OK for it to spill over into the Swap memory?

I’m guessing that this means there is enough inactive memory that could be swapped without adversely impacting performance to go to the higher levels you recommended.

openhabian@oh-m:/boot $ cat /proc/meminfo
MemTotal:        3934164 kB
MemFree:          617844 kB
MemAvailable:    1928960 kB
Buffers:          169020 kB
Cached:           994100 kB
SwapCached:            0 kB
Active:          2110760 kB
Inactive:         864160 kB
Active(anon):    1813924 kB
Inactive(anon):      564 kB
Active(file):     296836 kB
Inactive(file):   863596 kB
Unevictable:          32 kB
Mlocked:              32 kB
SwapTotal:       3145720 kB
SwapFree:        3145720 kB
Zswap:                 0 kB
Zswapped:              0 kB
Dirty:                88 kB
Writeback:             0 kB
AnonPages:       1811832 kB
Mapped:           170832 kB
Shmem:              2688 kB
KReclaimable:     228160 kB
Slab:             257988 kB
SReclaimable:     228160 kB
SUnreclaim:        29828 kB
KernelStack:        8272 kB
PageTables:         8892 kB
SecPageTables:         0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     5112800 kB
Committed_AS:    2961568 kB
VmallocTotal:   257687552 kB
VmallocUsed:       38580 kB
VmallocChunk:          0 kB
Percpu:              720 kB
CmaTotal:          65536 kB
CmaFree:           41664 kB
openhabian@oh-m:/boot $
12

ideally you don’t want to ever use swap, especially if it means writing to sd card!

13

So perhaps I should increase -Xmx by 500 MB, so from 768m to 1268 m? That would leave some cushion to avoid swaps to the SD card.

14

you could try that

15

I did, and I bricked it. It is a headless unit and I don’t have a keyboard handy, so I don’t think I can edit it back to what it was. I do have the OH 4.2.1 SD card with the previous version of openhabian, so it won’t be much work to create a new one.

16

You didn’t, its display was just a cosmetic bug

17

@mstormi would it be possible to add a menu option to change the Java timezone?

Another (better) fix would be to adjust the Astro (and other bindings) not to use the system time zone but respect the openHAB setting. I can look into that.

18

You can use the timezone parameter in openhabian.conf.
I’ve added a fix in openHABian that it’s appended to Java params now (main branch only so far).

19

I have had this issue ever since moving to 1.9. Even if you set the timezone in openhabian.conf on the SD before first boot it ignores it. It always goes to London. Same for password. It will grab the locale if you set it.
I always check and edit the following files after a build.

/etc/timezone
/etc/default/locale
/etc/default/keyboard
20

They’re the openHABian defaults, and in fact they are what they are for good reasons.

-Xms pre-allocates memory to speed up stuff, but that’s an only minor benefit to be traded off against the effects of increasing it. Doing so will result in more paging hence SD deterioration.

-Xmx is just a hard limit and does not affect paging.
If -Xmx had been too low, java would have crashed when this had been reached.
Since you did not report anything I guess it wasn’t, and there’s also no reports of Java crashing elsewhere because of this although about any openHABian user is using them.