@Ben I do believe it was also discussed that local device activities would route locally, so if you have a switch to turn on a light bulb, that will no longer require round trip to the cloud.
1 Like
Should be, but arenāt. Today is especially bad, with very noticeable delays, bad enough that (a) my wife has told me 2 or 3 times that things are slow, and (b) Iāve had rooms that simply didnāt turn on at all. My 95% figure is made up, but itās that bad or worse Ben, and has always been that bad or worse. You can see why people complain about STās architecture, when the performance is spotty at best.
Iām doing some testing right now and Iām not seeing any delays. That certainly doesnāt mean there arenāt issues at all right now, but delays can be something local as well. Iāve also confirmed with our tech-ops team that there are no servers with degraded performance at the moment. If you havenāt already please email support@smartthings.com so we can assist you in troubleshooting.
This is definitely not motion sensor related. The only way it could be is if motion sensors across the board are simply flaky. Iām using nothing but ST motion sensors, and I have yet to see one not fire as expected. The delays HAVE TO BE IN THE CLOUD. There is no other possible explanation. Well, there is one other possible explanation: Z-Wave. But that makes no sense either. There can be a latency in z-wave responses. But for the problem to be widespread on a particular day indicts the CLOUD!!
I wonder why there is such an apparent disconnect between what ST thinks is the performance (as indicated by @Benās post), and the reality that we as customers actually experience.
@Ben, are you guys running any performance metrics? Canāt you tell from log analysis that response times are sometimes crap??? I spend a ton of time trying to figure out whatās going on, but thatās all wasted effort. Sorry, but āexpected behaviorā should only be expected if you have some reason to believe itās actually happening the way you expect. It isnāt.
We have a wealth of monitoring services keeping an eye on metrics that are way over my head technically, as well as an entire team (tech-ops) that manage our server infrastructure. One of those metrics is roundtrip communications to test devices all over the country.
Have you emailed support@smartthings.com?
@Tyler, It hardly seems appropriate for me to email support every time I have a slow-down in motion latency, as that would be every day or more than once every day. Are you kidding? I suspect that you need to look at a case like mine, which from what I can tell from the forums is quite typical, and track the hell out of it. Just why didnāt the lights turn on when I entered my office 15 minutes ago? I have no idea. Like I said, the reliability EVERY DAY is at best 95%, and Iāve never seen it not be flaky on any single day. Maybe itās my ISP, maybe itās my z-wave, maybe itās my zigbee, maybe itās my devices, maybe itās my hub, maybe itās your cloud. Which would you want to place a bet on??
No, Iām not kidding when I ask you to email my team. Certainly itās not the experience we aim for if youāre seeing these slowdowns frequently, but these forums are not a means for me or my team or our engineers to troubleshoot issues at an account/hub level. Sure, we can look at the server metrics and say āno problems hereā but itās concerning to me when multiple people jump in on a thread speaking to similar issues. The path for us to investigate those issues further is for you to email us.
Why didnāt your lights turn on? I have no clue. ZigBee motion sensor? Z-Wave lights? Mesh networking issue? RF interference? Local networking issue? Obviously these questions are rhetorical, but itās not as simple as saying that thereās an issue with our servers. There are a lot of pieces here.
To give you a specific example, I worked with someone this morning who said that ānothing was workingā. When we went to investigate it, it turned out that what wasnāt working was one specific LAN device that had stopped reporting. We directed them to assign that device a static lease on their router and re-add it to SmartThings. It started working immediately after that. In this case thereās certainly more that we can be doing on our end to recover gracefully from issues like a LAN device that is no longer reachable, but the problem certainly wasnāt a server issue on our end.
tl;dr if youāre interested in having us look at an issue please email us.
2 Likes
Iāve done that, and weāll see where it goesā¦ Thanks
1 Like
I agree that contacting support (for any product or service, actually) is a daunting prospect when the problem Iām experiencing is not deterministic.
My ISP (Comcast) for example, gave me spotty service over a few weeks last year ā turtle slow bandwidth would last anywhere from a minute or two to an hour. It shouldnāt be my responsibility to run continous diagnosticsā¦
Importantly, I certainly believe SmartThingsās support is magnitudes better than Comcast: but with that disclaimer out of the way, Comcastās handling was atrocious: i.e.; Web chat asked me to reboot the cable modem but keep my browser open so they could resume chat. You can guess how well that worked out.
The problem resolved itself after a few weeks with no intervention on my part and no notice from Comcast. Some research revealed that they had had a physical infrastructure (cable cut? fried neighborhood router?) in the area a few weeks prior to my noticing any issues. Might have been the cause, but Iāll never know.
Back to SmartThingsā¦ Pretty much every time I try to create a live replicable and measurable scenario of this intermittent latency problem, I have been unable to. It truly seems random. Frequency of occurrence varies from week to week; overall rare enough (for my household) that Iām definitely not eager to spend diagnostic time on it with supportā¦ Which is not ideal for either of us in the long term, perhaps; because I still have a fear of uncertainty and unreliability.
End-to-end automated continous diagnostics are the ubiquitous first step in this type of industry (ādistributed systemsā?) and I presume SmartThings has implemented thisā¦ Yet, the Community continues to experience inconsistency and canāt set or believe high service level expectations.
1 Like
7 Likes
Bruce, what else do you have running on your LAN? As a network engineer for the past 20+ years my first instant reaction is to blame your ISP. Barring your ISP then I would turn to packet prioritization on the LAN and at your gateway (cable/dsl/dedicated) to the Internet. I have also experienced the exact same problems and behavior you have explained. In some cases rebooting the ST hub made it go away - in others I found āthe significant otherā streaming too much media (fixed that with a high-end router and QOS switch) - in the third case I found that Hue-ST were having some local battle on the LAN that was unexplained - only a couple times (around the holidays) have I noticed that it was ST Cloud related.
I would start with your ISP connection to check for Jitter (variable latency) and then see what else is using your Internet connection all the time - TV? large email and spam filters? Internet Radio? likely something that is continuously causing persistent Jitter is the root causeā¦
Happy hunting!
1 Like
@Tyler - yep, that gif made my day. Use that all the time. I need to get that sound clip so I can just play it automatically.
The disconnect is, in many cases, due to the vast variance in each homeās environment. Everything emitting radio waves can effect the performance of systems such as SmartThings. I have seen the addition of a Sonos or the turning on of an Apple TV, or even the placement of the hub, have significant performance ramifications.
2 Likes
Related to this - I was having issues and found one of the articles on this site about wireless frequencies really helpful. Actually bought a more powerful router, moved things around in my house, hard-wired a ton more devices, and now things are working great.
Regarding being able to debug wireless issues further - are there programs I can use to help understand this?
Yes, there are very sophisticated tools that can isolate these issues all the way down to which specific square foot of your home has what types of interference - however - unless you have significant experience driving theses tools the data is not very useful to the novice user. There are some simple guidelines that can be adhered to and from there most of the forensic testing that can be performed is virtually irrelevant - the solution, should you discover the ārootsā of the problems, is the same.
Here is some background and then I will share some ābest practicesā that usually will cure almost anyonesā home networking anxieties. First; keep in mind that WiFi (802.11b/g) runs at 2.4 GHz - so do Zigbee and Bluetooth. Add in an old cordless phone (if anyone still has one) and it is a guaranteed recipe for disaster under load - meaning even with ā5 barsā on all devices once you start to run serious traffic across the wireless link the packet retries and interference will increase infinitum giving virtually no throughput and causing a horrible mess for the Zigbee devices also. Z-Wave is a much better player in the current home environment because it runs at 900 MHz. Again, old cordless phones run in this ISM band but there are very few of these left. So in short - Zwave plays nicer when 802.11 b/g are in the house. Now to exasperate that same situation throw 802.11n @ 2.4 GHz into the mix and add to the unpredictable results of everything.
Here are āreal lifeā experience recommendations and the ābestā for a ST home friendly environment: Hardwire as many ābandwidthā intensive devices as possible - i.e. AppleTV, Sonos, any WebTV like thing, video game consoles, etc. If that is impossible then try to use ONLY 5.x GHz WiFi - 802.11a/h/n (you can usually select this option in your wireless access point / gateway / router configuration) this will āclean upā the air for Bluetooth and Zigbee. If you have to keep 2.4 WiFi for certain devices (Wemo is one) then use a separate access point if possible and limit the devices to only those that āhave to have itā and keep them as low bandwidth devices. On that same note - stay away from WiFi extenders and if you have more than one access point (AP) in the home on 2.4 GHz make SURE that the different APs are on channels 1, 6, or 11. Any other configuration is guaranteed to cause doom and unpredictable results.
Hope this helps everyone - trying to āsurveyā your home or pay someone to find the āWiFiā problems is not worth it. The recommendation will be the same as above.
3 Likes
Speaking of the devil (Comca$t), Iāve endured 5 hours of Internet outage today. Needless to say, my āsmartā home became totally dumb in an instant. Fortunately, I donāt use SmartThings for anything āmission criticalā, but these are the times when you realize that you should not take always-on Internet for granted. My Philips Hues stills worked though, which proves how important the local processing is from the user experience standpoint.
2 Likes
Thanks, this is super helpful!
Sorry to hear of your outage, though hopefully not too common for any of us. Being without the internet is bad enough without having to be stuck in the dark or even locked outā¦
One poster mentioned that the mobile apps should probably always run from the cloudā¦ The Hue Bridge is a good example of cloud independence even for UI access, as the hub itself runs a local http / REST-API server that can satisfy most client requests. The cloud is only used for āsceneā sharing and for access from outside your LAN.
So that begs the question of Hub Version 2.0: Can it, possibly, please, serve a user interface (or client API) as well?
One way to handle this is for the Hub 2.0 to serve an HTML5 version of the UI, thus killing two birds with one stone. I think the brilliant folks at SmartThings could make it seamlessly determine how to draw screens using local objects first (like a CDN cache), only going to the cloud (when the cloud is available) to update the cache as new tiles and icons, etc., are added.
ā¦CP / Terry.
It appears from some analysis that @Tyler did yesterday that my problem lies in z-wave land, not zigbee, LAN, Cloud or ISP. In one instance captured in the logs there was a 15 second hiatus between the hub sending a setLevel command (after the roundtrip to the cloud) and the lights actually turning on. So one possibility is that one of my z-wave devices is faulty and somehow drags the z-wave network down. Next challenge will be to find such a device. I have over 65 z-wave dimmers and switches, so itās certainly possible thereās a bad apple. Itās not clear how to find it though!!
4 Likes