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
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.
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
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
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.
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.
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)
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)...
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.
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?
Just add more and more log statements, perhaps to the point where they are every other line of code if you need to.
But I suspect you should not assume the error is lying to you. Add some logging to that 12th rule and see what that rule is doing. That error usually occurs when trying to use something that is incompatible with the operation you are trying to do. For example, if you cast the state of a Number Item to Number but the Item’s state is actually NULL or UNDEF will make an error like that.
No, you converted it to a LocalDateTime. But that should be compatible with most of the stuff you’d use a ZonedDateTime for. But maybe not because LocalDateTime strips the time zone information out and ZonedDateTime needs the timezone information.
No, that is a DateTimeType you are creating there. And that line is pretty redundant because vSunrise_Time.state already is a DateTimeType. You need a ZonedDateTime (or something compatible like LocalDateTime) to do comparisons like isAfter.
val day_start = (vSunrise_Time.state as DateTimeType).getZonedDateTime
This all looks like snippets from the Time of Day design pattern. Are you aware that I rewrote that code in a way that all you need to do is copy it and configure your Items? No more need to modify any code.
Also, there are several postings near the bottom of the thread that show what needs to change to make the old Rules DSL version work with OH 3.
In the very near future I’ll be able to distribute it as something that is installable through MainUI. In the mean time it takes some copying and pasting to install and use. But one “installed” all you need to do is create and configure some Items.
