I agree. The notion of SmartThings as “open development platform” is highly overblown. Out of purported 20,000 “developers” there may be at most a couple of thousands who created original smart apps or device handlers. In most cases these apps are trivial and are basically hacks to work around some missing features or outright bugs in the platform. My own Pollster is the #1 example.
-
Not a written one, but, yes, various founders and early engineers said this to me and groups even 2 years ago.
-
I think rule builder got pivoted into the Dashboard Solution Modules, then SHM and Smart Lighting. My guess is they did dismissed any thoughts of a rule builder that could be done entirely within the existing SmartApp API (ie, similar to @bravenel’s Rule Machine) as too complex for users, and, deferred any work on one that would use a new GUI because that would require too much human resources / distract from core projects.
I agree. When I started with HA I started on the Wink hub. I went there because I got it for 10 bucks when I bought 2 bulbs. The app was acceptable. It was missing a lot of the complex rules I was hoping to design, but it was workable.
The reason I looked elsewhere was due to the lack of performance of the platform, not the app.
I was really hoping for more when I came to ST, but was severely disappointed in the APP. The reason I came here and the reason I am still here, the community.
Rules engine is not a “rocket science”, whatever that means. A company that received $200M funding from Samsung and incapable of delivering a decent mobile app is a sad joke.
There was a thread last year after SHM came out that was a discussion of feature requests. See @geko’s post that describes some pretty basic functions that SA had but SHM did not. As far as I know none of that’s changed now. Oh, except SHM just flat out doesn’t work anymore.
Everything has been working somewhat stable this week, but tonight had another issue where SHM did not disarm and went off. Hopefully the updates scheduled for tomorrow are significant and robust enough to bring stability back.
One of my main disappointments during this has been Smart Lighting on the V2 hub. Throughout these issues, Smart Lighting has been very unstable while from my knowledge, should be running locally and not affected by these platform issues. Lights take 5+ seconds to turn on and sometimes turn off even though there is motion (only way to get them back on is to hit the switch manually, or wait for motion to stop and then move again). This has improved this past week, but I’m in the mindset now that nothing runs locally on this hub. I’m guessing there might be a very specific set of settings for a Lighting Automation to run locally.
Anyways, thanks for the continued updates. Good luck on improving the platform! One thing I’d really like is an error log or some confirmation that a routine or action did not complete.
If you have doubts you can always unplug the ethernet cable to see what really runs locally. I experienced the same lag last week and also thought that nothing runs locally anymore. The physical test showed that everything was running locally, however the delay increased a lot more without internet. The lag was more like 10 to 15 seconds. That lasted for about a week, until Friday night when everything came back to normal.
You’re right, I completely forgot I did notice this delay when I was setting up a new switch and had the same breaker off that the router/modem was connected to. I guess the unfortunate thing is it does seem to still rely partially on the ST platform. One of the main benefits of running locally is the response time, which is pretty much nullified with this delay. There is still the fact they will run, it just seems poor design that it affects response time.
I believe that for Smart Lighting to run locally, all involved devices must also run locally (motion sensor triggers, lights, etc.) It is my understanding that only the official Device Handlers with directly controlled devices run locally, so nothing that’s been added through the IDE, or anything like Hue, where it’s controlled through the Hue bridge. So if you have a motion sensor with a community Device Handler, the entire rule (and possibly all Smart Lighting rules) will run from the cloud.
I hear you. The only reason I am using Smart Lighting as much as I can, is the response time. See it degrading in the past few weeks was very disappointing. I hope they fix the platform soon. I know I cannot use Rule - or any other cloud based app - in certain places like hallways because the lights don’t come on fast enough.
Rule of thumb for a locally run Smart Lighting instance is: use Smart Lighting, use an officially supported zigbee and (most) zwave devices with a stock handler. To validate, check this link:
https://graph.api.smartthings.com/localInstalledSmartApp/list
Awesome link, thanks! Just noticed my cabinet LED controller (which isn’t the important device to turn on right away) was in my kitchen automation. Moved it to a separate automation and now the important one shows up locally. It seems to respond slightly faster, but the delay issue with no internet/intermittent platform issues is still present. A step closer though.
If you have a zwave motion you will never get rid off the lag even when the platform is running fast. I had to put a zigbee sensor in my kitchen to get a decent response time. Likewise for my hallways. I have zwave sensors in rooms where you need to open a door. By the time you swing the door open, the light comes on in ‘normal’ platfom days.
Which Zwave motion sensors are you using?
I have several iris zigbee sensors and five Enerwave ceiling mount Zwave sensors.
They seen to average about the same response time, but over the pay couple of days the Zwave have slowed down…
You name it, I have it, and all are solid but slow. Fibaro, Aeon Labs, Ecolink - no Enerwave though…
I’ve used the Ecolink and I hate them… I can get in the room, do what’s being to be done, and leave the room before they get around to even noticing me. Reminds me of a wife I used to have.
The Enerwave have been great. Very fast with a really quick 15 second reset. Great for big rooms with the 360° detection.
But they are a huge pain in the butt to get connected to ST. But once done, Rock solid . I have five of them.
Everything here is unstable. So, no change there.
One Garage light simply won’t turn off, despite removing it and adding it again. The Front entrance light is now not triggered by its Smart Lights rule. The alarm system sometimes trips and can’t disarm, but if I wait a while I can eventually dismiss the alarm and disable the system.
Just waiting to see when it all calms down.
@slagle
Have determined the repeated local instructions are not just log artifacts.
Tonight the ceiling light came on as scheduled by the smart lighting automation.
I turned the light off via Echo.
It came on again because the original smart lighting automation was still repeating.
It continued to repeat another 12 or 13 times.
I turned the light off again via Echo about 4 minutes after it had come on the second time and it then stayed off.
Can you PM me your support ticket please? 
I see no difference between Z-Wave and Zigbee device delays. In fact, I go to the IDE and look at the time stamps on the events and you can see the delay in generally in executing of the SmartApp and not how quick the sensor gets the trigger to the system. I have about half and half between the two technologies and various manufacturers.
