Actions are too slow

I made my own motion sensor out of a PIR wired up to a ST shield with a bit of code. The motion sensor has a built in ‘activity’ light. I have verified that the microcontroller sees its pin go high very close to when this light turns on, and immediately sends a zigbee message to the hub. So, I configured this new ThingMotion sensor to turn on a light.

It takes several SECONDS from after the motion sensor’s ight goes on to when the ST controlled light turns on.

There is some serious lag in this system somewhere, and I’m pretty sure it’s not in the mesh network. Anyone have any luck speeding things up? I’m concerned I’m going to need to abandon ST in favor of a ‘do it myself’ solution, which I was trying to avoid, if I can’t get the responsiveness to something reasonable (i.e. below 500msec).

The lag is likely from the ST hub communicating with the AWS cloud that triggers the action. I know they are constantly tweaking to get better performance and I’m sure it’s high on their list.

This cloud based approach for local control seems like a very bad design choice. Sure, a link to the cloud is useful for integrating with offsite resources or for remote control/monitoring. But sensors triggering switches dozens of feet away should do so without looping through a server 3000 miles distant.

Yup, agreed. For most of what I do, it’s not a huge deal for lag to be a second or two (or 10). But yes, if your lights don’t turn on because AWS is down or just a bit slow, it’s a bum out. This is something I’m certain they’re working on, though (speculation).

It seems to me that having the local ST hub handle triggers, with regular refreshes to the cloud would be a much more efficient use of resources then having every action/command go through the cloud.

So, in your example, the local motion triggering a light is set up and uploaded to the cloud, but the local hub retains the responsibility for executing. The hub then regularly checks the cloud to see if the SmartApp has been changed/updated/deleted.

Yeah, something like that. I’m imagining that changes would be pushed from the cloud to the hub via a pegged up TCP connection rather than having the hub poll. However, for many many actions, the hub should just execute the app locally. I assume they have some flavor of linux running in there. Seems like it should be straightforward to send little java jar files to it from the cloud after they are compiled from the groovy source.

@ppmo,

It seems to me that having the local ST hub handle triggers, with regular refreshes to the cloud would be a much more efficient use of resources then having every action/command go through the cloud.

Honestly, I think there are merits to both side of the discussion. I think we can all see the merits of local control, but there are advantages to everything being on the web as well.

First, it makes the Hub much cheaper. If the Hub is merely a device that passing commands and events back and forth (Yes, I know I’m over simplifying things here) it’s a lot cheaper than a device that needs a more robust OS, memory, and processor to be able to store programs, execute them and make determinations on when to do things.

Second, by having everything cloud based SmartThings has to worry a lot less about fragmentation. When new device types are created, when new SmartApps are made, when changes are made to the software that runs the whole process, they make these changes to the setup in the cloud and they are done. They don’t have to worry about pushing all this info to the many users around the world. This leans right into the next point…

Third, support is easier when the SmartApps are installed on their server. They can control things more to ensure that the programs aren’t going to crash the system.

Don’t get me wrong here… I’d like to see some level of local control for when/if the cloud service goes down. But I understand why SmartThings decided to setup the model the way they did, and I don’t think it’s all bad.

It’s ok for certain things to be in the cloud, especially for development and debugging. But, when you’re deploying a finished app to the home, the current level of lag in executing actions is unacceptable. The product is basically a non starter for interactive lighting control in its current incarnation, especially for motion triggers. Unless this gets fixed or suitable workarounds are permitted by end users, I would not recommend this system.

@chrisb:

First, it makes the Hub much cheaper. If the Hub is merely a device that passing commands and events back and forth (Yes, I know I’m over simplifying things here) it’s a lot cheaper than a device that needs a more robust OS, memory, and processor to be able to store programs, execute them and make determinations on when to do things.

I wouldn’t call $99 for a dumb hub “cheap”. Compare this with AppleTV running iOS on A5 processor for $84 on Amazon.com. And that includes WiFi and remote control :slight_smile:

@rdlee632:

However, for many many actions, the hub should just execute the app locally. I assume they have some flavor of linux running in there.

The ST hub runs on puny Microchip PIC32 micro controller. No Linux there for sure :slight_smile:
It really is dumb. In one of ST’s “Office Hour” they briefly mentioned working on the “next generation” hub, but I wouldn’t hold my breath considering they seem pretty much overwhelmed with ongoing software development.

But, when you’re deploying a finished app to the home, the current level of lag in executing actions is unacceptable. The product is basically a non starter for interactive lighting control in its current incarnation, especially for motion triggers.

You’re absolutely right. I’ve been a vocal critic of the “Cloud-Only” approach in these forums and even got some hard-core ST backers angry (right @twack? :wink: ) However, you need to read SmartThings “creation myth” to understand its genesis. Well, maybe it’s not a myth but it does have at least two elements of the myth - “the flood” and “the revelation” :slight_smile:

Anyhow, it looks like it was originally conceived as “remote alert” system and then later on repackaged as generic “home automation” system because it’s difficult to sell alert-only product. But IHMO, it’s a huge stretch to call it “home automation” yet.

They put a PIC in there?? Oh lord. My wifi access point has more horsepower than that. Why does it cost $99?

Well, does anyone know of an open, forward looking, home automation platform out there with a reasonable developer community around it? I would prefer to stick with zigbee, as I think it’s the future, tho there does seem to be a lot of legacy zwave stuff out there right now.

If not, looks like time to roll my own. Perhaps get an atheros ar9331 based, openwrt linux compatible, wifi access point with 16MB ram and 8MB flash for less that $50. Slap on a zigbgee usb module for $30 bucks and, in theory, away you go, for less than the cost of a smartthings hub. Anyone tried this?

I think the disconnect here is between hackers/coders and laymen like myself who just need a simple way to automate their home. Maybe ST isn’t the entirely-open platform you imagined, but it does have just enough openness and ease of use to allow someone like me (who had never touched a line of code in his life) to write a simple app that has fundamentally changed how he uses his home. My girlfriend has never opened the app. Let me repeat this; my girlfriend has never needed to open the iphone app because everything is operable via physical switches and/or logic. Yes, there are occasional hiccups and yes, communication has been an issue. But don’t throw out the baby with the bathwater here. Richard Lee, the solution you are talking about is appealing to maybe dozens of people in this country. For the average guy like me (and my girlfriend), we’ll stick with ST.

@rdlee632:

If you’re looking for an open-source home automation project with active community, take a look at Ninja Blocks. It’s both open hardware and open software. Functionality-wise, it’s very similar to SmartThings. It does not have built-in Zigbee or Z-wave radio, but either can be added using USB stick.

Linux-capable hardware is abundant and cheap. There’s no reason to build custom “junk” boxes. In fact, a decent 10", $90 Android tablet has all the hardware you need for a home automation system. Just stick it to the wall and there you have it - a self-contained automation system with touch screen, camera, WiFi, bluetooth and backup power.

I’ve looked at other options: homebrew based on Node.js on a Pi that I still use for media control - and I found this, which looks promising: http://thethingsystem.com/

But, for most people, I think ST offers the best automation system overall. It’s not perfect, but they have the staff, budget and a decent community that is constantly improving it.

I think the best solution would be one that “knows” that an app requires external dependencies or not (such as checking weather, using the virtual presence, etc). If it’s all local devices (zigbee presence turning on a light switch, for example) defer to the hub if it’s capable hardware-wise.

When I open my window and it checks the weather, that’s not a huge problem if it lags a few seconds. What is more troublesome is when I turn on a light switch and a virtual 3-way switch takes 10 seconds to kick in.

Hmm… those Ninja guys sound like they have a much better strategy. Wish I had heard of them first. Seems like they are definitely more up my alley than SmartThings, which seems to cater more to the “laymen” of the world.

Apparently their new NinjaSphere gateway has integrated Zigbee, and add-on Zwave support. Dammit, just missed their latest kickstarter deadline.

@imbrian:

I found this, which looks promising: http://thethingsystem.com/

Thank you. Finally, somebody in this business starts making sense:

One thing that's rather odd about some makers is that they view the access protocol as some kind of proprietary intellectual property. That is, of course, their perogative. It is, however, fundamentally silly. If you are a macguffin guru and your goal is to cover the world in macguffins, then you want as many people as possible writing clients to manage your macguffins. Otherwise, you're simply limiting your adoption and the size of your market.

The above quote highlights everything that’s wrong with the home automation industry. Another good point:

When a water sensor detects a leak, it puts the home in alert mode. (...) And all of this should happen regardless of whether the home has Internet connectivty when your water heater springs a leak.

Cannot agree more.

I’m back for a while to see if the IDE has improved. Still kept my ST hub (even though I moved on to vera) in hope that the ST IDE would be more usable now (but nope, its still too lacking in debugging features) to monitor a holiday home, but I’m reading the rest of the posts observing for reliability issues first, since the use case isn’t supposed to be too complex.