I am excited to share that the W3C Web Thing Protocol Community Group has published the first draft of the Web Thing Protocol WebSocket sub-protocol, a dedicated real-time protocol for the Web of Things.
The Web Thing Protocol provides a WebSocket sub-protocol for monitoring and controlling connected devices over the Web, and I believe could be a key enabling technology for an open ecosystem of IoT web services.
I'm not sure I understand your point. The idea of the hub is to consolidate (centralise) multi-vendor building management systems into a single unified interface, for the benefit of the people whose responsibility it is to manage building systems (i.e. Facilities Managers). https://krellian.com/hub/
The terminals (e.g. a touch screen control panel attached to a wall) are just fairly dumb clients which provide access to that user interface appropriate for a given user in a given room.
What part of this design did you interpret as being incompatible with that?
Getting expertise for an ad hoc system is more obscure than getting service from an established vendor.
So who are likely users? Obviously organizations that can devote software engineering resources towards building a system to monitor ad hoc sensor systems.
So the first cost has to have a cost advantage for building over buying. And the lifetime costs of in house application maintenance have to be better than vendor service.
To put it another way, when is it low hanging fruit for software engineering resources? Including developer moral (thinking of what developers might rather be doing) and the clout of a physical plant managers to redirect engineering resources.
My comment is social and economic not technical. It is about the C-suite’s problems.
I'm still not sure I've fully understood you, but I think you're probably making some assumptions about the business model around this and how it would be deployed, whereas the blog post was just about the technical architecture.
I agree that it's easier for businesses to buy in a solution than try to develop something in-house. The intention is certainly not that commercial users of this operating system would need to write their own code. It is just one part of a wider commercial solution.
Perhaps that's my fault for sharing this outside of the context of the problems it is intended to solve and the wider business model around it.
Regardless, I appreciate you taking the time to respond.
A whole building operating system, built on web technologies, which weaves together every sensor, actuator and human-computer interface in a building into a seamless user experience.
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.
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.
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.
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.
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.
HTTP2 server push isn't really designed for the kind of two way communication needed in IoT use cases, it's mainly designed for web servers pushing CSS files down to a web browser before they're requested.
MQTT isn't a web protocol and the goal here is to give things URLs on the web. But I'm aware of some Web of Things implementations using MQTT over WebSockets to benefit from the QoS features.
The Web Thing Protocol provides a WebSocket sub-protocol for monitoring and controlling connected devices over the Web, and I believe could be a key enabling technology for an open ecosystem of IoT web services.