Number Comparison results wrong all of a sudden

#1

This piston has been executing successfully for years, all of a sudden it is not evaluating correctly, pertinent section bolded.

3/23/2022, 12:27:53 PM +404ms
+0ms ╔Received event [Thermostat].temperature = 72 with a delay of 112ms
+72ms ║RunTime Analysis CS > 21ms > PS > 6ms > PE > 46ms > CE
+75ms ║Runtime (40475 bytes) successfully initialized in 6ms (v0.3.114.20220203) (73ms)
+76ms ║╔Execution stage started
+89ms ║║Comparison (enum) on is (string) on = true (1ms)
+90ms ║║Condition #21 evaluated true (10ms)
+91ms ║║Cancelling condition #15’s schedules…
+92ms ║║Condition group #15 evaluated true (state changed) (13ms)
+96ms ║║Comparison (decimal) 72.0 rises_to_or_above (integer) 71 = false (1ms)
+97ms ║║Condition #17 evaluated false (4ms)
+98ms ║║Cancelling condition #15’s schedules…
+99ms ║║Condition group #15 evaluated false (state changed) (6ms)
+103ms ║║Comparison (decimal) 72.0 drops_to_or_below (integer) 69 = false (1ms)
+105ms ║║Condition #18 evaluated false (4ms)
+106ms ║║Condition group #16 evaluated false (state did not change) (5ms)
+107ms ║╚Execution stage complete. (32ms)
+108ms ╚Event processed successfully (109ms)

#2

Was there a driver update?

#3

So what was the value the previous time the comparison was evaluated? Without knowing that we can’t tell what the error is.

#4

not sure, it is a “Honeywell Home Total Connect Comfort” thermostat which shows a type of “placeholder”, I guess it is all cloud based?

#5

the value the previous time was 71.0 which should have evaluated to true as well, but did not.
Seems like it has clicked back into gear and is working again without any changes from me.

3/23/2022, 3:03:02 PM +593ms
+1ms ╔Received event [Thermostat].temperature = 71 with a delay of 95ms
+146ms ║RunTime Analysis CS > 93ms > PS > 11ms > PE > 41ms > CE
+148ms ║Runtime (40477 bytes) successfully initialized in 11ms (v0.3.114.20220203) (146ms)
+149ms ║╔Execution stage started
+160ms ║║Comparison (enum) on is (string) on = true (1ms)
+161ms ║║Condition #21 evaluated true (8ms)
+162ms ║║Cancelling condition #15’s schedules…
+163ms ║║Condition group #15 evaluated true (state changed) (11ms)
+167ms ║║Comparison (decimal) 71.0 rises_to_or_above (integer) 71 = true (1ms)
+168ms ║║Cancelling condition #17’s schedules…
+169ms ║║Condition #17 evaluated true (5ms)
+170ms ║║Condition group #15 evaluated true (state did not change) (6ms)
+172ms ║║Cancelling statement #22’s schedules…
+197ms ║║Executed physical command [Flame].off() (22ms)
+197ms ║║Executed [Flame].off (23ms)
+199ms ║╚Execution stage complete. (51ms)
+200ms ╚Event processed successfully (200ms)

Thanks for attempting to debug, I guess we can just mark it as a glitch in the matrix and move on.

#6

Just guessing here that the driver was updated to output values in decimal when it was integer before. Have you tried to change your comparison value to decimal also?

#7

If that is the case then the comparison in the logs in the original post was correct.

In order for ‘rises to or above 71’ to be true the piston must be processing a temperature event, the value in the event must 71 or more, and the previous time the comparison was evaluated for a temperature event it must have been less than 71. So false was correct as the temperature was already at the threshold before the latest reading.

So you then have to consider why the previous instance 71 was also considered false.

There is a ‘gotcha’ here. Suppose the piston logic is something like:

If switch S is on
And temperature T rises to or above 71

And the sequence of events is:

T 71 (S on)
T 70 (S off)
T 71 (S on)

The trigger condition would not be reached in the second case (the AND is already false so the default behaviour is not to bother with the second condition) so as far as the condition is concerned the events are:

T 71
T 71

The temperature did rise to or above 71 but the comparison didn’t know.

So yes there may have been a glitch but you do also have to consider if there are circumstances where the trigger condition wouldn’t get evaluated, such as short circuited ANDs (first condition false) or ORs (first condition true) or nested conditions, and it could make a difference. You may have discovered a ‘never normally happens’ combination just did happen.