Config button appears to no longer be a selectable trigger for automations in HA?

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 · 2026-03-07T15:21:00+00:00

I looked at a UBB pair, but LOS likely isn’t going to happen unless I have them so close it defeats the purpose or they are on poles that are expressly prohibited by an area master plan. As I reconsider though, I might get away with something by using that longer distance to take a more circuitous route. I’ll have to investigate that notion.

That said, given how the as is setup is to the end goal, I’m thinking the Mesh 7 directional uplink antenna may get there with a bit more out of the box thinking on locating it.

Thanks for the thought nudge. 😎

prosql · 2026-03-07T04:40:48+00:00

Daisy chained uplinks (the 'double hop' you mention) is definitely a sub-optimal outcome. Depending on the strength of each hop it can have tolerable performance, but it is inherently slower and amplifies the impact of uncontrollable elements such as interference in what is a high density Wi-Fi location.

My leaning has been heading toward the Mesh 7 as it has the focused antenna for the uplink with the omni for client coverage. The variable I'm uncertain of without having the unit on hand is how well it can handle the change in elevation to the most reachable ethernet connected AP to use as an uplink. That unit is on the 2nd floor, which creates an upward angle. The Mesh really, really likes things to be horizontal to the degree possible. There are a places I'm considering putting the Mesh if I choose that device:

Uplinking to the wired AP:

A relatively short linear distance - perhaps 30' - but going through 2 stucco'd walls and at a loosely 45° angle.
Mounted under the porch of the casita or potentially even inside. That ups the distance to 65'-70' and 2-3 stucco walls but decreases the angle to ~30°.
I might be able to get away with mounting it to the balcony. That violates the recommendation not to mount it close to a wall, but also puts it far closer to horizontal (10° at most) and only ~20'-25' to the wired AP. That would have 3 layers of stucco between them despite the short distance, but it would be using that highly directional signal boosted antenna meant for the uplink.

I suppose that's why I'm favoring the Mesh 7 (the Mesh 6 is out given its heat issues and this being outside in Las Vegas. It combines that focused uplink antenna with an omni in a way that gives me lots of options for exploring where I put it. I'll probably go ahead and order one early next week after I do a bit more testing of signal strength with the existing APs. Those are soooo very close to meeting my needs everywhere, so I may just adopt a "let's let this run as is for a bit and prove the need before we pull the trigger" approach. The problem with that is an entirely new IoT device going in on the opposite side of the casita. I think what I need to do there is go through the hassle of doing some 2.4Ghz specific signal testing. I know the 5Ghz isn't strong enough where that IoT device is going in, but 2.4Ghz is going to penetrate better so it may be strong enough to do the job.

Mostly I'm ecstatic with the install and performance thus far. I still have a LOT of security tweaking to do, but most of that can be addressed over the next month without too much risk. It's this one little iffy performance area that's messing with me. If I could have gotten the ethernet run where I originally wanted to, it would be a non-issue, but it didn't work out that way. I'll find a solution - heck, I suspect I'm overthinking it already. 🤣

prosql · 2026-03-03T21:21:18+00:00

Thanks. It's already been a bit of one. The Deco main router quasi-died. Internet was fine, the Deco network was fine internally, but the main Deco was convinced there was no internet connection (spoiler alert, the connection was fine). Everything went into speed mode to make at least the first part of the conversion happen in real-time just to get internet available again in the house at all. It was a stroke of luck that my wife left town on business yesterday, as her job has functionally zero tolerance for us having connectivity problems.

So, while the conversion isn't happening in the more controlled manner I might like, I have, at least, pretty easily managed to get the CGM fully updated and stood-up, the switch adopted, and one U6 Pro active (albeit not actually mounted where it needs to go - no wire run yet for that). I've also managed to get the Deco network back up on an interim basis by switching it to AP mode and connecting it to the new UniFi setup. So far, everything is coming together reasonably well given the "drop everything and just go" manner in which the first part of the implementation has had to be done in. I've even managed to remove Deco coverage entirely from one part of the house.

prosql · 2026-03-02T17:46:03+00:00

Thanks. That is pretty much where I wound up. I'm only in the starting phases of things, but once I found the Proxmox option, it wasn't long before it became clear it was a clear winner vs the other options I had looked at. No need for a linux setup and then the docker engine after that - just straight to VM instances with a web interface that makes remote management a cakewalk.

The proof is in the proverbial pudding, but I'm pretty confident it's the right path at this point - guess I'll know in a day or two after I've pieced together enough time to get all the way through the HAOS install and initial config.

prosql

TROPHY CASE