Enum to String comparison difference

rfs · 2017-12-21 06:37:16 UTC

1) Give a description of the problem
Lights should only turn on if motion in the living room is followed by motion on the stairs, but it appears a string-to-enum comparison is failing even though the values match.

2) What is the expected behavior?
Enum “active” = String “active”

3) What is happening/not happening?
+207ms ║║Comparison (enum) active changes_to (string) active = false (0ms)

4) Post a Green Snapshot of the piston

5) Attach any logs (From ST IDE and by turning logging level to Full)
12/20/2017, 10:27:47 PM +686ms
+1ms ╔Received event [Living Room Motion Sensor].motion = inactive with a delay of 193ms
+180ms ║RunTime Analysis CS > 17ms > PS > 53ms > PE > 111ms > CE
+183ms ║Runtime (43187 bytes) successfully initialized in 53ms (v0.2.100.20171211) (180ms)
+183ms ║╔Execution stage started
+195ms ║║Comparison (enum) off is (string) off = true (1ms)
+196ms ║║Condition #17 evaluated true (9ms)
+199ms ║║Comparison (enum) inactive changes_to (string) active = false (0ms)
+201ms ║║Condition #6 evaluated false (3ms)
+201ms ║║Condition group #3 evaluated false (state did not change) (14ms)
+205ms ║║Cancelling statement #14’s schedules…
+208ms ║║Executed virtual command setState (0ms)
+209ms ║╚Execution stage complete. (26ms)
+210ms ╚Event processed successfully (210ms)
12/20/2017, 10:27:40 PM +982ms
+0ms ╔Received event [Upstairs Motion Sensor].motion = inactive with a delay of 101ms
+144ms ║RunTime Analysis CS > 12ms > PS > 27ms > PE > 105ms > CE
+146ms ║Runtime (43184 bytes) successfully initialized in 27ms (v0.2.100.20171211) (145ms)
+147ms ║╔Execution stage started
+158ms ║║Comparison (enum) off is (string) off = true (1ms)
+159ms ║║Condition #17 evaluated true (8ms)
+166ms ║║Condition #6 evaluated false (6ms)
+167ms ║║Condition group #3 evaluated false (state did not change) (15ms)
+170ms ║║Cancelling statement #14’s schedules…
+173ms ║║Executed virtual command setState (1ms)
+175ms ║╚Execution stage complete. (28ms)
+176ms ╚Event processed successfully (176ms)
12/20/2017, 10:27:25 PM +956ms
+1ms ╔Received event [Upstairs Motion Sensor].motion = active with a delay of 98ms
+145ms ║RunTime Analysis CS > 14ms > PS > 26ms > PE > 105ms > CE
+148ms ║Runtime (43181 bytes) successfully initialized in 26ms (v0.2.100.20171211) (147ms)
+149ms ║╔Execution stage started
+159ms ║║Comparison (enum) off is (string) off = true (1ms)
+161ms ║║Condition #17 evaluated true (7ms)
+167ms ║║Condition #6 evaluated false (5ms)
+168ms ║║Condition group #3 evaluated false (state did not change) (16ms)
+172ms ║║Cancelling statement #14’s schedules…
+174ms ║║Executed virtual command setState (0ms)
+176ms ║╚Execution stage complete. (28ms)
+177ms ╚Event processed successfully (176ms)
12/20/2017, 10:27:17 PM +595ms
+1ms ╔Received event [Living Room Motion Sensor].motion = active with a delay of 104ms
+178ms ║RunTime Analysis CS > 14ms > PS > 55ms > PE > 109ms > CE
+180ms ║Runtime (43182 bytes) successfully initialized in 55ms (v0.2.100.20171211) (179ms)
+181ms ║╔Execution stage started
+193ms ║║Comparison (enum) off is (string) off = true (1ms)
+194ms ║║Cancelling condition #17’s schedules…
+195ms ║║Condition #17 evaluated true (10ms)
+207ms ║║Comparison (enum) active changes_to (string) active = false (0ms)
+208ms ║║Cancelling condition #6’s schedules…
+209ms ║║Condition #6 evaluated false (5ms)
+210ms ║║Condition group #3 evaluated false (state did not change) (25ms)
+213ms ║║Cancelling statement #14’s schedules…
+216ms ║║Executed virtual command setState (0ms)
+217ms ║╚Execution stage complete. (36ms)
+218ms ╚Event processed successfully (219ms)

rfs · 2017-12-22 03:27:35 UTC

It’s odd… sometimes I see this enum:

+305ms	║║Comparison (enum) turningOn is (string) off = false (1ms)

and other times this one:

+207ms	║║Comparison (enum) active changes_to (string) active = false (0ms)

draftpunk · 2021-01-28 14:45:31 UTC

I’m seeing similar behavior from the motion sensor on my ecobee. Does anyone have any ideas as to what’s going on? Sometimes it will work correctly, but lately I’ve been seeing this log:

Comparison (enum) active changes_to (string) active = false (1ms)

orangebucket · 2021-01-28 18:25:51 UTC

That means that the value hasn’t changed since the trigger was last evaluated. The trigger believes the Motion Sensor was already active, so active to active is NOT a ‘change’.

Consider when the motion sensor was last inactive. When the piston ran, would it have got as far as this trigger? Or did something stop it? It has to evaluate the trigger otherwise it doesn’t see the inactive.

Watch for something like an only when restriction that is false, a previous condition in an and group being false, a previous condition being an or group being true, or the trigger being nested under another if that returned false.

As a simple example consider:

if
    time is between sunrise and sunset
  and 
    Motion Sensor motion changes to active
then
   ...
endif

Suppose the Motion Sensor state changes to inactive ten minutes before sunrise. The piston will run and evaluate time is between sunrise and sunset. That will be false and that means the whole and group will evaluate as false, so webCoRE will not evaluate the next condition as it will not affect the result (you can change this behaviour). This is bad news as the changes to trigger doesn’t know the Motion Sensor is now inactive.

Now consider:

if
    Motion Sensor motion changes to active
  and 
    time is between sunrise and sunset
then
   ...
endif

The logic is equivalent but this time the Motion Sensor trigger is always evaluated so the trigger knows it is inactive.

It may seem a bit strange to talk about the trigger not knowing that the attribute value has changed. However what you have to appreciate is that motion sensors, for example, don’t necessarily have to send events in the sequence inactive, active, inactive, active etc. They can send inactive, inactive, active, inactive, active, active, active etc. Although we often talk about pistons subscribing to ‘changes’ in attributes, we really just mean subscribing to a particular stream of events. SmartThings can also sometimes delay events and they can end up in a jumbled order. The triggers work with the events in the order they are actually received by the piston so they can’t even cross check with the actual state of devices. So they have to keep their own track of what is going on.