Wink down! Another one bites the dust.
Things in the smart home space aren't going as I predicted 2-3 years ago. But, strangely, much of my advice since remains fairly pertinent.
I bet the Sonos people are feeling a little less jilted now though.
Anyway, the Wink move sucks. I don't really follow the company, so I can't really claim to have seen it coming. But, when Nest basically abandoned updating their API for years and Google sucked them into the fold the writing was on the wall for me. Google is a profitable company. I'm not sure how the Nest division stacks up, but I can say that with some basic effort on Google's part, that division could be profitable even if it isn't currently. There was no *need* to do that to it.
And so, I decided at the time that happened that would slowly invest in smart home solutions which weren't tied to other companies clouds. It remains one of the primary reasons I see Ikea as one of the safest bets in smart home. They use an industry standard protocol (ZigBee), the hub only reaches out to the internet for updates and the parent company created it as something complimentary to their primary business. They didn't buy a company and hope to profit, or create this division and hope for it to fund everything.
The big problem is that none of the big players are taking the Ikea approach.
What makes Wink costly to sustain is their cloud. Ikea's operating costs for their smart home are likely pennies on the dollar to what Wink needs to spend.
Smart Things is likely also not profitable in and of itself. But, Samsung is a much bigger, more divers entity than Wink and can use it as a wedge to get people to buy in elsewhere. But, even still, there is no guarantee that Samsung will maintain its model either. Frankly, even Ikea isn't a perfectly safe bet. I'm not scared there. But, I will admit that the possibility exists.
I am not arguing that everyone should drop everything and run out and buy all new stuff. I think it is prudent, if you already own something else, to hold onto it until something like this happens. You could drop hundreds or thousands on a fear which never materializes. And that wouldn't be a wise investment.
But, when looking into additions to your smart home, it may be wise to start taking stock and ensuring it is either inter-operable on some level, or is not a major risk factor in the first place. Lights are simple. Look for something ZigBee based, and verify that people have gotten them working on a competing platform, even if that means reduced functionality. People have gotten Hue lights working on Tradfri bridges and vice versa. Which ultimately means if one company or the other (or even both) exited the game in a way which leaves me up a creek, I can still salvage my lights. WiFi lights, probably aren't as standardized. Z-Wave I hear can be a pain, but can be made to work.
These trouble however bring me back to an earlier suggestion. Why hasn't someone offered an all-in-one solution yet? Something like a Raspberry Pi 3 or 4 has the power to run OpenVPN, Home Assistant, while also handling things like a ZigBee and Z-Wave receiver. And that is all while running a full Linux distro of sorts, and having headroom for even more.
I bring up OpenVPN because the typical problem with hubs has been external access. But, the solution is actually QUITE simple: Sub-domains + VPN + Custom DNS provider. Wireguard is even lighter than OpenVPN, so the solutions get increasingly better with time.
To recap what I suggested a while ago. Someone should create a hardware appliance based on something like a Pi. It should come pre-configured to be configurable similar to normal smart devices where a temporary BT network is established to complete the setup. During the setup, a subdomain is registered for the account, and a daemon process keeps the record up to date. The user is prompted to confirm if they want to switch to the custom DNS provider which will receive these updates "immediately" even when a dynamic IP is used. Then, this information is used to complete the VPN installation. The app on the phone stores the data, and always uses a VPN tunnel when not on the same network as the hub. The app can also communicate with the Hub to help provision VPN access for other clients in the household if desired.
Voila! You have a hub with minimal maintenance requirements for the parent company. The smart home data never needs to leave the home network. This mitigates a lot of risk associated with holding personal information for the parent company. But, they could offer paid services like online video storage, etc... for paying customers. And presumably, if they were receiving subscriptions for those services they could afford the personnel and hardware to keep that afloat and profitable.
Put another way, it maximizes the upfront profit of the hardware, reduces risk, and still leaves the door open for ongoing revenue generation.
A lot of these hubs with no service charges are basically depending on profit from the hardware sales to pay for the infrastructure. But, this only works if there is enough profit from each sale to pay for it over the usable life, or if you can count on continued growth. This is likely the problem Wink encountered. They weren't selling enough hardware to stay afloat offering the services for free. Largely because the offerings were rich, and largely handled within their infrastructure.
Registering subdomains and running a DNS would require a lot less maintenance. Most of the actual smarts happens on the consumer hardware. Their hub and their phone or other devices. Very little of what goes on actually needs to go through their servers. So, it is much more likely that each hardware sale, if there is profit margin in the hardware, will pay for its own needs over its life and beyond.
By acting, essentially as just a DNS provider, you're never even need to touch the customer's data, which in turn allows you to spend a lot less time, effort and resources, like money, hardening your infrastructure against attacks.
And, as I said, none of this means that you can't still monetize a service. Paying for things like video storage for security cameras, or machine learning and so on are things that many people will still find value in. I mean, even if you allow recording locally, it doesn't help if someone breaks in and smashes the hard drive. True security requires offsite storage. And this solution does nothing to provide that.
BTW, I know this is possible because this is more or less my setup right now. And, it wasn't insanely complicated for me to do. Furthermore, everything is in docker containers and was configured either via the command line or config files fed into the images. Which means, it could all have been automated and wrapped up in a prettier, even easier to configure package.
Comments
Post a Comment