Conditions evaluating incorrectly

#21

Roger that. I did clear a bunch of logging I forgot I had on too - and walked each piston to make sure I didn’t have funny things floating around. I am sure it doesn’t help with new hub 27.6 firmware apparently breaking port 39500 for IP communications.

#22

@dejavux2, thanks. Do you have any results from testing the version change? I want to understand whether this was a problem with the new code or with updating in general.

#23

After rolling back, everything started working as expected. I did have a couple of misfires, but nothing major.

#24

Just an FYI:

I tried to run the cleanup, but all I get is “Something’s Wrong, we can’t load your screen right now”.

Never mind… after trying again, I got “Success!”

#25

Early results on my end are that the version rollback (actual code not just version number change on new code) seems to resolve the issues experienced. Not all the misevaluated conditions / pistons had a chance of running but the few that did seem to have completed successfully.

#26

After rolling back you were going to try changing the version number in the Groovy code, that’s what I’m still looking for to help figure out what’s going on here. Since setting a new version seemed to result in some unexpected warnings it sounds like you rolled back those changes. If you didn’t roll back immediately please share the results – did conditions evaluate correctly or incorrectly with just the version number bump?

Otherwise, try updating just the version numbers of the v0.3.10e.20190628 code to the latest v0.3.10f.20190822 and see if everything still works properly.

#27

Right now I am still in the ‘burn-in’ period to validate everything works well with the older code. It seems promising. Once I validated it is all good, I can bump the version number and report back.

To make sure I understand the ask correctly. I should go into the old code (v0.3.10e.20190628), up the version number to the one that’s in the new code (v0.3.10e.20190826), save / publish and report back on success / fail - right?

Do I do this on all 4 groovy files or just the webcore.groovy one?

Would this allow you to validate if the issue is in the update mechanism or a bug introduced in the actual code changes made in the v0.3.10e.20190826 release?

Thank you for all your help!!!

#28

Yes that is correct, please bump the version number on all 4 smart apps. This is not really a normal thing to test, but since the code changes do not seem like they would be related I want to start here to see what happens.

#29

I rolled back to 628, changed to code to reflect 826 as asked. Since doing this, pistons started acting as expected, and as they use to.

I will be reporting more testing, which I’m almost finished with.

#30

Thanks, I’m going to check with some other smart app devs before asking you to try any more code changes.

#31

Ok, here is the rundown of the testing I have completed.

Since rolling back to 628 (and changing code to reflect 826), pistons started acting as expected, and as they use to.

I went back into the code and changed to reflect 628. The entries did not turn purple (indicating that an update is available), so I did a ‘compare’ and overwrote the local copy of all 4 back to 822.

Then, I did some heavy testing. I’ve been running around my house opening doors, walking in and out of rooms, turning things on and off…my neighbors probably think I’m crazy. All the while watching the piston states.

Here is what I’ve learned about the update to 822.

Before the update to 822, this code would run perfectly:

image
image.png1178×1377 62.1 KB

After the update, only the top trigger in this piston would work.

I started watching very closely what was happening, and determined that it is the “Wait” command.

Prior to the update, the bottom 2 triggers would happen regardless of were the “Wait” was in the first trigger.

After the update, the “Wait” was causing the bottom 2 triggers to be ignored. ST reported ‘closed’ correctly, but it was never picked up by WC. So, the “Wait” would trigger, and nothing else in the piston would trigger while the “Wait” was in progress. Again, this didn’t happen before.

I hope this makes sense.

So, I started playing with the piston to see what I could do to make it work right in 822.

I ended up splitting this piston into 2 pistons.

image
image.png1178×1060 49.9 KB

image
image.png1178×898 22.9 KB

There are 2 extra triggers in this second piston, which are the Garage Door and Garage Motion Detector.

After making this split, the pistons are happy, and work great.

This also solved an issue I was having with the Garage Lights turning off when they shouldn’t, but that’s for another post.

So, for me at least, the issue is the way the “Wait” command is being executed in the new 822 version.

The “Wait” was causing anything else in the piston to be ignored.

Although I would rather keep things together in one piston (to keep away from having too many pistons [clutter for me]), I am ok with splitting them out into 2 pistons.

I hope this helps, and makes sense.

#32

Thorough and insightful! @smurf236 can you identify any parallels with your pistons?

#33

I don’t seem to have issues with the wait statement in my pistons. My problem was actual logic conditions evaluating incorrectly and causing issues with the logic of the pistons. This was substantiated by the logs.

Right now I am in the rollbacked version of the code with the bumped version number. I also changed logging to full on a bunch of pistons that previously was working without an issue so I can report more details. So far mostly working with the following caveats:

  1. Not a lot of activity in the household in the past 24 hours so insufficient test data to establish a definite view if this is resolved but I don’t see the

  2. One condition evaluated incorrectly as per the logs but the piston did execute which makes it still inconclusive.

I will update when more pistons run and I had a chance to see if they consistently execute correctly.

I did see along the past week and a half delays in sensors activity that did throw off pistons but I suspect these are more ST related than Webcore although may be related to @dejavux2 reports?

#34

@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.

#35

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!

#36

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.

#37

@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.

#38

Hmm. All interesting stuff.

  1. 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.

  2. AFAIK issue is only related to conditions evaluating incorrectly and it does seem to be evaluating incorrectly on a programmatic basis not physical events.

  3. 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?

  4. @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

#39

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.

image
image.png1178×667 16.2 KB

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)

#40

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.