I have to wonder why. Planned obsolescence is an obvious answer, but if the new "standard" methods for controlling the speakers are smartphones or Alexa, it doesn't seem like they gain much from the switch. Is the protocol used by the CR100 that much of a pain to keep supporting? It makes me wonder about their software development practices.
They're also claiming in the forum thread it's because of battery issues (battery getting older, more at risk for device to malfunction, etc). Seems like a bad reason to brick a device (and was likely made up once it was decided not to support)
Note: planned obsolescence is illegal in France. I think French customers would have a quite strong case to make under that law. Sonos gives the possibility not to upgrade, so they might get away with it, but it's hard to know in advance.
The first effects of a world of end-to-end encrypted media streaming. You don’t own the content, you don’t own the hardware, you can’t play whatever you want, you just pay and go with whatever happens to be there. You can change channels like a Radio, that’s about it
Isn't that life anyway? We're only on earth for a short time. You can't take your music to the grave with you, so why not accept its never really yours anyway?
This isn't about accepting it's "not really yours". This is about accepting it's actually someone else's that then has control about what you can and can't do. That entity will often be on earth for even a smaller time than you before it goes bankrupt or loses interest in that product. So you get to spend your short time on earth dealing with product obsolescence instead of owning your stuff while you're alive and even being able to pass it on to your children. It's a terrible bargain.
No, it isn't. You don't need to take your music to the grave, those who come after you can inherit it. It can be 'yours' if you want it, as long as you managed to avoid the traps set by those who'd like you to believe there is no other way so you might as well accept it and just pay, and pay, and pay again.
well, if you were careful enough when you bought that "The Dark Side of the Moon" LP vinyl you'd have a collectors item but - most importantly - a media record you can play anytime you want without having had to pay thousands over the course of a lifetime. Just a little cash 44 years ago.
Really? I have my grandfathers and fathers vinyl records. They still play just fine. I'll give them to my daughter. Probably still going to play just fine. That's not going to change because Chess Records is out of business or Universal decided to change the EULA when it bought Motown.
I expect any and all features of my Sonos speakers to possibly stop working except the local music library. If they ever stop that, I and others will file class action lawsuits at the very least. When the dust finally settles, that will probably be the only service still working anyway in the not so distant future. It's sad that the commercial market cannot and will not create worthwhile music services that are worth paying for in the long term. If my favorite songs disappear from the online library every few months, why should I pay a monthly fee? This happens on every service and is a categorical failure of the system's only purpose, to keep my favorite songs available. I'll take my NAS over those systems any day.
>If they ever stop that, I and others will file class action lawsuits at the very least.
The complete failure case for Sonos is the company stops existing or discontinues the product line and your devices are all stuck at whatever software version was the last, possibly useless after security issues or other software rot. There's no reason (and possibly no entity) to sue when that happens.
As long as it still plays shit off my NAS, I don't care. And I don't see why it wouldn't, whether the company exists or not. That's what I was trying to convey above.
Because your new NAS no longer supports the old protocol. Because there was a security issue that's too serious to allow you to keep it on without a fix. Because...
Sure, but we're moving from a time where your audio gear was something you could fix and would last for decades to having these kinds of devices where software support may last a very short time. If you're ok with that tradeoff that's fine. Personally I'm not.
Well why is it irrelevant. It used to be you ditched your receiver or player when it was irreparably broken, not when Sony or Technics decided they’d had enough supporting your hardware. Here you have hardware that is useless without a software service that gets discontinued or it’s utility modified after-sale. For now users can stay on current firmware but that depends on whenever Sonos will pull a Sony PlayStation move and force an update to continue access to DRM’d music
But this is why lithium ion batteries need special lithium ion charging circuitry in the first place... If you don't have this, the cells will happily take as much energy as you give them and then promptly catch fire.
It doesn't make sense to me that this would only now be a problem. Either the circuit was designed correctly, and this excuse is bullshit, or they should have issued a recall ten years ago.
You are probably thinking of NiCad and to some extent NiMH simple constant current chargers. If you do that with a lithium battery you will have problems pretty much right away, possibly involving fire.
If you buy into a proprietary ecosystem, especially a DRM-encumbered one, and doubly-especially a streaming one, don't be surprised when the inevitable happens and your non-ownership of any part of the system bites you.
I speak from personal experience. I lost some of my small Kobo library when they dropped support for their Web reader, and I closed my account (no support for my everyday / work laptop).
I'm an FSF supporter (technically FSFE), but I think we should be careful about these claims. It's not like open source projects never drop features. You could say "yeah, but they wouldn't be forced to upgrade" - but neither are the users in this case, as the reply says.
What the users here want is to continue getting the new features and fixes of the new versions of firmware, while keeping support for the CR100. Even with the source, that would require someone to integrate those two parts, which might be prohibitively expensive.
Don't get me wrong, I think they should have the right to do that if they wished, but it's not like it would just fix the problem; it would only allow them to fix it if they could afford it.
With free software no one can shut down a service like they are doing. A product will continue to function and it will continue to receive updates as long as there is enough interest by the open source community in that product.
Let's take for example Android smartphone, there are some old smartphone that thanks to the community are still updated to the latest version of the OS, on the other side when Apple say it's done you take your outdated iPhone and toss it in the bin, no one can continue to support it.
They aren't shutting down a service, they are updating a product. Specifically, they are releasing a new version of the speakers firmware that removes support for the protocol used by CR100.
All you wrote regarding Android is true, and that's why as I said I support the FSF and Free Software in general, all I'm saying is that you can't take that community for granted. Maybe someone would appear to re-add support for the CR100 to the new firmware - or maybe nobody would.
I’m against bricking devices arbitrarily, but this product was more than 12 years old and hadn’t been sold since 2009 (I had one in 2006 when I was still in college and Sonos’s killer feature for me was that it worked with the original streaming music service, Rhapsody). Frankly, giving customers $100 credit seems kind to me. Plus the CR200 still works and they don’t have plans to brick it, so there is that.
I feel for some of the users, but reading some of these complaints makes me roll my eyes. I’ve owned lots and lots of electronic devices over my life — and many audio systems — I can’t recall any other connected system having 13 years of support.
I think what we're trying to rail against here is that why should 13, or whatever, years be an acceptable figure.
My car is older than that. My toaster over is old, I've had CRT TVs that were much older before they died.
I'm gonna go with a big fat juicy 'No!' here. We ought to be building for longevity and serviceability. Don't end support, just open it up. Publish the relevant source code, documentation etc.
We shouldn't accept that it's ok or normal to dispose of a thing just because it is X years old.
It’s an accessory. If we were talking about the speakers themselves, I wouldn be more sympathetic, but in this case I’m just not.
The reality is that the nature of connected devices makes things different. This isn’t the same as a CRT TV (but also, look at how much it costs and how difficult it is get parts for a CRT in 2018). And like it or not, your next car won’t be as repairable as your current 15 year old car, because it will require custom software and bench access and updates that most mechanics will not pay for or maintain.
At least these Sonos users have the option of not installing an update. This isn’t like Revolv where it just stopped working.
The CR100 uses Flash IIRC...it is absolutely ancient. I’m not sure we should be realistically asking development teams to maintain separate code bases for old, obsolete software. Google and Amazon changed backends that made the CR100 stop working. Are you saying that that’s a travesty too?
Legit question: how long should any company/service be required to add backward compatibility to old, obsolete products?
I fundamentally agree that we should be building for longevity and serviceability, but that isn’t always possible. The platform and stack the CR100 was built on is not modern and cannot be easily maintained. And even if the software was open source (which would be great), that doesn’t change the fact that if the endpoints on the services it relies on change, nothing can be done.
The only reasonable compromise I can see would be an update that would allow the CR100 to continue to work only with local files. Otherwise, at least users can opt not to update if they rely so heavily on a 13 year old controller.
> And like it or not, your next car won’t be as repairable as your current 15 year old car, because it will require custom software and bench access and updates that most mechanics will not pay for or maintain.
Noting that the automotive market is increasingly opening itself up to the kind of obsolescence problems the software industry has never bothered to come to grips with (indeed, is to some extent actively against solving, from incentives at the business level to personal disinclination on the part of most programmers) isn't exactly a resounding counterpoint to worries about how software problems are affecting less crucial hardware devices.
> Legit question: how long should any company/service be required to add backward compatibility to old, obsolete products?
There's a point in here that's legit: perpetuity is a high bar, most products don't last forever. But there's also an extent to which this question is largely a dodge of the real question: what is "old"? Why do we accept or feel forced to accept a decade or shorter timeline?
> we should be building for longevity and serviceability, but that isn’t always possible. The platform and stack the CR100 was built on is not modern and cannot be easily maintained.
You know how we talk about code smells? (Or maybe we don't anymore, it was always a weird term and maybe it's so early 10s now). Pretty sure the word "modern" when it comes to software should be understood as a "thought smell."
Every platform/stack any software is built on will be "not modern" by software standards in well under a decade, and is quite likely to grow more difficult to maintain over time. An acknowledgement of the value of longevity and serviceability doesn't mean much while implicitly accepting software-related value choices that mean longevity and serviceability remain not only difficult to attain but difficult to conceive of.
> And even if the software was open source (which would be great), that doesn’t change the fact that if the endpoints on the services it relies on change, nothing can be done.
If the software were open source, when endpoints change, the threshold for continuing utility is whether there's a developer out there somewhere who cares enough to work on it. Or could be made to care by consumers bearing cash.
My car is older than that. My toaster over is old, I've had CRT TVs that were much older before they died.
Moreover, the audio equipment community that they're clearly targeting these things at definitely loves its old equipment: and for good reason, because good audio equipment lasts a very long time.
Because they rely on a network of connected services to function and those services can’t be expected to maintain endpoints and compatibility with old, insecure, technology.
Sonos is a closed system; AFAIK CR100s don't connect directly to the outside world; all Sonos has to do in order to support CR100s is to not actively disable them.
I have computers built in the mid-80s through 90s that I can connect to securely over an IP network. The idea that it can't be done is the party-line of companies that don't want to invest in doing it. If that's you're business model, fine, but be up front that you're going to screw your customer every couple of years.
Giving customers $100 of credit that can only be used to buy your products because you've disabled something they've bought that you don't sell any kind of meaningful replacement for anymore doesn't sound that generous. Especially since CR200s sell for closer to $150 on eBay, a figure that may well go up now that everyone with a CR100 needs to replace it, and there's no guarantee that won't be discontinued too.
If every tech device over 12 years old I have stopped working tomorrow, I would be in a heap of trouble.
That's the thing with streaming devices: they are dependent on external support for basic functionality, and manufacturers can arbitrarily decide (or be forced) to cut that support arbitrarily.
Plus the CR200 still works and they don’t have plans to brick it
As far as I understand, it all works in the local network. It shouldn't be too hard to create a server to translate its calls to the new api (that the smartphone app uses), no?
edit: I don't understand why you'd down-vote this. I'd love to correct it if I said something blatantly wrong, just tell me. Also, I wasn't dismissing this as a non-problem, but rather questioning if there'd be an easy solution. My parents are also affected BTW.
Maybe. Apparently they use a non-standard wireless networking protocol called Sonosnet. They do have "bridges" to connect to a regular Wifi or ethernet network, but it's not clear to me if the CR100 can use those to connect to the speakers (and hence to the hypothetical "fake speaker" server).
I'm sure all of this is reverse engineerable, but it might be less work to build everything from scratch :)
Their main concern sounds like a liability issue (they cite the aging Li-ion battery heavily). They're not selling it anymore, so why not bundle together some internal docs and release some sort of technical manual or detailed repair guide to give users the option of replacing the battery? Of course this would be a "you people are on your own if you screw it up" but that's to be expected.
> Their main concern sounds like a liability issue (they cite the aging Li-ion battery heavily)
Gratuitous power autonomy is quite high on my "things I won't buy" list. I was once scouring Amazon et al for some cheap bluetooth speakers for stationary use as a "poor man's Sonos", but they all came with their own integrated power bank. Ended up buying a radio that had BT input just as a secondary feature. About three times as expensive as originally planned, only to avoid seeing one more 18650 (or pair thereof) idling into decay under my watch.
I'm not always that eco-aware, but when I get stuck on an issue I tend to get irrationally zeaolous (probably a quite common form of mild bigotry)
I'm getting really sick of appliances depending on smartphone apps, they're brittle as hell and have no longevity as OS updates kill them off (and eventually as mobile OS's die completely).
I had a right faff on finding a IP security cam that didn't use the bloody awful onVIF protocol and would connect to a network without a mobile app to configure it. I take care of remote access myself, so I don't need the "feature" of having my video streams routed through a server in china so I can view it on the go.
I had the same issue with RGB lighting controllers for my shelving and bookcase, in the end I had to settle on a ESP8266 based controller and figure out the protocol with wireshark, I now have some of my lighting operable from a webpage on my home server.
I really wish there were a decent, privacy respecting hub that could be used for controlling all of this kind of gear.
Its one of these, unfortunately you still need the app to get it to connect to your network, but from then on you can fire packets at it to change the colours.
There is a python library up on github for interfacing with it, and I think there might be alternate firmware for its microcontroller available.
I really wish more of this home automation gear would use powerline networking, no need to faff around with WiFi settings.
It's how it used to work, X10 home automation. Incredibly primative but considering we can run Ethernet over the houses electrical wiring now it's a more elegant solution.
I have some sonoff wireless power switches for my living room lamps, they keep losing their wireless connection and need power cycling.
I don't know if it's crappy firmware of if it's the usual unreliability and fickleness of WiFi.
I've been through several ONVIF cameras which did provide RTSP but only at 240p resolution. Now I go straight for a camera with a web interface and exclusive RTSP output.
I take care of remote access myself, so I don't need the "feature" of having my video streams routed through a server in china so I can view it on the go.
Ironically, if you want a "pure" IP camera, one that you connect to directly, the best way to find one (and "try it out" too) is to look at the models of those that people have exposed to the Internet --- either deliberately or accidentally:
I bought my first Sonos elements in 2006, and used to love them.
I still use Sonos, for lack of a better option (?) but have come to hate it, the devices, the company, the whole "ecosystem", with the heat of a thousand suns.
It updates constantly, you can't ever refuse an update, updates stop the system just when you need to use it, change the UI for no reason, and every update breaks something. Every single iteration is a little slower; I used to keep an oldish ipod touch just to manage Sonos but now it's so slow it's almost unusable.
Since 2006 my use of Sonos HAS NOT CHANGED AT ALL: mp3s are stored on a Nas and they're played in various "rooms"; and sometimes I listen to radios; and THAT'S IT.
Of course Sonos as a company has to support new streaming services and whatnot, but why does it have to break everything in the process, or force all users to upgrade? Why can't it leave us alone??
Every 6 months I try to look for an open source alternative, maybe based on a Pi (+ relay to power up amps on demand) but have not been very lucky so far. Am very interested in any pointers to something simple to implement and that I would completely control.
I have exactly the same feeling. It feels like every time I go to cook in the kitchen and open the app on my phone, it brings the update process up. Numerous times, i've lost connectivity entirely, which seems to only be fixed by deleting the app from my phone, re-installing, signing back in, going back through the basic pairing process. It just makes me want to throw the whole thing out. It's beyond maddening!!
Why can't it support bluetooth without purchasing the stupid bridge? Sometimes I want to watch Netflix when cooking and have the audio come out the system. Somebody should bring out a decent competitor to fix these issues. I'd buy it in a heartbeat.
I'm quite happy with a squeezebox server running on a linux computer, and music streamed to a Squeezebox Radio. Sadly these cannot be bought anymore, but there is a chromecast plugin that works with squeezebox server - I can then stream to a chromecast audioplug + powered speaker (edifier 1280T). Unfortunately the edifier does not have USB for chromecast power, but the sound is pretty decent. I've also streamed to a sony SRS-X 77 with a bit less success, there are occasional wifi dropouts.
> due the age of the battery in the controller, it has the potential to overheat when left charging for extended periods of time
This is some argument on Sonos' part! The reason why the battery in the CR100 is "old" is because Sonos chose to build a device with a non-replaceable battery!!
If they're so concerned about safety why don't they offer to replace the batteries (for a reasonable fee)??
According to some of the posters in that Sonos forum thread, aftermarket batteries are available for the CR100. What I'm not sure about is how easy they are to replace, but it's clearly possible for some users.
It’s not hard to replace; probably the hardest part is separating the adhesived back rubber cover and then sealing it again after. The battery uses a modular connector.
So, end users are now figuring out why it's bad to buy into such proprietary, closed systems. I can fully understand the outrage. Unfortunately I find that most people don't care if you warn them about such things beforehand.
Any product that relies on a manufacturer-only provided online service of any kind to provide its functionality, will simply stop functioning whenever the manufacturer feels like it (or goes out of business, etc). Oh, and it will also most likely not care about your privacy, but that's a given these days.
Also, any product relying on a closed-source smartphone app (using proprietary protocols to communicate with the product) will also become increasingly annoying as time passes. At some point, the app won't get updates anymore, and some time after that you'll have to keep a special old smartphone around just for the purpose of running that app. Sounds great, eh?
On the other hand, many 30, 40, 50 years old electronics products still work fine today, and can be used, as they were self-contained, and wholly owned (and fixable) by the user.
p.s. the fact that ageing batteries are cited as reason by Sonos also further shows what a stupid idea it is to put non-replaceable batteries into products. I really hope that regulation will finally end that practice soon.
66 comments
[ 2.8 ms ] story [ 194 ms ] threadhttp://www.techradar.com/news/sonos-finally-kills-off-cr100-...
--
I have to wonder why. Planned obsolescence is an obvious answer, but if the new "standard" methods for controlling the speakers are smartphones or Alexa, it doesn't seem like they gain much from the switch. Is the protocol used by the CR100 that much of a pain to keep supporting? It makes me wonder about their software development practices.
The complete failure case for Sonos is the company stops existing or discontinues the product line and your devices are all stuck at whatever software version was the last, possibly useless after security issues or other software rot. There's no reason (and possibly no entity) to sue when that happens.
Because your new NAS no longer supports the old protocol. Because there was a security issue that's too serious to allow you to keep it on without a fix. Because...
I have Bluetooth speakers in my rooms and Spotify and Radio apps on my phone / tablet. Cheap and easy.
...uh, what? I assume I'm missing something here, because this doesn't make any sense. Can someone explain?
It doesn't make sense to me that this would only now be a problem. Either the circuit was designed correctly, and this excuse is bullshit, or they should have issued a recall ten years ago.
https://xkcd.com/743/
If you buy into a proprietary ecosystem, especially a DRM-encumbered one, and doubly-especially a streaming one, don't be surprised when the inevitable happens and your non-ownership of any part of the system bites you.
I speak from personal experience. I lost some of my small Kobo library when they dropped support for their Web reader, and I closed my account (no support for my everyday / work laptop).
What the users here want is to continue getting the new features and fixes of the new versions of firmware, while keeping support for the CR100. Even with the source, that would require someone to integrate those two parts, which might be prohibitively expensive.
Don't get me wrong, I think they should have the right to do that if they wished, but it's not like it would just fix the problem; it would only allow them to fix it if they could afford it.
Let's take for example Android smartphone, there are some old smartphone that thanks to the community are still updated to the latest version of the OS, on the other side when Apple say it's done you take your outdated iPhone and toss it in the bin, no one can continue to support it.
All you wrote regarding Android is true, and that's why as I said I support the FSF and Free Software in general, all I'm saying is that you can't take that community for granted. Maybe someone would appear to re-add support for the CR100 to the new firmware - or maybe nobody would.
But I can't find any open source solutions, hooking into the chrome cast protocol seems impossible as all receivers must be signed by Google.
I feel for some of the users, but reading some of these complaints makes me roll my eyes. I’ve owned lots and lots of electronic devices over my life — and many audio systems — I can’t recall any other connected system having 13 years of support.
My car is older than that. My toaster over is old, I've had CRT TVs that were much older before they died.
I'm gonna go with a big fat juicy 'No!' here. We ought to be building for longevity and serviceability. Don't end support, just open it up. Publish the relevant source code, documentation etc.
We shouldn't accept that it's ok or normal to dispose of a thing just because it is X years old.
The reality is that the nature of connected devices makes things different. This isn’t the same as a CRT TV (but also, look at how much it costs and how difficult it is get parts for a CRT in 2018). And like it or not, your next car won’t be as repairable as your current 15 year old car, because it will require custom software and bench access and updates that most mechanics will not pay for or maintain.
At least these Sonos users have the option of not installing an update. This isn’t like Revolv where it just stopped working.
The CR100 uses Flash IIRC...it is absolutely ancient. I’m not sure we should be realistically asking development teams to maintain separate code bases for old, obsolete software. Google and Amazon changed backends that made the CR100 stop working. Are you saying that that’s a travesty too?
Legit question: how long should any company/service be required to add backward compatibility to old, obsolete products?
I fundamentally agree that we should be building for longevity and serviceability, but that isn’t always possible. The platform and stack the CR100 was built on is not modern and cannot be easily maintained. And even if the software was open source (which would be great), that doesn’t change the fact that if the endpoints on the services it relies on change, nothing can be done.
The only reasonable compromise I can see would be an update that would allow the CR100 to continue to work only with local files. Otherwise, at least users can opt not to update if they rely so heavily on a 13 year old controller.
Noting that the automotive market is increasingly opening itself up to the kind of obsolescence problems the software industry has never bothered to come to grips with (indeed, is to some extent actively against solving, from incentives at the business level to personal disinclination on the part of most programmers) isn't exactly a resounding counterpoint to worries about how software problems are affecting less crucial hardware devices.
> Legit question: how long should any company/service be required to add backward compatibility to old, obsolete products?
There's a point in here that's legit: perpetuity is a high bar, most products don't last forever. But there's also an extent to which this question is largely a dodge of the real question: what is "old"? Why do we accept or feel forced to accept a decade or shorter timeline?
> we should be building for longevity and serviceability, but that isn’t always possible. The platform and stack the CR100 was built on is not modern and cannot be easily maintained.
You know how we talk about code smells? (Or maybe we don't anymore, it was always a weird term and maybe it's so early 10s now). Pretty sure the word "modern" when it comes to software should be understood as a "thought smell."
Every platform/stack any software is built on will be "not modern" by software standards in well under a decade, and is quite likely to grow more difficult to maintain over time. An acknowledgement of the value of longevity and serviceability doesn't mean much while implicitly accepting software-related value choices that mean longevity and serviceability remain not only difficult to attain but difficult to conceive of.
> And even if the software was open source (which would be great), that doesn’t change the fact that if the endpoints on the services it relies on change, nothing can be done.
If the software were open source, when endpoints change, the threshold for continuing utility is whether there's a developer out there somewhere who cares enough to work on it. Or could be made to care by consumers bearing cash.
Moreover, the audio equipment community that they're clearly targeting these things at definitely loves its old equipment: and for good reason, because good audio equipment lasts a very long time.
That's the thing with streaming devices: they are dependent on external support for basic functionality, and manufacturers can arbitrarily decide (or be forced) to cut that support arbitrarily.
Plus the CR200 still works and they don’t have plans to brick it
You can't be serious.
The speakers still work. There is an app.
I would agree if it were the speakers. It’s not. It’s a remote that hasn’t been sold in almost ten years.
edit: I don't understand why you'd down-vote this. I'd love to correct it if I said something blatantly wrong, just tell me. Also, I wasn't dismissing this as a non-problem, but rather questioning if there'd be an easy solution. My parents are also affected BTW.
I'm sure all of this is reverse engineerable, but it might be less work to build everything from scratch :)
Gratuitous power autonomy is quite high on my "things I won't buy" list. I was once scouring Amazon et al for some cheap bluetooth speakers for stationary use as a "poor man's Sonos", but they all came with their own integrated power bank. Ended up buying a radio that had BT input just as a secondary feature. About three times as expensive as originally planned, only to avoid seeing one more 18650 (or pair thereof) idling into decay under my watch.
I'm not always that eco-aware, but when I get stuck on an issue I tend to get irrationally zeaolous (probably a quite common form of mild bigotry)
I had a right faff on finding a IP security cam that didn't use the bloody awful onVIF protocol and would connect to a network without a mobile app to configure it. I take care of remote access myself, so I don't need the "feature" of having my video streams routed through a server in china so I can view it on the go.
I had the same issue with RGB lighting controllers for my shelving and bookcase, in the end I had to settle on a ESP8266 based controller and figure out the protocol with wireshark, I now have some of my lighting operable from a webpage on my home server.
I really wish there were a decent, privacy respecting hub that could be used for controlling all of this kind of gear.
I'd love to do something similar in my own home
Its one of these, unfortunately you still need the app to get it to connect to your network, but from then on you can fire packets at it to change the colours.
There is a python library up on github for interfacing with it, and I think there might be alternate firmware for its microcontroller available.
I really wish more of this home automation gear would use powerline networking, no need to faff around with WiFi settings.
I have some sonoff wireless power switches for my living room lamps, they keep losing their wireless connection and need power cycling.
I don't know if it's crappy firmware of if it's the usual unreliability and fickleness of WiFi.
What's wrong with ONVIF?
Even if you don't have a use for the extra features it provides it guarantees you'll get an RTSP URL you can use.
It's been my experience that the ones that don't advertise ONVIF support are the ones that require cloud-connected or proprietary crap.
Ironically, if you want a "pure" IP camera, one that you connect to directly, the best way to find one (and "try it out" too) is to look at the models of those that people have exposed to the Internet --- either deliberately or accidentally:
http://www.insecam.org/en/
I still use Sonos, for lack of a better option (?) but have come to hate it, the devices, the company, the whole "ecosystem", with the heat of a thousand suns.
It updates constantly, you can't ever refuse an update, updates stop the system just when you need to use it, change the UI for no reason, and every update breaks something. Every single iteration is a little slower; I used to keep an oldish ipod touch just to manage Sonos but now it's so slow it's almost unusable.
Since 2006 my use of Sonos HAS NOT CHANGED AT ALL: mp3s are stored on a Nas and they're played in various "rooms"; and sometimes I listen to radios; and THAT'S IT.
Of course Sonos as a company has to support new streaming services and whatnot, but why does it have to break everything in the process, or force all users to upgrade? Why can't it leave us alone??
Every 6 months I try to look for an open source alternative, maybe based on a Pi (+ relay to power up amps on demand) but have not been very lucky so far. Am very interested in any pointers to something simple to implement and that I would completely control.
Why can't it support bluetooth without purchasing the stupid bridge? Sometimes I want to watch Netflix when cooking and have the audio come out the system. Somebody should bring out a decent competitor to fix these issues. I'd buy it in a heartbeat.
This is some argument on Sonos' part! The reason why the battery in the CR100 is "old" is because Sonos chose to build a device with a non-replaceable battery!!
If they're so concerned about safety why don't they offer to replace the batteries (for a reasonable fee)??
https://en.community.sonos.com/advanced-setups-229000/guide-...
Any product that relies on a manufacturer-only provided online service of any kind to provide its functionality, will simply stop functioning whenever the manufacturer feels like it (or goes out of business, etc). Oh, and it will also most likely not care about your privacy, but that's a given these days.
Also, any product relying on a closed-source smartphone app (using proprietary protocols to communicate with the product) will also become increasingly annoying as time passes. At some point, the app won't get updates anymore, and some time after that you'll have to keep a special old smartphone around just for the purpose of running that app. Sounds great, eh?
On the other hand, many 30, 40, 50 years old electronics products still work fine today, and can be used, as they were self-contained, and wholly owned (and fixable) by the user.
p.s. the fact that ageing batteries are cited as reason by Sonos also further shows what a stupid idea it is to put non-replaceable batteries into products. I really hope that regulation will finally end that practice soon.