Caveat - I haven’t read the rest of the thread from here… so I don’t know if it’s been brought up
I don’t necessarily understand the details, so I may be off base here. I’m just going off of how the URL ‘looks’.
Could the pains that Smart Tiles is going through right now with authentication also come into play with the dashboard interface for CoRE? (I can provide a link to the thread if nobody is familar with what I am speaking)
Do share that please, am not aware of what SmartTiles is going through
Here’s the thread… they were having issues with oAuth … and had to change authentication/login which is kind of ruining the experience for many folks using the app.
Ok, I think this is to do with the research reports earlier being journalistic enough to say “hackers” got to unlock doors. What I think happened is someone stole/found a phone (or was given the URL by someone who didn’t know the possible consequences), found the SmartTiles app and since OAuth is a permanent token, managed to unlock the door using the stolen/found phone or URL. To prevent this from happening, SmartTiles needs a more “temporary” login. That is all because SmartTiles gives you direct access to devices. @625alex am I correct in my assumption? Since CoRE is significantly different in that it does not give the user direct access to control devices, it can keep using the OAuth for as long as it stays “read-only”. I will keep this in mind for backup/restore functionality.
I am not sure if ST is about to make away with OAuth endpoints, but I wonder why SmartTiles did not require a PIN for security related commands like disarm, unlock and open, and get to keep OAuth…
I try to avoid comparing CoRE to RM, but since you asked, I don’t remember it ever taking more than 1 second with RM.
The statistics are showing an average evaluation time of 500ms with an average delay time of 1.5 seconds.
Ummm, delay time is a bit outside my control. But does it consistently take 2 seconds? Does it ever happen much faster?
If often takes longer than 2 seconds, but I can’t remember it ever taking less. The max eval time is 6 seconds and max delay is 5 seconds so it’s possible even if one of them is fast, the other could be slow making it still take at least 2 seconds.
I’m assuming I didn’t have this issue with RM because it immediately performed the action instead of scheduling it?
The scheduling doesn’t really wait for another run, it runs it at the end of all tasks having been performed. I will look into ways to improve speed. I’m sure there are things I can do. That’s what beta is for 
Correct, but if SmartThings scheduler is acting up, it will affect the performance of all piston actions, right?
There are a lot of benefits to the way yours works so I’m not bashing it, I’m just trying to get a better understanding of how it works.
Using minimal wording, it works like this:
I see this URL however its too small to read, this would not be a problem however for some reason my phone will not allow me to copy it either. (only shows a Past option)
No “Select”? I can help with some javascript, select (and copy?) on tap. I’ll try that.
If you enable debug messages, can you tell me how long it takes to process the event and how long it takes to process the tasks, and how long till “Done in Xms” ?
Thanks for the explanation. You’ve made a lot of these detailed explanations on various things in this topic so someone should really try to find them all so they can be included in the documentation.
So if I’m reading that correctly, problems with the scheduler shouldn’t affect the piston unless it’s using waits or the safety net kicks in because the actions couldn’t be completed within the SmartApps execution time limit?
Correct. Which would not be 2 seconds, but 20, so you’re not hitting that. Besides, you’ll see a warning in the logs…
What I think is the main Achile’s knee is the use of atomicState. I am forced to use that on each task being executed to avoid the same task being executed by a parallel run of the same piston. THAT slows things down… but prevents the double commands that are sometimes experienced with RM and other apps. It’s a safe thread mechanism, built on top of ST’s Groovy implementation.
As for the documentation, I’ve recently started conveniently adding #documentation to each of these posts you mention here
No there is no ‘select’.
That would be great if you could fix it!
If not, It may be just my very old phone and if I’m the only one seeing this. I can just live with it.
Thanks!
I have all forms of logging in CoRE and the Piston enabled, but it’s skipping most of the log messages.
I’m running late for work so I’ll do some more testing when I get home tonight.
So, neither of these ran this morning but I cant remember if I went into all of my pistons and hit “done” after the update last night.
Take your time. Also, enable only either trace or debug messages at a time, see if that helps with the skipping
Can you please try and have the live logging on when that piston is supposed to run? Enable debugging, trying to figure out if you get any errors?
