Interesting article

Found this via another forum and thought I’d share it. Although it doesn’t go into much detail, it is quite interesting to see what’s happening. Have the likes of Google, Amazon and Apple killed off the phase ‘Smart x’ already?

https://staceyoniot.com/the-chickens-are-coming-home-to-roost-in-the-smart-home/

The problem is they can sell a standardized interoperable product but they choose not to do this. No mention of the free software solutions trying to herd these cats into cooperation either.

1 Like

I doubt Google, Amazon, Apple and the like are interested in helping Open Source projects. They are looking to maintain their revenue streams.

The question is not about open source projects… It´s missing standards, which leads to missing results.

1 Like

It is also about vendors wringing every fraction of a cent out of a product. There is no reason they cannot support 5GHz wireless standards except perhaps a fractional cost savings in materials.

My view is that these big players spotted what they thought was an opportunity to gather loads of data and create a growing revenue streams. But as with all large companies, they change direction or leadership and therefore products either grow, progress no further or are killed off all together. They all want you to buy into their ecosystem and have no desire to allow any form of standardised integration, all in the aim of protecting revenues.

Until all of the players in the “Smart Home” technology space move away from Hubs and Cloud subscriptions were never going to truly get an intelligent home for the masses. The likes of use using openHAB, Home Assistant and OpenRemote will always find a way, but will have to compromise to make things workable.

In the ideal world, each IoT device would be wifi (TCP/IP) enabled and have an openly documented API built in. You could then choice how you build your own ecosystem, such as adding a Hub for the compute power and associated apps, Cloud subscription if you want things managed for you or for the enthusiast like ourselves we’d be able to build things using Open Source.

Totallt agree on this.

It doesnt really matter what interface to use. The biggest issue is to get everyone to use the same… and…

…ofcuse provide an open API…

As the article mentioned, the direction things are heading is tightly coupled to the cloud. That by itself isn’t bad for most users if the vendor can guarantee the service, the privacy and able to offer compelling features. For hardcore advanced users, the reliance on the cloud is always a big no no.

I see the future of home automattion to be user defined rules done through voice interface such as Google Assitance or Amazon Alexa. They already have the eco system. The next step is to let user define rules similar to how we define email filtering rules in Outlook. That requires building a DSL or voice grammar of some sort to do X when Y happens and so on. They can provide some templates, but advance use cases are really user specific.

The other problem is the lack of understanding and awareness from the users. They only know of the dead stupid use cases like telling the tool by voice to turn on the light. They forgot the automation term in the whole concept. There are so many things that we can do. It’s a combination of devices. The more devices you have the richer the integration can be and thus the more various use case scenario.

standards

5 Likes

Hehe thats exactly what the vendors are capable of doing! :rofl:

1 Like

I saw the article and came away thinking “meh”. Where’s the news here? About every ten years or so someone invents a new name for the same old thing. What was once called “ubiquitous computing” became “ambient computing” became “Internet of Things”. I see nothing wrong with a move from using “Smart Home.” As hinted at in the article, if you only stick to commercial offerings it’s hard to call anything you can do with this stuff “smart”.

Apple less so, but all three are very active participants in Open Source. But, they have the same motivations that anyone has to contribute to an FOSS project which is “I’ll contribute by adding something to the project that I need.” And Google in particular is an originator of many many many FOSS projects.

They may not be interested in helping us because we don’t have anything they need and as with any company there is a strong “not invented here” attitude. But it is incorrect to say that these companies do not contribute to FOSS projects. They do so in a self interested manner, but so do the rest of us.

Standards are a double edged sword though. Once a standard is set, it becomes relatively fixed forever. This means that new and novel use cases may become impossible as they are outside the standard.

And one reason why we don’t have a standard in this area is that:

  • the requirements are diverse making a single standard unlikely to be sufficient
  • no one has developed a compelling standard that has some sort of advantage over the others (note that an advantage need not be technical superiority, e.g. VHS versus Betamax)
  • there is that thorny problem of remote access.

Also, make no mistake, there are tons of standards in this realm that are being used.

  • TCP/UDP/IP
  • 802.11
  • Zwave
  • Zigbee
  • OAuth
  • HTTP(S)
  • TLS/SSL
  • USB/Serial/etc
  • UPnP
  • Multicast
  • MQTT

I can go on. The problem isn’t that we lack standards. We couldn’t integration anything into openHAB if there were not standards upon which all this stuff is built. The problem is the standards in use are often not compatible meaning we have to have something like openHAB to bridge between them. I do not see this changing in my lifetime.

Every decision made by a vendor is based on this sort of calculation. You can’t blame them for looking at the market and deciding that the added cost to support 5GHz (for example) would be justified by increased sales. If the market overall doesn’t care enough than it’s not a good business decision to pursue it. It might be inconvenient for you or for me but we are not the majority of the market. We wouldn’t drive up the sales enough to make it worth their while.

OK, let’s pretend I’m a company. I want to stay in business. To stay in business, I have to make more money on the services and products I sell than it costs for me to provide them. *There currently exists no single standard in this ecosystem for my company to adopt." So I have three choices, two of which are really the same choice:

  1. Adopt someone else’s standard, but whose? Which one has enough users that it would increase the sales of my product? Is there one? I don’t know what it is if there is.

  2. Build my own “standard” and publish it as one more among the dozens of existing standards.

  3. Build my own and keep it my own.

Given that 1 really isn’t an option, though Google, Microsoft, Mozilla, et. al. are all trying to build their own “one standard to rule them all” but none of them have much broad adoption, we are left with 2 or 3. And from a cost perspective, 2 costs significantly more to do than 3.

Given that the vast majority of customers who will be buying my product don’t care at all if I’m doing 1, 2, or 3 it won’t drive any of my sales, what choice do I have? 3 makes the most business sense.

There are strong technical reasons why most of these companies rely on a cloud service and no, it’s not just to gather all your data. It is the only viable way to provide the ability to the average joe user the ability to access their devices remotely.

And if you go back to thinking like a business that wants to stay in business, one must ask:

  • Does it make sense to provide an API at all? Will the ability for advanced users to integrate with their products drive sales enough to cover the initial and ongoing costs?

  • If it makes sense to provide the API, does it make sense to provide two APIs? We already need the cloud based service to allow remote access. We already have to build an API for that cloud based service so our apps can communicate with the devices. So do I just publish that API and make it usable and call it done, or should I go through the effort to build yet another API that allows for local access?

  • What risk do I face by opening up an API, either through the cloud service or locally? What if I’m hacked? What if I do it poorly and user’s data is exposed? Providing access to the data and abilities of an IoT system does not come risk free. All it takes is one bug or inept configuration of a database and suddenly you become the latest threat to privacy and civilization.

If you think about it from a business perspective, it’s no wonder that when there is any API at all, it’s through a cloud service. Those of us who are home automation enthusiasts are not a large enough of a market to change the answers to those questions much.

And that is one of the big issues with the cloud approaches. The vendor cannot and will not guarantee the service. Just look at the Google Graveyard for the recent news from BestBuy.

In my opinion, cloud based smart devices are way overpriced. And I totally agree, if you have the skills and desire, you should stick to stuff with a local API. But we are not a big enough market so we will always be under served in this regard. As discussed above, the business side of things will drive companies towards the cloud service API.

1 Like

Why? 2.4GHz RF is nor reliable and we already have perfectly good standards designed specifically for Smart Home devices. Z-Wave is engrypted, designed for low battery use and distance,
TCP/IP opens up your whole home network, even with WPA2 due to known broken security.

And the problems with standards are made manifest.

When there is only one standard, which is what everyone is advocating on this thread, then there will be compromises for some users. Z-Wave and Zigbee indeed are good standards. But they require special hardware. WiFi is pretty much ubiquitous so from that perspective it would make a good candidate for a standard. And even if 2.4 GHz is unreliable (which is not the case for most users), as I said above, technical superiority is rarely the reason why any standard becomes successful. It becomes successful because it achieves a certain mass of users large enough that the standard has to be supported because a failure to do so will start to impact sales. That makes standards like WiFi and BT pretty attractive.

What I meant is, there is a need of standard of how to integrate these things into homes. Ofcouse there are several kinds of interfaces, which you list above. But what good is it, if you´re home is not capable of integrating to any of those, og maybe only a few, which btw doesnt cover whats needed an a typical home.

What we see is, that each Vendor is making their own idea of, what a smarthome is, (and specially whats its not). Only a very few systems try to make it complete, but yet lack quite a few important options, (for god know what reason). When something lack options, there is a greater need of a way to integrate with other options… The only place you see this, its in non-commercial/open sources, like openhab.

If we turn to more specific devices… Lets say you have a garagedoor opener today. This one use one kind of interface which suit your smarthome system just fine. Now it breakes and you need a new one, but the only avialble is one which dont suit your smarthome. Now what? Either rebuild your smarthome to suit the new garagedoor opener, or??
The garagedoor opener itself… It really isn´t rocket sience. How come simple things like these has to be so complicated then?
And it´s gets even worse, if it´s a cloud controlled device… Now the interface is still standard, but its a closed enviroment. And almost any cloud base service do not support other devices unless its from the same vendor… Except for google hom, alexa etc which tries to collect lots of vendors. But it´s still cloud based and closed enviroment, and also lack of lots of features and opputunities which a real smarthome system would provide, (again like openhab). Openhab also suffer from alot of problems, mainly because it´s based on volunteers/open source, as well as it rely on the device will somehow provide an open API or something simular, which lots of devices havn´t got. As a user you cant rely on a device will run with openhab.

In short - there is a clear path (or standard) missing here. There are too much struggle allround with stuff which basicly is very simple. Most vendors just dont want it to be simple. It´s a choice. Not a need.

Dont get too focused on the interface itself. As explained in previous post, there is a whole other problem which is much more serious, in my opinion.
An vendor can and will make use of the already exsisting interfaces. The problem is how to get the devices to communicate with each other through a main system (smarthome). Each vendor dont really care about eachother. They care about their own stuff only. And this reflect the user/customer in a way which makes is quite impossible to combine. Or at least with alot of stuggling, for simple stuff.
It´s like taking a bunch of people from all around the world, asking them to co-work, but not beeing able to communicate/understand eachother. Either they never succeed, or it will take a lot of hassle to do even simple stuff.

And they’re is only two ways to make a vendor care:

  • make it profitable for them to do so
  • make it legally required

I’m the US, option two is almost certainly not viable so we have the first option. So how to make it profitable? There is no money in creating such a standard thus far. In fact there is a strong disincentive to do so because releasing such a standard for free and unencombered use would cost the company that makes it and benefit all that’s company’s competitors.

I agree, this is the problem.

One way could be to develope devices with open API´s only for the required communication. Unfortunatly most vendores sees this as an “extra feature”, and therefore either dont provide, or asking money for it.