Perhaps the new hub will help define a difference between free and paid services. Basic local processing, which would reduce the internet dependency and decrease latency; and more advanced features, some of them paid, supported with cloud computing resources. E.g. X amount of smart apps processing time for free, and additional blocks for a fee.
1 Like
@beckwith I donât know where you got August 31st from the TIME list. It is the only one that mentions a Summer release, but the August referred to in the article is the lock company, not the month! If you could link to a definitive date published anywhere Iâd appreciate it.
Sorry for the confusion.
These are sales dates which are the last day of the period, not engineering dates which are the first. Ben confirmed earlier the original â1st Quarterâ release was March 31. That would make Mondayâs âAprilâ release the last day of April - April 31. Summer release thus is the last day of meteorological summer or August 31.
It could be September 22 but most companies use meteorological seasonal dates not astronomical.
Not sure why so many are worried about SmartThings version 2 hub adding fees etc. I donât think they would intentionally screw us. Theyâre adding additional functionality to there next hub which comes at a cost. They are expanding into the alarm monitoring industry. There are numerous hub options if for what ever reason you become unsatisfied.
Iâm thinking that SmartThings is delaying the launch of their hub because they may have come up with some last minute design changes that they would like to address. August would be an extreme delay especially after CES when people are ready to implement new tech into their homes.
This seems a little disingenuous to characterize âslipping datesâ in this way. I assume this is taken as Q1 means March 31st and April means April 30. August 31st is not a thing.
2 Likes
As I have said many times, I donât know of any company more open than SmartThings when it comes to strategy and schedules. But you canât say the dates have NOT slipped. Almost all technology companies deliver at the end of published release dates if not later. I donât see SmartThings as any different here.
I understand there are quite a few variables that impact delivery making precise dates difficult. However if you are going characterize me as disingenuous, please give us a more precise date.
As I tell my kids⌠Pointing to others âbad behaviourâ is no excuse ⌠YES they have slipped but it is typical
I am most interested in the capability to run apps locally on the hub. I tried smarthings about 12 months ago, but had to return it due to the extreme lag of running all app interactions through the cloud.
Anything more been announced about what/how many apps will be able to be run locally? Can the cloud be entirely cut out of the picture with the new hub?
1 Like
From developers call yesterday, we know that thereâs going to be about 512 MB RAM to run locally and a lot of things are not finalized yet such as priority of SmartApps or if developer can choose which SmartApps will always run locally. One thing the everyone is expecting is the final product will be easy to use but yet it needs to be really flexible. For now, you can expect that the SmartApp will run automagically between local and cloud.
Thereâs been a couple of suggestions that the 2 USB 2.0 ports can be expanded to increase the memory size to store more apps locally.
To be honest, 512 MB is quite a lot. I would expect about 1/2 would be used for the OS and 256MB left to be used exclusively for SmartApp. A complicated 600 line SmartApp like ActiON would be about 30kb each. Iâm guesstimating that you can store about 8000 SmartApp? This is more than enough for an average user.
1 Like
I just hope they release it before its ready. (end sarcasm)
Seriously⌠The release date is when its ready. Would you rather have the hub v2 without anything working or wait for it to work?
Hub v2 is a radical change in strategy from cloud only to local processing with cloud backend. I will be shocked if everything is available and working great at launch.
My wishlist for Hub v3 is already startingâŚ
-External antenna for rack mounting and/or optimizing signal strength to/from hub
-Built in wifi chip (may be able to use usb wifi device?)
-Full bluetooth not just LE (not confirmed v2 wonât have this)
-Local storage (may be possible via usb drive) for audio, data storage for apps, etc.
-POE support
-Local hub access via HTTP / API calls from other local machines / device (may be possible v2)
-Wall mount bracket (may be possible with back cover design replacement)
-Rack mount setup, 1U
-USB 3
-IPv6 support (may be in v2?)
Oh and keep the price under $99 (ha, ha, ha)
Hey, I guy can dream, right?
2 Likes
Hmm⌠well I really hope they leave the decision as to whether the app runs locally or in the high latency cloud at the discretion of the user.
Other than the âcloud firstâ strategy, the smarthings ecosystem is pretty nice. The developer community seems active, the apis seem fairly open, etc. Itâs just unusable for the purposes I want to put it to (such as motion and proximity activation). Even turning on and off lights by a wall switch has an annoyingly noticeable delay due to the cloud round trip.
In my opinion, activation based on motion shouldnât go through any Hub to send command to activate the device. It needs to be embedded locally within the device, and when the device is turned on, then only it should report to Hub.
Well, I wonât expect the local app execution will solve delay problems if youâre using motion sensors to turn off or on lights. Iâm guessing that it will still take a couple of seconds for the lights to turn on, which I think itâs still annoying for some, at least for me.
Why? Motion sensors would take a couple of millisecond to react and sends the event to Hub, Hub process the rules (which might take a second or two) then sends it to your light which might take a couple more seconds. It still wonât be a perfect solution if youâre thinking of walking into the room and the lights turn on automatically within milliseconds. Furthermore, because itâs wireless, thereâs bound to be some wireless interference happening which may cause some of the single connected light bulbs not to turn on. Thereâs a lot of points of failure for these kind of scenario and itâs not the best design.
Youâre probably better off with plugs like this if youâre switching lights on or off based on motion:
I believe that the local execution design is to accommodate power outages e.g unlock the door when detect your non mobile presence, alert when smoke alarm detects smoke or even water leakage.
1 Like
For what itâs worth, I routinely have about 1 second turnaround time for motion activated lights, about 95% of the time. The other 5% it might take 2 or 3 seconds (or sometimes more). And Iâve got some 24 motion sensors activating lights (or stopping lights from turning off). I assume the slow cases ARE roundtrip to cloud cases. So if locally stored apps left me with 1 second response times 100% of the time, Iâd be a happy camper. Even my wife thinks the lights are quite responsive, except when they arenât. Sheâs so used to it, that I hear about it if there is an issue. She loves it, and itâs sold her on ST.
2 Likes
My motion activated lights donât take multiple seconds to turn on, maybe 1, and this is more dependent on the motion sensor than anything else.
And if apps running on V2 will be taking seconds to execute, then there would be something very very flawed with the design, I just donât see how it would take the hub more than 50 to 100ms (if that) to plow through itâs event Q and do itâs thing.
2 Likes
I built my own PIR motion sensor. It activates within tens of milliseconds when detecting motion. I made my own zigbee transmitter using an XBee module, the time of transmission was milliseconds, at most. So, getting the motion data to the hub should take 50msec, tops. Now, I donât know what you think is in the hub, but its not a hamster with an abacus. There are electronics in there operating at an appreciable fraction of the speed of light. Running a groovy script should take milliseconds. Then, back out to the light switch by radio is again milliseconds. All told, the light switch should be told to turn on within 100msec.
I was seeing several second delays. The delays were not even consistent. I did some more experiments using wireshark to monitor traffic to/from the hub and determined that the hub was getting the motion event very quickly and forwarding it on to the cloud, but the cloud did not come back with the command to turn on the light for seconds.
Thus, if smartthings continues with its âcloud firstâ strategy, it wonât bring back dissatisfied users like myself.
2 Likes
First off, sorry you ad that experience. You must have had some sort of additional issue because latency from hub to cloud and back is not that large. We are speaking of 100-200 milliseconds on average.
To your other questions - yes the next generation of the hub will be able to run apps locally. We spoke about this at some length on last nightâs dev discussion (video being processed now). Apps that do not require access to web services, etc will be run locally when possible - this will be most of the time. If there is a âpile upâ of queued apps locally some may be offloaded to the cloud for additional processing capacity. An internet connection will likely still be required at times though many smartapps will fire and events will process without one.
2 Likes
This is not expected behavior. All such events should be sub 1 second.
My lights are well under 1 second all of the time except last night when we sat in the dark for 3 hours 
Good thing Iâm an ST believer.
@bravenel, @Ben - Could this be a delay from the motion sensor and not ST? For example, I noticed that my Monoprice motion sensor is slower to respond than my Fibaro or ST Gen1. I put all three together and the had them trigger the same light. In testing, my Monoprice was noticeably slower. This could help account for the delay you are seeing?
Perhaps they have fixed things. My experience was from mid January 2014. It was extremely laggy⌠as though they were using AWS SQS or something and had a bottlenecked reader. Maybe they switched to Kinesis? DunnoâŚ
I still want user stimulus based events (such as switches, motion sensors, etc⌠anything where the user knows they requested an action) to be processed locally⌠and quickly.
Things where the stimulus is unknown to the user (weather forecast, stock price, twitter posts, whatever) can certainly be processed in the cloud with some latency.
Use of the mobile app probably can and should go through the cloud, too.