I have a couple of rule 5.1 apps with just added triggers based on humidity changed. One increased, one decreased.
Both generate errors like this:
app:4172022-10-17 12:18:11.661errorinvalid operand type for 85(number) increased 73(number)
app:4172022-10-17 08:22:11.863errorinvalid operand type for 79(number) increased 74(number)
app:4172022-10-17 07:23:11.939errorinvalid operand type for 87(number) increased 71(number)
The triggers look like this:
Humidity of Ensuite Multisensor(81) increased
Not found any reference to this issue elsewhere.
Running a C-7 on 2.3.3.134.
Any thoughts @bravenel ?
I'm not seeing any error with this. Please show a screenshot of the logs, not copy/paste.
Thanks for looking. This is what I see.
This is the corresponding trigger
What kind of device is Ensuite Multisensor? And which app is app 417? That's the appId, and it should be in the url when you open the rule. Turn on all logging in the rule itself, so we can see more context in the logs.
It's an Aeon Multisensor 6. There are 2 apps (on and off) with corresponding increase and decrease errors. Logs on way. Thanks for looking.
unfortunately humidity is dropping and I put the logging on the increase side but it still did this. I will capture a log going the other way in the morning (showers 
).
I need you to post a screenshot of a portion of the Application State from the App Status page. You get to the App Status page from the gear icon upper right on the app page, or to the left of the app on the Apps page. I need to see the value for "prevState".
I would suggest that you remove this rule, and recreate it. See if it misbehaves after that.
Thanks for sticking at this. First is the log showing the bug and that the rule is not triggered when the error occurs.
Happy to recreate but bear in mind there are 2 identical problem rules. both show the same issue.
I need to know the deviceId of the multi-sensor in the rule you posted the 'prevState' for. You can see that by opening its device page, it's the number in the URL.
That's not what I need. Look at the url in the browser, it has a number embedded in it. You showed the Device Network Id, but that's different. The device id is part of the url.
Sorry misunderstood. Ensuite Multisensor 161
I can see what's going on. That device evidently has reported "inactive" for currentHumidity. You can see that in 'prevState' for device 161. The comparison of 75 > "inactive' obviously fails, and that causes this error. The rule is pulling up device.currentHumidity each time it is triggered by that one trigger, and that value is getting stored in prevState.
Please try a test. Create a rule with only the single trigger, not four of them, with just the Humidity increased (or decreased) trigger. See if that works or not. This may be a driver bug, but it's hard for me to tell, but the fact that you also have it triggered by Ensuite Multisensor motion active suggests that might be the case.
Actually, I wonder if the rule did this some how in processing the motion trigger -- that's a possibility also, and that would be a bug in RM.
Here's the events, well the top.
Creating test rule
Thanks. I'm pretty sure this is a bug caused by the multi-sensor and the way Rule 5.1 handles keeping the previous value (for things like changed, increased, decreased). Clearly what happened is that it stored away the 'inactive' from a motion event, and then mistakenly tried to use that in a humidity comparison.
The fix is actually quite simple, and I will get it into the next release.
A work-around in the meantime is to use your new rule, that only has the humidity trigger to run the actions of your other rule (remove the humidity trigger from it). So you'll have two rules, one with only humidity, and the other with the other triggers. One set of actions only. Once the next release comes out, you can go back to the way you had it.
1 Like
brilliant. thanks for taking the trouble. I will set that up.
Actually, it's the combination of 'motion stays' and 'humidity increased' that did it. I'm testing to confirm, but here's my prevState:
The next temperature report from this multi-sensor will attempt to compare the temperature to "inactive", and that should fail (using released version).
Now I need an identical rule with the fix in place, and test it the same way.
Here is the error from the released Rule 5.1 rule, followed by the absence of error from the fixed version of the same rule:
And finally, here is the prevState for the multisensor in the fixed version, where now it is keeping track of Temperature and motion separately, so no more mixups and attempts to compare numbers to strings:
It's not that cool here, I used an ice cube to push the temperature down for testing. 
you're on ice cubes. I'm juggling showers and fans 
cloned existing rules and adjusted triggers so humidity is seperated out.
sadly still get this
