Trigger conditional on variable seems to be passing despite evaluation to false

[rvrolyk]

I have a trigger that looks at a thermostat heat or cool setpoint and compares each of them to a variable. This evening, I noticed when I increased the cooling setpoint, the action triggered despite the condition being false. I don't think it used to do this? I haven't done any testing to see if it is a comparison to a variable that's causing it to pass through or if it would do so with a fixed value.

I'd expect the above to only trigger if the cool setpoint was decreased below 75 or the heat setpoint was increased above 60.

You can see the event was the cool setpoint changed to 78 but the trigger fired anyway and the actions were evaluated.

Is there something wrong with my expectation? Should I just set the action to have a conditional to exit the rule in cases where this would be false?

@bravenel

[bertabcd1234]

@rvrolyk

I'd expect the above to only trigger if the cool setpoint was decreased below 75 or the heat setpoint was increased above 60.

No, it will trigger (and always has) on any event that matches the criteria. If you only want to trigger on a specific state change, required expressions make that easier to capture now. See: Rule-5.1 - Hubitat Documentation

[rvrolyk]

Sure, but in this case the event was “cooling setpoint changed to 78”. How does that match the criteria in my rule?

[bertabcd1234]

Wait, I was looking at the wrong setpoint. Yes, that seems odd. What is the actual value of the variable (don't trust the display here)?

[rvrolyk]

It is 75 —

(Sorry for iPhone screenshot….)

[bravenel]

Please post the Event Subscriptions from the App Status page.

[rvrolyk]

Sure, here you go.

[bravenel]

I need you to show the entire rule, as there may be some interaction happening with the Required Expression.

[rvrolyk]

Sure, the required expression isn't super complex and should evaluate to true (at least right now) all the time as long as we're home (that is, for summer months we have the thermostat cooling all the time and the other controller switch is always off).

[bravenel]

I'm not able to reproduce this problem at all.

New rule:

Logs from setting the thermostat to different values:

It triggered when it was supposed to, and not when it was not supposed to. ==> I don't know what your problem is caused by.

[rvrolyk]

well that's curious. I can do some more testing on my end when I have a bit of time this week.

The thermostat driver/app (from here) looks like it's generating an event from a json response with unit "F" --

is it possible that's being interpreted as a string in the trigger but not in an action (comparing numbers in actions works fine for me)?

thanks for looking into it and trying to reproduce!

[bravenel]

@rvrolyk

is it possible that's being interpreted as a string in the trigger but not in an action (comparing numbers in actions works fine for me)?

No, because it actually ends up in a mathematical comparison. The units don't matter.

[rvrolyk]

So much for that theory then… I’ll poke at it a bit more and if I manage to find out why I’ll let you know. Thanks for checking it out.

[rvrolyk]

I can’t explain this either. I have a test rule that simply has the two triggers and logs as an action. If I use a virtual thermostat I see the behavior you do. But if I use my actual thermostat then it triggers incorrectly like I reported initially. This is the exact same rule in both cases.
This leads me to believe it’s the driver somehow but I’m unclear how/why. Any suggestions on what to look at in the driver/app? (I say app because that’s what is actually generating the event on the device)

[bertabcd1234]

Is it possible that your driver is sending the temperature value as a string instead of a number? I don't have a device so can't test this for sure, but if you look inside the refreshHelper() method (the line that starts with def refreshHelper( — can't easily see the line number since the link above is to the raw code, not the fancy GitHub formatted one), you may get your answer. I don't have one of these devices or know what the JSON it's parsing looks like, but logging a bit more information in this block of code might help you figure it out:

if (optionalUnits != null)
        {
            sendEvent(device, [name: deviceString, value: value, unit: optionalUnits])
        }

maybe change it to something like:

if (optionalUnits != null)
        {
            sendEvent(device, [name: deviceString, value: value, unit: optionalUnits])
            if (deviceString == "heatingSetpoint" || deviceString == "coolingSetpoint") {
                adjfaasdlfj(value) 
           }
        }

That adjfaasdlfj(value) line will, of course, throw an error — but Logs will contain the method signature it's looking for, including what the type of the parameter (value) actually is. Sort of a cheat, but it works. If the type is not some numeric type, likely Integer or BigDecimal, that could be the problem (the most likely problem here is String).

[rvrolyk]

Thanks for the idea on how to verify the value type - it’s an Integer so should be ok. I don’t have my laptop for a few days and don’t want to try hacking on the code (much) from my phone but when I’m back I’ll have to dig a bit more.
Your guess was the same as my original one though Bruce said it shouldn’t matter and now we know it’s an Integer.
I’ll try updating a virtual thermostat from an app but I imagine that works fine.
There’s no special setpoint handling in the driver itself but maybe there’s something else different.

Error in case you’re curious:

errorgroovy.lang.MissingMethodException: No signature of method: user_app_thecloudtaylor_Honeywell_Home_104.adjfaasdlfj() is applicable for argument types: (java.lang.Integer) values: [64] on line 645 (method refreshThermosat)

[rvrolyk]

If I reduce the trigger to just the cooling setpoint it works fine. I haven’t tried just heat but guess that works too. My theory is that somehow the two are conflated but I haven’t dug enough yet to know how/why. The events page for the device only shows cooling changed and I’d think it would show both if my theory was right (so maybe it’s wrong?).

[rvrolyk]

The server response contains the heating and cooling setpoints so even though it’s only doing one of the two, both are actually updated. The events don’t show that because there’s no change to the heating one (in this case). I don’t quite understand why my rule shows the event as a cooling change but I suspect it’s the heating trigger that’s actually matched in this case.

[rvrolyk]

Ok well that’s not it. I tried wrapping that in some conditional blocks so it only sent the event relative to the thermostat mode but it’s still triggering. Even more odd, I saw it work correctly a few times but no change in between success and failure.

[rvrolyk]

Since I was seeing a bit of inconsistency, I decided to retry my test with a virtual thermostat again. Much to my surprise, the rule I was using failed that test like it had with my real thermostat. So, I created a brand new rule and tried again but it did the same. @bravenel, you really don’t see this on yours?

Edit: I tested on my other hub running 2.3.2.133 and see the same thing.