benfrancis
Joined 12 years ago
Karma
244
Submissions
25
Member since
Aug 7
Recent submissions
Comment · 1 year ago
Comment · 1 year ago
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.
Comment · 1 year ago
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?
Comment · 1 year ago
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.
Comment · 5 years ago
Introducing Krellian Hub and Krellian Console, powered by WebThings, built on W3C WoT standards.
Comment · 6 years ago
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.
1. https://docs.google.com/document/d/1H3coHbb3Bwd02_NJi4KEBONB...
Comment · 6 years ago
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.
Comment · 6 years ago
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.
Comment · 6 years ago
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.
Comment · 6 years ago
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.
Comment · 6 years ago
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.
Comment · 6 years ago
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?
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.