rule "Check FBH in heating period"
when
Time cron "0/10 * * * * ?"
then
var DateTime dt = new DateTime()
var String monthName = dt.monthOfYear().getAsText()
logInfo( “FILE”, monthName)
end
In the log I get:
2016-03-08 08:37:51.412 [ERROR] [.o.m.r.i.engine.ExecuteRuleJob] - Error during the execution of rule Check FBH in heating period
java.lang.RuntimeException: The name ‘.getAsText()’ cannot be resolved to an item or type.
Strange I got this example from a joda tutorial. However edited with your line…
var DateTime dt = new DateTime()
var String monthName = dt.month.getAsText()
logInfo( “FILE”, monthName)
… but it does not work either. Error:
2016-03-09 08:23:20.268 [ERROR] [.o.m.r.i.engine.ExecuteRuleJob] - Error during the execution of rule Check FBH in heating period
java.lang.RuntimeException: The name ‘.month’ cannot be resolved to an item or type.
SInce also this line: var LocalTime now = LocalTime.now()
gives an error I belive there is something wrong with the import.
I’m on rasbian wheezy with openhab 1.8
Not know what you were looking at I can’t comment. But the link above comes straight from Joda and says:
DateTime dt = new DateTime(); // current time
int month = dt.getMonth(); // gets the current month
int month = dt.month().get(); // alternative way to get value
String monthStr = dt.month().getAsText(); // gets the month name
Depends on the error but I doubt it is a problem with the import as there would be no DateTime at all if the import is wrong.
I highly recommend using Designer which will tell you if you have syntax errors or lacking imports.
It would seem that the month method is not exposed in the Rules DSL so we can’t get at the month name using getAsText. Perhaps it is using an older version of Joda.
You can try to get the month name as follows:
var String monthName = String::format("%1$tB", dt)
I think that String::format works with Joda time. If not just use Java’s built in Date object.
import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*
import org.joda.time.*
import org.joda.time.format.*
import java.lang.String
rule "test"
when
Time cron "0/10 * * * * ?"
then
var DateTime dt = new DateTime() // current time
var int month = dt.getMonth() // gets the current month
var String monthStr = dt.month().getAsText() // gets the month name
logInfo( "FILE", monthStr)
end
Designer also tells me:
Couldn’t resolve reference to JvmIdentifiableElement ‘getMonth’.
Couldn’t resolve reference to JvmIdentifiableElement ‘month’.
Couldn’t resolve reference to JvmIdentifiableElement ‘getAsText’.
It is not about getting the name of the month, it is more about in general getting the Joda things to work in my rules. Since it is easier and more elegant than the Java build in Date object.
After some time of frustration I wanted to start again on this antried without joda. But it also does not work well.
import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*
import java.text.SimpleDateFormat
import java.util.Calendar
import java.lang.String
rule "test"
when
Time cron "0/10 * * * * ?"
then
var Calendar cal = Calendar.getInstance()
var SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss")
logInfo( "FILE", "Time: " + sdf.format(cal.getTime()))
end
Designer tells Multiple markers at this line
Couldn’t resolve reference to JvmIdentifiableElement ‘getInstance’.
Couldn’t resolve reference to JvmIdentifiableElement ‘Calendar’.
And also in the log:
java.lang.RuntimeException: The name ‘Calendar’ cannot be resolved to an item or type.
I don’t get it. The most simple time thing just does not work. Any hint?
I don’t know whether or not this is your problem, but I’ve had problems like yours because of duplicate class names. So when there is a Calendar class in the OH API it might use that one in your program, not the Java one. The only solution I can see in that case (as written not sure if this really is your problem but it sounds like) is to use the fully-qualified names as @rlkoshak mentioned.
I have tried different ways of getting DateTime to register (with and without fully-qualified names) and in all of them the designer program tells me “Couldn’t resolve reference to JvmType ‘DateTime’”
I feel as if i’m going round in circles.
Using OH1 with designer 1.8.3, Java updated to latest version.
import org.openhab.core.library.types.*
import org.openhab.model.script.actions.*
import org.joda.time.*
rule "At Dusk Turn Lights On"
//Compare now to sunset time provided by Lightwave Link (lw_wifilink_dusk)
//If after dusk turn all lights to 50%
when
Time cron "0/60 * * * * ?"
then
var DateTime sunset = new DateTime((lw_wifilink_dusk.state as DateTimeType).calendar.timeInMillis)
if (sunset.isAfterNow())
{
logInfo("Test", "Sunset")
}
else
{
logInfo("Test", "Daytime")
}
end
Does it run? I just added the following line to a rule and Designer had no problem with it.
var org.joda.time.DateTime sunset = new org.joda.time.DateTime(new DateTimeType().calendar.timeInMillis)
Here are a few more working examples from my rules:
val sunrise = new DateTime((Sunrise_Time.state as DateTimeType).calendar.timeInMillis)
val twilight = new DateTime((Twilight_Time.state as DateTimeType).calendar.timeInMillis)
val evening = new DateTime((Sunset_Time.state as DateTimeType).calendar.timeInMillis)
I have just reinstalled Windows on my desktop due to a hard disk crash, and now my rules file that I have been using for the last 9 months is displaying this error.
I have tried restarting designer and rebooting the pc, to make sure all paths were set, but to no effect.
Yes, see in the image. Interestingly, the import doesn’t report an error, but then trying to use a DateTime, even after it has been imported specifically, does.
I’m seeing the problem with ‘now’ as well, but I think they are in the same package. Something in my new installation is causing this, but I have no idea how this scripting language resolves classes.
As @rossko57 said, there is a problem with the current builds of Designer that causes them to not recognize now and other joda classes. This is just a Designer issue. Does the rule run? If not then what is the error reported in OH?
The rules have been running fine for months, so its a designer issue.
If its a bug that’s been introduced in designer, is there a way to get a previous version that worked?
Edit:
I have just found and downloaded version 1.8.2, from bintray, which I think is the previous version (I can’t find any version info in the designer files). It is exhibiting exactly the same symptoms, so I’m not sure this is a designer bug or an installation problem.
I can’t find any older versions of designer to test.
