My initial feeling is that nearly all events are at the same high-priority level in the Home Automation use case. A motion detector or button that activates a light, or a presence sensor that opens a lock … both need to have sub-second response time in order to maintain an acceptable live-user experience.
But that leaves me thinking: What could be “lower priority events”? I think most (?) scheduled events are lower priority that live actuated events; IMHO. If I have my lights to turn on at Sunset, if they turn on 10 seconds or even a few minutes after Sunset it doesn’t really matter.
Another scheduled event example might be the timeout on a motion detector … There are SmartApps which shut off a light or close a garage door, etc., a certain number of seconds or minutes after motion activity ceases. I think these have a few seconds of tolerance, but not minutes.
One thing to consider as well is that you have a lot of information passing from devices to the hub that are event related. ST Multi-Sensors are being polled for temp, contact, etc… Aeon Multi Sensors are doing motion, light, humidity. The list goes on. If it were me, here’s the order I’d go in.
Manually triggered events
Events triggered by schedule
Device polling
Now, on the other hand… Is registering that a door was opened at your (supposedly empty) house just as important as making sure someone lights are turned on? Does that heat spike and light jump in your house mean what you think it means?
So I don’t know. Device polling and keeping stuff on schedule and everything else in a lot of ways is just as high a priority as manually flipped switches in the app. I guess I see where you could prioritize, but I certainly can see why they aren’t as well.
I don’t think there’s enough data moving around to require QoS in the traditional sense, but I think ST is going to have to rethink their infrastructure (if they’re not doing os already) to keep up with demand.
I have a 30-40ms ping to their border and a 50 megabit connection, and only a handful of devices, so things should run as smoothly as possible for me, yet I see a lot of time-based events delayed by minutes, and when there’s the occasional hiccup then some things just won’t work. My problem is not bandwidth, nor latency, but instead it’s fighting with the tons of other requests hitting the ST infrastructure at particular times.
We need QoS, but more along the lines of better transaction management for events and better handling of failures whenever something doesn’t go right.
Agree. The ST status page could show an automatic graph of cloud latency or loss, and an individual manual user-initiated test of round-trip command lag or loss, among other metrics.
I often wonder if the statuses are manually updated and out-of-date. Because I only check when I have an issue (yes the wall switch is on), and all the statuses are green.
But I don’t have to check often. Every 3-4 weeks.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
6
Agreed – that ties in very closely with a recent post to this other Topic thread:
The major positive impact that SmartThings Hub Version 2.0 will provide is local caching and execution of all SmartApps that do not require any services external to the LAN. SmartThings will still be “cloud-centric”, but this is new hub v2 architecture should bring tremendous benefits in performance and reliability.