Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rules var number can get string value #4443

Open
sifourquier opened this issue Nov 9, 2024 · 2 comments
Open

rules var number can get string value #4443

sifourquier opened this issue Nov 9, 2024 · 2 comments
Labels
bug An unexpected problem or unintended behavior of the Core

Comments

@sifourquier
Copy link

Expected Behavior

in a .rules file if i write
var Number currDay = now.getDayOfWeek()
currDay need take 1 to 7 or an error if getDayOfWeek() return a string

Current Behavior

in a .rules file if i write
var Number currDay = now.getDayOfWeek()
Number take value "SATURDAY"

Possible Solution

Number no need accepted not number value

Steps to Reproduce (for Bugs)

write in a .rules file

`rule "test2"
when
Member of gTimepicker changed or
Time cron "* * * 1/1 * ? *"
then
var Number currDay = now.getDayOfWeek()
logError("test2", "currDay "+currDay)

end`
and show in log
2024-11-09 09:33:52.614 [ERROR] [org.openhab.core.model.script.test2 ] - currDay SATURDAY

Context

the rule work fine with old version of openhab

Your Environment

openHAB 4.2.2
debian bookworm
openjdk 17.0.13 2024-10-15

@sifourquier sifourquier added the bug An unexpected problem or unintended behavior of the Core label Nov 9, 2024
@rkoshak
Copy link

rkoshak commented Nov 13, 2024

This isn't a bug. This is how many typeless scripting languages work. The problem is Rules DSL tries to be both typless and typed at the same time (because Java is strongly typed).

Rules DSL usually determines the type of a variable at runtime. In fact, it's better to let it determine the type at runtime. When you force the type, it can cause all sorts of problems. In a best case scenario, the type of the variable is simply ignored. In a worst case scenario (e.g. primitives as types) this can add minutes to the amount of time it take to parse and load a Rules DSL file.

So a best practice in Rules DSL would be

var currDay = now.getDatyOfWeek()

Only specify the type when you absolutely have to.

The obsurd way Rules DSL handles types is one of the reasons I no longer recommend development using it. Any of the other options behave in more logical ways and are now just as easy to use as Rules DSL ever was.

This particular feature comes from the upstram Xtend library as Rules DSL is built on Xtend and this behavior is implemented by Xtend. Fixing it will require a change there. OH can't do much about it. But because this was a deliberate design decision and not a bug or regression.

You don't say what "old version of openhab" you are referring to or what you mean by "work fine" but one of the breaking changes between OH 2.5 and 3.0 was dropping the Joda time library in favor of the built in java.time library. These two are similar but not identical. IIRC getDayOfWeek() back then returned a number between 1 and 7. But java.time.ZonedDateTime returns an enum: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/ZonedDateTime.html#getDayOfWeek()

And looking further you will see that the enum has a getValue() method to get the number value. https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/DayOfWeek.html#getValue()

So use

var currDay = now.getDayOfWeek().getValue()

If you are coming from an OH 2 version, this is one of the many documented breaking changes that you need to account for manually.

If you are comming from OH 3, I am skeptical that this ever worked as described because ZonedDateTime's getDayOfWeek() has not changed between Java 11 (OH 3) and Java 17 (OH 4). It's always returned an enum of the days of the week.

@sifourquier
Copy link
Author

Thanks you for your reply.
i have update my server then maybe is a not update of OH (minor update) but a update of java i not remeber les version of java i use beford

It is a old rule. I need change for other ruls language

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An unexpected problem or unintended behavior of the Core
Projects
None yet
Development

No branches or pull requests

2 participants