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
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: https://docs.hubitat.com/index.php?title=Rule-5.1#Required_expression
Sure, but in this case the event was ācooling setpoint changed to 78ā. How does that match the criteria in my rule?
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)?
It is 75 ā
(Sorry for iPhone screenshotā¦.)
Please post the Event Subscriptions from the App Status page.
I need you to show the entire rule, as there may be some interaction happening with the Required Expression.
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).
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.
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!
No, because it actually ends up in a mathematical comparison. The units don't matter.
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.
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)
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
).
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)
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?).
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.
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.
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.