True isn't true anymore?

This seems to be an odd day!

I have those code lines:

var Boolean OK = transform("JSONPATH", "$.ok", json)
if (OK=true) {
  var Boolean WholeDay= transform ("JSONPATH", "$.station.wholeDay", json)
  logInfo("OpeningTimes Lambda", "WholeDay = {}", WholeDay)
  if (WholeDay) {
    //Open the whole day! Create times that show that.
    logInfo("OpeningTimes Lambda", "Open: {}", Open)

I do get the first logInfo:

[INFO ] [ome.model.script.OpeningTimes Lambda] - WholeDay = true

but I don’t get the one inside the “if (WholeDay)”. I tried it with WholeDay=true, (WholeDay=true) and WholeDay==true also!
I restarted OH2 and also rebooted my raspi. It was working until last nigth as expected!!!

If there was a problem with the Open.postUpdate, you wouldn’t see the second log line. OTOH, I assume you looked for related exceptions or errors in the log file. Just in case there an error that’s not being logged, you could try putting a log message before the postUpdate.

Sounds like strange things did happen last night. @opus Could this be related to your problems?

Thanks for the reply, as usual my statement was to short.
The rules runs over tha posted part and executes the Else branch. So the rule didn’t run into an eror there.
I think I’ve checked the obvious reasons/causes already.

As far as I understand the problem in this report is caused by an update, I didn’t do any update since installing the stable OH2.

Spent to whole evening on it, can’t figure out where the problem is coming from. The behaviour switched in between and did the True branch even if the statement was false. More over the postupdate didn’t work in some cases.

The diversity of the false behaviour seems to be pointing on a general system problem, could that be a problem with the SD Card?

Tomorrow I’l do some tests without lambda expressions, just in case.

What is the scope of WholeDay, might something else be interfering with it?

WholeDay is declared two lines above the If statement (as in the first post), so it is local to that rule and known within that statement.
The logInfo, which is just after the declaration, states WholeDay: true and in the next step the If statement treats it as not true! Where should WholeDay be interfered with?

[Edit:] didsome more detailed cheks.
Using “if (WholeDay=true) {…” ,will run the true branch IN ANY CASE, since WholeDay is set to true that way!
Using “if (WholeDay==true) {…” raises an error:

09:01:01.376 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Error during the execution of startup rule ‘OpeningTimes’: Could not invoke method: org.eclipse.xtext.xbase.lib.BooleanExtensions.operator_equals(boolean,boolean) on instance: null

Using “if WholeDay {…” does NOT run into the true branch although WholeDay is true!

That’s informative. Either WholeDay or true is found to be null, when handled as a Boolean.

Have you seen this (unresolved) post, are you in similar circumstances i.e. startup?

Thanks for the reply and No, I’m not in similar circumstances. The above discribed behaviour has nothing to do with StartUp, nor with the fact that I initially saw in a lambda expression.
I do also understand the error in this way, however what part would you expect to be null, the “false” or the variable which was declared two lines above and which was positvely logged in the line just above???

In a nadditional test I used those lines:

var Boolean WholeDay= transform (“JSONPATH”, “$.station.wholeDay”, json)
logInfo(“OpeningTimes Lambda”, “WholeDay: {}”,WholeDay)
if WholeDay { .
logInfo(“OpeningTimes Lambda”, “WholeDay: {}”,WholeDay)

This time I get the two expected logInfos, but not if I do not set WholeDay manually to true!!

13:37:26.194 [INFO ] [ome.model.script.OpeningTimes Lambda] - WholeDay: true
13:37:26.203 [INFO ] [ome.model.script.OpeningTimes Lambda] - WholeDay: true

I’ll use a work-around by reading the expected boolean from the json-string into a string and while checking afterwards if the string contains(“true”) I set the boolean. Not nice but working!!

I’m sure you already fixed the typo in there

It all feels like that is returning a string instead of a boolean, which would cause the logInfo and branch cases as described.

I was curious enough to have a play (OH 1.8.3)
I think this has something to do with Java primitives under Rules DSL and type casting.

Replicating your issue

var Boolean testB = "true"     //  casting a String to boolean (primitive I reckon) 
logInfo ("playtime", "B " + testB)    // displays true
logInfo ("playtime", "B {}", testB)   // displays true
if(testB == true) {                // gives the " ... BooleanExtensions... on instance: null" error 
   logInfo ("playtime", "B comparison true")			    	

Note the error from BooleanExtensions with a B
I do not think var Boolean = is producing a Java Boolean object at all. I suspect it is producing a primitive boolean with a small b and no extensions.
At least, testing with var boolean = produces exactly the same results.

On second thoughts, maybe it does produce a Java Boolean … but what the Rules DSL specific
if() requires is a rules DSL specific Boolean.

Anyways, fixing the issue is as easy as -

var testA = new Boolean("true")      // casting the string as a Boolean (object) 
logInfo ("playtime", "A " + testA)       // displays 'true'
logInfo ("playtime", "A {}", testA)       // displays 'true'
if( true == testA) {
    logInfo ("playtime", "A comparison true")   // displays			    	
if(testA) {
   logInfo ("playtime", "A defaults true")    // displays			    	

Thank you for that lengthy explanation.
That difference between primitive and object Boolean is new to me. My above posted work around can be shortend with this knowledge.

var OK= new Boolean(transform("JSONPATH", "$.ok", json))

For the “typo”, in my eyes that was OK, but as I’m coming from basic I’m blind on that.topic.

I think this is a bug.
There is a philosophical debate whether a Boolean could ever be equal to a boolean, even if they were both true (or false) seeing as they are different kinds of things.

But, something as simple as

var B/boolean myTest = "some value" 
 if (myTest) { logInfo("here","true") }

should not break with an error, whatever path you expect the if to take.
We are OH1, so who cares it won’t be fixed.

Can anyone please test on OH2 and see if this issue is present ?

I’m on OH2!

Okay, issue raised

I read to coments on github. I guess at least I have to admit that the use of the Eclipse SmartHome Designer would have shown exactly that!:flushed: