I started receiving "invalid operand type" on "increased by over" and "decreased by over" triggers on a rule machine trigger. I haven't recently changed anything on the app, so not sure what's going on. I tried editing the trigger and re-saving, and that worked, so it's valid, but still receiving the error. I can delete and recreated the triggers, but I thought @bravenel might want to look at it before I do to see if it's a bug.
Here's my config and logs:
Are you on the latest hub platform version? This sounds like a previously discovered issue, though I can't recall if the last update was released before or after the fix was made (if not, should be the next one).
Thanks. Yep, sorry forgot to include. I’m on 2.3.6.144. Maybe the fix hasn’t been applied yet… no confirmation in that post.
Maybe you need to open and save the rule? Not sure if this is required, just a thought...
@JD0691 confirmed .144 fixed the issue in his case:
Thanks for the suggestion. Tried that again to no avail
Hmmm... That is odd...
@bravenel - Could there be something else going on here? Compared to the fix that was included in 2.3.6.144?
I don't know what would cause this, and can't reproduce it. I suggest you recreate that rule, and let us know if it still throws the error or not.
I was able to reproduce it just now in a new rule, using my EcoWitt weather station (I'm assuming not the same driver @brad is using). This rule is setup on a C-7 running 2.3.6.144. The windGust attribute in the driver is defined as a number.
I get the same behaviour using a virtual temperature sensor and triggering on the temperature attribute increasing by 1 or 1.5 (in case inclusion of a decimal place was important). Both scenarios with the temperature sensor produce the invalid operand error.
I tried to fix by recreating the triggers, but still happening. I’ll have to rebuild the rule.
Actually using OpenWeatherMap-Alerts Weather Driver which reports the value as a decimal
I suspect this may not work either, based on my experience. That said, still worth doing to get another test result, and ultimately the one that matters in this case 
Yep, I was also using attributes that recorded decimals.
Is this a community driver? If so, please provide a link to it.
That's the one I was using, not @brad . But I did experience the same error with the ecowitt driver. I also saw it using the built-in virtual temperature sensor.
Oops. Sorry. I thought I was being helpful, instead I was confusing. Should have waited for the actual person to respond.
Meh... you could probably say the same about me 
. Will leave Bruce and Brad to work it out.
The one I’m using with the trigger issue is:
Definitely something going on here. I recreated the rule, and still receiving the errors.
I also created a new virtual thermostat and rule to see if I could reproduce the behaviour there also same as @sburke781, and I was able. See that rule and logs below. It looks like the first event/trigger after the rule initilizes is fine, but subsequent ones don't work. I tried a number of varying triggers with decimals, numbers, variable instead of constants, different values... and they all fail after the first trigger. Of note, though, oddly 2 of the triggers are throwing 2 errors.
This is baffling, as I am not able to get this behavior at all.
Please show me the Application State for objects beginning with "p", from App Status page.
Interesting. The virtual thermostat rule is reporting the temp as a string. Assuming this is the issue.
This is the app that uses wind_gust. Looks like this one is null.
I created both of these rules new from scratch, so not how they got like this.
Those are both problematic. The virtual thermostat with a string value, obviously cannot be compared to a number, and the null attribute for device 519.
Here is what I get for a virtual thermostat:
I'm going to did some more as to how you could get what you're showing.
For the device 519 case, what is the attribute?
Download the Hubitat app
