Conditions evaluating incorrectly

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

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