I strongly disagree. They have a W3C spec for the WebThings API[1]. Not a protocol as such but its a big step in the right direction.
And the existing product is great. I have been using it for months to control my TV, stereo, lights, etc with no issue. I have even added custom adapters for my own little projects. It's a great product to work with and use.
I agree that this project was unlikely to make Mozilla any money, but this is much more than a "conceptual thought".
Indeed they did do quite something in standardization of thing controls for which it so sad to see it going unmaintained. On the tunnel side though which they are also shutting down there are plenty alternatives e.g.[1]
I'm pleased to report that WebThings isn't dead, it is alive and kicking with a new commercial sponsor.
The Thing Description specification at the core of WebThings is now a W3C Recommendation (https://www.w3.org/TR/wot-thing-description/) and there is a new W3C Web Thing Protocol community group working on standardising the concrete HTTP & WebSockets based protocol WebThings uses to monitor and control devices.
The WebThings platform includes over a hundred GitHub repositories worth of code (https://github.com/WebThingsIO/) but I'm sorry to hear you feel it lacks a convincing story. That's something I hope to improve in WebThings' new life beyond Mozilla's R&D department.
I know this may be painful to hear since the new commercial sponsor is you but having an early stage startup which is entering the fairly crowded digital signage space be the commercial sponsor is not something which is going to raise anyone's confidence level that WebThings has a long term future.
* true openess that would allow some hope of device vendors contributing integrations
As a former developer of a proprietary home gateway who has studied and implemented many home automation protocols I know too much the mess of the home automation ecosystem. Just walled gardens. And gateway APIs are one way to lock-in users and software developers.
I wonder if that "new commercial sponsor" will not change the balance of independancy.
I hope this goes well, but I am worried. This is a project that I really care about. Mozilla seemed like our only hope for a smart home that doesn't spy on you between WebThings and all the speech processing tech they had.
It's important that we have open source alternatives. I will be contributing to this project and I encourage others to do so as well.
Apple’s HomeKit Is another ecosystem that doesn’t spy on you. It’s the main reason I picked it even though there are fewer, more expensive devices to choose from.
Helpful reminder that Apple still cooperates with the FBI [0]. They famously participated in PRISM and only pivoted to privacy-based marketing after this bad PR. It's also closed-source, so you have absolutely no idea that what you've said is true; they've certainly lied about it before.
For a small cost of being forever locked into Apple's DRM laden ecosystem and where each device needs to carry Apples proprietary authentication chip to make sure you don't accidentally actually own the device.
This is exact opposite for what WebThings stood for.
All the HomeKit devices I have also support other protocols in addition. You can also add third-party/custom devices using HomeBridge. The authentication chip hasn't been required for a few years now.
This is probably part of why they stopped referring to it as "hass", although many who have been a part of the ecosystem (and probably don't speak German) continue to use the term.
OpenHAB is still a bit user unfriendly from my experiences working with it. My existing stuff will talk to Google or Amazon's assistants, but getting OpenHAB to talk back and forth with those devices and Google/Alexa is proving to be a pain in the ass.
I like that cloud access is free, and Alexa integration works for me, although I prefer to keep my automation stuff relatively simple.
For me, I like the OpenHAB scripting, I personally found HomeAssistant to be too complicated to do some things because it was focused on being easy to use. I spent a long time trying to figure out how to get HomeAssistant to do what I wanted with my zwave smart locks, and it was much easier to do it on OpenHAB. So obviously, YMMV based on your preferences and requirements.
I see a lot of people using NodeRed also, which I guess is cool, but I found NodeRed incredibly frustrating compared to writing a script from scratch.
Sorry to hear that and I'm very sad about the recent layoffs at Mozilla too, which included lots of people I know. What would convince you to give WebThings a second chance under its new management?
For me, what would do it is a complete product that is not niche. A Chromecast competitor that supports the big platforms and content providers out of the box (Android/iOS, Spotify/Netflix, Alexa/Google/Siri) would be ideal. This already exists in the Chromecast, except it's not open. Ideally, it'd just be software on a Raspberry Pi or any hardware.
Interesting. That's very different to what WebThings provides today but that's something I'd like to see too and have toyed with building in the past.
Chromecast was once very close to being an open platform by implementing the DIAL protocol (although DIAL also had some centralisation issues), but is now a proprietary platform built on the Google Cast protocol, and is creeping towards morphing back into Android TV.
There was once a project to build a Firefox OS based TV stick called Matchstick which could have been great (B2G is still used on current Panasonic smart TVs believe it or not), which unfortunately got embroiled in a debate regarding DRM and never made it to market.
The digital signage platform I'm currently building at Krellian (https://krellian.com) could be adapted to consumer use cases like Chromecast and I'd be interested in building that in a standards-based way (e.g. using the W3C Second Screen Protocol), but the challenge would always be getting support from the big content providers, and of course the issue of DRM.
The strange thing is that as far as I get, Mozilla didn't fire a single ff dev. Servo - yes, mdn - yes, but they actually want to focus on FF and transfered people from the servo team to the core product.
The only parts of Servo that could realistically be ported into Gecko within the next couple of years have already been ported. Servo's DOM engine would be the last major remaining piece, but that would be a very, very long-term project.
According to your link, developer tools and internal tooling/infrastructure teams took a cut. The effects will mostly be indirect.
Internal tooling and infrastructure teams that work on Firefox are still Firefox teams though. If you work on the build pipeline you still count as a Firefox development in my book.
They were not very clear on where the cuts are, but here is the quote from the linked article:
"In order to refocus the Firefox organization on core browser growth through differentiated user experiences, we are reducing investment in some areas such as developer tools, internal tooling, and platform feature development, and transitioning adjacent security/privacy products to our New Products and Operations team," Baker wrote.
The article prepends the paragraph with another sentence to impose its own interpretation on it, but the way I read it is that the browser division is reorganized around the user experience and everything else is moved in products and operations. Not sure how to highlight the words "browser growth".
Regarding Servo, the project is killed and part of the people had been kicked out, but the rest were merged with the core engine team. My understanding is that Mozilla decided that even Google is not doing two browser engines at the same time and decided to move the old one to rust the evolutionary way.
Did they fired someone from the ff team? Maybe, but I don't think that it is because the browser is no longer important for them. The fact that they moved there best rust devs to it testifies that at least they are not giving it up so far.
I think the sentence you've quoted makes it clear that cuts have happened to certain Firefox teams.
Now, we can argue about what the effect is of this cuts is but at least you have to accept that some Firefox teams have received cuts and likely those people have either been moved or dismissed.
When you say they moved their best Rust devs onto Firefox, yes but in part that is possible because they have made cuts to the Rust toolchain teams.
The teams were downsized, but I'm not sure what happened to the people because it was bundled with the products and operations team. This is what I meant. Not a hill worth dying for though. It will be most clear if someone knows what the Taiwan office were doing because they were hit the hardest as far as I get.
Regarding the rust toolchain, all the FAANG are using rust one way or another. The project is healthy and Mozilla is not key there already. I'd even say that it would've been ugly if a non-profit corporation had to pay for the development of tools that trillion dollar companies are using.
From their message, it's not clear to me how COVID-19 is to blame for the layoffs. Especially in Taiwan, since Taiwan has been among the best in the world[1] at handling the pandemic and is doing relatively well.
Did Google reduce their payments in the new search deal because people search less when they work remotely due to COVID-19?
Did Mozilla reduce investment in tooling because developers' need for tools is reduced by COVID-19?
I think what they're referring to is that COVID has damaged the advertising industry from which Mozilla receive royalties but in fact the problem is much more likely to be that only a small minority continue to use Firefox.
The WebThings platform was a four year project at Mozilla which sadly ended when their Emerging Technologies department was wound down, as part of a recent round of layoffs affecting a quarter of Mozilla's workforce.
The closest that WebThings got to a commercial product was this developer kit available on OKdo https://www.okdo.com/p/mozilla-webthings-gateway-kit/ As the Founder of the new commercial sponsor for WebThings, that's something I'd like to change.
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.
> 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.
Kudos for that. Too many "smart" things are tied to online accounts for no good reason.
Disclosure: I work at Siemens on an implementation of the Web of Things not related to the Mozilla Project.
What is mostly misunderstood about the Web of Things, is that it does not define a network protocol but a document format to describe devices in terms of properties, actions and events.
Interactions are then further described by „forms“ that contain Hrefs with the protocol scheme supported by the device (e.g. coap://, opc.tcp://). The idea is not to introduce the next unifying protocol, but to unify the description of devices that support arbitrary protocols. Think of OpenAPI for IoT.
It serves us well in industrial settings where protocols like opc-ua, bacnet, coap, modbus and the like will stay the leading protocol in their respective domain for the foreseeable future. Such a descriptive approach to me seems the only option to at least write applications in a uniform manner.
Looking at efforts like MS Device Description Language (DTDL) or AWS Things Graph Data Model (TDM), it makes sense to have at least one openly standardized description language to prevent fragmentation at that level. The war on fragmentation at the protocol level is already lost IMHO (and everybody lost).
Something that worth to be mentioned too, is that the gateway project has been designed to be extensible with addons. The community took off with more than hundred of adapters to support new devices or protocols and even online services.
Myself I wrote a couple of them and use them to push further than the regular smarthome use cases.
And to be clear, IMO that is absolutely fair.
At this stage WebThings seemed more like a conceptual thought, rather than actual marketable products, protocols or even code.
If Mozilla need to cut for real, they should definitely get rid of stuff like this which lacked a complete and convincing story.
reply