Not calling other software engineers 'losers' is not about political correctness. They're "losers" because they take their product on a path you don't like? Come on. Linus can be emotional in his posts because Linux is his "child".
Yes and no. Performancewise, the iconic Ferrari Testarossa from 80s/90s does 0-62mph in 5.8sec. That's in the ballpark of today's family SUV EV, like the Tesla Model Y (standard version, 'Performance' does 3.3sec) or Hyundai Ioniq 5 (again standard version, performance 'N' does 3.4sec).
But I'm sure the "fun factor" in a Ferrari is much greater and of course there's a nostalgia factor as well... it was "THE" supercar when I was a kid. I would love to drive one today and it would be much cooler than a Tesla Y or Ioniq 5 :-)
It's even funnier when you realize all of the V6 Camrys built in the last 10 years also have a 0-60 of 5.8 seconds or less, and with the right tires and some suspension tweaks probably handle about as well as an 80s Ferrari.
The last Testarossa I saw in the wild was around 2010 parked in Hoxton London. None of the upholstery was holding up and it looked like it might not be driveable. But it got there somehow.
That is my sticking point - every border router I can find has a bunch of other things I don't want. I don't want my lights available from the internet, I just want to turn on the shed outside light from inside the house when I have guests. (since they are likely to park by the shed and walk to the house)
That is I don't want google/amazon/samsung/apple to control my house. Most border routers are also connect to our smart home system. (there are exceptions but it isn't clear if they are better)
While not a proper product, you can buy a small ESP32C6 devboard for up-to-5 USD/EUR and flash an example from esp-idf. This is paired with some software that runs on posix systems (think your HA host) that together form the necessary commissioning and border routing functionality. Its ends up being a relatively simple device that just takes IP packets off the radio and puts then somewhere else, so I've no doubt somebody will shortly make one (I've been working on one such for myself as an experiment.)
For what you're looking to do in principle you don't really need any of this after the initial commissioning. So long as the radio waves can reach the devices they will be able to talk to each other.
Just checked again, those ideas have started to mature to something that is possible now (vs 6 months ago when I last looked). I have kids and many other things in my life, so I'm don't have much time to work on projects like this. That might be what I end up doing, for now I just have a light that hasn't worked for months because I don't want to figure this out (the manual switch is broken. Since the switch is both rarely used and one I'd want remotely controlled anyway I've been hesitating)
SMLight also do their PoE sticks that can be flashed to either talk Zigbee or Thread (but you'll need a border router, such as the OpenThread border router).
Their latest one has two radios so you can do both Zigbee and Thread from a single device.
I've found however, that Thread prefers several border routers around my house to operate well.
I mean... I have an Aqara Matter over Thread smart lock that connects via AppleTV (which is a Thread border router) to Home Assistant. And I can control the lock both with HA and Apple HomeKit. And this whole thing works flawlessly. Aqara, Apple, open source HA. Never thought this would be so smooth.
I think the whole point of Matter is that the devices are manufacturer independent and you can use any device with any hub.
I have an Aqara Thread over Matter smart lock too. The only thing I can do with it via Home Assistant is remote unlock/lock and get the battery %. I can't do user management or the million other features that require me to use the Aqara app.
Yes, that's true. I think Matter doesn't support yet many of additional configuration stuff. Hopefully that will change as the technology matures. As I use it with HomeKit as well I can do some user management through Apple Home. However, full config with all options only through BT and Aqara app, as you say. At least for now.
What? You can buy a very cheap ESP32 with Thread and easily build your own device with Matter/Thread and it will work. Doesn't seem that closed. There is OpenThread that is an open source implementation of Thread. Home Assistant is compatible with Matter over Thread devices...
What's closed about this?
I know almost nothing about Matter but is this true? I though that if you control your own fabric, you can talk to any device on it because they trust your controller.
This is correct; the hand-wringing in this thread is fair in that Matter does have a central governing authority who determine which devices are trusted, but completely unjustified insofar as that making a DIY Matter fabric/network is extremely easy.
The part about Matter that's "closed" is the device attestation process; the Distributed Compliance Ledger (DCL) contains a closed set of trusted Product Attestation Authorities. The device's Device Attestation Certificate (DAC) needs to chain to these PAAs for a "production" Matter Commissioner to enroll the device in a fabric without additional steps.
Here's he thing: all available Matter Commissioners make it really easy to commission a device with an untrusted DAC; for Google you need to add the IDs for the device to a Developer account associated with device you're trying to use as the Commissioner, and for Apple (at least as of a year or so ago when I last tried this), you just press "Trust this untrustworthy device" on a dialog box.
So it's kinda like UEFI Secure Boot? PKI with a default list of officially trusted companies, and it's supposed to let the end user add their own keys, but the details make people nervous because it would be really easy for the vendor to break that any time they feel like it?
* The list of officially trusted companies and root certificates is stored on a blockchain, for whatever reason, but at least this way it's a fairly open list and it's supposed to be shared equally across all vendors.
* It's a lot easier to get an official key provisioned / device certified. It's not like UEFI where there's some murky trusted set of root keys belonging to a major manufacturer (Microsoft) who blesses things at a whim.
Importantly:
Even if the "vendor" (in this case, it's Google/Apple) stopped supporting test keys in their Commissioner, one could still run a "fully private" Matter fabric with their own Commissioner. Of course, if this happened, a user couldn't commission their devices onto the walled garden Google Home / Apple Home ecosystems, but, they could still make their own Matter fabric with their own Controller. It's not done this way normally: even with HomeAssistant, which can run its own Matter Controller, the Commissioner role is typically delegated to Apple/Google SDKs through the Home Assistant app. But this is because it's a huge pain to develop a working Commissioner (due to Bluetooth, mostly), not because it's not possible. There's no "lock-out" that causes Matter devices to only provision to approved Controllers/Fabrics - the lock only goes the opposite direction, to prevent end users from buying insecure/spyware devices with the Matter label.
However, unfortunately:
* You don't really enroll your own key or root certificate with most of the "standard" (Apple/Google) Commissioners to use them with development devices - rather, you use a fixed set of vendor or device IDs which signify them as test devices (in the extra easy path, you even use a fixed device certificate for a Test Device). This makes sense from the constraint that users can still build and develop their own devices while protecting the ecosystem from "rogue vendors," but it's not like UEFI Secure Boot in this case where the end user can enroll their own keys and truly control the system end to end.
Now again, there's nothing stopping the end user from building a Commissioner which would trust their own self-signed certificate, besides it being a pain in the butt, but that's not how it works by default - it's truly a development mode, not a bring-your-own-keys.
Buy a device from the manufacturer “Eve” try to add it to homeassistant after upgrading its firmware to use matter/thread: no can do, they don’t give you their key to talk to their devices.
I did exactly this. Got an Eve smart plug meter and it works flawlessly in HomeAssistant. I'm also pretty sure I had upgraded to the latest firmware via Apple Home app before doing so.
Great, their new devices actually work in thread mode with HA, but their older ones only when you got an Apple hub device. I’ve got 6-7 of their devices before matter was a thing and 0 work with HA. Even those that got firmware updates.
If course it has to be pre-planned, someone needs to have the hardware with them. So sometimes there's a spontaneous connection over normal mobile phone. That's something that everyone has with them at all times.
A decent quality stream is not 256 kilobytes per second (1/4 megabyte), as you write. You probably meant 256kilobits, which is only 32 kilobytes. For speech that’s VERY high quality. Teams actually uses either G.722 or SILK codec, which is just 40kbit/s. That’s 5 kilobytes per second.
256kbps (yes I was pissed and miss-typed B for b and a few other transgressions) or whatever is sod all these days for throughput, as you well know, so worrying your codecs down to 40kbps means nothing if your jitter buffer is going mad!
Modern home/office internet connections are mostly optimised for throughput but rarely for latency - that's the province of HFT.
You see tales from the kiddies who fixate over "ping" times when trying to optimize their gaming experience. Well that's nice but when on earth do you shoot someone with ICMP?
I can remember calling relos in Australia in the 1970s/80s over old school satellite links from the UK or Germany and it nearly needed radio style conventions.
I've been doing VoIP for quite a while and it is so crap watching people put up with shit sound quality and latency on a Teams/Zoom/etc call as the "new" normal. I wheel out Wireshark and pretend to watch it and then fix up the wifi link or the routing (Teams outside VPN - split tunnelling) or whatever.
Tangentially related to the topic of the bandwidth efficiency of Teams: screen sharing in Teams has a very low framerate of about 3 to 4 fps. It is driving me insane, especially when the presenter starts relentlessly scrolling up and down and circling things with the mouse cursor.
I think Microsoft took bandwidth efficiency a bit too far here.
