Execution of startup rule 'System started' has been postponed as items are still missing

Add-ons Bindings
1

I am seeing this error with this rule:

import org.openhab.core.library.types.*
import java.lang.Math.*
import org.joda.time.*
rule "System started"
when
System started
then
logInfo(“file”, “**>>> system started”)
var DateTimeFormatter dtf = DateTimeFormatter::forPattern(“yyyyMMddHHmmss”)
end

In looking at the code here: https://github.com/eclipse/smarthome/blob/master/bundles/model/org.eclipse.smarthome.model.rule.runtime/src/org/eclipse/smarthome/model/rule/runtime/internal/engine/RuleEngineImpl.java

It looks like the rule engine is catching an exception and eating it. The error message does not disclose the actual exception so I have no idea what the problem is. Would be better is the details of the exception were printed to the log.

Any ideas what is wrong with the line of code that creates the DateTimeFormatter ??

2

Are you sure about the method forPattern? I can’t find it in the list…
openHAB uses joda 2.9.2 (see here), but forPattern was introduced with joda 2.9.4.

3

Yea, my mistake there. forPattern is s static method on DateTimeFormat, NOT DateTimeFormatter.

The correct code is:

val DateTimeFormatter dtf = DateTimeFormat::forPattern(“yyyyMMddHHmmss”)

The DateTimeFormat is a factory for DateTimeFormatter.

However, after making the correction it still fails and without the exception logging I have no idea why it is failing.

4

I moved the code into an item changed rule and now I can see the actual error:

An error occured during the script execution: The name ‘DateTimeFormat’ cannot be resolved to an item or type.

So for some reason OH2 thinks that DateTimeFormat is not available. I have an import line:

import org.joda.time.*

???

5

After a lot of my own head-scratching trying to work out the available objects for date and time, I had more success with the later Java built-in objects, than joda.

In case it helps, here’s a few links that helped me hack some rules together:
https://eclipse.org/xtend/documentation/
https://www.eclipse.org/smarthome/documentation/javadoc/org/eclipse/smarthome/core/library/types/DateTimeType.html
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/Formatter.html

//import org.eclipse.smarthome.core.library.types.DateTimeType
The import is commented out in my working rule, as ESH Xtend didn’t seem to need it.

6

If you use the Designer for editing your rules, you will see that it complains about not being able to resolve DateTimeFormat (and that import org.eclipse.smarthome.core.library.types.* etc. are not required).

After a lot of my own head-scratching trying to work out the available objects for date and time, I had more success with the later Java built-in objects, than joda.

Thinking about it, I think this is the real issue here: In OH1 I introduced joda, because it provided convenient methods for time handling. Now in OH2, we are on Java8, which actually comes with a modified version of joda built-in (as java.time) - so many classes are now available twice and the rule engine probably has a hard time to find the one you actually mean to use.

I wonder if it is time to get rid of the joda lib and change the rule engine to use the java built-in classes instead?

7

The Designer e.g. does not complain anymore, if you use:

import java.time.format.DateTimeFormatter

rule "System started"
when
	System started
then
	logInfo("file", "**>>> system started")
	val DateTimeFormatter dtf = DateTimeFormatter::ofPattern("yyyyMMddHHmmss")
end
8

Hi @Kai ,

Although I don’t have the Java knowledge to comment on the relative strengths of the two libraries, from a user perspective having one unambiguous set of ‘standard’ objects to re-use would be a huge advantage over the confusion of many options in example code.

Copy/ Paste coding only got me so far before I had to start thinking! :wink:

The downside of rationalising out Joda is obviously that existing OH1 users would need to port across existing rule code and examples to Java8 / Xtend, but being able to refer to one set of known good documentation is really helpful. Even better if it comes for free via platform re-use…

9

I agree. I have entered an issue, so that it is not forgotten.