Supporting Thread in particular is an interesting choice, because as far as I'm aware Thread is one of the most open-source IoT stacks[0]. Thread isn't really used in consumer hardware, which is probably the reason it's so obscure within the hacker community, but there's a lot of buzz around it within industry groups. Companies like Google, ARM, Amazon, LG, NXP, Samsung and many others are supporting the development of Thread.

What's interesting about Thread is that it takes advantage of IPv6 to allow any device on a network to talk to the World Wide Web. Usually, you can only talk to your IoT gateway over the web, and then tell it to control its children. Thread simplifies all of that and lets you directly talk to any child via its IPv6 address[1].

Compared to some other IoT protocols, Thread also takes a strong stance on security: unlike other protocols such as Bluetooth Low Energy, you cannot create an unsecure Thread network[2], you must have the correct credentials to talk to any Thread network, and all communications are encrypted.

I believe that Thread is going to be a very important part of the future of IoT, and I'm excited to see what comes next.

[0] https://openthread.io/

[1] https://www.threadgroup.org/What-is-Thread

[2] https://www.threadgroup.org/Portals/0/documents/support/Thre...

> Usually, you can only talk to your IoT gateway over the web, and then tell it to control its children. Thread simplifies all of that and lets you directly talk to any child via its IPv6 address[1].

But I don’t want every one of my potentially buggy IoT devices to be directly addressable on the Internet.

Ideally they’d each be isolated, with the minimum connectivity needed to the hub.

Yes, you can isolate individual devices the same way you'd isolate any IPv6 device on your home network - using a firewall. Normally you would firewall away your entire home network and only open up connectivity to the devices you want.

Additionally, you can configure the firewall on the Border Router as well, which is the device that actually interfaces between Thread and other networks.

That's a shot in the dark, but I may ask it here: Do you have a simple documentation that would tell someone who knows how to route an IPV4 network and avoid the pitfalls, what is the correct way to do it in IPv6? I struggle to find a good summary of the things one needs to know

IPv6 is weird for someone coming from IPv4. Basically every IPv6 address is a public IP address. Your firewall is responsible for blocking inbound traffic from actually getting to the devices at these addresses. This replaces NAT. So, what I do is have a default rule that blocks all IPv6 traffic inbound. Then, instead of a NAT rule, port forwarding, etc., I just allow inbound traffic on certain ports to certain addresses.

Thread uses something called a Border Router to handle the Thread Network / Home Network communication. The end devices can only communicate with the router, which then could make a potential http request or whatever. Giving an end device direct web access would have to be a deliberate move.

Another great open source competitor is Home Assistant [0] which has been around much longer and is relatively mature.

[0] https://www.home-assistant.io/

Yes, that's what I'm running at home for almost a year now. There is so much stuff already in this system, it is amazing.

I always found the scripting a bit annoying (programmer by day, so I could, if I would want to, but...).

That's why my HA install is accompanied by a NodeRED instance. I really like just clicking my flows together. And if there is something missing, you can be sure that someone already built a matching node.

Also z-wave

> without a middleman

Are you saying that I should be able to connect to my home directly over the Internet? How does it bypass NAT.

You configure your router to not use NAT for IPv6, and get your ISP to provide you more than a /128, is how. This is why industry is adopting it and consumer devices aren’t.

(IPv6 space is big enough that there’s no reason that residential ISPs shouldn’t be assigning everyone larger prefix ranges by default, but that doesn’t mean they will. They probably think they can up-sell it. Thread is a great, simple protocol for the hypothetical world where the residential ISPs give up on this practice. It’s not so great for the world we’re in, unless you’re already using some separate VPN overlay network.)

The problem for me in the UK is that most ISPs are dynamically allocating prefixes using DHCP-PD. So I've not got static address I can put in my firewall for the equivalent of ipv4 port forwarding.

"without a middleman" means it won't rely on some 3rd party to work. As a contrast, for example, a SmartThings hub requires an internet connection to work because (almost) everything is sent to Samsung first.

Whether you want to connect to your home directly over the internet is up to you, in this case.

The goal of this is to be hosted on a router. I'm assuming it wouldn't go around NAT as much as replace NAT by replacing router's firmware.

You've guessed correctly that this is one of the most painful parts of the setup. I use a different open source product for the same purpose (Home Assistant), and it allows me to go around NAT manually (use dynamic DNS service, open up the port on a router, route it to a local device, issue a Let's Encrypt certificate) or pay them a few bucks per month to ease the pain.

Mozilla hosts an https tunnel for subdomains that match YOUR-subdomain.mozilla-iot.org where users choose a unique subdomain and a cert for it is auto-installed (using LetsEncrypt) onto the RPi or Turris Omnia during first time setup. In the future once the WebThings Gateway has control over edge firewall rules, then the tunnel can go away in favor of a "hole" for 443 or a port forward rule for https access directly to the gw. Privacy risks are far reduced if we all run our own local smart home gateway in our homes.