LOL… I don’t want to ask. I will just say, it probably don’t take AI to predict.
1 Like
One reason might be to reduce load on your system, if that is indeed the case. But if having multiple apps subscribed, and actively running in your system adds more load and adds more latency, it may be advantageous to simplify.
Not sure if those are all true though.
Would be interested to know myself as I move things from RM and other functions/apps to CoRE if this should be a design goal.
2 Likes
I can predict random things. Like the dishwashers being hungry right about… now! Random enough… I got an extra dishwasher for the week, for a total of three hungry motherwashers. 
I predicted that too, about a year ago… ;))
2 Likes
Actually Smart Lights was most likely running in the cloud. Reason being, I’m using custom device handlers for my Hue and GE Link lights.
Still an interesting test because Smart Lights epitomizes a custom built, narrowly specific SmartApp of the kind that should just work better than something like CoRE, if you subscribe to the thinking that more complex things are always slower, and simpler things are always faster. Just goes to show that doesn’t always shake out in the real world.
Simple task does not always equal simple code, even though it should. And vice versa.
1 Like
At one point I had 89 Rule Machine rules. Rule Machine was running roughly 95% of my automations. While I did not have a whole lot of the problems that were occurring throughout the ST environment I was still having problems. Things were sluggish and getting worse.
Since the downfall of RM and my making my system much more diverse, my system has been a lot better.
The only smartapps I had installed was:
- Rule Machine,
- Amazon Echo
- Hue Connect
- Smart LIghting
- SmartTiles
Now, I have all of those, plus:
- Talking Alarm Clock
- MediaRenderer
- Life360
- Keep me Cozy
- IFTTT
- CoRE
- Button Controller
- Battery Monitor
- Ask Alexa
1 Like
go to this link and see if your smart lighting rules are here… if they are not on this list, then they are NOT running local.
https://graph.api.smartthings.com/localInstalledSmartApp/list
One thing to note here is that I built CoRE with two main things in mind:
-
Performance - I cache things and make sure to not check the same thing several times. On a good day when ST is working fine, a piston that does not execute any commands can reach below 50ms of total execution time. Last time I checked today, it would take about 130ms from event date/time until CoRE would start executing and about 70ms to complete execution, for a total of about 200ms. This was tested using a virtual minimote by pushing its buttons in the ST app. So the minimum overhead of CoRE is about 50-70ms. Typical overhead, I would guess about 100-150ms. Now, the more complex conditions, the more it would take to process the event (see the trace logs - they give the event processing time and the task processing time separately). Commands/tasks seem to take a lot of time with my Hue light strip being the champion at sometimes taking more than 2 seconds to execute - we’re talking about
device.on()taking that time. I doubt it any cloud SmartApp would do any different at this point. -
Reliability - this somehow conflicts with the first point, because in order to survive any possible timeouts, CoRE is first building a list of scheduled tasks before it proceeds to physically executing them. This obviously adds a little bit of an overhead but provides crazy timeout survival skills.
The main issue with CoRE is its sheer size, around 400kB+. There is a hard limit on the UK shards (empirically determined) at 500000 bytes, about 487kB.
3 Likes
I wouldn’t correlate them, however.
I was using that (downfall of RM) as reference to a point in time.
1 Like
So, would it now be the time to start removing some of the things in the CoRE that aren’t necessarily needed?
Easier said than done. What is not needed? Custom tasks represent one line of code - it contains all the info that is then parsed by the code to determine input settings for the task, plus a tiny procedure to execute the task… Not a big save. We are talking less than 1kB per most custom commands…
2 Likes
Interesting. Are you able to gather execution time data from the pool of CoRE users deployments, or is this simply from your own system?
One thing that has been frustrating me is Door Locks not unlocking for a long period of time or not at all, by routine or other means.
When I started rebuilding and moving to CoRE I took into account several issues with ST and starting egineering around them, and I wonder if the Z Wave locks I have are slow or have high rates of failing or if the execution of the unlock commands (from routines and other) were just timing out/extremely laggy.
Either way, I hope the way I have implemented in CoRE by streamlining, and double execution when it comes to the unlocks, helps. I have a child that will need to get back into the house next year when they get back from school - and although I have backups upon backups - I want the system to unlock reliably.
I can tell you that half of all piston executions today (for all users) took less than 350ms.
You can always follow up with another piston, say 30 seconds later to check. That’s what I will do for mine. When I leave, everything locks automatically. Then 30 seconds later get a report that all is ok.
Good idea, I will do that for departure scenarios.
For the unlocks, the time is sensitive to maintain proper levels of acceptance but I will add a 1 or 2 second delay to the second round of unlock commands I launch so they aren’t right on top of each other.
How do you track this?
Cameras in your house.
4 Likes
I can’t share more at the moment, sorry. I am trying to convince @alex to help us by providing more execution stats for developers in the IDE so that we can code better. Help us help them help us. Kind of… I am thinking, allow the developer to know how many executions the app had in the last hour/24hours, min/avg/max execution time, etc. Something that we can use to quantify performance. Then we can strive for better/faster results.
3 Likes
Let’s face it, real transparency would have this and more up front and center to the entire community.
Transparency is not a strength of the current guard at ST. We get token information when it suits an agenda.
I am all for the developers having it, but I am not necessarily super excited about creating classes of people. I understand there may be some circumstances where there would be certain data that was security sensitive, but my default would be let it all out to all.
I think ST’s actions have made it clear they simply won’t do it, despite the lip service.
End Cynicism. Okay, we all know that’s not the end of it, but it does conclude this post.