Wink gets a poke in the eye

Software 'update' takes down every Wink hub for half a day; "some" haven't recovered and need to be replaced:
http://www.engadget.com/2015/04/19/wink-home-automation-hub-bricked/
Craig
 

Watched a segment this morning on television (which I never watch anyways) about the "cloud" and "subscriptions".  
 
I have stuff here today that I purchased for use and still use this stuff without a monthly subscription (willy nilly stipends).
 
The stuff still works; wonder now if I can call them antiques (well also have some old clocks too from the 1800's that tell time).
 
Maybe Dean (CQC) can reinvent the cloud; patent the name making it propietary "CQC-ICU" or "i SEEYOU-CQC" or something similar....-

Yeah, Wink really shit the bed on this one.  I have one that was being used to control my Z-Wave lock (very successfully) and it is totally bricked.  They are sending me a prepaid box to send it back *and* a $50 coupon to anything in the Wink store.  Good on them for trying to make it right, but terrible execution.
 
I understand why the cloud is used - provide anywhere access, nearly unlimited processing ability and scalability - but I don't understand why local devices can't be controlled locally.

What harm the company had done to itself with this boo-boo may be unrecoverable.  Not only will they face a lot of cost in trying to fix it, but the black eye it gives not only them, but cloud based systems in general will hang in there for some time.

jkmonroe said:

I understand why the cloud is used - provide anywhere access, nearly unlimited processing ability and scalability - but I don't understand why local devices can't be controlled locally.

Click to expand...

 
They certainly can be controlled locally, some folks hacked these hubs to gain access to internal radios, but if you want a device that you pay almost nothing for, the company wants your life's data in exchange.

I understand why the cloud is used - provide anywhere access, nearly unlimited processing ability and scalability - but I don't understand why local devices can't be controlled locally.

Click to expand...

 
They can be controlled locally just fine.
 
I can control your devices locally here in Chicago.
 
Personally I am selfish here with my automation / internet stuff.  The cloud has gotten too loosey goosey for me.
 
Wondering; is it a figment of my newton these days?
 
I take what I want selfishly and do not give anything back curmudgeon wise and can get to my stuff whenever and/or wherever I am at.

:rofl:

pete_c said:

They can be controlled locally just fine.
 
I can control your devices locally here in Chicago.

Click to expand...

jkmonroe said:

I understand why the cloud is used - provide anywhere access, nearly unlimited processing ability and scalability - but I don't understand why local devices can't be controlled locally.

Click to expand...

 
Agreed.  To be able to control stuff in the home while away, all that is really needed amounts to a dynamic DNS service.  The device at home ("hub", "gateway", whatever-you-call-it) contacts a server (securely) to record how to access it.  When I need to connect, I obtain the appropriate address from the server (securely).  After that, all communications are direct to the device; no cloud interaction required.  If the DDNS service goes away, local control continues to work.  It would be nice if one could configure a replacement DDNS service, as well.
 
Craig

jkmonroe said:

I understand why the cloud is used - provide anywhere access, nearly unlimited processing ability and scalability - but I don't understand why local devices can't be controlled locally.

Click to expand...

 

pvrfan said:

Agreed.  To be able to control stuff in the home while away, all that is really needed amounts to a dynamic DNS service.  The device at home ("hub", "gateway", whatever-you-call-it) contacts a server (securely) to record how to access it.  When I need to connect, I obtain the appropriate address from the server (securely).  After that, all communications are direct to the device; no cloud interaction required.  If the DDNS service goes away, local control continues to work.  It would be nice if one could configure a replacement DDNS service, as well.
 
Craig

Click to expand...

Aside from that, when would I ever find myself wishing, "Gee, I sure wish my home automation was in the cloud instead of local"?  At a practical level, I don't see where the value is to end-users.  What am I missing?
 
My internet access is fairly reliable, but it still goes down from time to time.  It's bad enough when the family complains Netflix isn't working, but at least that's unavoidable....

the value is ease-of-use - log into this website or app and configure all of your devices and logic.  
 
it's easy - and to me would be a preferred method - but once i am done with the setup/config, they should be able to push that information back down to my hub/device so it all runs locally.
 
hue is the perfect example of this.  the hub and lights are controlled locally, but i log into the app/cloud to create my scenes and get remote access.  everything i do in the Hue cloud is pushed back to the local hub for local control and access. 

But why would that need to run on their web site? If you run it locally then it can be a native application, and doesn't depend on the internet being up. I can't see any reason for it other than their wanting to make money by knowing what you buy and do (and anything else they can figure out from that.) If it was just for remote connection outside the home, they could provide a simple proxy service for you to use that wouldn't allow them to know anything about you other than that you logged in with a valid user name and password. They could figure out from where of course, but still. They could do everything without the whole cloud thing, so I can't see how it's to anyone's advantage but theirs.

To paraphrase Oliver Wendell Holmes, "Simplicity lies on the other side of complexity."
 
I think the better question is why do it locally; are there real advantages, or only those imagined?
 
As long as the system *runs* locally, I could care less where or how it is configured as long as it's easy.

Mi Casa Verde is a good example of a more expensive yet sluggish platform.  Wink was conceived and shipped before Raspberry Pi 2, back when getting enough oomph into a cheap device might have been unrealistic.  That's a simpler explanation of why Wink was cloud based.  I have a tough time believing datamining of home automation will produce much gold:  maybe in some imagined future, but no time soon.  
 
It's easy to forget that we're all reacting to Wink as it is in the harsh light of today's present context, but on paper, before it was developed and produced, it probably seemed quite compelling for an entry level device at such a low price point.  Aside from Nest, I think Wink may have raised the most money (>$100 million, IIRC).  If the cost of Wink could be made low enough, Wink could be baked into a lot of things (clock radios even) at an even lower incremental cost.  I'm not sure if that was the narrative, but I can see how it might have gotten investors excited enough to buy some equity.  After all, if there is going to be an IoT (admittedly, a big assumption), what's it all going to connect with?  Probably no one can answer that, but it looks like Wink tried to cover all the possibilities by connecting with as many wireless standards as it could.  It didn't require much technical risk at the hardware level to stitch together the different RF interfaces (just have a look at how they did it: http://community.smartthings.com/t/wink-hub-teardown/3288).   Rather, Wink appears to have been a marketing rush to stake out a position as a low-cost multi-standard hub in an attempt to be at the center of things.
 
Anyhow, that's my low-effort conjecture at reconstructing how Wink could have raised so much money and became what it is.  If anyone here happens to know or has a better theory, I'd be interested.

jkmonroe said:

To paraphrase Oliver Wendell Holmes, "Simplicity lies on the other side of complexity."
 
I think the better question is why do it locally; are there real advantages, or only those imagined?
 
As long as the system *runs* locally, I could care less where or how it is configured as long as it's easy.

Click to expand...

 
But, what if you need to change the configuration right now, or for that matter to just even use it right now? It wouldn't have bricked if it didn't depend on their cloud interface.

It bricked because the entire device relies on the cloud.  So on that point I wholly agree - there is no reason that this stuff needs to run in the cloud.
 
My thought is more like taking the Admin Interface, putting it in the 'cloud', then you publish all of your changes back to the local device; everything still runs in my home, just like it does today.  No futzing with firewalls and ports, just clicky-clicky - you could access it from Italy or San Francisco or laying on your couch.
 
Right now this isn't applicable to higher end systems, but there is no reason that it can't be.