#Thread, home network and ipv6?

1 messages · Page 1 of 1 (latest)

sour sparrow
#

Hi! So i bought one of the new ikea matter over thread bulbs to try out since I've been unable to find reasonably priced 1500lm + zigbee bulbs that fit in my lamp. Flashed the thread firmware on a conbee II I had laying around, set everything up in home assistant and I'm now trying to connect the bulb, but failing. In the process I'm also learning some things about how thread works that is very much turning me off using it... Before I throw the bulb out and use it for target practice, can someone check if I understand this right?

Seems like thread needs home assistant to be connected to a LAN with a working ipv6 setup, is this correct? Is it just for communicating with the phone app during setup, or is it needed after setup too?

Also, why this whole stupid needing a phone to pair thing anyways?

dawn moon
#

Same boat here but slightly behind you. Differences: I have a SMLIGHT SLZB-06 I’m hoping I can use as a thread “modem” on USB. I do not want thread/IPv6 on my LAN. I’m hoping the IPv6 side of thread can stay on the HA. But I’ll also need to use this OpenThread Border Router addon. I’m hoping I can run that in docker as my HA setup is all with docker. In terms of devices literally today I received some Ikea MoT buttons to play with. Early days, this is just a recon. I’m not gonna switch out my 100 odd devices Zigbee network any time soon but learning about MoT, even though I’m sure the practical advantages compared to Zigbee are close to zero, seems somewhat sensible. Will report here how I get on and you do the same. 🤣

stray bridge
spiral void
#

im having some trouble pairing as well

#

s6-rc: info: service otbr-agent-configure successfully started
s6-rc: info: service otbr-agent-rest-discovery: starting
[18:47:18] INFO: Successfully sent discovery information to Home Assistant.
s6-rc: info: service otbr-agent-rest-discovery successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
00:00:27.149 [N] Mle-----------: RLOC16 ec00 -> fffe
00:00:27.661 [N] Mle-----------: Attach attempt 1, AnyPartition reattaching with Active Dataset
00:00:34.163 [N] RouterTable---: Allocate router id 59
00:00:34.163 [N] Mle-----------: RLOC16 fffe -> ec00
00:00:34.172 [N] Mle-----------: Role detached -> leader
00:00:34.172 [N] Mle-----------: Partition ID 0x3b7197d3
[NOTE]-BBA-----: BackboneAgent: Backbone Router becomes Primary!
00:00:37.366 [W] P-RadioSpinel-: Error processing result: NoAddress
00:00:37.366 [W] P-RadioSpinel-: Error waiting response: NoAddress
00:00:38.363 [W] DuaManager----: Failed to perform next registration: NotFound
00:00:56.442 [W] SrpServer-----: Failed to handle DNS message: Drop
00:00:59.750 [W] SrpServer-----: Failed to handle DNS message: Drop
00:01:04.410 [W] SrpServer-----: Failed to handle DNS message: Drop
00:01:34.064 [W] P-RadioSpinel-: Error processing result: NoAddress
00:01:34.064 [W] P-RadioSpinel-: Error waiting response: NoAddress
00:04:53.974 [W] P-RadioSpinel-: Error processing result: NoAddress
00:04:53.974 [W] P-RadioSpinel-: Error waiting response: NoAddress
00:04:55.919 [W] SrpServer-----: Failed to handle DNS message: Drop
00:04:58.491 [W] SrpServer-----: Failed to handle DNS message: Drop
00:05:03.608 [W] SrpServer-----: Failed to handle DNS message: Drop

#

does anyone know what this error is?

lyric python
#

those logs aren't really that meaningful. please start a new thread if you're having a different problem from the person who started this thread.

sour sparrow
sour sparrow
glacial wave
#

If your network is not ready, it would be better to use the Zigbee protocol, which is simpler and more mature.

dawn moon
#

A question about Thread. Suppose I did use an Apple TV as my BR (I’m not going to, but am curious) what prevents a rouge MoT device interacting with the rest of my LAN? This is the problem I have with Thread vs Zigbee.

#

@sour sparrow currently stuck getting otbr to start via docker. But at least my SMLIGHT firmware is now on MoT mode. 😀

glacial wave
#

You mean a “rogue” device?

glacial wave
dawn moon
dawn moon
glacial wave
#

Matter is only the application layer.
Thread is the transport protocol.

dawn moon
#

I shall do some reading. I know those facts.

Consider the following hypothetical scenario. Innocent party places a device on there thread network. A light. It doesn’t matter. Everything is fine. Unknown to the innocent party this device is in fact equipped with some other network connection (it could be 5G who knows). There are two scenarios: the BR is also comprised and the BR isn’t compromised. What could an adversary do with that thread network connection in those scenarios? Yes this is deep in paranoia territory, but I have a fair idea of what the risks are with a zigbee network and want the same knowledge before looking at MoT seriously.

glacial wave
dawn moon
#

(On TBRs) “This connection allows Thread devices to communicate with devices on other networks and access cloud services, enabling remote control and monitoring of the smart home ecosystem.” I missed that bit.

#

How can protocol security be off topic when this is a forum for discussion of open-home-protocols? Are you from the Thread marketing department?

glacial wave
dawn moon
#

Do you think network security and home automation don’t coincide?

#

If so you are not qualified to give any advice.

sour sparrow
dawn moon
# sour sparrow Thanks. I have a zigbee network so I'll stick with that. Wanted to try thread fo...

I think, but have yet to prove it, that it is possible to use Thread devices with HA by creating a IPv6/Thread network between the HA box running OTBR and the matter service/addon, assuming you have a directly attached (USB) modem. Thus you can effectively contain the potentially infested with malware devices, just as you can with Zigbee. All they’d have access to is the OTBR container, and possibly other Thread devices. Much the same as Zigbee really. The thing you’d be missing out is creating networks of BRs each with their own devices, and yeah cloud control. But that’s a price I’m happy to pay. But I may also be talking nonsense.

lyric python
#

HAOS doesn't really provide the network configuration abilities to set that up, but yes - in theory, having a private network which home assistant (or more specifically, the matter server) and thread border router both have interfaces on should work for control. the problem then would be commissioning devices. The standard commissioning flow requires that your phone be able to talk to thread devices via wifi once they're connected to the thread network. Additionally, commissioning via Android devices currently requires that the phone has an internet connection.

#

something interesting about matter is that "binding" (having one device send commands directly to another device without the controller being involved) works between devices on different networks; e.g. a wifi light switch can control a thread bulb. This requires that traffic can be routed between the two networks via a thread border router of course.

dawn moon
lyric python
#

the standard commissioning flow works by having the phone talk to the matter device over bluetooth to provide the network (wifi or thread credentials). the phone then acts as a matter controller itself to talk to the device and finish the initial setup. once it has confirmed the new device is online, it "shares" the matter device with the controller that you want to add the device to.

#

the home assistant app makes use of matter functionality provided by the phone os to do all of this (part of ios on apple, part of google play services on android) - home assistant itself is only involved in the final step where the device is "shared" to it.

#

this was done to make development easier, rather than having to implement all the bluetooth discovery and matter stuff in the home assistant app itself.

dawn moon
#

Soooo if the phone can’t reach the thread network it can’t commission the device? Is that right?

lyric python
#

right now there is an alternate commissioning flow supported by home assistant (tho it's a bit manual to do) where you can use a bluetooth adapter connected directly to the machine running python-matter-server to commission directly. you are limited by bluetooth range, of course.

#

indeed, the phone has to be able to talk to thread devices in order for the standard commissioning flow to work.

dawn moon
#

In that case I’ll never use thread. Tis a shame. Luckily I only spent about £20 on ikea buttons.

lyric python
#

in the future, when home assistant switches from python-matter-server (based on the matter c++ sdk) to matter-js, additional commissioning options might become possible.

#

the problem right now is that there's no way to separate the "talk to new device with bluetooth" and "finish matter setup" to run on different devices.

#

thread is also designed to have multiple border routers on a single network to provide redundancy. It also means if the thread mesh can't reach some devices, you can add an additional border router closer to them to connect everything. thread devices can then talk to each-other via the two border routers.

#

this is different from zigbee, where you can only have a single coordinator, and if it can't reach some devices the only thing you can do is try to extend the mesh via repeators or set up a second completely separate zigbee network with a separate coordinator.

dawn moon
#

Zigbee’s got some faults for sure. But I’ll take them over this.

#

I don’t know what I’m doing yet over 2.5 years I’ve built my network out of randoms (ikea and sonoff being the main 2 manufacturers) and am upto 103 devices. Not one fault that wasn’t explainable because of batteries. This is what MoT is up against, for me. Can see no real benefits to me as a hardcore “local control, get off my LAN, don’t trust the device firmwares as far as I could throw it” type of guy. Not a normal customer I guess!

lyric python
#

yeah, an explicit goal of matter is for devices to have local control… with multiple separate controllers from different vendors being able to control the same matter devices simultaneously. and there's not really any way to do that goal other than to get the devices onto the same network as the controllers that are talking to them.

dawn moon
#

Maybe they can find a way to move the commissioning into HA like with ZHA.

lyric python
#

commissioning from HA is already possible; requires a bluetooth adapter on the HA machine (not used by any other integration) and for the matter device to be in range of that adapter.

dawn moon
#

Do you mean MoT device?

lyric python
#

any matter device, either wifi or thread.

#

as i mentioned, this might be able to be improved in the future due to the switch to matter-js (e.g. it might be possible to use bluetooth proxies, or have the phone app only do the bluetooth step while home assistant does the rest)

dawn moon
#

Hmm interesting. Where’s that documented? Sorry.

#

I’m sure I have a BT dongle somewhere.

#

Yup ESPHome BT proxy would be nice. Have one if those for the switchbot curtains.

lyric python
#

not really sure where this is documented, but on HAOS you can go to the matter server add-on options (advanced options) to set the bluetooth adapter id to use, and then access the matter server add-on web ui and press the "Commission Node" button to start the commissioning flow from there.

#

note that the bluetooth adapter must not be used by home assistant's native bluetooth integration for this to work.

#

amusingly, matter also works fine over wired ethernet, so you can get devices like PoE window shades: https://www.smartwingshome.com/pages/the-worlds-first-poe-matter-over-ethernet-motor

SmartWings
The World’s First PoE Matter over Ethernet Motor

SmartWings PoE Matter over Ethernet Motorized Shades offer a streamlined and contemporary approach to window coverings by leveraging Power over Ethernet (PoE) technology. These motors deliver both power and data through a single PoE LAN cable, removing the requirement for separate electrical wiring or battery changes.

dawn moon
#

I think what I’ll do is have a play with the matter server first and look at OTBR after I’ve got that working. The matter-app looks simple enough to get running In another container.

#

It’s a shame but I don’t think I have any matter devices to play with. Is it the matter-app that translates devices from matter protocol into HA entities? And when “HA” gains new understanding of matter device types I’ll need to pull on that docker image to see the improvements?

#

Are there any plans to fold the matter addon into HA proper?

lyric python
#

the "python-matter-server" is a separate app that runs the matter controller code, and talks to the integration in home assistant to expose devices as HA entities.

#

decision was made to have it be separate on purpose, partly to isolate it, partly so that you don't have annoying delays after restarting home assistant while it sets up subscriptions and stuff all over again.

#

it's basically more like zigbee2mqtt than ZHA, i guess you could say :)

#

and yeah, important to keep both the python-matter-server contaner and the home assistant integration that talks to it up to date.

dawn moon
#

The HA matter integration is part of HA isn’t it? Or is it HACS? Yeah it’s got Z2M vibes. Have messed with both and, you’ve guessed it, I prefer ZHA. I do use MQTT for other things though.

lyric python
#

the integration (the code that runs in home assistant and talks to the external matter server) is part of home assistant, yes.

#

it uses a custom websocket protocol to talk to the matter server.

#

device support is partly implemented in the matter server, partly in home assistant. My understanding is that the matter server exposes matter devices "as is", and the home assistant integration is responsible for deciding how to turn that into home assistant devices entities.

dawn moon
#

It’s interesting how the integration is configured with the addon’s websocket address but the addon needs access to the HA admin UI via a token. Most protocols/integrations just need the first link. Maybe it should have been implemented with MQTT as the middle man. 😉

lyric python
#

hmm? no, python-matter-server doesn't need a home assistant auth token, i think?

#

if it does have one, the only reason i can think of is to handle authentication for the web view when opened via home assistant (rather than accessed directly)

#

if you're running it standalone in docker, there's no requirement to provide such a thing.

dawn moon
#

2.1.

#

Must be something else.

lyric python
#

no idea what that is, but that's not the home assistant matter server.

#

oh, that looks like a bridge that exposes home assistant devices as matter devices so other matter controllers can use them.

#

the opposite thing of the home assistant matter server, which lets home assistant use matter devices.

dawn moon
#

Cool thanks. I’ll look for this python-matter-server.

lyric python
#

when using HAOS, it's just the "Matter Server" add-on, but it should get autoinstalled when you set up the Matter integration.

dawn moon
#

I’m dockering. 🙂

#

Looks simple enough. Will give it a try.

dawn moon
#

Still can’t get my button to go through the Apple Home provisioning. It gets through the connecting phase but gives up after about 2 mins of “setting up”. No attempt at restricting thread traffic on my LAN, is basically a flat network.

#

Following that pretty much.

lyric python
#

note that the tricky stuff regarding network setup is part of the reason why using the HAOS add-on is recommended; HAOS has the network preconfigured and iirc even a kernel patch to make failover between border outers work better.

dawn moon
#

Wow. Does this complication exist even with one BR, where (by policy) you don’t want thread traffic emerging through the BR? I had hoping that the IPv6 network just had the OTBR, devices and possibly the matter server on a single subnet? I’ve played with IPv6 only enough to know it’s a minefield.

#

The networking, from a physical point of view, is trivial for my HA setup. Just one 10/24 subset. Plus of course the containers. Most of them are on host networking iirc. I have HA, ESPHome, mosquito, etc all on the Debian host. Got no plans to switch to HAOS or proxmox etc.

mild beacon
dawn moon
lyric python
#

The Matter/Thread protocol is designed for the thread border router and matter controller to be separate devices connected via a network link. So the thread border router needs to be able to route traffic between the thread network and the external network link in order to be useful. The fact that you can mostly make it work by having a 'localhost' link between the TBR and Matter controller when both are running on the same system wasn't intended.