SOLVED - WebCore thinks light is on when it is not

#1

1) Give a description of the problem
WebCore keeps evaluating the Island light (White Bulb 3) as being on when it is not. I simplified a more complex piston to the attached.

2) What is the expected behaviour?
Turns Island light (White Bulb 3) on

3) What is happening/not happening?
Island light (White Bulb 3) does not turn on.

**4) Post a Green Snapshot of the piston!

image
image.png1178×466 43.4 KB

5) Attach logs after turning logging level to Full
2020-09-13, 7:40:29 a.m. +646ms
+0ms ╔Received event [Kitchen Light].switch = on with a delay of 39ms
+50ms ║RunTime Analysis CS > 15ms > PS > 27ms > PE > 8ms > CE
+52ms ║Runtime (36690 bytes) successfully initialized in 27ms (v0.3.110.20191009) (51ms)
+53ms ║╔Execution stage started
+61ms ║║Comparison (enum) on changes_away_from (string) off = true (0ms)
+62ms ║║Cancelling condition #2’s schedules…
+63ms ║║Condition #2 evaluated true (6ms)
+64ms ║║Cancelling condition #1’s schedules…
+65ms ║║Condition group #1 evaluated true (state changed) (8ms)
+67ms ║║Cancelling statement #3’s schedules…
+75ms ║║Skipped execution of physical command [Island Light].on([]) because it would make no change to the device. (4ms)
+76ms ║║Executed [Island Light].on (6ms)
+79ms ║╚Execution stage complete. (26ms)
+80ms ╚Event processed successfully (81ms)

#3

Have you tried to set command optimization to off? Webcore will send the command whatever it thinks the status is.

#5

Turned command optimization off which resulted in the following log but Island Light (White Bulb 3) didn’t turn on.

2020-09-13, 8:36:58 a.m. +340ms
+1ms ╔Received event [Kitchen Light].switch = on with a delay of 37ms
+46ms ║RunTime Analysis CS > 14ms > PS > 25ms > PE > 7ms > CE
+48ms ║Runtime (36725 bytes) successfully initialized in 25ms (v0.3.110.20191009) (46ms)
+49ms ║╔Execution stage started
+56ms ║║Comparison (enum) on changes_away_from (string) off = true (1ms)
+57ms ║║Cancelling condition #2’s schedules…
+58ms ║║Condition #2 evaluated true (5ms)
+59ms ║║Cancelling condition #1’s schedules…
+60ms ║║Condition group #1 evaluated true (state changed) (6ms)
+62ms ║║Cancelling statement #3’s schedules…
+70ms ║║Executed physical command [Island Light].on() (4ms)
+70ms ║║Executed [Island Light].on (6ms)
+72ms ║╚Execution stage complete. (23ms)
+73ms ╚Event processed successfully (73ms)

#6

Does it show as off in the app?

#7

Could the bulb be at the limit of the range? I’m not sure if the devices send a confirmation which is then acknowledged by ST.

Could you have removed/moved another device which has altered the range of the mesh networking? I lost control of a few devices when I moved a smart plug, and had to put it back just to maintain the network.

#8

OK so how is the bulb behaving when controlled directly from the ST app?

#9

Ended up resetting the switch to Factory Default, adding it back to smartthings and redoing the programming to solve the problem.