Upgrade 2 to 3 strategy/planning

Still applies

hmm…I’m sure you are correct, I dug around the forum a bit and even read some posts you made, but there doesn’t seem to be a definitive “do this to set the java time”. Lots of “I did this”, “that didn’t work for me, I did this”…

I’ll look in more detail in the morning.

Thanks

Login to your OH system via ssh and then execute

timedatectl

what does it show ?

Here it shows:

      Local time: Sun 2021-06-27 09:49:09 CEST
  Universal time: Sun 2021-06-27 07:49:09 UTC
        RTC time: Sun 2021-06-27 07:49:12
       Time zone: Europe/Berlin (CEST, +0200)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

Execute

openhab-cli console -p habopen env | grep timezone

to see the timezone that is set /used for Java. Returns e.g.:

String          user.timezone   Europe/Berlin

Other stuff to check:

ls -l /etc/timezone  /etc/localtime 
lrwxrwxrwx 1 root root 33 Feb 12 19:46 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin
-rw-r--r-- 1 root root 14 Feb 12 19:46 /etc/timezone

cat /etc/timezone
Europe/Berlin

returns:

               Local time: Sun 2021-06-27 13:40:22 CEST
           Universal time: Sun 2021-06-27 11:40:22 UTC
                 RTC time: n/a
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Noted “NTP service: active” is different from yours “NTP synchronized: yes”.

No clue if that makes a difference.

openhab-cli console -p habopen env | grep timezone

Returns: “No more authentication methods available”, but, “user.timezone Europe/Berlin” is returned without the grep.

“/etc/timezone” contains: “Europe/Berlin”

Isn’t /etc/timezone an OS setting? Can that be changed in the normal Linux admin ways?

What is the definitive way to set the what JAVA thinks?

No. I also saw that depending on the Linux flavour. Have both types here.

What is the timezone that you are looking for ?

Sigh, so in the mean time I looked to see if ntp was installed. Apt said no, so I installed.

Now timedatectl shows:

           Universal time: Sun 2021-06-27 12:21:47 UTC
                 RTC time: n/a
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

so now it looks like the system is set to the right timezone, but not using NTP?

Edit: It now says:

           Universal time: Sun 2021-06-27 12:31:04 UTC
                 RTC time: n/a
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no

But, the OH log still show the wrong time.

The host operating system has a clock - and a timezone.

The Java sub-system has a clock- and a timezone. When you install Java, it guesses timezone based on OS timezone, unless you tell it different. If you later amend the OS timezone, I do not think it changes Java. This is the clock the logger uses.

openHAB application has a clock and a timezone. When you install OH, it guesses timezone based on Java timezone, unless you tell it different. If you later amend the OH timezone, it does not change Java. If you did have to amend OH, it’s a good clue the Java timezone was not what you wanted.

Don’t forget we still do not know what timezone you think is wanted.

Umm…

After you see timezone being set to EDT.
What is the output again for the other check I posted earlier ? Do they all show EDT related entries now ?

openhabian seems to use timesyncd instead of ntp. You can use the openhabian-config menu 33 entry to switch it on ( again ).

               Local time: Sun 2021-06-27 10:55:01 EDT
           Universal time: Sun 2021-06-27 14:55:01 UTC
                 RTC time: n/a
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no

openhab-cli console -p habopen env gets:
user.timezone Europe/Berlin

The for any state change:

2021-06-27 16:53:00.968 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'vTimeOfDay' changed from 2021-06-27T10:52:00.961-0400 to 2021-06-27T10:53:00.963-0400```

I just noticed this in the log:
2021-06-27 16:55:01.197 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'ntp:ntp:local' changed from OFFLINE (COMMUNICATION_ERROR): The network connection to the timeserver 0.pool.ntp.org cannot be established -> returning current sytem time instead. to ONLINE

1 Like

Thanks!

To get the Java engine going right timezone, you need to pass extra java options parameter as environment variable for container like this:
EXTRA_JAVA_OPTS="-Duser.timezone=America/New_York"

I’m sure that this is obvious and how to accomplish it is also obvious…but, not to me.

  • there is a JAVA engine, and I knew OH is written in JAVA
  • there is a way (unknown to me) to pass environment variable to the JAVA engine
  • I have no idea where one defines the environment variable
    (is it in some JAVA environment?) (Is it a system environment variable?)
  • I don’t know if this happens dynamically or a reboot is needed, logout/in, restart OH?

10 minutes of web searching I found some posts here that imply it can be added to start.sh by adding this line to top of the file.

export EXTRA_JAVA_OPTS="-Duser.timezone=America/New_York

But, they all show openhab2 directories.

My system has:

$ cd /
$ find . -iname 'start.sh' 2>/dev/null
./opt/openhabian/tests/start.sh
./usr/share/openhab/start.sh
./srv/openhab-sys/start.sh

Sorry to be so thick headed.

It should be possible to add ( no export in front )

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

to
/etc/default/openhab
that file is sourced from within start.sh which is at /usr/share/openhab/start.sh.

That file already contains:

EXTRA_JAVA_OPTS="-Xms192m -Xmx320m"

So, I should make it?:

EXTRA_JAVA_OPTS="-Xms192m -Xmx320m -Duser.timezone=America/New_York"

Edit: that appears to be good.

Thanks!!!

1 Like

There is a lot going on here. It looks like you’ve had help with the timezone issue and the rrd4j issue. But I see two questions unanswered.

Probably but I can’t say for sure. That’s really an InfluxDB question about how to transition storage from one machine to another. Typically one would execute a dump of the database on the old instance and a restore on the other machine. But I haven’t used InfluxDB in quite some time so I can’t comment on more than that.

MapDB is very much still supported but it’s a separate add-on. I don’t think you can reuse the old mapdb files in OH 3. But you are now out much. MapDB only saves the most recent values for each Item.

Thanks for the reply.

the rrd4j appears to be working for my number items I want to persist, though it is apparently using whatever default is configured when it is activated.

At this point I still don’t know what I was persisting in mapdb… But, it is not on the addons website, at least I couldn’t find it yesterday.

So this is much like rrd4j, but can handle more than numbers?

I have the old influxdb .cfg file. and I’m wasn’t putting much into it, so ground zero wouldn’t be much of a problem (done that a lot with this…). But, the Graphana pages would be nice to migrate.

Is it best to install Influx from the openhab tool?

on a different note I saw a reference by you about Joda time in OH3.

I think I get the change to

With the Joda way this is 23:00 (I think)

val night_start = now.withTimeAtStartOfDay.plusDays(1).minusHours(1)

and the equivalent would be:

val night_start = now.withHour(23).withMinute(0).withSecond(0)

Did I get that right?

Default strategies are a new thing in OH 3. For rrd4j it’s persist all supported Items on every change and every minute with restoreOnStartup. To change that you need to create an rrd4j.persist file with a different set of strategies.

Probably. I don’t know everything that it does but suspect it will create the DB user and database for you and if you install be hand you’ll have to do those things manually.

Looks like it should work. However, be careful with daylight savings days. You might convert now to a LocalDateTime which takes those things into account better.

val nighty_start = now.toLocalDateTime().withHour(23)...

Yeah, that makes sense…silly DST…

So I now have a astro thing:

astro:sun:local

In my old rules I reference:

when
  System started or // run at system start in case the time changed when OH was offline
  Channel 'astro:sun:home:rise#event'    triggered START or
  Channel 'astro:sun:home:set#event'     triggered START or
  Channel 'astro:sun:minus90:set#event'  triggered START or

I think I need to change this to:

when
  System started or // run at system start in case the time changed when OH was offline
  Channel 'astro:sun:local:rise#event'    triggered START or
  Channel 'astro:sun:local:set#event'     triggered START or
  Channel 'astro:sun:minus90:set#event'  triggered START or

Am I right in thinking the last line implies I need to add a sun thing called minus90 astro:sun:minus90 with set offset of 90 minutes?

Yes but only if you want to keep things the same. You could also pick on of the other channels on your astro:sun:home Thing, for example nauticalDusk or something like that and apply the offset to that one Channel.

Still debugging…

When the log says there was an error in play-12, I think this is supposed indicate the 12th rule in the file play.rules. In my case the error is being thrown from the 8th rule in the file. (If it was 1 off…I’d say it was a starts at 0 rather than 1 discrepancy…but, a delta of 4 I don’t get.)

Also the error in the log is:

Script execution of rule with UID 'play-12' failed: An error occurred during the script execution: null in play

Not sure how I ma that to a line in the file…

I have a good idea where it is because I’ve added log entries.

It has something to do with changing:

val morning_start = now.withTimeAtStartOfDay.plusDays(1).minusHours(18) 

To:

val morning_start = now.toLocalDateTime().withHour(6).withMinute(0).withSecond(0)

Then subsequently the line:

vMorning_Time.postUpdate(morning_start.toString)

I’m guessing the return type is different, but not being savy with JAVA, I’ll need to research that.

The major question of this post: is there a better way that adding loginfo() lines to narrow down errors like this?