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.
1 Like
Oops. Sorry. I thought I was being helpful, instead I was confusing. Should have waited for the actual person to respond.
1 Like
Meh... you could probably say the same about me 
. Will leave Bruce and Brad to work it out.
2 Likes
The one I’m using with the trigger issue is:
1 Like
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.
2 Likes
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?
And it seems like the same issue, power being reported as string
I did some more digging, and in the custom driver I posted above, it looks like an attribute for wind_gust may be missing, so is it possible that upon trigger creation the “null” value is being produced due to a lack of attribute type being specified?
Not sure how that explains my thermostat test initially, but I did try that one again and am now getting the big decimal same as you.
1 Like
Are you using Custom Attribute for these? That could explain the problem. I believe Custom Attribute defaults to String, but I'll have to check. The driver must define the correct type for the attribute.
Same problem here. I modified a rule, changing it from triggering on changed temperature to increased by 1 temperature.
C8 on 2.3.6.144
Samsung Zigbee button using built in Samsung Zigbee button driver.
Edit:
my application state is different.
NAME p.130:temperature TYPE java.math.BigDecimal VALUE 68.17
NAME p.PB TYPE String VALUE true
Error Log entry: invalid operand type for 68.17(number) decreased by over 1.0(number)
Are you using Custom Attribute?
Yep. Isn’t that the only way to add wind_gust since it can’t be aligned to a standard attribute in HE?
Since I don’t know what that is, I’m going with no. 
