Individual actionsare executed (read scheduled for execution) before the whole condition is evaluated, so the state change is unknown at that time. I can make it execute on conditionstate change only…
How fast is your presence sensor? Was it ever faster?
yea execute on condition state change only, that’s what I need!
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:
- event comes in - gets preauthorized (to prevent routine, piston, ask alexa from executing the piston unless there is a trigger looking for that exact routine, piston or ask alexa macro)
- eligibility is checked - this is to ensure that in a mixed trigger/condition piston, only triggers start evaluations
- conditions are checked for truth, one by one. Individual actions are scheduled at this time. Scheduled means added to a list of things to do.
- overall piston state is determined, THEN or ELSE actions are scheduled at this point. Again, added to a list.
- A safety net is installed to ensure we’re getting out of sticky situations (if we timeout)
- the “todo” list is parsed and merged to the main list of tasks. The “todo” list can contain additions or removals, this is how TOS works
- Time triggers are evaluated for next expected time, ST job is scheduled at that point for the next FUTURE point in time that is required for a run.
- All tasks that are due at this point (time <= now + 2s) are executed. They are not delayed until a new ST job runs.
- Safety net is removed
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)
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.
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.