2024-05-10 electronics, hacking, hardware, overengineering, rant

A lot of my projects don’t work out. That’s fine, failing is a very healthy way to learn. However, there are cases where the reasons behind failures are absolutely infuriating. So please, allow me a rant. I’ll spend a few words on how I got where I am. If you don’t care, feel free to skip to the large “Thread?” headline. I won’t judge¹.

In 2022, I published an article on how I created a severely over-engineered coffee bean storage and inventory-keeping solution. Since then, many people reached out to me to say that they appreciate my post and took it as inspiration to start similar projects for different needs. I absolutely love that!

More recently, I’ve been actively working on two related projects. One is a sensor I’m not going to talk about yet, but another is a “version 2” of that coffee storage display. My primary motivation for version 2 of that display was to increase the battery runtime. The displays averaged 40 days on a charge when my article was published. That’s alright, but it could be better. I managed to get this up to 55 days with a few software tweaks, but I wanted to explore how to push this further.

So, I started learning about low-power electronics, leading me down a few complicated but fascinating rabbit holes. To start off, I purchased a very nice power profiler from Nordic Semiconductors and profiled my whole system. If you’re curios, this is how such a profile looks like. Long story short: I re-wrote parts of the display firmware, identified some problematic components on the DevKit, and bypassed them. Ultimately, it became clear that one of the big factors is… WiFi.

You should know that while I love working on projects like this, I’m also inherently lazy. Using WiFi for such a project made sense to me, as I already have all the required infrastructure set up, and letting the display hardware talk to a service I run is super easy: just connecting to WiFi and sending a request to another device in the LAN. But sadly, WiFi is also really inefficient for a use-case like this. Even just establishing a connection can take a long time; it requires high transmission powers depending on where your access points are set up; it’s all less than ideal. So I explored alternatives, and as it turns out, there’s much to choose from! I didn’t want to build my own hardware², so I wanted to pick something with a good availability of DevKits and ready-to-use modules. Standards like LoRa and Zigbee came to mind, of course.

As nice (and usually power-efficient) as those technologies are, there’s a huge downside compared to WiFi: I can’t just build the display module and use it - I also need to build “the other end”, a receiver/transmitter/hub or whatever, that acts as a connection point for the displays to exchange data with. That’s not only a whole other piece of hardware I have to run; it’s also another piece of software and firmware I have to write. And as I mentioned earlier, I am lazy. Luckily, there’s a really interesting alternative!

Thread?

Despite its awful name³, the Thread network stack is really cool. Thread uses the same physical layer as Zigbee, IEEE 802.15.4, and it’s also a meshed network. But two things made Thread stand out for me. Thread is based on top off 6LoWPAN, short for “IPv6 over Low-Power Wireless Personal Area Networks”, and that’s kinda cool. In short, this means that each of your devices gets one or more IPv6 addresses, the internal addressing is done via IPv6, and you just throw IP packets around in the network. Even cooler is that the Thread network connects to your regular home network via a bridge called “Border Router” - so your devices can use IPv6 to talk to your applications, and vice-versa.

Wait, a bridge? Didn’t I say I don’t want to run a bridge? Well, yes, but that’s another cool thing about Thread: you might already have a Thread Border Router running. For example, if you have an Apple HomePod or a Nest Hub, you already own a Thread Border Router. If you run Home Assistant, you can buy a dongle for ~40 euros and turn your Home Assistant node into a Thread Border Router. It’s all really approachable. And if you use your existing Thread network, things get even more awesome! I did mention that Thread is a mesh network, and this feature is actively used and supported by a lot of commercial hardware. I have several Eve Energy “smart plugs” in my home, and since they are always connected to power, they function as a Thread repeater⁴, expanding your network’s reach without you doing any work!

So all of that sounds pretty neat, huh? And it is! I got two Thread DevKits to explore more (if you’re curious, I got a nRF52840-DK and a nRF5340-DK, as well as a nRF52840-Dongle for debugging⁵), and learned a lot. Within a reasonably short timeframe, I managed to hack my own border router into my Apple-based Thread network, I managed to use Wireshark to sniff on my Thread network, and I shoved my own Thread devices (based on the two DevKits) into the network, and confirmed that everything worked as I hoped it would. So, of course, I started roughly outlining a series of blog posts about all of this. Ultimately, my goal was to get other hobbyists into exploring Thread, switching away their projects from WiFi or Bluetooth, and making their projects a whole lot better.

And this is the point where this post turns into a rant.

No Thread.

So far, I have only talked about the nice things around Thread. However, I also have to talk about the ugly parts: The Thread Group. While Thread builds on many free and open standards like IEEE 802.15.4, IPv6, and CoAP, Thread is very much neither free nor open. Quite the opposite, actually.

You can request the Thread Specification for free on their website, and you will get it delivered to your inbox very quickly, but you’ll notice a few odd things. For once, there’s an “I agree to the End User License Agreement” checkbox on that page you ignored, but even more obvious: the specification PDF document is password-protected, DRM’ed, and heavily watermarked. To understand why, let’s look at that license agreement again. Partial quote, emphasis mine:

Thread Group, Inc. […] hereby grants you a […] license […] to view, download, save, reproduce and use the Specification solely for your own internal purposes in accordance with the terms of this License Agreement. […] No right to implementation of the Specification is granted to you by this License Agreement. […] Membership in Thread Group is necessary to implement, practice, and ship Thread technology and Thread Group specifications. Failure to maintain active Thread Group membership while shipping Thread technology may result in legal action, including but not limited to licensing fees.

Oh. So even though you can buy freely available DevKits, you aren’t actually allowed to … well, use them. Unless you’re a Thread Group member, of course. The least expensive membership level that will enable you to implement the Thread Group IP, called “Implementer”, is a cheap USD 7,500. Per year, that is. But hey, don’t worry, if you’re an “innovative IoT start-up company”, you can apply to get a two-year membership for free! But of course, you have to pay afterward, and this program isn’t even applicable to hobbyists.

This whole mess isn’t helped by OpenThread, an open-source implementation of Thread. The project is licensed under a BSD 3-Clause license, so it looks very open and friendly to use. However, their repo also includes a fun little notice highlighting that “members of the Thread Group may hold patents and other intellectual property rights”. And, in fact, the Thread Group website has a dedicated FAQ-section on OpenThread, which is fairly clear:

Q: What Would Prevent A Company From Shipping A Product Based On OpenThread Without Joining The Thread Group?

A: If developers choose not to join Thread Group and ship products using Thread technology, they are not conferred the IP rights required to practice and ship Thread technology, and may subject themselves to legal action, including but not limited to licensing fees.

To summarize: if you’re a hobbyist without access to some serious throwaway money to join the Thread Group, there is no way to use Thread legally - the license does not include an exception for non-commercial uses. If you’re like me and want to write a series of blog posts about how Thread works, there’s also no legal way.

A commercial membership program for technology stacks like Thread isn’t new; it’s somewhat common in that space. Same with requiring certifications for your commercial products if you want to use a logo like the “Works with Thread” banner. And that’s fine with me. If you’re selling a commercial electronics product, you have to go through many certification processes anyway, so that seems fair. But having a blanket ban on implementations, even for non-commercial projects, is absolutely bonkers. This means that no hobbyist should ever get close to it, and that means that the next generation of electrical engineers and decision-makers don’t get to play around with the tech before they enter the industry. But of course, that doesn’t really matter to the Thread Group: their members list includes companies like Apple, Google, Amazon, Nordic, NXP, and Qualcomm - they can just force Thread into being successful by making sure it’s shipped in the most popular “home hubs”. So it’s just us that get screwed over.

Anyway, if you planned to look at Thread… well, don’t. You’re not allowed to use it.

I contacted the Thread Group’s support email address on 2024-04-19 to request clarification on non-commercial Thread use. I did receive an “I have forwarded your message” from a member immediately, but no further response arrived. On 2024-05-01, I contacted the Thread Group’s press contact, requesting a comment. As of publishing this post, the Thread Group has not responded. The full text of both messages I sent can be found here.