Conditions evaluating incorrectly


#1

I have close to 80 pistons running for many months without an issue. Since the latest Webcore update, most of them are failing and looking at the logs they are consistently failing on conditions that were working consistently well and suddenly are not.

Events are triggering correctly but the condition that is part of the event is evaluating false. This happens mostly when the trigger is generated by another piston (e.g. programmatically vs. physically). The two distinctions didn’t make much of a difference and all are set as ‘Any’ to catch both programmatic and physical changes.

An example for a conditional failing on a programmatic change of a switch (as said, I have many of these failing spontaneously) - The condition is triggering as Arm stay turns to on by another piston:

Received event [Arm Stay].switch = on with a delay of 86ms

at the same time, the comparison that is that trigger shows as evaluated false which is the oddest thing as the piston fired as a result of turning the switch to on.
The switch is confirmed to be on and the condition evaluates as false.

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

This is not a single occurrence. My house is a mess as nothing works as expected and despite triggers firing and pistons waking up, conditions get skipped all over the place. I tried deleting the cache several times. No change. Someone suggested creating a new instance and moving the pistons there but the backup/restore workflow is a one-by-one migration, does not seem to work right and at ~80 pistons is insane to go through.

All this was fine until the recent update - what gives?

Log for programmatic change showing evaluating as false (first) and physical change of same by pushing the button in the SmartThigns app (second):

I8/26/2019, 12:12:18 PM +557ms
+1ms ╔Received event [Arm Stay].switch = on with a delay of 86ms
+132ms ║RunTime Analysis CS > 22ms > PS > 67ms > PE > 42ms > CE
+134ms ║Runtime (44763 bytes) successfully initialized in 67ms (v0.3.10f.20190822) (133ms)
+135ms ║╔Execution stage started
+141ms ║║Comparison (enum) on changes_to (string) on = false (1ms)
+142ms ║║Cancelling condition #153’s schedules…
+143ms ║║Condition #153 evaluated false (4ms)
+144ms ║║Cancelling condition #80’s schedules…
+145ms ║║Condition group #80 evaluated false (state changed) (7ms)
+146ms ║╚Execution stage complete. (11ms)
+147ms ╚Event processed successfully (147ms)

‘Physical Change’

8/26/2019, 12:13:50 PM +821ms
+1ms ╔Received event [Arm Stay].switch = on with a delay of 88ms
+149ms ║RunTime Analysis CS > 21ms > PS > 76ms > PE > 51ms > CE
+151ms ║Runtime (44766 bytes) successfully initialized in 76ms (v0.3.10f.20190822) (149ms)
+152ms ║╔Execution stage started
+158ms ║║Comparison (enum) on changes_to (string) on = true (0ms)
+160ms ║║Cancelling condition #153’s schedules…
+160ms ║║Condition #153 evaluated true (4ms)
+161ms ║║Cancelling condition #80’s schedules…
+162ms ║║Condition group #80 evaluated true (state changed) (7ms)

Any ideas or similar experiences? I find it hard to believe I am the only one experiencing this behavior across a large set of pistons…


webCoRE Update v0.3.10f.20190822 - Custom headers on web requests by @Bloodtick_Jones, capability selection fix
Sonos tells me "door left open"
#2

I don’t know if this is where to post this, but I’ve been having an issue with Contact Sensors ever since this update was applied. Before this update, everything was fine and working as expected.

The ‘Closed’ state of the contacts is being ignored by WC. I’ve check ST, and they show as Closed, but the ‘changes to closed’ pistons are not firing off.

I’ve done so much testing the last 2 days, and I’m getting frustrated. I have contact sensors on the fridge and freezer (because my daughter seems to like to just push the doors when she’s walking away, and they don’t always close). I have pistons setup so that if the doors stay open for 2 minutes, do this, 3 minutes do that, but if the doors close, do nothing. I’ve had to PAUSE these pistons, because even though the doors are closing, the 2 minute and 3 minute pistons are still firing, and it’s because the ‘Closed’ is being ignored by WC.

Here’s just one example: Door opened, 3 people walked out, door closed.

8/25/2019, 9:28:21 PM +256ms
+1ms ╔Received event [Home].time = 1566782902614 with a delay of -1358ms
+161ms ║RunTime Analysis CS > 31ms > PS > 60ms > PE > 70ms > CE
+164ms ║Runtime (45604 bytes) successfully initialized in 60ms (v0.3.10f.20190822) (162ms)
+165ms ║╔Execution stage started
+191ms ║║Executed virtual command [Garage Auto Off].setVariable (1ms)
+201ms ║║Condition #31 evaluated false (6ms)
+203ms ║║Condition group #30 evaluated false (state did not change) (7ms)
+210ms ║║Condition #42 evaluated false (5ms)
+211ms ║║Condition group #41 evaluated false (state did not change) (6ms)
+213ms ║╚Execution stage complete. (48ms)
+214ms ╚Event processed successfully (214ms)
8/25/2019, 9:28:17 PM +136ms
+0ms ╔Received event [Home].time = 1566782898954 with a delay of -1819ms
+441ms ║RunTime Analysis CS > 30ms > PS > 45ms > PE > 367ms > CE
+444ms ║Runtime (45605 bytes) successfully initialized in 45ms (v0.3.10f.20190822) (443ms)
+445ms ║╔Execution stage started
+471ms ║║Skipped execution of physical command [Garage Auto Off].on([]) because it would make no change to the device. (4ms)
+472ms ║║Executed [Garage Auto Off].on (6ms)
+476ms ║║Executed virtual command [Garage Auto Off].wait (0ms)
+477ms ║║Requesting a wake up for Sun, Aug 25 2019 @ 9:28:22 PM EDT (in 5.0s)
+481ms ║╚Execution stage complete. (36ms)
+483ms ║Setting up scheduled job for Sun, Aug 25 2019 @ 9:28:22 PM EDT (in 4.996s)
+490ms ╚Event processed successfully (490ms)
8/25/2019, 9:28:13 PM +648ms
+2ms ╔Received event [Back Hall Door Sensor].contact = open with a delay of 210ms
+148ms ║RunTime Analysis CS > 30ms > PS > 64ms > PE > 54ms > CE
+150ms ║Runtime (45621 bytes) successfully initialized in 64ms (v0.3.10f.20190822) (148ms)
+151ms ║╔Execution stage started
+159ms ║║Comparison (enum) open changes_to (string) open = true (0ms)
+160ms ║║Cancelling condition #17’s schedules…
+161ms ║║Condition #17 evaluated true (6ms)
+162ms ║║Cancelling condition #16’s schedules…
+163ms ║║Condition group #16 evaluated true (state changed) (8ms)
+210ms ║║Comparison (time) 77293813 is_between (datetime) 1566730020000 … (datetime) 1566778380000 = false (6ms)
+211ms ║║Condition #18 evaluated false (46ms)
+212ms ║║Condition group #44 evaluated false (state did not change) (48ms)
+214ms ║║Cancelling statement #24’s schedules…
+228ms ║║Skipped execution of physical command [Garage Light 1].setLevel([100]) because it would make no change to the device. (7ms)
+229ms ║║Executed [Garage Light 1].setLevel (8ms)
+238ms ║║Skipped execution of physical command [Garage Light 2].setLevel([100]) because it would make no change to the device. (5ms)
+239ms ║║Executed [Garage Light 2].setLevel (7ms)
+248ms ║║Skipped execution of physical command [Garage Light 3].setLevel([100]) because it would make no change to the device. (6ms)
+248ms ║║Executed [Garage Light 3].setLevel (7ms)
+256ms ║║Skipped execution of physical command [Garage Light 4].setLevel([100]) because it would make no change to the device. (4ms)
+257ms ║║Executed [Garage Light 4].setLevel (5ms)
+265ms ║║Skipped execution of physical command [Garage Light 5].setLevel([100]) because it would make no change to the device. (6ms)
+266ms ║║Executed [Garage Light 5].setLevel (7ms)
+274ms ║║Skipped execution of physical command [Garage Light 6].setLevel([100]) because it would make no change to the device. (5ms)
+275ms ║║Executed [Garage Light 6].setLevel (6ms)
+283ms ║║Skipped execution of physical command [Garage Light 7].setLevel([100]) because it would make no change to the device. (6ms)
+284ms ║║Executed [Garage Light 7].setLevel (7ms)
+292ms ║║Skipped execution of physical command [Garage Light 8].setLevel([100]) because it would make no change to the device. (5ms)
+293ms ║║Executed [Garage Light 8].setLevel (7ms)
+296ms ║║Cancelling statement #46’s schedules…
+301ms ║║Executed virtual command [Garage Auto Off].setVariable (1ms)
+304ms ║║Executed virtual command [Garage Auto Off].wait (0ms)
+305ms ║║Requesting a wake up for Sun, Aug 25 2019 @ 9:28:18 PM EDT (in 5.0s)
+309ms ║╚Execution stage complete. (158ms)
+311ms ║Setting up scheduled job for Sun, Aug 25 2019 @ 9:28:18 PM EDT (in 4.996s)
+324ms ╚Event processed successfully (324ms)

Any help would be greatly appreciated.


webCoRE Update v0.3.10f.20190822 - Custom headers on web requests by @Bloodtick_Jones, capability selection fix
#3

The same thing as above is happening to Motion Sensors, the ‘Inactive’ is being ignored.

Example: 3 people moving through the garage, and then left the garage. ST reports as Inactive, but WC is ignoring the ‘changes to Inactive’.

8/25/2019, 10:10:14 PM +286ms
+0ms ╔Received event [Home].time = 1566785415464 with a delay of -1179ms
+155ms ║RunTime Analysis CS > 33ms > PS > 68ms > PE > 55ms > CE
+157ms ║Runtime (44977 bytes) successfully initialized in 68ms (v0.3.10f.20190822) (156ms)
+158ms ║╔Execution stage started
+181ms ║║Executed virtual command [Garage Auto Off].setVariable (1ms)
+192ms ║║Condition #17 evaluated false (8ms)
+193ms ║║Condition group #16 evaluated false (state did not change) (9ms)
+195ms ║╚Execution stage complete. (37ms)
+196ms ╚Event processed successfully (196ms)
8/25/2019, 10:10:10 PM +271ms
+0ms ╔Received event [Home].time = 1566785411868 with a delay of -1597ms
+160ms ║RunTime Analysis CS > 33ms > PS > 68ms > PE > 58ms > CE
+162ms ║Runtime (44977 bytes) successfully initialized in 68ms (v0.3.10f.20190822) (161ms)
+163ms ║╔Execution stage started
+187ms ║║Skipped execution of physical command [Garage Auto Off].on([]) because it would make no change to the device. (2ms)
+188ms ║║Executed [Garage Auto Off].on (4ms)
+192ms ║║Executed virtual command [Garage Auto Off].wait (0ms)
+193ms ║║Requesting a wake up for Sun, Aug 25 2019 @ 10:10:15 PM EDT (in 5.0s)
+197ms ║╚Execution stage complete. (34ms)
+198ms ║Setting up scheduled job for Sun, Aug 25 2019 @ 10:10:15 PM EDT (in 4.995s)
+206ms ╚Event processed successfully (206ms)
8/25/2019, 10:10:06 PM +556ms
+1ms ╔Received event [Garage Motion Detector].motion = active with a delay of 252ms
+151ms ║RunTime Analysis CS > 33ms > PS > 64ms > PE > 55ms > CE
+154ms ║Runtime (44996 bytes) successfully initialized in 64ms (v0.3.10f.20190822) (152ms)
+155ms ║╔Execution stage started
+162ms ║║Comparison (enum) active changes_to (string) active = true (1ms)
+163ms ║║Cancelling condition #2’s schedules…
+164ms ║║Condition #2 evaluated true (5ms)
+165ms ║║Cancelling condition #1’s schedules…
+166ms ║║Condition group #1 evaluated true (state changed) (7ms)
+215ms ║║Comparison (time) 79806724 is_between (datetime) 1566730020000 … (datetime) 1566778380000 = false (6ms)
+217ms ║║Condition #3 evaluated false (48ms)
+218ms ║║Condition group #37 evaluated false (state did not change) (49ms)
+220ms ║║Cancelling statement #14’s schedules…
+232ms ║║Skipped execution of physical command [Garage Light 1].setLevel([100]) because it would make no change to the device. (6ms)
+233ms ║║Executed [Garage Light 1].setLevel (7ms)
+242ms ║║Skipped execution of physical command [Garage Light 2].setLevel([100]) because it would make no change to the device. (6ms)
+243ms ║║Executed [Garage Light 2].setLevel (6ms)
+252ms ║║Skipped execution of physical command [Garage Light 3].setLevel([100]) because it would make no change to the device. (6ms)
+253ms ║║Executed [Garage Light 3].setLevel (8ms)
+261ms ║║Skipped execution of physical command [Garage Light 4].setLevel([100]) because it would make no change to the device. (5ms)
+262ms ║║Executed [Garage Light 4].setLevel (7ms)
+271ms ║║Skipped execution of physical command [Garage Light 5].setLevel([100]) because it would make no change to the device. (6ms)
+272ms ║║Executed [Garage Light 5].setLevel (8ms)
+279ms ║║Skipped execution of physical command [Garage Light 6].setLevel([100]) because it would make no change to the device. (4ms)
+280ms ║║Executed [Garage Light 6].setLevel (5ms)
+289ms ║║Skipped execution of physical command [Garage Light 7].setLevel([100]) because it would make no change to the device. (6ms)
+290ms ║║Executed [Garage Light 7].setLevel (7ms)
+299ms ║║Skipped execution of physical command [Garage Light 8].setLevel([100]) because it would make no change to the device. (5ms)
+299ms ║║Executed [Garage Light 8].setLevel (7ms)
+302ms ║║Cancelling statement #39’s schedules…
+307ms ║║Executed virtual command [Garage Auto Off].setVariable (1ms)
+310ms ║║Executed virtual command [Garage Auto Off].wait (1ms)
+311ms ║║Requesting a wake up for Sun, Aug 25 2019 @ 10:10:11 PM EDT (in 5.0s)
+315ms ║╚Execution stage complete. (160ms)
+316ms ║Setting up scheduled job for Sun, Aug 25 2019 @ 10:10:11 PM EDT (in 4.996s)
+326ms ╚Event processed successfully (327ms)


#4

I forgot to mention that these 2 pistons were working perfectly until the recent update.

Thank you!!


#5

Since there were no changes in the last release that seem in any way related, please try rolling back to the previous version so that we know whether the problem is in the code or the ST platform.


#6

I’ve rolled back. I will test and report back.


#7

The rollback seems to have fixed my issues.

Here is the same piston as my first post above, now working as expected:

8/26/2019, 9:58:16 PM +281ms
+0ms ╔Received event [Home].time = 1566871097415 with a delay of -1134ms
+152ms ║RunTime Analysis CS > 24ms > PS > 62ms > PE > 66ms > CE
+155ms ║Runtime (46948 bytes) successfully initialized in 62ms (v0.3.10e.20190628) (154ms)
+156ms ║╔Execution stage started
+369ms ║║Executed physical command [Garage Auto Off].off() (182ms)
+370ms ║║Executed [Garage Auto Off].off (184ms)
+376ms ║║Skipped execution of physical command [Garage Auto Off Half].off([]) because it would make no change to the device. (4ms)
+377ms ║║Executed [Garage Auto Off Half].off (6ms)
+385ms ║║Condition #42 evaluated false (5ms)
+386ms ║║Condition group #41 evaluated false (state did not change) (7ms)
+388ms ║╚Execution stage complete. (232ms)
+390ms ╚Event processed successfully (389ms)
8/26/2019, 9:48:17 PM +200ms
+2ms ╔Received event [Back Hall Door Sensor].contact = closed with a delay of 1649ms
+166ms ║RunTime Analysis CS > 23ms > PS > 72ms > PE > 70ms > CE
+169ms ║Runtime (46960 bytes) successfully initialized in 72ms (v0.3.10e.20190628) (166ms)
+170ms ║╔Execution stage started
+178ms ║║Comparison (enum) closed changes_to (string) open = false (0ms)
+180ms ║║Cancelling condition #17’s schedules…
+181ms ║║Condition #17 evaluated false (6ms)
+182ms ║║Condition group #16 evaluated false (state did not change) (7ms)
+189ms ║║Comparison (enum) closed changes_to (string) open = false (1ms)
+191ms ║║Cancelling condition #59’s schedules…
+192ms ║║Condition #59 evaluated false (6ms)
+193ms ║║Cancelling condition #58’s schedules…
+194ms ║║Condition group #58 evaluated false (state changed) (9ms)
+200ms ║║Comparison (enum) closed changes_to (string) closed = true (1ms)
+202ms ║║Cancelling condition #31’s schedules…
+203ms ║║Condition #31 evaluated true (6ms)
+204ms ║║Cancelling condition #30’s schedules…
+205ms ║║Condition group #30 evaluated true (state changed) (8ms)
+208ms ║║Cancelling statement #32’s schedules…
+213ms ║║Executed virtual command [Garage Auto Off, Garage Auto Off Half].wait (1ms)
+215ms ║║Requesting a wake up for Mon, Aug 26 2019 @ 9:58:17 PM EDT (in 600.0s)
+220ms ║╚Execution stage complete. (51ms)
+221ms ║Setting up scheduled job for Mon, Aug 26 2019 @ 9:58:17 PM EDT (in 599.994s)
+235ms ╚Event processed successfully (235ms)
8/26/2019, 9:48:07 PM +258ms
+0ms ╔Received event [Home].time = 1566870488272 with a delay of -1014ms
+296ms ║RunTime Analysis CS > 30ms > PS > 61ms > PE > 205ms > CE
+299ms ║Runtime (46945 bytes) successfully initialized in 61ms (v0.3.10e.20190628) (298ms)
+300ms ║╔Execution stage started
+324ms ║║Executed virtual command [Garage Auto Off].setVariable (0ms)
+333ms ║║Condition #31 evaluated false (6ms)
+334ms ║║Condition group #30 evaluated false (state did not change) (8ms)
+341ms ║║Condition #42 evaluated false (5ms)
+342ms ║║Condition group #41 evaluated false (state did not change) (6ms)
+344ms ║╚Execution stage complete. (44ms)
+345ms ╚Event processed successfully (345ms)
8/26/2019, 9:48:03 PM +109ms
+0ms ╔Received event [Home].time = 1566870484038 with a delay of -930ms
+127ms ║RunTime Analysis CS > 24ms > PS > 50ms > PE > 54ms > CE
+130ms ║Runtime (46943 bytes) successfully initialized in 50ms (v0.3.10e.20190628) (129ms)
+131ms ║╔Execution stage started
+157ms ║║Skipped execution of physical command [Garage Auto Off].on([]) because it would make no change to the device. (3ms)
+158ms ║║Executed [Garage Auto Off].on (5ms)
+161ms ║║Executed virtual command [Garage Auto Off].wait (1ms)
+162ms ║║Requesting a wake up for Mon, Aug 26 2019 @ 9:48:08 PM EDT (in 5.0s)
+166ms ║╚Execution stage complete. (35ms)
+167ms ║Setting up scheduled job for Mon, Aug 26 2019 @ 9:48:08 PM EDT (in 4.996s)
+175ms ╚Event processed successfully (175ms)
8/26/2019, 9:47:58 PM +806ms
+1ms ╔Received event [Back Hall Door Sensor].contact = open with a delay of 106ms
+105ms ║RunTime Analysis CS > 16ms > PS > 40ms > PE > 49ms > CE
+108ms ║Runtime (46962 bytes) successfully initialized in 40ms (v0.3.10e.20190628) (106ms)
+109ms ║╔Execution stage started
+115ms ║║Comparison (enum) open changes_to (string) open = true (1ms)
+116ms ║║Cancelling condition #17’s schedules…
+117ms ║║Condition #17 evaluated true (5ms)
+126ms ║║Comparison (time) 78478924 is_between (time) 28800000 … (time) 66600000 = false (6ms)
+127ms ║║Condition #18 evaluated false (9ms)
+128ms ║║Condition group #16 evaluated false (state did not change) (16ms)
+133ms ║║Comparison (enum) open changes_to (string) open = true (1ms)
+134ms ║║Cancelling condition #59’s schedules…
+135ms ║║Condition #59 evaluated true (5ms)
+144ms ║║Comparison (time) 78478942 is_between (time) 66600000 … (time) 28800000 = true (6ms)
+145ms ║║Time restriction check passed
+146ms ║║Condition #60 evaluated true (10ms)
+147ms ║║Cancelling condition #58’s schedules…
+148ms ║║Condition group #58 evaluated true (state changed) (18ms)
+150ms ║║Cancelling statement #24’s schedules…
+161ms ║║Skipped execution of physical command [Garage Light 1].setLevel([100]) because it would make no change to the device. (5ms)
+162ms ║║Executed [Garage Light 1].setLevel (7ms)
+169ms ║║Skipped execution of physical command [Garage Light 2].setLevel([100]) because it would make no change to the device. (5ms)
+170ms ║║Executed [Garage Light 2].setLevel (6ms)
+177ms ║║Skipped execution of physical command [Garage Light 3].setLevel([100]) because it would make no change to the device. (5ms)
+178ms ║║Executed [Garage Light 3].setLevel (6ms)
+186ms ║║Skipped execution of physical command [Garage Light 4].setLevel([100]) because it would make no change to the device. (6ms)
+187ms ║║Executed [Garage Light 4].setLevel (8ms)
+196ms ║║Skipped execution of physical command [Garage Light 5].setLevel([100]) because it would make no change to the device. (7ms)
+197ms ║║Executed [Garage Light 5].setLevel (8ms)
+204ms ║║Skipped execution of physical command [Garage Light 6].setLevel([100]) because it would make no change to the device. (4ms)
+204ms ║║Executed [Garage Light 6].setLevel (6ms)
+213ms ║║Skipped execution of physical command [Garage Light 7].setLevel([100]) because it would make no change to the device. (6ms)
+213ms ║║Executed [Garage Light 7].setLevel (7ms)
+220ms ║║Skipped execution of physical command [Garage Light 8].setLevel([100]) because it would make no change to the device. (5ms)
+221ms ║║Executed [Garage Light 8].setLevel (6ms)
+223ms ║║Cancelling statement #61’s schedules…
+227ms ║║Executed virtual command [Garage Auto Off].setVariable (1ms)
+230ms ║║Executed virtual command [Garage Auto Off].wait (1ms)
+231ms ║║Requesting a wake up for Mon, Aug 26 2019 @ 9:48:04 PM EDT (in 5.0s)
+234ms ║╚Execution stage complete. (126ms)
+236ms ║Setting up scheduled job for Mon, Aug 26 2019 @ 9:48:04 PM EDT (in 4.997s)
+244ms ╚Event processed successfully (244ms)

Wait!!! Let me put it back to it’s original state. I forgot that I was re-working these pistons, trying to make things work.

I will put it back as my first post, and test again.

But, I must point out, that even with this change, it was not firing on ‘changes to closed’.


#8

I have to point out, that I am not the original poster. I do not know if this rollback has/will fix the issues in the original post.


#9

Thanks! Tomorrow I’m going to review a past issue that we had with the platform that required the smart app version to be updated despite not having any code changes.

If you are still willing to tinker with the code… please try, without making any changes to the actual code, just changing the version number on that previous version. For example, you might change the four smart apps from version = function() { return 'v0.3.10e.20190628'; }; to today’s date version = function() { return 'v0.3.10e.20190826'; }; followed by save and publish – I am curious whether the change is related to code in the new version or to the platform caching based on the old version number.


#10

I reverted the code back to it’s original setup, and tested again. Perfect!! This solved the Contacts issues, and the Motion Detection issues.

I am happy again… I will be Resuming the pistons that I Paused because of this issue.

Thank you!!!

Again, just want to point out that I am not the original poster, and am curious to see if this solves their issues as well.


#11

I’m very curious to know if the difference is caused by the code or by the version number. If you have a tolerance for some brief mayhem please test changing just the version number as described in the previous reply.


#12

I just finished changing the version number.

Got some warnings on some Pistons that fired in the middle of the change:

WARNING: Results may be unreliable because the parent app’s version (v0.3.10e.20190826) is newer than the child app’s version (v0.3.10e.20190628). Please consider updating both apps to the same version.

This will fix itself.

But, the most curious thing: The Home page of WC is now stating that a new version is available: v0.3.10f.20190822… which is in the past.

Never mind. The message went away.

I will continue monitoring.

More weirdness… I just started to create a new piston to replace one that I deleted.

image

The UI Version is wrong, and the Build is showing 0.


#13

Thanks for all the activity. I won’t be able to roll back / play with the version numbers until late tomorrow (Central Time) due to some work commitments. Seems like the other posters on this thread are experiencing similar weirdness whether it is because of the code change or something with ST. I will continue to monitor the thread throughout the day but as mentioned won’t have enough time to properly go through the motions until later in the day / evening.


#14

The UI version and warnings shown in the dashboard are from the web app version which is hosted at dashboard.webCoRE.co. I should have mentioned that those warnings are expected.

The build version on a piston is the number of times you’ve edited it since the initial save.


Conditions fail
#15

Also possibly relevant to this discussion, which ST shard is your account on? Please share the web address of the “SmartThings Groovy IDE” page after you log in to account.smartthings.com. I haven’t had any luck reproducing this issue with contact sensors or switches on the graph.api.smartthings.com shard.


#16

As far as for me, today, a piston that was executing another piston on a daily basis @ 6:30AM ran as per its timed event and conditions met. It reports in the log that it was indeed executing the second piston as it should have. The second piston however never ran (it has no starting condition, it’s just a plain scene routine). The Last Run timestamp on that second piston shows its last run date was yesterday @ 6:30AM despite having been called by the first piston. Unclear why it wasn’t invoked as per the log in the first piston - no changes have occured to any of these pistons in many many months.

I’ve been tinkering with the others reported at the beginning of the post for too long of a time trying to figure them out but otherwise let the entire library of my piston be be until there is a conclusion here on the issue.

Something is definitely off since the last update whether it is a caching issue, a WC or ST issue - I just can’t put my finger on it and as mentioned seems to do both with invocation as well as with conditions that should evaluate to true, suddenly not evaluating correctly.

My shard: https://graph-na04-useast2.api.smartthings.com/


#17

My shard: https://graph-na04-useast2.api.smartthings.com/


#18

OK. I rolled back to the older version (v0.3.10e.20190628) as suggested. Will report back in 24 hours of any impressions / changes. Thanks


#19

For a data point. I had some screwy behavior last week with webCoRE not properly running pistons near the upgrade timing. Randomly I just went in a cleared the ‘clean up and rebuild data cache’ from the IOS app and that apparently fixed the problem. Has been good since.


#20

Thanks for the tip @Bloodtick_Jones - I have cleared the cache several times over - no change to the erratic behavior I am experiencing since the update with conditions that should evaluate as true, are evaluated incorrectly as per the original post.