#Integrating thread/matter to a complex network

1 messages · Page 1 of 1 (latest)

broken violet
#

I am a happy user of home assistant with zigbee devices for quite a few years now.
Given that matter/thread are the new emerging standards for iot devices, I thought now its a great time to study them, understand them and try to see how they could fit in my setup.
Analysis and questions follow bellow:

#

My network setup is heavily based on VLANs and network segmentation. Part of it looks like this:

  • A home VLAN that can access all other VLANs and the Internet
  • An iot VLAN that cannot access any other VLANs nor the Internet, it only accepts incoming connections (I don't use/like devices that phone home)
  • A services VLAN that can access only the iot VLAN and the Internet, and it accepts incoming connections from other VLANs (the home VLAN in our case)
    All network traffic is controlled by a router/firewall in the middle that forces the rules for all the inter-VLAN traffic.
    All the (managed) network traffic is explicitly IPv4 (I mean some devices probably have link local IPv6 addresses, but they aren't explicitly used in any server/service or VLAN firewall access rules, and the router doesn't have any IPv6 ip and prefix).

My home assistant setup with the zigbee devices, looks like this:

  • Home assistant and zigbee2mqtt run as podman containers inside the same iot podman pod (meaning they can access each other via localhost, as they belong to the same linux network namespace)
  • A Sonoff ZBBridge Zigbee Gateway flashed with tasmota acts as a zigbee coordinator that listens for serial over tcp connections
  • The home-assistant/zigbee2mqtt iot pod is exposed using macvlan (meaning it has its own IP) in the services VLAN
  • The zbbridge is resides in the iot VLAN along with other wifi iot devices (this doesn't matter for now as we focus on the zigbee part)
  • The home-assistant container/pod connects from the services VLAN to the (tcp listening) zbbridge in the iot VLAN and can interact with all the zigbee devices through the coordinator.
#

Now, after studying the thread/matter concepts it seems like this is a very different beast from the common zigbee2mqtt setup. Summing up my understanding:

  • Thread border routers do not act as zigbee coordinators (proxies), but as plain routers, that accept IPv6 traffic and forward it from my normal wifi/eth link based network to the thread link based network
  • Thread/matter relies pretty heavily both on IPv6 link local traffic and mDNS traffic for device discovery/provisioning
  • Thread border routers advertise the IPv6 prefixes / routes for the devices in the thread network, and any device that needs to communicate with them must use them to access the thread devices (not sure about that)
  • A thread border router must probably be on the same network segment (VLAN) as home-assistant for it to work

If I also understand correctly, the components that compomise a working ha/thread/matter setup are:

  • Home Assistant
  • Matter Home Assistant integration that connects home assistant to the matter server
  • Matter Server that acts as the controller for matter/thread devices (is this the component that discovers/communicates with the tbr?)
  • Thread Border Router that routes the IPv6 matter traffic to the thread devices
  • Thread Home Assistant integration? (not sure if this is mandatory)
#

So my questions are:

  1. Are the above software compoments correct? How exactly do they interact with each other?
  2. Does my main network need to know the IPv6 routes advertised using RAs from the thread border router, or is this something only home assistant (or matter server?) needs to know?
  3. Has anybody with a more advanced network setup have any documentation/analysis on the actual thread communication sequence and network dependencies to augment my understanding?
  4. What are possible ways that I can make matter/thread work without having to flatten my network?
  5. Can I have a home assistant instance that resides on a different network than the matter/thread devices and still make this work?
#

Integrating thread/matter to a complex network

hidden cobalt
#

more or less correct, but you're missing one thing - device commissioning. For device commissioning the recommended method is an Android or iOS mobile device running the Home Assistant app, and that device must be on a WiFi network bridged to the same network link as the thread border routers are on (specifically, must receive IPv6 RAs from the TBR, and must be able to resolve mDNS queries answered by the TBR). Additionally, Android devices require a working internet connection for Google Play services.

#

The "matter server" is the part that actually talks to matter over thread devices, and therefore must have the routes to the thread network available and be able to resolve dns.

#

The Thread Home Assistant integration is technically not required, but the main thing it does is synchronize the thread network credentials to the Home Assistant mobile app so that you're able to commission Thread devices. There's a separate "Open Thread Border Router" integration which talks to thread border routers running OTBR (or something which provides OTBR apis) and that allows home assistant to retrieve the thread network credentials from the TBR (and also adds UI allowing you to set up a thread network from HA, change the network channel, etc). The OTBR integration can be configured with a static hostname/ip address to connect to, which may or may not work around issues with resolving mDNS.

#

There's not really any support for this sort of thing (you get to keep the pieces when it breaks) but you can probably get it to work if you run the "matter server" in the iot vlan (please note the tricky OS/networking requirements in https://github.com/matter-js/matterjs-server/blob/main/docs/os_requirements.md). Home assistant's matter integration talks to the matter server by making an outgoing websocket connection (it sounds like your network setup will allow this). If you are using android devices for commissioning, you will need to add (temporary) firewall rule exceptions that allow the android device to connect to the internet from the iot vlan.