Convert Double to Integer?

Setup, Configuration and Use Scripts & Rules
1

Hello

how can i convert a double to a integer in a rule?

thx

2

double.intValue will do the conversion by stripping off the decimals. To round, add 0.5 first, (double + 0.5).intValue.

3

Or use Math::round(decimal). Note that if you pass in a double you will get back a long. If you pass a float you will get back an int.

By default the Rules DSL stores everything as a BigDecimal which has intValue like Scott indicates. However, if you are explicitly using a primitive double you will have to use Math::round().

The correct answer will depend on context.

4

Hi Rich,

jumpin’ in from another thread:
I tried to follow your suggestion with round, where m is 2 in this case

var Number hour = now.getHourOfDay
var float c = (((m * 24) + 12 - hour) / 3)
logInfo("weather.rules", "c: " + c)
var int x = Math::round(c)

This works to round e.g. a fixed value of 15.1 to 15.
But if I use c instead, I get:

2019-02-19 19:40:20.723 [INFO ] [smarthome.model.script.weather.rules] - hour: 19
2019-02-19 19:40:20.738 [INFO ] [smarthome.model.script.weather.rules] - c: 13.66666667
2019-02-19 19:40:20.744 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'daily forecast DayX (toda': An error occurred during the script execution: Could not invoke method: java.lang.Math.round(float) on instance: null

EDIT:
It does not work if c is double:

Rule 'daily forecast for DayX': An error occurred during the script execution: Could not invoke method: java.lang.Math.round(double) on instance: null
5

If you look closely at the first error you will see that Math::round requires a float, not a double. Use c.floatValue.

6

Thanks - I will try that.
I thought, because c is defined as float above it is float already!?

But it’s not working either:

var float c = (((m * 24) + 12 - hour) / 3)

An error occurred during the script execution: Could not invoke method: java.lang.Float.floatValue() on instance: 13.33333333

but if I remove the float in the definition of c it works.

var c = (((m * 24) + 12 - hour) / 3)

Thanks for your help!

7

As a general Rule, it is better in Rules DSL not to be specific until you have to be. In this case, just let the type of c be whatever Rules DSL decides it should be after the calculation (which would be BigDecimal) and only convert it to a float (or anything else more specific) when you have to (e.g. the call to Math:round).

Besides strange type errors like you are seeing here, directly creating primitive variables can add minutes to your Rules parsing time on an RPi and should therefore be avoided.

Unlike what many of us were trained to do and what seems the right thing to do, in Rules DSL, not specifying type unless you have to is better than specifying the type everywhere.

8

@NCO, have you seen this? Looks like you may be doing the same thing.

9

Alright, thanks Rich.
I will keep this in mind and will review my code for similar potential improvements.

10

Hey, Scott.
You’re smart and recognized right away what I was after :slight_smile:

Thanks, I know your thread, but would like to avoid the experimental rule stuff (which is mandatory for your approach, right?)
So I wanted to create a “regular” rule to simulate my daily forecast.

11

Yes, you would need the NGRE and Jython. Once the IDE setup is functional again, I’ll be able to complete Jython scripted Actions, make a bundle for Jython, and package the rule up as a template available in the marketplace. Will be much easier! IMO, it would be much less effort to setup Jython than rebuilding this in the DSL. Have you created the 600+ Items yet?! My script will do that for you. :slight_smile:

Either way, good luck and let me know if you need anything. I’m actually sitting here testing an update where I’m iterating the Channels so that new Items will be created when the OWM binding is updated. So, my head is full of OWM ATM.

12

The real “experimental” part is defining Rules through PaperUI/JSON. The engine that runs both PaperUI/JSON Rules and JSR223 Rules is the same so it does become confusing. But defining Rules using .py files is supported quite well and not at all what I’d call experimental. And thanks to the efforts of Scott, becoming better every day.

I do not hesitate at all to recommend giving it a try.

13

Thanks guys. @rlkoshak @5iver

Isn’t NGRE about creating rules in PaperUI?
I just use the regular like .rules to keep everything close together for better transparency.

Anyway, you are most probably absolutely right and I am just looking for a „Best“ approach for me (and my capabilities :wink:

@5iver:
Your roadmap sounds promising and very tempting.
I did not create that many items, because I just focus on the crucial ones for me.
Temp, condition, rain and few others.

Be assured, that I will keep a close look on your progress.

Again, thanks for your support!

Just a side note.
I am more than 2 years playing around with openhab and using this community intensively.
Actually, I always found a proper solution for me here so thanks to all of you guys around here :slight_smile:

2 Likes
14

It’s both. PaperUI/JSON Rules is one way to create Rules that run on the NGRE but JSR223 is another way to write the code a little more directly. The JSR223 part is mature and fully capable. The PaperUI/JSON part is not as mature nor documented (but it’s getting better every day).