Mozilla WebThings: An Open Platform For Building IoT Devices

Mozilla recently officially released their IoT platform. This framework comes with “Gateway” software that can run on a Raspberry Pi and a framework that can run on any number of devices.

As we’ve seen, IoT is a dubious prospect for consumers. When you throw in all the privacy issues, support issues, and end-of-life issues; it gets even worse. Nobody wants their light bulbs to stop working because a server in faraway land shut down, but that’s an hilariously feasible scenario.

WebThings comes with a lot out of the box. It comes with a user interface, logging, rules, and an easy-to-understand API. Likewise the actual framework allows for building on many common devices and can be written in Node, Python, Java, Rust, Micropython, and used as an Arduino library. This opens it up for everything from a eBay ESP32 to a particle board.

We’ve started to notice some projects that use it trickling in on the tip line and on hackaday.io. We’re interested to see what kind of community grows around this, and are curious if it won’t be too long before easy-to-hack kits start showing up on your favorite online retailers.

There’s good documentation and of course, being open source, you can check out the source for yourself.

24 thoughts on “Mozilla WebThings: An Open Platform For Building IoT Devices

  1. From a quick glance at the web site it seems promising in that it doesn’t seem to pass all your data through a third party server. I haven’t read enough yet to determine whether your data stays private or not. I have been working for a while on cloud free IOT implementations and this may turn out to be a good way to go to prevent the rapacious vacuuming up of personal data. I hope so, and will check it out.

    1. Yes, all your data stays local to your gateway. There’s an OAuth framework to enable securely sharing data if the user wants to share some of it. Currently, data are coarsely shareable per device, either “monitor” or “monitor/control”. Users can revoke the OAuth JWTs at any time. Data sharing to services could be made even more fine-grained in the future. Currently I’ve only used OAuth to share my data with the “voice control” add-on which runs on the same gateway, so that I have private voice control too. :)

  2. I have witnessed products still functional as the day they left the factory except for one tiny detail, the company shut down the servers that made all the special features work or contained the install files or some type of key / registration file that permitted the device to work (reason to buy in the first place was these features). A good example is X10 devices they had cameras connected to the web viewable remotely many years ago, the also had a programmable controller that let you automate lighting and practically any device you wanted to, well they went bankrupt or sold the business but servers went down and a wide part of the product line lost all if not all useful functionality making the devices just e-garbage overnight another company now sells x10 branded devices but its a limited line and they put some of the old server functions back online but to little and not all device functions were partially restored. Every IP camera I have seen for sale that you can view any where with a computer or smart phone rely on a server operated by the seller and are at risk of death on the demise of the parent company or corporate decision to turn off the servers.
    Why not setup a trust or pool of some sort with a portion of the sales price going in to it from all server dependent devices with the funds being used at the time the company cant or wont keep the servers running. The companies participating could use a logo so folks would know which products were “insured” against death by no support part of the requirement for products to be so labeled would be 1. the fee collected for each device sold 2. the manufacturers agreement and contract to migrate the soon to disappear server to the groups server farm at end of life. the group would keep the server side software running for either a fixed number of years or until server traffic for a device went below a set level for a number of months.
    I refuse to buy any device that needs a server to remain working big name companies kill products as often as some folks change socks! small companies disappear like Mr. Hoffa , never to be seen again! so until I know the server will exist until the device is as historic as a rug beater I wont but them!

    1. You don’t need services from Mozilla to run this gateway. They provide a tunneling service in case you can’t port forward 443 to your gateway (through your firewall), but that’s just for you as a convenience — it makes it easy to access your home gateway from anywhere.

    2. Or even something as simple as releasing documented server API calls and adding a button you can press to let you change the server address. This way you can change the address of the server to be a computer you own running software that provides the same API calls so the device can run within your network if need be.

    1. You do realize Java started out as something running on a SIM card? https://en.wikipedia.org/wiki/Java_Card

      Only recently something quite obvious hit me: “Perfect IoT device would include an internal scripting language (ideally standardized and easy to grasp, embedded python/java/js/lua etc) and API exposing all of gadgets hardware. This way user/owner/external service providers could supply their own script snippets implementing desired functionality. Aka general computing.”

      Closed firmware IoShit hardcoded and tied to particular Gateway/infrastructure is always a bad idea, no matter who controls/owns the latter. Every IoT product should provide easy user controlled programmability.

    2. The WebThings Gateway is a place to secure, process, and log your IoT device data and enable interoperability between devices via the “web of things” API. See iot.mozilla.org/frameworks for the many open source library implementations (in several languages) that help you bridge your IoT data to the web. I have built many “web things” that connect to my gateway, but I can mix them with commercial smart home products too (battery operated door sensors, motion sensors, and buttons are better/nicer than I can make — Zigbee stuff for example.)

    3. Um, are you perhaps confusing the gateway and the actual remote-sensors? The sensors can be programmed using C/C++ using the Arduino APIs or Micropython, for example. It’s just the gateway itself which runs on more capable hardware and OS.

  3. BTW, their provisioning scheme does not work without being connected to the internet (they are using HTTPS but you can’t use that with a IOT without internet since the certificate chain can not be trusted without internet connectivity). So when you have to connect to the IOT’s AP to set up your home AP to use you’re doing it in HTTP over a plain / open WIFI connection. Similarly, even when provisioned, your IOThing can’t barely use HTTPS since it must download a valid certificate for your IP address / DNS name, which you don’t have at home. So no valid certificate could be issued, and HTTPS will either trigger a scary warning (if using self signed certificate), or no HTTPS (guess what manufacturer chose). Mozilla solution here is to have a gateway running on the internet (with a valid certificate, but you have to trust the server will continue forever), and have the IOT speaks to it and proxy the result to you. Whenever you want to run without an internet connection, your IOT will not work anymore, you can’t even speak to it directly, and any bug on the IOT’s firmware can/will be used to hack your IOT.

    1. You can skip the free and automated installation of a valid LetsEncrypt cert (you choose your own subdomain) that ensures https access when you are remote, but I find that feature AMAZINGLY convenient. Install your own cert if you want to skip Mozilla’s convenience.

      On the second point, if you have a “plan” and “open” Wi-Fi network at home, then I would tackle that security issue first. I agree that using the certified https tunnel when I’m at home seems inefficient, but if you skip the tunnel you can still connect using https://gateway.local, it’s just that your browser will complain of a lack of a valid cert, and make you acknowledge your actions before you can connect.

      1. Try that, you’ll see it does not work. Certificate requires a DNS address and no CA will emit a certificate for a .local name. Good luck maintaining your DNS name with a dynamic IP address (and even more that the IPv4 address pool is gone). If you use a self signed certificate, you’d be better not to use a certificate at all because in the former case, you’ll have a very false feeling of security. There is still no certificate pinning in the standard so if any hacker wants to capture your communication, he just has to set up a self signed CA for his proxy to your original gizmo. Since you’ll be used to see the “self signed certificate” warning, you’ll accept it and… you’re in cleartext without even seeing anything wrong. There are many open issue with this (I created many of them), and right now, there is no viable solution that can be easily circumvented.

  4. I actually have been self-hosting and using Mozilla Webthings for my smart home for about five months. I really like that you can write add-ons and custom webthings in multiple languages made it easy to migrate my custom source over to their platform. I have eight smart switches, two custom always listening voice assistants, control over my smart TV, local weather, leak detection in my basement, temperature sensors and a heat oil fuel sensor. Next I’m working on adding a diy vacuum robot to the mix. If I had any gripes it would be that their rule system is sometimes flaky and I wish there were themes to tweak the interface. Feel free to AMA.

        1. I don’t follow any convention someone else had defined, I just simply have the topics /devices/insertdevidhere/stat and /devices/insertdevidhere/cmnd — the first one receives JSON-formatted strings from the corresponding device and the second one is used to send commands to the corresponding device. What the JSON-string contains obviously depends on the device, but usually temperature, humidity, battery-voltage, RSSI and such.

          OpenHAB has built-in support for parsing JSON-strings and therefore any values out of them, so it works quite well with that regards. Though, I don’t quite like OpenHAB; it’s way, WAY too clunky, a god damn pig when it comes to resource-usage and the codebase and everything is like someone loaded a shotgun with random blobs of code written in random languages, shot it at the wall and called the outcome OpenHAB.

  5. For my efforts it looks easy to use. And I might even try and get the Docker image to work here. And again on a Raspberry Pii.

    @Kathy Giori any suggestions on what specie of Raspberry Pi to try and get to work with the Docker on Raspberry Pi image?

    But selecting a target or even device to make the rest of the stuff work will be difficult but not impossible.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.