Maybe just a marketing failure, but WebThings to me always seemed like a project with no clear purpose in the ecosystem. Not enough mindshare and nothing unique to attract that mindshare. Open-source home automation projects is not a field lacking options. While the idea of standardization for protocols has some merit, a W3C group working silently and then tying it to another new standalone "gateway" project is not the way to get the standard attention (sadly an anti-pattern many of the more niche W3C groups fall into, made worse by time limits imposed on WGs). Projects with more impulse behind them create defacto-standards instead, and unless the focus shifts to integrating with other software more I don't see them coming out of that ditch.
(+ for my taste the standards involve to much JSON-LD complications, but I'll accept that that's taste)
EDIT: I guess part of the question is, what exactly is the goal? Bringing forward the WebThings "standard", or building yet another IoT/home automation controller? To me it has seemed like the "mission" is the former, while the thing actually done is the latter.
Haven't used it (or any IOT), but they are doing something right:
(quote) Because your smart home gateway is designed to operate locally inside your home without the need for a centralised cloud service, it will continue to work just as before. You’ll still be able to monitor, control and automate your home via the gateway’s web interface inside your home network.
Sure, but that's true of pretty much all the open-source options in the field. (To be clear, I don't want to say it's bad, just not sure about the place and why)
I totally see your points.
The interoperability of a standard and a common voice on the home protocols could be relevant move. The gateway is not need or at least is in a very competitive market (with open source solutions)
It seems like they still have no clue how lucky they are to have the Rust Programming Language and yet they still really cannot create any revenue outside of their contract with Google. Without it, Mozilla would cease to exist.
That's the actual reality of open-source. It is funded by the same companies that oppose privacy - contradicting Mozilla's mission.
And I routinely placed in track races when I was a teenager, but funny how that doesn't help me with running as a middle aged overweight guy.
I love the Mozilla mission, and worked at Mozilla for several years as both an IC and Manager, but the current Mozilla leadership, and Mozilla fan base need to stop pining for the old days, and figure out a clear, sustainable path forward.
I don't think there is anything wrong with Mozilla earning money through their Google contract, but if the Mozilla mission is going to persist beyond the short term, they desperately need both revenue diversification, and a new, high-impact project that will buy them relevance in a market where the influence that Firefox has is waning.
Although this is a bit of a downer comment, I really do believe that is important that they are successful in this, and winding down investment in low-impact, low-relevance projects like WebThings in a way that preserves them for the community is a great step forward.
To answer your question, the goal of the WebThings platform as a whole is to improve interoperability between connected devices by making the Web of Things a unifying application layer for the Internet of Things which bridges together multiple underlying IoT protocols. The goal of the WebThings Gateway is to allow users to directly monitor and control their homes over the web, without a middleman. Building a smart home gateway just happens to be the most obvious way to achieve the latter in a way that demonstrates the benefits of the former, whilst maximising compatibility with existing smart home devices.
I agree with your observations on the traps W3C Working Groups can fall into, though it's not fair to say the Working Group tied the standard to a particular gateway project. There are multiple implementations of the Web of Things (e.g. see ThingWeb http://www.thingweb.io/) targeting a range of different use cases spanning different application domains like smart homes, smart cities and industrial applications. WebThings itself has a framework of libraries to help device makers build web things using a dozen different programming languages which have no dependency on the gateway. I acknowledge that there is a bit of a risk in implementing a smart home gateway of making the gateway itself the platform, rather than the Web of Things, and that's something I was very conscious of when designing the WebThings Gateway.
Something I think might help make the Web of Things approach more clear might be to create a general purpose Web of Things client/browser (e.g. a mobile app) which isn't tied to a gateway and can communicate directly with any web thing over the internet. Unfortunately with the current Thing Description specification this level of ad-hoc interoperability isn't possible, which is one of the reasons I created the Web Thing Protocol Community Group (https://www.w3.org/community/web-thing-protocol/), to standardise a more concrete (sub-)protocol for the Web of Things such that any WoT client can communicate with any WoT device.
It was by creating an implementation-driven defacto standard of sorts with Mozilla's Web Thing API (https://iot.mozilla.org/wot/) that Mozilla managed to drive a lot of simplifications to the W3C Thing Description standard, including dialling down the dependencies on RDF and semantic web technologies in favour of a more pragmatic default plain JSON serialisation. I hope that can continue by demonstrating traction with developers using the Web Thing Protocol in their real world IoT applications.
I acknowledge that WebThings has at times lacked an obvious direction and has not yet achieved mainstream mindshare, but I'm hopeful that things might be different outside the constraints and politics of a not-for-profit browser company.
I think WebThings, which I haven't heard about in over a year, sounds like the BetaMax to Connected Home over IP (CHIP)'s VHS: https://www.connectedhomeip.com/
Which has ZigBee, Z-Wave, Ikea, Legrand, Amazon, Apple, Comcast, Google, Huawei, Samsung, Texas Instruments, and a lot of others on board. Almost every consumer electronics, home automation, and home electrical company is on their list somewhere.
I think that's a fair observation and I'm really excited about CHIP. The person driving CHIP at Apple was the person who originally hired me to work at Mozilla and I'm hopeful they might pull it off. The list of participants is impressive and just getting Apple, Google, Amazon and Samsung around the same table is an achievement (Samsung and Google are both members of W3C WoT groups but Samsung is the only one really participating). A couple of points though...
Firstly, CHIP is focused specifically on the connected home whereas the Web of Things has broader applications. My commercial interest in the Web of Things extends beyond the connected home.
Secondly, it's not yet clear to me whether CHIP will compete with or could complement the Web of Things.
On the face of it, being an IP-based protocol, CHIP could solve the same kinds of problems as the Web of Things in the connected home space. It could be potentially become ubiquitous on devices, gateways and cloud services. However, I wonder if the dependency on IPv6 may limit the adoption outside local networks initially. This may mean that devices themselves use CHIP instead of something like Zigbee or Z-Wave, but that IoT applications on gateways and in the cloud continue to use other technologies, like the Web of Things.
Either way I hope CHIP succeeds and I'm looking for ways to support CHIP on the WebThings Gateway.
Having tried 10+ "IOT Frameworks," and still had to write our own because none of them managed to even boot on the most beefy MCU on the market without extra RAM.
Another example of something begging for a question "Do these people ever use their own software?"
Specific to the software discussed here: Bit weird criticism of software that obviously is not intended to run on end-devices with MCUs, but on a more powerful gateway. (But yes, there is overall too much focus on that part compared to the bits that run closer to the hardware)
The Web of Things direct integration pattern [1] (running a web server directly on a device) is not a good fit for MCUs, with a few very high end exceptions (e.g. ESP8266 and ESP32 for which the WebThings Framework works perfectly well).
For constrained devices like MCUs the gateway integration pattern is a better fit, which means using some other low power communications mechanism on the device itself and having a gateway bridge the device to the Internet and the Web of Things.
It's also within the charter of the Web Thing Protocol Community Group to explore a more lightweight CoAP+CBOR alternative to the default HTTP+JSON sub-protocol, which may help in some cases.
(+ for my taste the standards involve to much JSON-LD complications, but I'll accept that that's taste)
EDIT: I guess part of the question is, what exactly is the goal? Bringing forward the WebThings "standard", or building yet another IoT/home automation controller? To me it has seemed like the "mission" is the former, while the thing actually done is the latter.
reply