Conditions evaluating incorrectly

#41

ok. update now that I am back home.

Running the older version with the newer version string. No good. Conditions inconsistently evaluating. In addition, I see these long strings in the log - somewhere the code is confused for sure. Given more reports are on this thread wrt conditions evaluating incorrectly - do we have a pattern emerging that can be fixed?

@ipaterson - quick clarification - I don’t think the issue has to do with physical sensors only. In my case, pistons get called by other pistons and either evaluate physical or non-physical events incorrectly. Also it depends if you consider presence change as physical or programmatic in your code but there seems to be a cluster of issues surrounding incorrect evaluation of presence.

Do you still want me to paste the new code vs. github? Would this get you anywhere in troubleshooting the issues? Happy to do so unless there is a prevailing theory that needs a different set of testing activities?

9/6/2019, 3:20:47 PM +254ms
+1ms ╔Received event [Valerie K].presence = present with a delay of 105ms
+148ms ║RunTime Analysis CS > 27ms > PS > 68ms > PE > 52ms > CE
+151ms ║Runtime (42640 bytes) successfully initialized in 68ms (v0.3.10e.20190826) (149ms)
+152ms ║╔Execution stage started
+170ms ║║Comparison (enum) present changes_to (string) present = true (1ms)
+172ms ║║Cancelling condition #7’s schedules…
+173ms ║║Condition #7 evaluated true (17ms)
+178ms ║║Comparison (string) :49914fee05dd0ba22460bac202289976: is_not (string) :49914fee05dd0ba22460bac202289976: = false (2ms)
+180ms ║║Condition #20 evaluated false (6ms)
+181ms ║║Condition group #1 evaluated false (state did not change) (25ms)
+190ms ║╚Execution stage complete. (38ms)
+191ms ╚Event processed successfully (191ms)

#42

Small observation… The following statement is false, so webCoRE processed this correctly.

:49914fee05dd0ba22460bac202289976: is_not :49914fee05dd0ba22460bac202289976:

As far as:

98% of Device Handlers do not report any difference between physical or programmatic interactions… Because of this, I always choose “Any interaction”

temp

If I need to distinguish between the two, I use variables like seen here.

#43

I think he means the problem is with the " 49914fee05dd0ba22460bac202289976" itself.

I wish I would have copied more of what was happening in mine, because Time was showing in very long numbers at the time, longer than usual (something like “59865452158746625412654268715815425425”). Too bad I didn’t think to copy it.

This piston was working fine for nearly two years...now not working
#44

Thanks, that is what I was looking for. I haven’t gotten anywhere contacting ST about this but will try again. Please feel free to remain on the older version if it still works.

#45

I too have been seeing the long strings in the logs instead of names. I wasn’t sure if that’s how it had always been though.

#46

I started noticing this behavior a few days ago and found this thread. It seems to specifically impact one piston more than others. Over the weekend I “tickled” the piston and it started working fine again. Last night, same behavior returned. Piston is triggered but does not perform the evaluation. 9/16 it worked, the two 9/17 runs show no eval.

Shard is NA01

I have not tried rolling back to the previous version yet.

Log_snippet_debug
Log_snippet_debug.JPG561×804 99.7 KB

#47

Could also be related to this other thread…

#48

Good thought! I was wondering this too. Some of my evaluations and execution steps are just not (mostly) completing.

#49

Thanks. What I’m seeing doesn’t quite line up with that though. The pistons are being triggered based on an event, but the evaluation isn’t being done and this started a few days ago.

Not ruling it out and now could be a combo of this and the previous issue. The piston I notice it on the most is a virtual switch and boolean variable to change house mode. Both the state change of the switch and the variable trigger the piston, but the state of the variable and switch are not always evaluated.

#50

House is empty now so able to test.

Still haven’t rolled back to previous version, but conditions are being evaluated a little more reliably. Out of 5 tests, 4 worked.

#51

I’ve been having strange issues as well. Even with code from examples that many others are using and haven’t reported problems with previously. I’ve noticed several recent threads where people have reported similar issues.

I’ve also been having smartthings related cloud problems and have previously responded to the ‘Is webcore slow this morning (16 September, 2019)’ thread mentioned above. It’s been very frustrating. If I could figure out a way to make Alexa speak using Linux or Windows directly, I’d just move everything internal at this point.

#52

FWIW, I rolled the Webcore code back to June and I’m still experiencing the same intermittence . Piston always executes, but the evaluation doesn’t always happen.

#53

I haven’t had any issues since the new ST firmware went out a few days ago. So far so good.

Edit: spoke too soon. It’s crapping the bed again today

WebCoRE reliability issues