@ipaterson - things seem to be working fine with the downgraded code and both with its authentic version as well as post bumping the version numbers to 826.
Not sure what the next steps are with respect to the newly released code that was malfunctioning?
Thanks much.
So, I’ve decided to keep 822. Even though I don’t like the fact that I had to split a lot of my pistons into 2 or more to accomplish the same things that a single piston did in 628.
Please keep me posted on the research/outcome of this.
Thanks!
If it helps, I have been struggling over the past few weeks with conditions being evaluated false even though they were true. I was struggling with one of my locations modes specifically (it would change to Away, and WC would trigger on the change, but the condion LM = Away would evaluate false).
I could get it working for a few hours by editing the name of the LM in the IDE or using the rebuild cache button, but nothing stuck. I ended up tracing it back to what i thought was causing it: the problem popped up when i installed a copy of the new app on my phone to add some hardware that needed to be added in that app. Not until i uninstalled the new app did my problems go away.
Only other change i had around that time was that i mistakenly deleted the Hello, Home smartapp. I restored it around the same time i uninstalled the new app and everything stabilized.
@smurf236 @dejavux2 thanks for sticking with me here. No luck tracing any logical connection between the code changes and this issue. You’re absolutely fine now to run on an older version; the only code change affecting pistons was just to add a new feature on web requests. The next release currently in the works was going to be a mandatory update but this is good motivation to ensure that it is backwards compatible.
I believe the next step is to rule out some sort of GitHub update issue that could have affected you both on NA04. If either of you are feeling adventurous, trying updating to the latest release by pasting the code rather than going through the ST update mechanism.
I was made aware of a problem with filtering events on physical vs programmatic interaction that can be fixed in the next update, but that seems to be a bug that has always existed. Since the issue in this thread affected contact sensors which are physical only I do not suspect it is related to the interaction filter.
Hmm. All interesting stuff.
I am traveling tomorrow until Friday so don’t roll forward until I am back or else the wife and kids will be in a limbo state where the house is doing whatever it wants without me helping out.
AFAIK issue is only related to conditions evaluating incorrectly and it does seem to be evaluating incorrectly on a programmatic basis not physical events.
Sensors are slightly delayed more than usual but were never they are reported by @dejavux2 on the same thread but I think may be a separate issue than mine under the same post?
@andynbaker’s theory is interesting. I don’t know if it has merit on this issue or not but I too installed the new app a couple of weeks ago. Haven’t used it beyond initial login process but it certainly is worth exploring as the cause? I did notice in the IDE when you go to edit a device that now in the drop down that was always empty in the bottom, it now says “Living Room” instead of being blank (and in the past had no options to select from). Seems that the new app is using that field of the device attributes to populate the room association. Perhaps this field is referenced by webcore or other and as such some of the logic in the actual code fails? I hear you saying nothing in the current version should have caused this to happen so looking at external factors that may have caused this and this theory seems worth pursuing.
Again, won’t be able to test the rolled forward code but have removed the new SmartThings connect app (seems useless) from my phone and will look for device handlers for things I wanted to explore that are supported by the new app (TP Link Kasa) next week when I return back home.
Perhaps there are others that can test the effects of the new app on webcore but it seems like I wouldn’t be the first one to have attempted it amongst the entire user base.
Thanks for sticking with us as well. I know this may be an isolated set of incidents but the health of webcore is important to us / me and tour attention and perseverance is very much appreciated.
Avi
Just FYI:
I just went through ST, and I’ve already had group names in the “Group” dropdown, so I’m not sure if that would effect it or not.
I have not installed any new apps.
To add to the confusion, I’ve started having issues with the following piston.
The logs say it executed, but it doesn’t actually change the variable from “YES” to “NO”.
I have to actually activate the button myself for the variable to change.
I think this is more along the lines of what’s happening to @smurf236.
It evaluated as True, said it executed, but it actually did not.
9/2/2019, 5:59:59 AM +969ms
+1ms ╔Received event [Door Announce 01].switch = off with a delay of 322ms
+133ms ║RunTime Analysis CS > 32ms > PS > 66ms > PE > 36ms > CE
+135ms ║Runtime (41191 bytes) successfully initialized in 66ms (v0.3.10f.20190822) (133ms)
+136ms ║╔Execution stage started
+143ms ║║Comparison (enum) off changes_to (string) on = false (1ms)
+144ms ║║Cancelling condition #2’s schedules…
+145ms ║║Condition #2 evaluated false (5ms)
+146ms ║║Cancelling condition #1’s schedules…
+147ms ║║Condition group #1 evaluated false (state changed) (7ms)
+152ms ║║Comparison (enum) off changes_to (string) off = true (1ms)
+153ms ║║Cancelling condition #6’s schedules…
+154ms ║║Condition #6 evaluated true (5ms)
+155ms ║║Cancelling condition #5’s schedules…
+156ms ║║Condition group #5 evaluated true (state changed) (7ms)
+158ms ║║Cancelling statement #7’s schedules…
+165ms ║║Executed virtual command [Echo - Mina’s Room].setVariable (0ms)
+325ms ║║Executed physical command [Echo - Mina’s Room].setLevel([50]) (157ms)
+326ms ║║Executed [Echo - Mina’s Room].setLevel (158ms)
+328ms ║╚Execution stage complete. (192ms)
+329ms ╚Event processed successfully (330ms)
I also had my location mode issue happen again today when I left the house. Some days it triggers and evaluates true, and others not. In the logs, I saw similar to above where the triggering event was clearly “true” - in my case it was location mode changed to away. But further down in the logs it evaluates the trigger as false when it gets to it.
I ended up just rewriting the trigger around presence for now.
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)
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”
If I need to distinguish between the two, I use variables like seen here.
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.
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.
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.
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.
Good thought! I was wondering this too. Some of my evaluations and execution steps are just not (mostly) completing.
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.
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.
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.
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.
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
