Why, oh, why does everyone seem to think that cloud based integration is a good thing? It's the worst possible scenario. You have an automation controller and some Sonos boxes right there, possibly in the same room, but we have to communicate through the entire outside world in order for them to talk to each other, and of course not talk at all if the internet connection is down. It's just ridiculous and I have to wonder if companies really understand the amount of backlash against these cloud based systems is growing out there.
We, and probably every other automation controller vendor, tell clients to avoid cloud based APIs and use devices that let them maintain control of their own systems. Ask for advice on any automation related forum and experienced people will immediately tell you to avoid cloud based APIs.
Maybe my tinfoil hat is too tight, but I can't help but wonder how many of these decisions are based more on data collection driven revenue potential than value for the customer. I fail to see any real benefit to it, and certainly not for automation system vendors.
Page 1 / 1
Hi Dean, it's an interesting discussion to start, though this post didn't quite belong on the topic you posted it on so I've made a new thread for it here so the community can join in.
Personally, I think the biggest benefit to a cloud-based API, the flexibility. We can update a cloud API at any time and have all systems be able to know new commands without any downloading or patching taking place. That allows new features to be added or improved all the time.
Another big one is that some of the oldest Sonos speakers (and other devices as well) don't have a lot of physical memory, and having the cloud manage more things allows us to add features to them that they otherwise wouldn't have the space to learn. A smart remote might not have the memory to know what commands to use for every device out there that it's supposed to work with, but it knows how to talk to its cloud, and that cloud would talk to the others.
Regarding voice control, cloud-based logic systems are often better at identifying the words that are said, and they can learn to identify what's said quicker too. The more certain commands are used, the better they get at picking them up through the background noise.
If it helps, I'm happy to confirm for you that we don't and won't sell any data that is collected by Sonos. The data that is shared with us we use to improve. When features are used a lot, we know that we should keep improving those features and add more depth to them.
Personally, I think the biggest benefit to a cloud-based API, the flexibility. We can update a cloud API at any time and have all systems be able to know new commands without any downloading or patching taking place. That allows new features to be added or improved all the time.
Another big one is that some of the oldest Sonos speakers (and other devices as well) don't have a lot of physical memory, and having the cloud manage more things allows us to add features to them that they otherwise wouldn't have the space to learn. A smart remote might not have the memory to know what commands to use for every device out there that it's supposed to work with, but it knows how to talk to its cloud, and that cloud would talk to the others.
Regarding voice control, cloud-based logic systems are often better at identifying the words that are said, and they can learn to identify what's said quicker too. The more certain commands are used, the better they get at picking them up through the background noise.
If it helps, I'm happy to confirm for you that we don't and won't sell any data that is collected by Sonos. The data that is shared with us we use to improve. When features are used a lot, we know that we should keep improving those features and add more depth to them.
Automatic upgrades are also very bad. It's the absolute last thing that any automation system vendor or automation system installer wants. What they want is happy customers with very stable systems, which automatic, forced updates are not amenable to. You can see me complaining in another section right now about how a forced update just broke our Sonos driver, and our Sonos customers are out in the cold because they can't prevent it or roll it back.
As to voice control. As I said, feel free to provide an optional interface for those folks want something simple. But, in a real automation system, the voice control will go through the automation system, which is far better placed to deal with that (because it can see everything and coordinate all devices to achieve some goal.)
I will also say that Oauth2 is a bad protocol for automation systems. It's phone app oriented, where some company is selling a phone app to users to access their Sonos. Automation systems don't work like that. There's no app, and there's often no web site to redirect back to, because there's no company server on which any user information or accounts or anything is stored. It's all local to the residence or business which has no publicly accessible target to redirect to. You need to provide a means for the user to do the process and get the token themselves which they can just past into the driver configuration when they install it. Nest does it this way and it's very straightforward (though most else about them is no more automation system friendly than your new API is.) Obviously you can support the regular Oauth2 scheme for those folks who can make use of it.
You guys seem to want to support the pro market, but everything you are doing is really the worst stuff possible to support it. I hate to seem overly negative, but it is what it is. There's a fair bit of discussion out there in the DIY and installer communities about looking to move on beyond Sonos because of these sorts of things.
As to voice control. As I said, feel free to provide an optional interface for those folks want something simple. But, in a real automation system, the voice control will go through the automation system, which is far better placed to deal with that (because it can see everything and coordinate all devices to achieve some goal.)
I will also say that Oauth2 is a bad protocol for automation systems. It's phone app oriented, where some company is selling a phone app to users to access their Sonos. Automation systems don't work like that. There's no app, and there's often no web site to redirect back to, because there's no company server on which any user information or accounts or anything is stored. It's all local to the residence or business which has no publicly accessible target to redirect to. You need to provide a means for the user to do the process and get the token themselves which they can just past into the driver configuration when they install it. Nest does it this way and it's very straightforward (though most else about them is no more automation system friendly than your new API is.) Obviously you can support the regular Oauth2 scheme for those folks who can make use of it.
You guys seem to want to support the pro market, but everything you are doing is really the worst stuff possible to support it. I hate to seem overly negative, but it is what it is. There's a fair bit of discussion out there in the DIY and installer communities about looking to move on beyond Sonos because of these sorts of things.
I run dozens of automated scripts nightly against cloud based systems using OAuth authentication. One time manual configuration, after which refresh tokens allow secure, automated logins. It's pretty standard for cloud systems these days, no better alternative that I'm aware of.
I assume you don't mean you do the initial operation via a script, right? If you do mean that, then I clearly don't understand Oauth2 because that would make it completely insecure. It's that initial one that is the issue. It assumes there's some web site to redirect back to to send the information. But there often isn't, and they weren't on any web site to begin with either. They aren't asking for access for some application of ours that uses our Sonos account. They have their own and are just installing a driver, which has no GUI component at all.
Maybe I'm misunderstanding that as well, and the final redirect isn't necessary in order to get the final information required. But, if not, why is it required and why does it have to be secure?
What Nest does is use a variation of Oauth2 which works quite well. The user does the initial operation and gets a PIN number. They give us that PIN and we can generate an access token from that on our own. There's no need for a redirect URL or anything of that nature at that point. And we can generate a new token from the PIN as required. The user can invalidate that PIN any time he wants and that invalidates all tokens generated from it.
That works out quite well for the automation system scenario.
Maybe I'm misunderstanding that as well, and the final redirect isn't necessary in order to get the final information required. But, if not, why is it required and why does it have to be secure?
What Nest does is use a variation of Oauth2 which works quite well. The user does the initial operation and gets a PIN number. They give us that PIN and we can generate an access token from that on our own. There's no need for a redirect URL or anything of that nature at that point. And we can generate a new token from the PIN as required. The user can invalidate that PIN any time he wants and that invalidates all tokens generated from it.
That works out quite well for the automation system scenario.
A sample comment from one of our customers just posted:
"It makes no difference, that option only allows you to defer updates for a little while, then they are forced on you. Trust me, I've tried. It is infuriating - when I started my collection of Sonos speakers years ago, there were very few updates, mostly just little fixes about once a year, but now they are so intrusive and SO frustrating when you've paid good money and have no control over your own kit!"
That's why forced automatic updates are bad. If people cannot maintain a stable system, and they can't even control when they have to deal with some known upcoming issues but have it suddenly forced on them when they aren't ready, that really doesn't sit well with most folks.
Of course if you didn't break things, or remove functionality and so forth, that would be another thing. But I can't imagine that you guys ever even bother to test the UPnP interface against a Windows UPnP client, since there's been multiple UPnP breakages over the years. We worked around some by taking over more of the UPnP functionality ourselves, but this time we can't and will have to remove functionality because the DeviceProperties services description file is causing a failure.
"It makes no difference, that option only allows you to defer updates for a little while, then they are forced on you. Trust me, I've tried. It is infuriating - when I started my collection of Sonos speakers years ago, there were very few updates, mostly just little fixes about once a year, but now they are so intrusive and SO frustrating when you've paid good money and have no control over your own kit!"
That's why forced automatic updates are bad. If people cannot maintain a stable system, and they can't even control when they have to deal with some known upcoming issues but have it suddenly forced on them when they aren't ready, that really doesn't sit well with most folks.
Of course if you didn't break things, or remove functionality and so forth, that would be another thing. But I can't imagine that you guys ever even bother to test the UPnP interface against a Windows UPnP client, since there's been multiple UPnP breakages over the years. We worked around some by taking over more of the UPnP functionality ourselves, but this time we can't and will have to remove functionality because the DeviceProperties services description file is causing a failure.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.