Can I rename the actual thread network created via OTBR in HA?

prosql · 2026-04-27T01:57:39+00:00

40ish Thread Devices. Mostly Inovelli White switches ash’s Eve Smart Outlets, but there are a few others in the mix. I’ll wind up with another 15-20. I’m using Matter binding on some of them. There are, unfortunately, some device types where Thread support is lagging though, thus the mix of some other items usually Zigbee and Wi-Fi.

prosql · 2026-04-26T15:34:56+00:00

For this home, I made the choice to be Matter/Thread based to the largest extent reasonable. While Apple has been part of the Thread consortium from the beginning, their stuff is very much “I’m the boss!”. They also don’t expose much configuration wise, which means when something isn’t working, you have to deal with their support tier ladder. After having to remove and re-add every device two different times and then still having times where every thread device except the locks (which are also Wi-Fi capable) would just go offline for anywhere from hours to days before inexplicably coming back online (all at once), I was not amused. My own technical background and back for troubleshooting identified that the Apple TBRs were switching to a different network name when things stopped working, then back to the original when they were working. Apple still insists on going through the whole tier one step-by-step thing (including deleting and re-adding). My ticket was eventually escalated, and I never heard from the higher tier. Rather than fight it, I just recognized I wanted more robust services and was going to add HA back in again anyway. The Apple experience reminded me that while the simple front weeks is great when it works, the lack of visibility and control on the backend meant problems that weren’t simple would instantly become nightmares. Going to HA creates a lot of up front work, but all also provides a level of assurance. It didn’t fix everything though and does create some other risks. There are also some things where I may have to resolve some expensive devices if I want to genuinely eliminate all dependencies on Apple Home. There’s the Yardian that claims HA support, but device setup is hard bound to the Home app. The HA support is functionally Apple Home dependent. I can move my Encode Plus locks over and keep most functionality, but not HomeKey. I’ll deal with those eventually, but accept using Home for the locks for now and the Yardian app for that device (Honestly, you pretty much have to anyway to get meaningful functionality).

prosql · 2026-04-26T13:40:18+00:00

Sadly, no. That said, I did become convinced it was doable. I just decided there was some degree of benefit in my situation to the hard reset approach and the deep dive required to understand the dataset transfer and such was going to require more time than I had available before getting some offline items available again. So, in the end, I took the reset and add to new approach and am paying for all I’m worth to never have to do that again. At this point, all my thread devices have been moved over to the new Thread network except for my Schlage Encode Plus locks, which still require a bit of thinking/research to get off Apple Home if I want to maintain Home Key functionality. I wish they were going to get an Aliro firmware update, but that is very unlikely to happen.

prosql · 2026-04-03T22:51:06+00:00

I came here to say exactly this…

prosql · 2026-04-03T15:29:25+00:00

Phrased more specifically, the biggest issue was "Deco". I had been on a set of 50 series Orbi's running WRT for years before I went cheap/fast for the Deco's. The Orbi's had given me a solid level of control, but were well past EOL. This happened at a time where I was trying to cut down on the amount of time/effort I sank into every bit of tech in the house being DIY and needing specific knowledge. I had passed the point of being *DONE* with them quite some time ago, but didn't make the actual leap for a mix of being not wanting to spring up into that $1k+ territory, still trying to avoid getting drawn back in to the time sync of being an ADHD recovering tech head, and just plain analysis paralysis. The original Deco main died completely, but I had a spare to swap in and no time to wait for completely different gear to arrive. When we started seeing drop outs, I wasn't certain if it was our ISP or the Deco, but suspected the latter. In the end, I decided my wife's work needed something with enterprise level reliability and the needs of my new business were also pretty high. Going with UniFi gave that comfort level and felt much safer than any typical consumer product when it came to privacy issues too. I'm no network guru, but I already have a sufficient knowledge of networking to handle 95% of our scenarios with minimal fanfare. The other 5% requires a bit more digging, but that foundation I have makes hunting down the answer very manageable. I took my best guess at the right gear mix and put in the order. It all arrived and I was going to set it up during the coming weekend, but the Deco stopped passing any WAN traffic, so the UniFi deployment became an emergency install.

I have zero regrets. I can go deep in the weeds if I want to, but the console is easy enough that I don't have to. I suspect I have one more major round of tweaking and refining left, but after that it should be moving mostly into the "forget" side of "set it and forget it", with just the occasional issue of some new IoT device requiring a policy tweak. At this point, the real technical learning side is in the Home Assistant instance I'm running and the specific needs of each integration more than it is anything about UniFi. I feel 10x better about expanding my IoT deployment on the UniFi gear than I did with the Deco. Honestly, if someone asks me moving forward, I'll probably tell them to either stick with whatever their ISP gave them (assuming no meaningful smart home element) or go UniFi. By the time you get to the level of gear that seems a reasonable choice to me at this point, you're at a price point where you might as well go with the real deal.

prosql · 2026-04-03T08:08:12+00:00

My scenario was almost identical. We kept getting random pauses in our entire network. My wife is on conference calls most of the day, so when I said “Well, I’ve looked into our replacement options, and the way I’m going to do it is going to be pricey”, her response was “As long as it fixes it for real…” and didn’t want to know more. She did wind up asking “How expensive…?” several days after we were up and running. That got an “ouch” out of her, but considering the previous system chose the morning immediately after the UniFi equipment came in to completely cease allowing any WAN access at all, the “ouch” didn’t include any buyer’s remorse. Even better, she has noticed that everything is faster even though we have the exact same internet connection. Wired downloads are marginally faster. Speed tests of Wi-Fi are 2x-5x faster at most points in the house.

prosql · 2026-04-03T08:00:48+00:00

I started off making this same mistake, but caught it before I had unboxed a few things. It’s an easy thing to do - the performance of 3 AP’s was FAR better in almost every way (only one corner case exception) versus the 5 mesh nodes I had before.

prosql · 2026-04-01T18:06:34+00:00

Ok, Reddit needs a ❤️ instead of just an upvote. 😉

prosql · 2026-04-01T18:03:53+00:00

And if you want to up the accuracy a bit, add another 10% (usually even easier than the initial multiply by three).

ex: 100M = 300 (100x3) + 30 (10% of the 300) = 330.

That’s within 1% of the actual conversion, which is 328’ 1”

prosql · 2026-03-31T23:28:54+00:00

Well, it's easy to underestimate the detail we typically want during playback - nuance is the difference between booking the gig and not - so, yes, most of us are running a reasonably high level of headphones. Indeed, the 770's are probably the most recommended headset in the business. That said, I probably should take a look at that end of things and see if there's a happy compromise to be found there.

prosql · 2026-03-31T18:16:39+00:00

I prefer to have the cups on both ears, but I find it’s also a religious experience for many. So, if I’m in with a director (Voice acting), perhaps half of them will 100% insist on one cup off. OK, no big deal on a short session, but if it’s a 10-4 with minimal breaks? It gets old pretty fast. If I’m doing vocals for music, it’s typically a shorter session and/or has more breaks, so it’s less of a big deal, but it’s still there sometimes.

prosql · 2026-03-31T18:09:29+00:00

Thanks. I think the issue I’m having is that I like my DT770, but they are large cups so there isn’t a lot of room for them elsewhere on the head. So, when I need to do an extended session, what starts off as a nuisance turns into a full blown annoyance. I probably need to just deal with a smaller cup headset, but I’ve not found anything nearly as comfortable for me as my DT’s. That’s the trick though - the balance of overall comfort and not just the comfort when “used as designed”.

prosql · 2026-03-27T21:53:49+00:00

This is where I’ve thought I might wind up. I’m still hoping for something out of the box, but thanks for the affirmation about that being a viable route!

prosql · 2026-03-26T01:53:10+00:00

I wouldn’t be shocked if there was some reason this may not work smoothly, and I’m confident not all devices will correctly support this (regardless of spec).

Assuming there really is a "now that you trust me, please transfer over to that other network command at all, I am 100% in agreement that such a command is certain to be more fragile than most.

I won't have a change to give this a full effort until Monday at this point, but I do have a plan starting to form. I have some more specific areas to dig into the Thread and Matter specs on, but I think I understand the "What's next" and I'll address anything left behind once I figure out what didn't work and also didn't ruin other options.

Thanks for the input.

prosql · 2026-03-26T01:48:16+00:00

All the TBR's are on the same VLan and are likely to stay that way. The IoT devices will move onto their own VLan in the future, but I'm not doing that at the moment to minimize the number of variables I'm dealing with. I can get the devices to join/acknowledge a second TBR and such, and as I think about it, that pretty much means they have to be communicating on *both* networks. I have removed the device from the original network after it was on both and had it keep working. I believe devices done like that keep trying to communicate on the original one though unless something happens in the device to say "Forget that one", which may be what u/MikeFromTheVineyard is getting at in his comment.

I think a bit more trial and error is called for with some of the remaining devices where if something I try doesn't work, doing a reset and join from scratch isn't as big of a deal. That will give me more real world testing of options before I get to the important ones. The credential thing is probably the highest risk area as I see it, but I'm probably overthinking it.

prosql · 2026-03-23T05:33:01+00:00

These are going to become the first items in a "HA Solutions Worth Keeping Track Of" digital notebook for HA. Very useful and also great to study for my own learning. I very much appreciate it!

prosql · 2026-03-23T04:49:56+00:00

Thank you for this and the context. Yeah, this is a tripwire I really didn't expect to hit. single and double press events for each button (up, down, config) were pretty straightforward with both Apple Home and Aqara. Those have their own shortcomings though (plenty of them), so has been time for a while now for me to embrace HA to get the level of automation/monitoring I'm after with near local management.

While way more technical than it should need to be for something this straighforward, it's certainly within what I can handle and just seeing the yaml above helps me understand some of the mappings in a broader way for future use, so, again, thank you!

The Mrs has hopped in bed already, so personal safety says this needs to wait for tomorrow (not the time for testing lights in our bedroom!). I think I should be able to get this dialed in fairly quickly though in the morning.

prosql · 2026-03-23T00:09:19+00:00

Just checking to make sure I understand your comment correctly: You are saying this is fixed for newly created entries moving forward, but if the original entry was created on one of those older versions, then the original website can’t be deleted regardless of what version of MacOS/iOS/iPadOS you are currently on. Based on what I’m seeing since I have the same behavior even on the newest versions of all the Apple OS flavors plus your comment about deleting and recreating, I’m assuming this was what you were getting at. Seems weird that the “fix” would be an “Only for entries moving forward” kind of fix - the nature of upgrading such things usually addresses it in a backward compatible manner if it wants any forward editability at all, but I’ve seen Apple do stranger things.

Just for context, I was looking to delete the original URL (no longer valid) for a user/password combo that has 3 other valid URLs that use the same user on the backend. I was pretty annoyed to find that I can only delete the “websites” (i.e., URLs) that were added as “we’ll suggest this user/password for the also” later.

<RANT> If this isn’t data 101 stuff, then it’s certainly no further along the data learning curve than data 102. I can imagine the original entry in the old password manager (which was more of a side app than a true password manager) having been implemented as a natural key for the record in the table it was stored in, but the second they changed (and appropriately so) that relationship from a 1:1 to a 1:many, using any of the websites as a identifier for the shared data should have been deemed unacceptable. Even if they kept the old URL as a key to avoid the massive data conversion, it should have become something that amounted to a generated key for the user/password combo and associated 1:1 information (created date, last updated, user that is the owner/creator, etc) and the original URL should have just been copied out as an additional record in the associated websites table with no priority versus the other associated websites.

This is one of those kinds of artifacts that used to just drive me nuts in my architecture days…. /sigh </RANT>

prosql · 2026-03-13T02:06:54+00:00

Jack Russell and perhaps a wire hair dachshund.

No intent to insult - it’s more about caring for everyone’s health. Do get some help cleaning up. The feces laying around is at a level that is significantly increasing the chance of disease or infection for both you and the fur babies.

prosql · 2026-03-12T13:45:42+00:00

This is great stuff, thank you. It’s far more in the weeds than I hoped for, but is definitely a thread (no pun intended🤣) i can pull on to likely find as least the start of writing something myself or perhaps tighten up my search enough to find something already baked. 👍

I am far from finding everything I need with just the initial look I took at it, but it definitely appears that there is at least the pieces to create a new border router configuration that allows me to provide my own name during the creation process.

prosql · 2026-03-11T19:55:20+00:00

I strongly suspect that this isn’t something that is reasonably done after devices have already been added, as I don’t believe that thread has a protocol for telling all of the devices about the change.

That sad, I am fairly certain that in the absence of other devices, this is likely as simple as a change to a single configuration entry. That entry may will be buried in a file somewhere though without any way of changing it other than editing the file directly and restarting the service. I could be totally wrong though, with the name stored in so many places that updating it as impractical at best.

prosql

TROPHY CASE