[HN Gopher] IKEA ditches Zigbee for Thread going all in on Matte...
___________________________________________________________________
IKEA ditches Zigbee for Thread going all in on Matter smart homes
Author : thunderbong
Score : 354 points
Date : 2025-07-09 09:42 UTC (13 hours ago)
(HTM) web link (www.theverge.com)
(TXT) w3m dump (www.theverge.com)
| sc970 wrote:
| The new verge paywall seems to come out of no where, and seems to
| cover every article with no free limit?
| Simulacra wrote:
| Paywalled. https://archive.is/uOHVR
| AndrewDucker wrote:
| Paywall bypass: https://archive.is/8S1un
| vachina wrote:
| Haha. Imagine a light switch that becomes obsolete like your
| wireless router.
| lotsofpulp wrote:
| Why can't it keep working via manual control?
| gorgoiler wrote:
| These types of switches will always retain manual control. It
| is common to separate the user facing switch from the actual
| electronics and everything still works manually. This means
| you can take any new or existing switch furniture and make it
| smart:
|
| https://sonoff.tech/products/sonoff-mini-extreme-wi-fi-
| smart...
|
| This is good because manufacturers of well built physical
| switches are usually rubbish at technology, and high tech
| electronics manufacturers are rubbish at making aesthetically
| pleasing, durable switches. Separating them gives you the
| best of both of worlds.
|
| The obsolescence is in the radio integration whereby one day
| you can control it remotely, the next day you cannot.
| bluGill wrote:
| IF they design it to work that way it can. Do you trust the
| manufacture to do that though? This is not only do they need
| to design it that way, but also that they need to ensure it
| works in all the edge cases. I've been in software long
| enough to know there are a lot of weird edge cases nobody
| thinks of that are then missed for years.
| lotsofpulp wrote:
| If you toggle or otherwise manually manipulate a light
| switch, surely it is physically disconnecting the circuits?
| I don't see how that mechanism could ever not work, absent
| mechanical issues.
| bluGill wrote:
| A smart switch cannot be a toggle. It needs a relay of
| some sort so that it can be controlled by software. There
| is a switch you control, then something, then the relay.
| That something needs to work.
| lotsofpulp wrote:
| Oh, I see. Thanks!
| cheeze wrote:
| > Do you trust the manufacture to do that though?
|
| ... Yes?
|
| I use Lutron so I'm less concerned about obsolescence...
| but yeah. Pretty much every smart light switch I've ever
| used is just a normal light switch with additional
| networking capabilites.
| vardump wrote:
| Does Thread work without cloud?
| bananapub wrote:
| yes, that's the entire point of it
| 0x000xca0xfe wrote:
| Yes but since it routes IPv6 and hubs are usually connected to
| the Internet when set up by the average consumer, it is very
| easy for Thread devices to "accidentally" gain Internet access.
| CharlesW wrote:
| My understanding is that it can never be accidental since all
| access is mesh-local by default. You'd have to install a
| border router capable of supporting NAT64 features --
| SmartFriends(tm), I think this generally not possible with
| consumer border routers, correct? -- and then explicitly
| enable it for a device.
| Toutouxc wrote:
| The question doesn't really make sense this way. Thread is more
| or less like Wi-Fi. It's a transport technology and protocol.
| It's HOW your devices can talk to each other. It's how they can
| say "I'm here and I can see 'AirPurifier324' over there."
|
| Matter is a bit like HTTP. It's WHAT your devices say to each
| other. It's a way for them to say "Hi, I'm a lightbulb and you
| can change my color and brightness."
| vardump wrote:
| Ok, let me ask another way.
|
| Can it operate without an internet connection and with an
| open standard that lets the me, the user, to be in control
| using a hub (if necessary) and software I choose, including
| an open source option should I so choose?
|
| Or do I have to use proprietary hubs and software to control
| the devices?
|
| In short, are there any end user hostile features or can I
| use the devices like how Zigbee works?
| Maxious wrote:
| Two devices can talk to each other if the hub helps them
| exchange keys https://community.home-assistant.io/t/how-to-
| implement-devic...
| kenmacd wrote:
| I've done everything using old Particle Xenon boards
| (nrf52840 microcontroller) and didn't encounter anything
| 'user hostile'. Originally I had all the 'hub' stuff on one
| of the boards too, but the newer recommended way is to have
| the board be the 'radio' and to use a normal computer for
| the routing.
|
| The matter network is just an IPv6 network, so I run coap
| server on my matter devices and then control them with
| command like 'coap-client -m post coap://[<ipv6
| addr>]/open_button'.
| thedougd wrote:
| Yes, local control is a key feature as well as multi-
| controller.
| nick__m wrote:
| I don't understand the problem that thread solves that zigbee
| doesn't! The article says that thread doesn't require a hub but
| it require a border gateway that is almost indistinguishable from
| a hub. And as far as my home assistant setup is concerned, it
| doesn't require a hub, only a zigbee radio.
|
| The only thing that seems to advantage thread is manufacturers
| support, but I don't see what's stopped them to regroup around
| zigbee.
|
| Any one has clues on why Thread was needed when zigbee already
| existed?
| AndrewDucker wrote:
| My understanding is that Thread is lower latency and lower
| power than Zigbee.
| nick__m wrote:
| How is that possible when thread use an ipv6 stack over
| 802.15.4 while zigbee use a simpler stack also over 802.15.4
| ? The only thing I see is that manufacturers prefer an ip
| stack because it's "easier" to develop for.
| AndrewDucker wrote:
| An excellent question - all I can do is point you at the
| research. See the top graph here: https://www.reddit.com/r/
| homeautomation/comments/nxmehn/clea...
| nick__m wrote:
| I should have been more precise, I don't doubt the claim
| about latency nor speed, but I really doubt that running
| an ipv6 stack requires less power than running the
| simpler zigbee stack.
|
| Also one Thread advantage from that discussion made me
| laugh: safe as the internet, using proven
| IP technologies
|
| But thanks you for answering me!
| dgacmu wrote:
| I haven't measured it, but: in a lot of embedded
| situations, the radio transmission time is the single
| biggest consumer of power. Thread+matter being more
| efficient on number of packets transmitted per command
| (the reason latency is lower) could actually translate to
| battery savings.
| 0x000xca0xfe wrote:
| But does it translate to real world gains? I've developed
| a Matter (wifi) device and the stack is ridiculously
| chatty.
| AceJohnny2 wrote:
| (offtopic) from the link
|
| > _as redundant and safe as the internet_
|
| Ahaha! Haaahahaha! i'm choking
|
| (Joking aside, I get that their point is they leverage
| the decades of work into IPv6 rather than recreate their
| own ad hoc, informally-specified, bug-ridden, slow
| implementation of half of the IP stack, but man did that
| phrasing get me)
| RandomThoughts3 wrote:
| > The only thing I see is that manufacturers prefer an ip
| stack because it's "easier" to develop for.
|
| It _is_ easier to develop on an ip stack.
|
| You have great tooling and great libraries out of the box
| because pretty much everything uses ip nowadays.
|
| Plus, at least part of the controllers people use for their
| smart home will use ip anyway. A non ip network will need a
| bridge.
|
| > How is that possible when thread use an ipv6 stack over
| 802.15.4 while zigbee use a simpler stack also over
| 802.15.4?
|
| Easy, zigbee doesn't use a simpler stack. Using the same
| physical layer protocol doesn't tell you anything about the
| rest of the stack.
|
| It's actually pretty simple. 6LoWPAN which is what Thread
| uses is more efficient than the Zigbee network protocol.
| Packets are smaller and the routing is better. It's not
| particularly surprising to be honest because Thread was
| designed by people who knew Zigbee really well and were
| aiming for an improvement.
| alsko wrote:
| Matter was created by the Connectivity Standards Alliance
| (CSA), formerly known as the Zigbee Alliance! Basically, Matter
| is the next generation Zigbee. Thread as a protocol predates
| Matter, and it is just one of the supported transports,
| together with Wifi and Ethernet (for now).
|
| Edit: One thing Matter adds that was not in Zigbee is Bluetooth
| provisioning, letting you use your phone to add a device to
| your network without QR codes or numbers to type in.
|
| Also fun fact; Homeassistant is part of the CSA and apparently,
| Google, Apple and others use HA for testing!
| bevr1337 wrote:
| > Edit: One thing Matter adds that was not in Zigbee is
| Bluetooth provisioning, letting you use your phone to add a
| device to your network without QR codes or numbers to type
| in.
|
| What follows are my two pennies as a developer working in
| home automation for 7 years. In this venue, readers may even
| have more knowledge regarding security, but I hope to speak
| to a common case.
|
| I develop this exact feature though not for Ikea. Having made
| the sausage, some of these UX-first flows are worrisome.
|
| Consider a lightbulb that factory resets given a rapid
| succession of power cycles. Most consumers won't have
| redundant power during a brownout, so there is an edge case
| where dirty power can mistakenly send the bulb to a reset
| state. (More plausibly, a child tugging at a light switch?)
| Now, any device in radio range has an opportunity to take
| over the bulb.
|
| Provisioning is rare. Unless the owner enjoys tinkering, a
| residential IoT device is provisioned a handful of times in
| its life. I _personally_ think it 's a waste of time to
| optimize this flow if the improvements are also
| vulnerabilities.
|
| Suppose I have a great new smart bulb. I'm ready for a larger
| market so I prepare a demonstration for Lowe's, hopeful for
| space in their lighting and rough electric aisles. Lowe's has
| seen this before. My bulb works fine but my users aren't
| technical. Lowe's replies, "we can't carry this. Users must
| deploy and control from a single app in 5 minutes." If I want
| my smart device to compete, my hand may even be forced to
| implement UX-first provisioning.
|
| Companies like Lowe's and IKEA don't want to be in the tech
| support business. My bulb is a liability because their
| customers will call with complaints or questions.
|
| I find QR codes to be a slick implementation. They don't even
| need electricity! Users can manage the system even when
| components go offline. Folks are trained on social security
| numbers and PINs for bank cards. It's easy to comprehend the
| QR code as a password.
| lukeschlather wrote:
| I feel like the problem is a lack of realism about what is
| required to meet the usability standards of traditional
| analog switches. Like, I hear you talking about a tradeoff
| between security and usability for a "rare" provisioning
| event but I think in practice if you imagine a device has a
| 10 year lifespan, I would guess that making the
| provisioning hardware probably translates into at a minimum
| a full month of downtime over the lifespan of the device,
| with many devices being down for months or years at a time
| because no one can be bothered to figure out why.
|
| The security concerns probably have typically zero impact
| on the operation of the device. I'm not saying that the
| security concerns are unjustified. Really I'm actually
| leaning more that this is completely impractical and not a
| good replacement for a dumb physical switch. The security
| issues are unacceptable and the downtime caused by even the
| useless security measures available is even worse. (Also,
| the security measures seem more concerned with whether or
| not I have a license to watch my video on that particular
| device than preventing people from turning on my toaster.)
| bevr1337 wrote:
| > if you imagine a device has a 10 year lifespan, I would
| guess that making the provisioning hardware probably
| translates into at a minimum a full month of downtime
| over the lifespan of the device, with many devices being
| down for months or years at a time because no one can be
| bothered to figure out why.
|
| Can you explain more about how you reached this
| conclusion? Why are devices offline for years now?
| lukeschlather wrote:
| The Bluetooth connection gets screwed up for some reason
| and it needs to be reprovisioned. The device is in a room
| which isn't really the domain of the person who can
| reprovision it. Whoever is actually affected by the
| outage can't fix it, has to realize that it's a solvable
| problem and ask the person who can solve it to fix it.
| This social problem of recognizing that a chore needs to
| be done will likely take at least a week, typically a
| month or even years to resolve.
|
| And the whole point of this is to provide a seamless
| experience that's easier than using a physical switch.
| But in practice this just generates chores that are
| actually more time-consuming than simply using a physical
| switch. (Even in the single-user setup, I can imagine
| that I actually just revert to using whatever hardware
| controls are available on the device for quite some time
| because reprovisioning it is too much of a chore, and
| whatever wireless options it provides are not worth doing
| that chore.)
| umbra07 wrote:
| on the other hand - I had contractors install our Nanoleaf
| recessed light cans (thread over matter) in our new house.
| In all the hubbub, I forgot to make sure to save the light
| cans boxes that had the QR codes inside. I found around
| half the QR code stickers, but I lost the other half. The
| light cans also have the QR codes printed on the top, but
| we have nailed-down attic flooring that covers them
| completely. So I'm basically just praying that Nanoleaf's
| CS can give me the pairing codes based on my order number,
| haha.
| bevr1337 wrote:
| Oof, yes that's certainly a way QR codes can go wrong.
| Ideally manufacturers print the QR code on the device
| such that it lasts the device's lifetime.
|
| It would be nice if technical users (installers) could
| reset the certificates or keys too. Besides losing the QR
| code, secondhand owners also want some assurances.
| luckydata wrote:
| exactly, this scenario is why I'm excited about bluetooth
| provisioning.
| luckydata wrote:
| while your example is correct, I have many many examples in
| my experience why scanning a qr code is simply infeasible
| in some situations and as a owner of a heavily automated
| home I welcome the development with open arms.
| AceJohnny2 wrote:
| > _letting you use your phone_
|
| _Requiring_ you to use your phone.
|
| I understand the value in streamlining the flow for the
| Average Joe, but as a power user I wish there were an escape
| hatch. Ultimately, it's a minor quibble. It _is_ a much more
| streamlined setup.
| amluto wrote:
| As I understand it, Thread can transparently extend its mesh
| over regular IPv6 (Ethernet, Wi-Fi, etc), whereas extending a
| Zigbee (or Z-Wave) mesh beyond useful mesh range is a mess. I
| have a Z-Wave network that uses two controllers, and it
| _sucks_. It's utterly obnoxious to maintain, the whole concept
| of multiple controllers is barely supported by zwave-js-ui, it
| is far to dumb to recover quickly on its own if it transiently
| loses connectivity to a node, and roaming between controllers
| is a complete non-starter.
|
| I haven't tried Thread yet, but I'm delighted by the concept of
| having a couple of easy-to-maintain base stations (routers or
| whatever they're called) connected to the local network and
| having devices automatically roam between them.
|
| I am _not_ delighted by the fact that an Apple Home Thread
| network, a Google Home thread network, and a Home Assistant
| native thread network appear to be different things that are
| not entirely compatible with each other.
| izacus wrote:
| > I am not delighted by the fact that an Apple Home Thread
| network, a Google Home thread network, and a Home Assistant
| native thread network appear to be different things that are
| not entirely compatible with each other.
|
| Hmm, in what way? The Matter standard does demand that
| devices support at least 5 of such "fabrics" at once. Where
| is the issue in practice?
| amluto wrote:
| Maybe there isn't one. Can I "pair" a Thread device with,
| say, an Apple TV and have it talk to the Apple TV via radio
| to an IKEA Dirigera hub and then IPv6 over Ethernet from
| the Dirigera to the Apple TV?
| mox1 wrote:
| Yes this is indeed a problem. You can get around this by
| piping the Z-Wave or Zigbee information into a MQTT server
| and basically run them as separate networks, with Home
| Assistant and MQTT tying it all together. But you will need
| some type of Zigbee to Ethernet adapter (Sonoff makes one,
| Raspberry Pi, etc.) or Z-wave to ethernet adapter (again
| Raspberry Pi). It's definitely clunky. But doable.
|
| I am running multiple Zigbee networks near each other (in a
| house and in a detached garage) with Home Assistant, MQTT
| server and a Sonoff Zigbee bridge, with Tasmota.
| umbra07 wrote:
| I believe this is what thread v1.4 is attempting to solve.
| Apple has already updated their Thread border routers to
| v1.4, and Google, Amazon, and Samsung have all promised to
| update their border routers too.
| AndrewDucker wrote:
| I am hoping that this is the thing that triggers Matter/Thread to
| go mainstream.
|
| I'm currently blocked because Google and Amazon don't support
| "Generic Switches". Which means that if I switch over a light-
| bulb to being a smart one I can't use something like the Arre
| Smart Button to control them. Which seems like such a standard
| requirement that I do not understand why it's not supported.
|
| If Ikea will let me set that up then I'll be delighted.
| cheeze wrote:
| For how much hype Matter had (I remember everyone saying "Just
| wait! Any day now!") it sure... hasn't delivered
| AndrewDucker wrote:
| Yeah.
|
| I've got it up and running with some Nanoleaf lights and
| Amazon Echo running as border routers, and it's rock solid
| nowadays. But my wife hates voice-controlled devices, so I
| can't put them in elsewhere until I can slap in some buttons
| to control them. And that's basically not supported, which
| leaves me thinking that either the spec is a disaster or
| Google/Amazon are deliberately kneecapping it.
| brulard wrote:
| I'm not sure what I am missing, but isn't it completely
| possible to connect any kind of smart button to control a light
| bulb? Isn't this exactly what home assistant is being used for?
| I only tried it, but was able to add a generic smart button to
| HA and let it control a USB switch with some led lights. How is
| your use case different?
|
| UPDATE: Ok, is this about the state of Matter implementation? I
| think I misunderstood that.
| gorgoiler wrote:
| My first reaction here was horror: Home Assistant and Zigbee
| integrate perfectly with IKEA's devices, and the devices are
| beautifully designed! Please don't take these away! Only the
| other day did I marvel at how a low battery indicator flashes on
| one of my remotes when I use it. A design flourish that I really
| appreciated.
|
| But I read that Thread supports IPv6 via mesh networking. It did
| always feel a bit awkward having Zigbee networking and IP
| networking competing over the same site. It would be very nice to
| issue commands from any peer to any other peer, using standard
| networking. Can anyone here confirm that Matter/Thread will be a
| bright, open, and happy new future?
|
| A lot of people I know would scoff at "smart home" stuff. I used
| to. Having a programmable house is incredibly useful though. When
| all your lights and sensors are available for programming you can
| do stuff that's cool not because it is particularly innovative
| but because it is incredibly _easy to implement_ :
|
| - my partner can control a "do not enter, call in progress" red
| light bulb;
|
| - my outside lights trigger off PIR, door sensors, or Ring motion
| detection;
|
| - I have a series of indoor lamps come on in succession if motion
| is detected outside at night;
|
| - we programmed a push button to turn a light green on one tap
| and red on a double tap for a fun game of twenty questions;
|
| - and my indoor Ring cameras shut down unless both my partner and
| I are out of the house.
|
| All of these things were _trivial_ to do given that everything is
| available on one Home Assistant instance!
| WhyNotHugo wrote:
| > Can anyone here confirm that Matter/Thread will be a bright,
| open, and happy new future?
|
| Sorry, it's a closed ecosystem. It relies on PKI and device
| attestation to ensure that only devices from approved partners
| are usable. It's unlikely that small players can participate,
| and zero chance of any homebrew scene.
| madwolf wrote:
| 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?
| Asmod4n wrote:
| You can't talk to other devices unless you got the private
| key of them.
| meepmorp wrote:
| > You can't talk to other devices unless you got the
| private key of them
|
| can you explain what you mean by this?
| Asmod4n wrote:
| 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.
| fnwbr wrote:
| 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.
| Asmod4n wrote:
| They work without issues Ine HomeKit mode. With
| thread/matter only Apple got the keys or whoever paid
| them to get them.
|
| Also: the Apple home app can't change their mode to
| matter, you have to do that in home assistant.
| Asmod4n wrote:
| 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.
| mmastrac wrote:
| 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.
| bri3d wrote:
| 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.
|
| https://developers.home.google.com/matter/primer/fabric
| yjftsjthsd-h wrote:
| 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?
| bri3d wrote:
| The design is both better and worse:
|
| * 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.
| 0x000xca0xfe wrote:
| And manufacturers tend to lock down their Matter devices,
| too, so you can't flash Tasmota or ESPHome on them. See:
| Shelly, Sonoff.
| 3nwf248 wrote:
| Not just tend to, have to. Matter certification requires
| flash encryption and FW signing.
| 0x000xca0xfe wrote:
| Are these requirements public?
|
| I was working on a Matter device but it never got
| certified due to high cost/lack of customer demand.
| Chihuahua0633 wrote:
| Matter specifies that all firmware images must be signed
| so the device can verify authenticity before
| installation, ensuring they haven't been tampered with.
| Matter further requires mechanisms to prevent
| unauthorized firmware execution and ensure that firmware
| can't be downgraded.
|
| Matter states that firmware images "may be encrypted."
| This is not a requirement, though encryption is allowed
| and may add security
|
| (https://community.arm.com/arm-community-
| blogs/b/internet-of-...)
| 0x000xca0xfe wrote:
| This sounds like it only affects OTA updates going
| through the Matter stack, not an explicit requirement to
| block serial flashing.
|
| Disclaimer: I haven't tried serial flashing of
| Shelly/Sonoff Matter-enabled devices myself, just
| remember some complaints of customers that failed to re-
| flash such devices.
| jekwoooooe wrote:
| You say that as if that's a bad thing. I would love to
| have more iot security
| markhahn wrote:
| where "security" here means "anything not explicitly
| sanctioned by the vendor is prohibited"?
| jekwoooooe wrote:
| No it means signed firmware and verified boot...
| bri3d wrote:
| I disagree that there's zero chance for a homebrew scheme;
| it's pretty easy to enable development mode and commission
| self-made devices using Google Home or Apple Home on both iOS
| and Android.
| lukeschlather wrote:
| Dev mode seems like such a nonstarter. I don't know what
| dev mode entails, but I don't want to be running my kitchen
| light in dev mode, I'll just use an analog switch.
| bri3d wrote:
| > Dev mode seems like such a nonstarter. I don't know
| what dev mode entails,
|
| ... what?
|
| All it means is that the "commissioner" (broker which
| attaches Matter devices to your Fabric) ignores the
| chaining of the device attestation to an approved CA. In
| the case of using Google's Commissioner, this requires
| adding a Vendor and Product ID in your account's
| Developer console. In the case of Apple's Commissioner,
| it's just pressing a "Trust this unknown device" button.
| That's it.
| lukeschlather wrote:
| I can't conceptualize exactly what the use case is here,
| but I get the impression there's a set of steps that have
| to be done in sequence after installing my light bulb,
| and that's another step to an already fairly involved
| process. All to screw in a light bulb. And the light bulb
| is the easy case. If it's actually _two_ devices and I
| want them to talk to each other, and one of them is
| automatically trusted, and the other one is untrusted, I
| 'm skeptical that just pushing the button is going to
| help. (Actually in general I'm skeptical that it will
| typically work without extensive research, and this is
| just one in a long list of potential gotchas.)
| ValentineC wrote:
| > _It's unlikely that small players can participate, and zero
| chance of any homebrew scene._
|
| I personally think the worst part of this is that China
| manufacturers are less likely to produce Matter/Thread
| equipment.
|
| Cheap China equipment has been great for Zigbee adoption.
| They're much less reliable, but fantastic for getting a smart
| home going for cheap.
| petre wrote:
| I wouldn't worry too much. Espresiff is going to flood the
| market with countless units of this chip available for
| cheap. It can do Zigbee/Thread/BLE.
|
| https://www.espressif.com/en/products/socs/esp32-h2
| alex_duf wrote:
| > It did always feel a bit awkward having Zigbee networking and
| IP networking competing over the same site
|
| Funny, to me that's a feature. It makes the threat of a hacked
| device that exfiltrate data from within your network much less
| likely. I avoid any wifi device because of that.
| stego-tech wrote:
| This. The network fragmentation is the point, just like how
| some businesses would run IPX internally and use a proxy for
| web/IP traffic to protect corporate infrastructure from
| malicious devices or software.
|
| Not _everything_ has to be on TCP /IP. For smart home
| connectivity, I'd say that's a feature, provided said
| networking standard is just as open as TCP/IP.
| Eduard wrote:
| > just like how some businesses would run IPX internally
|
| when? In the 1990s?
| vachina wrote:
| Yes, not to mention WiFi is so much more power hungry.
| thedougd wrote:
| The thread border gateway (Apple TV, HomePod, Google Nest
| Speaker, etc) sends an IPv6 router advertisement to the network
| for the Thread IP space. Multiple border gateways can advertise
| the same IP space for redundancy.
|
| I have/had a segmented network, so I made sure my router
| accepted this route so that devices on different networks could
| communicate with the Thread devices. It worked, usually.
| However, I ran into some challenges with the reliability of
| communicating from my phone to various devices. I never quite
| got mDNS reflection 100% correct, and I strongly suspect that's
| my problem. If you look at an mDNS entry for a device, you'll
| see some advertise all their IPv6 addresses including link
| local (fe80::). I suspected some clients were dumb, trying the
| first IP they found, and giving up when it didn't work. I was
| working on modifying the golang mdns-reflector project to
| filter these entries. I had some success, but I haven't
| finished.
| mft_ wrote:
| Huh... anyone know what this will mean for people with legacy
| Ikea lightbulbs and hub?
|
| e.g. if I add future Ikea lightbulbs or other equipment, will
| this mean managing them via a different system?
|
| (By the by, I've been very happy with Ikea bulbs so far; while
| other people complain of LED bulbs with a short lifespan,
| [touches wood] I've not had a single failure with Ikea smart
| bulbs, with ~7 years and counting on one of mine.)
| api wrote:
| Isn't this the history of home automation? The money is in
| getting people locked into a "system," but the systems are
| things that tend to rapidly become dated. So people will invest
| in a system and either get disillusioned due to the downside of
| lock in or the system goes obsolete and the newer stuff is not
| compatible because it's a whole new system. Rinse, repeat.
|
| There have been many attempts at industry standards but they
| fray around the edges. Nobody understands that a protocol and a
| spec is not a user experience, so the standards just become the
| basis for closed walled garden "systems."
|
| It's why I stay away from it.
| nick__m wrote:
| That's the strength of a DIY approach backed by a community
| of users like homeassistant, it doesn't get obsolete.
|
| I will just have make sure that I have a spare zigbee radio
| in case they eventually disappear from the market.
| jkestner wrote:
| "[Matter in its current version] doesn't really help resolve
| the key issue of the smart home, namely that most companies
| view smart homes as a way to sell more individual devices and
| generate recurring revenue."
|
| https://staceyoniot.com/matter-only-solves-about-one-of-
| the-...
| madwolf wrote:
| 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.
| umbra07 wrote:
| 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.
| Spooky23 wrote:
| The newer DIRIGERA hub has both radios, and recently added full
| thread support in a firmware update, so you should be good if
| you have it. Otherwise, add that or an upcoming hub or migrate
| the old bulbs.
|
| I love my Ikea smart home gear, it works really well. Odd that
| a cheap furniture store that sells meatballs seems to have a
| more coherent smart device strategy than major tech companies!
| kedikedi wrote:
| I think that applies to many other electronics they sell too.
| I find them pretty well engineered overall.
|
| My guess is that it's because they sell any particular piece
| of hardware in millions and it's in their best interest to
| design it properly so they don't have to deal with the
| returns.
| AndrewDucker wrote:
| Looks to me like they'll continue to work. There are multiple
| mentions of backwards compatibility in the article.
| WhyNotHugo wrote:
| This sucks. Matter is a closed ecosystem, enforced using a public
| key infrastructure (PKI) and device attestation certificates.
| Thread seems to require paying royalties if you want to ship
| devices. It's disappointing that IKEA claims that this move is
| towards a more open ecosystem.
|
| On top of that, the switch breaks compatibility with existing
| hardware (except for the Touchlink functionality). If you have a
| bunch of Zigbee devices, but at some point want to add some of
| the new ones, you need to start thinking about replacing all the
| perfectly working Zigbee devices or have a fragmented network.
| Toutouxc wrote:
| > If you have a bunch of Zigbee devices, but at some point want
| to add some of the new ones, you need to start thinking about
| replacing all the perfectly working Zigbee devices or have a
| fragmented network.
|
| Yes, if you're using the manufacturer's half-assed smartphone
| app, but if you're on Home Assistant, like basically anyone
| who's serious about their smart home, having multiple kinds of
| smart devices isn't really a problem. It's just one more radio
| to configure. Some people run both Zigbee and Zwave, some
| people run Zigbee + Wi-Fi or even Zigbee + Zwave + Wi-Fi +
| cloud integrations, Home Assistant doesn't care.
| darkwater wrote:
| Yes, but then you have a hard-dependency on HA for inter-
| network communication, which I try to avoid as much as
| possible (but I fail to, for a couple of subsystems). My
| failure model is:
|
| 1) no electricity, everything down but fiber, wifi, HA and
| the doorbell (they run off an UPS)
|
| 2) internet down: no problem, you just cannot reach the home
| automation from outside
|
| 3) Home assistant down: zigbee devices are paired together
| (like buttons + bulbs) or I have physical zigbee relays
| controlling dumb bulbs.
|
| But, as said, I have some subsystem not fully working when
| (3) happens, like a zigbee button controlling a tasmota-based
| fan control.
| orev wrote:
| I consider it a requirement of any smart home that
| alternative methods need to be available during failures.
| Simply having other devices around that aren't smart, like
| an old fashioned light bulb and physical switch to get you
| through until you can fix whatever is down. 100% uptime is
| very difficult for large, well-funded IT companies, so I
| don't think it's reasonable to expect it from these
| consumer-grade devices.
|
| We survived for over 100 years by getting up and flipping a
| wall switch, so the risk of a few hours without smart
| features shouldn't be a showstopper.
| Marsymars wrote:
| Lutron Caseta switches don't use an open protocol and
| don't seem to get much love in the fancy consumer-level
| smarthome space, but have been bomb-proof for reliability
| for me and work to turn lights on/off as long as they
| have power.
| baq wrote:
| zigbee has one great advantage over everything else: it's
| immune to DHCP and DNS failures and misconfigurations. if
| you're running a pihole or something, it can break iot
| devices in random ways if your DHCP server boots after your
| access points. (don't ask me how I know and the fix was to
| hard reboot my lights by cycling power in the distribution
| box. not great, not terrible.)
| g1sm wrote:
| Thread doesn't depend on DHCP or DNS either.
| lopis wrote:
| I use HA and all my IKEA lamps are zigbee. Raspberry pi
| obviously doesn't have native zigbee radio support, so I have
| a USB zigbee antenna. Now this means if I buy any more IKEA
| lamps, I would need a second antenna, and the new lamps would
| not integrate into the zigbee mesh network. It really sucks.
| buremba wrote:
| I'm in the same boat; HA is making a considerable effort,
| but connectivity is challenging. I was a bit frustrated
| when I found out that the antennas don't support both
| Zigbee and Matter simultaneously, despite the claim. You
| can only support one at a time, so apparently we will need
| the second antenna.
| cameronh90 wrote:
| Some USB zigbee dongles can be flashed to be "multi-PAN",
| but my experience is it's currently buggy and I would let
| them bake that for a bit longer.
|
| Alternatively, both Sonoff and Home Assistant do a thread
| dongle for about $30 that you can use simultaneously with a
| zigbee one. Plus if you have any of the following, they can
| be used as a Thread border router: Apple TV, HomePod, Echo
| G4, Eero 6/7, Nest Hub, Nest Wifi, Google TV Streamer.
| There's also the OpenThread Border Router which can be used
| on certain ESP32 hardware (ESP32-S3 for $10 or ESP32-H2 for
| $6?) but that obviously requires more work.
| macNchz wrote:
| Perhaps I never put enough effort into it, but I've slowly
| coalesced on _only_ having IKEA smart home products after
| years of acquiring piecemeal stuff and trying to wire it
| together with Home Assistant. I 've shut down HA, and with
| every non-IKEA "smart" thing I have nowadays I just use the
| manufacturer's app (though I've become pretty sour on most
| smart devices overall and avoid them when possible).
|
| I didn't really care for the way it became a sysadmin job
| where the stakes of a bad update or me not reading some
| release notes were that my light switches didn't work until I
| sat there and futzed around with it. I'm a programmer, enjoy
| Linux admin, run a whole bunch of servers....but having to
| dive into logs and YAML configs because the lights in my
| kitchen won't turn off is just not ideal. Similar issues with
| HomeKit, except when things mysteriously stop working there's
| even less ability to diagnose, given Apple's design
| principles that everything "just works", so apparently
| providing detailed error messages or diagnostics is gauche.
| barbazoo wrote:
| What you're describing hasn't happened to me yet with Home
| Assistant luckily, even after 5+ years of running it. I
| can't remember an update ever breaking any of my stuff. I'm
| running a docker container though so YMMV. Might be
| different with the other install types.
| rtkwe wrote:
| Me neither, but I'm running the HA Yellow dedicated low
| power hardware instead so I can keep it running off my
| battery backup longer just so it lasts as long as it can
| along with my internet during outages.
| arcbyte wrote:
| I use SmartThings and ive never missed with any configs at
| all. Only ever one single app - smartthings. Ive been
| extremely happy after dozens of devices.
| danieldk wrote:
| Same. Their Hub (now sold by Aeotec) does Z-Wave, Zigbee,
| and Thread. There is also a pretty active plugin
| community.
| JoshTriplett wrote:
| That's exactly the reason I'm hesitant to dive into Home
| Assistant myself. I want my smart-home devices to Just
| Work. I want them to be _appliances_.
| Cu3PO42 wrote:
| For what it's worth, mine do. Nothing in my HA has ever
| broken after an update or randomly for some other reason.
| op00to wrote:
| ZWaveJS used to break frequently for me, but I run an HA
| container on a Linux box, rather than the HAOS or
| whatever. I control the updates, and can rollback if
| things break, so it's not really a problem.
| waste_monk wrote:
| I installed Home Assistant recently and the docs suggest
| HAOS is the strongly preferred option these days.
|
| Something about HAOS uses docker to install and manage
| extensions, whereas if you run the HA docker container it
| can't as docker-inside-docker isn't supported (?), and
| thus some functionality is unavailable (at least at the
| surface level).
| distances wrote:
| I just lived half a year without Philips Hue remote
| control because it stopped working during an update and I
| couldn't bother to check why. It was some name change
| somewhere, might have been an issue with how I set it up,
| can't even remember. Simple fix but I did have to dive
| back to the config files.
| dzikimarian wrote:
| View above is bit outdated. Yes, there was a lot of yaml
| in the past. Right now you can just install Home
| Assistant OS and configure it from GUI.
| Marsymars wrote:
| The problem I've run into is that once you're running a
| lot of devices, you inevitably end up with a bunch of
| automations and logic that can't really be simplified.
| With Apple Home/HomeKit, everything Just Works, but
| having dozens of automation rules and scenes configured
| in Apple's low--information-density UI is worse than
| managing yaml config.
| JoshTriplett wrote:
| I don't mind the idea of writing configuration. I mind
| the idea of things breaking mysteriously, or on upgrade.
| lurking_swe wrote:
| There is a tradeoff here. If your expectations are high
| you will always be disappointed with a smart device
| advertised as an appliance. it's difficult to customize
| to make it _actually_ smart if it's designed as an
| appliance, because every manufactures app is limited.
| Even apple home and google home are junk for automating
| things. It's OK as a basic dashboard though.
|
| Here are a few "smart" things my home assistant can do in
| my home, which are impossible with an "appliance":
|
| - when washer or dryer is done (detected via power
| monitoring), send push notification. But ONLY send it to
| the people that are home at this moment. If nobody is
| home, send it to the person that left home last. (i store
| this state in a custom _last_person_departure_ variable).
|
| - if the washing machine door was closed after it was
| emptied, send push notification to the people that are
| home. Remind them to leave the door open. (front load
| washer where closing the door leads to mildew)
|
| - If a water leak is detected, send a push notification.
| if not ACKed within 3 minutes, send a "critical alert" to
| everyone's phone.
|
| - If nobody is sitting on the couch (pressure sensor
| under the cushions), and no media is playing on the tv,
| turn off the tv after 20 minutes.
|
| - turn on the hallway light if motion detected or if the
| front door is in an open state. but keep it on if the
| door remains open (chatting with a neighbor, bringing in
| packages, etc) Importantly, delay the "turn off" action
| with a timer and reset that time if more motion detected
| or the door is re-opened.
|
| - when i'm on a work zoom call, automatically turn on a
| red light next to my home office, so family doesn't
| interrupt.
|
| That's just the tip of the iceberg. I also get a push
| notification when the printers ink is below 20%, and
| more.
|
| Unfortunately a truly smart home requires effort to set
| up. Because a smart home is unique to YOU. Everyone has
| different workflows, habits, and preferences. It's not a
| generic off the shelf component like buying a washing
| machine, where the user preferences can be simplified to
| a handful of settings.
| turtlebits wrote:
| Home Assistant "just works". Yes it has a ton of knobs, but
| in the 3 years I've been running it, it's had no issues.
| Certain manufacturer devices being flaky, yes, but as a
| platform, it's been rock solid. I've not touched its config
| in over a year and everything works as it should.
| delusional wrote:
| > Certain manufacturer devices being flaky, yes, but as a
| platform
|
| This makes me a little weary of your comment. I don't
| think I'd really care if my lights not working was due to
| a "manufacturer being flaky" if they worked yesterday,
| but don't today.
|
| Are you talking about devices being flaky on first setup
| (which sucks, but is understandable), or are you talking
| about them being flaky after an update?
| op00to wrote:
| I think one solid way of handling the instability is to
| use high quality light automation (Lutron Caseta, for
| example) for the things you'll really notice, but for
| stuff you care less about (for me that's cameras,
| temperature sensors) you can use cheaper ZWave stuff w/
| home assistant. The lights turn on and off when I expect,
| but temperature might update a little less frequently if
| HA is flaky.
| ajolly wrote:
| Long tail can be flaky, but in practice as long as you
| buy devices that are local first IE don't need to access
| the cloud you'll be fine.
|
| (For temp and humidity sensors the Bluetooth Xiaomi
| sensors are great and they're about $5 each)
| rpcope1 wrote:
| Honestly, for any sensor that's basically just read only,
| the best thing I've seen is to just avoid all of the
| bluetooth/wifi/zigbee/zwave entirely, and just use basic
| tried and true accurite (or similar) sensors that never
| need updates and just pull the data with rtl_433. Way,
| way less fuss, they always just work, batteries last
| longer, by and large zero bullshit.
| jermberj wrote:
| If I had to guess, they're probably referring to the way
| that certain devices broadcast their APIs to external
| services. A lot of them have no intention of allowing
| open access to APIs (e.g., my mini-split controller
| requires a slight hack to get it connected to HA).
|
| That is, the flakiness isn't due to HA updates breaking
| connections or an unstable server, but rather
| manufacturers designing closed and/or brittle systems.
| Try as they might, the HA authors and surrounding
| community can only do so much for such devices.
|
| Also, I believe the word you're looking for is 'wary' (as
| in, to be skeptical or suspicious), not 'weary' (as in,
| to be tired). :)
| tick_tock_tick wrote:
| It's the devices that is flaky. Some of the shitty bulbs
| I got don't always turn on in one command but that was
| true via their own app too. Basically shitty devices
| aren't magically better via home assistant.
| turtlebits wrote:
| I have several Aqara temp/humidity sensors that
| intermittently lose connection. They don't affect the
| operation/stability of the rest of the HA platform and is
| not a problem with HA, as my other zigbee devices that
| report the same data work fine.
|
| I should probably just remove them, but I don't have any
| automations that depend on them.
| macNchz wrote:
| I guess the fact that some manufacturer integrations are
| flaky is hard to reconcile for me as far as the promise
| of "having multiple kinds of smart devices isn't really a
| problem". Regardless of whose _fault_ it is, those flaky
| devices contribute to a less stable system.
|
| It's been a bit since I was operating it, but I did at
| times certainly have issues with updates--perhaps just
| individual plugins or system updates that created an
| issue, either way, still a situation where I had to sit
| at a terminal and debug. I only ever ran the Docker
| version, not the OS, so perhaps this is less problematic
| in a more completely controlled stack.
|
| I don't think I'm alone in this view, broadly speaking: h
| ttps://www.reddit.com/r/homeautomation/comments/18hvl3b/i
| _g...
| turtlebits wrote:
| For my flaky devices, it it not a manufacturer
| integration, but over Zigbee. It's definitely the device
| as my other Zigbee devices are solid. Others have
| reported issues with the device in question (Aqara
| Temperature and Humidity Sensor)
|
| I ran the docker version on a QNAP for a long time, now
| on a Home Assistant Green.
| zeehio wrote:
| I have been using Home Assistant for more than 5 years.
| The stability of the system has improved a lot in the
| last year. I don't recall the last time I had to
| reinstall or restore a backup.
|
| At the beginning (0.7 or maybe even earlier) I remember
| to have to reconfigure or reset my instance a few times a
| year. Those times are long gone.
| iamspoilt wrote:
| I second that. Home Assistant "just works". I have had it
| running on this cheap used HP EliteDesk 705 G3 Mini
| Desktop for more than 4 years now without a hiccup and
| barely any maintenance or hygeing work on it. Just
| sitting in my tv stand and doing it's work.
|
| https://homeautomation.substack.com/p/setting-up-home-
| assist...
| DavideNL wrote:
| Curious, do you do HA updates automatically, manually
| regularly, or "manually once a year or so"?
| iamspoilt wrote:
| Manual, would do it once a month or so. Hasn't broken
| ever since I have been running HA. I run the full Haas OS
| btw.
| qwerpy wrote:
| Not who you asked, but I do it "manually once a year or
| so" on a HA instance in a container running on unraid. It
| sometimes causes problems. Recently HACS (not a built-in
| part of HA but useful to get some extensions) broke on a
| HA update and I had to spend more time that I would have
| liked figuring out how to fix it. It involved running
| shell commands inside the container. Definitely not for
| anyone who isn't a techie.
| radicality wrote:
| Surprised at your issues with HA. Similarly to others that
| responded, my setup with HA / zigbee2mqtt and >30 zigbee
| devices (including some ikea buttons) has been pretty rock
| solid over many years, including easy migrations from an
| rpi3 -> rpi4 -> rpi5 (with ssd).
|
| Usually when I had some zigbee issue, it was because of a
| crappy product (eg some wired air sensor that would spam
| the zigbee network every 1 second with a lot of data), so
| then I just stop using such devices and before I buy I
| check compatibility with HA / zigbee2mqtt.
| petre wrote:
| I just use Ikea's remote because I won't bother to link the
| light and the rmote through HA and set up scenes. It just
| works as a remote: on/off/dimmer. I can either pair the
| thing with the HA ecosystem or the remote, but the remote
| always works, regardlesif HA is on or not. I have just one
| set of lights.
| sshine wrote:
| I also switched from Philips Hue to IKEA. I like how you
| can pair things by holding them close and pressing a
| button. Doesn't need to get smarter than that for me.
| wafflemaker wrote:
| I have about 20 Phillips Hue bulbs at home. My younger
| brother laughed at me for spending a small fortune on them.
| Approx 1 bulb per year dies and requires a replacement _.
| Other than that everything just works after the initial
| setup - daylight like automation.
|
| I even once had my wife add a bulb and while it wasn't
| easy, she did it.
|
| When a year later I asked brother about the some random
| bulb he had - didn't work anymore.
|
| _ It's even better, because Norwegian law gives 5y
| guarantee on electronics - could just have this bulb
| replaced as faulty in the shop.
| dieortin wrote:
| It's not acceptable for any LED bulb, let alone one as
| expensive as Philips HUEs are, to die so soon.
| barbazoo wrote:
| Agree. It's a hassle to set up once but then you quickly
| forget about it.
| philjohn wrote:
| Yes and no.
|
| Pairing a Matter device takes much longer than pairing a
| Zigbee device through Z2M in my experience, and the Matter
| add-on still sometimes needs restarting as it refuses to
| allow any more devices to pair after a while.
|
| But - rather than need a Zigbee dongle (or manufacturer hub)
| if you've got Apple or Google devices such as HomePods you've
| got a ready made Thread network as they act as border
| routers.
| poulpy123 wrote:
| most people don't want to manage a self-hosted server just
| for interacting with some smart devices in their home
| BuildTheRobots wrote:
| HA doesn't care but your radio environment probably does. One
| of the great strengths of Zigbee is the mesh network - it
| doesn't matter where in my house I dump something, because
| all my bulbs are Zigbee repeaters it's going to get a signal
| and be able to route back to my HA box.
|
| If I now get a _single_ Thread/Matter/Zwave device to replace
| one that's broken, ignoring the cost of a new radio for HA, I
| have to give very serious thought to where it's going to live
| vs signal availability as I build out yet another network.
|
| tldr: HA is fantastic for coordinating disparate devices, but
| RF still bites.
| cameronh90 wrote:
| It is still somewhat annoying for those of us with solid
| walls.
|
| I can't just add a new Thread device at the other side of my
| house as the walls attenuate the signal between it and the
| border router. Equally I can't start replacing Zigbee devices
| willy-nilly in case I create Zigbee dead zones.
|
| Not the biggest problem in the world but it does mean I'll
| likely need to get some pointless Thread smart plugs as
| temporary network extenders when I add my first Thread
| device.
| archagon wrote:
| I wish Matter accounted for mixed-mode networks. If a
| Thread device is nearby, use that. If not, try Wi-Fi.
| aenis wrote:
| Depends on your 2.4GHz band's saturation. Where I live I have
| only a few "good" channels. I have about 350 zigbee devices
| over two separate networks - and thus two channels - and the
| remaining good 2.4GHz channels are used by the physically
| separate IoT WiFi network. I dont want to deal with yet
| another network that may or may not like the channel I have
| to put it on.
| WhyNotHugo wrote:
| You can configure Zigbee devices to interact directly to each
| other, without using the hub as a middle-man for all their
| communication (the hub only does the configuration itself).
|
| This doesn't work when mixing Zigbee+NonZigbee devices.
|
| See: https://www.zigbee2mqtt.io/guide/usage/binding.html
| wkat4242 wrote:
| Yeah and matter needs internet access in many cases. It was
| supposed to be the saviour of open home automation. But in
| practice it leaves too many strings attached that the
| manufacturer can take advantage of.
|
| And despite it not being open enough for open source
| enthusiasts, it's also got a bad name with manufacturers. I
| work for one and I asked why we wouldn't implement matter and
| thread and it was laughed off because apparently marketing will
| never give up their own app as a data collection and cross
| selling vehicle. Of course those are exactly the reasons I
| don't want this.
|
| I didn't even know about the certification that only big
| players can do and the locked firmware requirements. It's
| ridiculous. Why were thread and matter hailed as the open
| revolution when they're exactly the opposite?
| K0balt wrote:
| >Why were thread and matter hailed as the open revolution
| when they're exactly the opposite?
|
| Subterfuge PR or the subversion of original intention by
| greed.
|
| Also, wasn't there recent news that thread was being
| abandoned by manufacturers, even declaring it EOL? Or am I
| conflating that with something else?
| umbra07 wrote:
| I remember an interview [1] with the Nanoleaf CEO (they
| switched to Thread over Matter years ahead of everyone
| else) about why Thread/Matter was so difficult, why
| everyone else didn't adopt it, and that they're going to
| wait for Thread to get better before they launch new
| products with it.
|
| On the other hand, I believe all the major Thread Border
| Router manufacturers (Apple, Google, Amazon, Samsung) have
| updated their Thread routers or committed to updating their
| Thread routers to Thread v1.4, which is a pretty major
| upgrade.
|
| [1] https://matter-smarthome.de/en/interview/nanoleaf-ceo-
| gimmy-...
| K0balt wrote:
| Yeah, doesn't sound like EOL to me. Must have been some
| other IOT/PAN technology.
| dylan604 wrote:
| > Why were thread and matter hailed as the open revolution
| when they're exactly the opposite?
|
| Because consumers are lazy and dumb, and do not do any kind
| of research. They believe what is written on the tin. Why is
| OpenAI called "open"?
| wkat4242 wrote:
| But it's not just consumers. I know the tech press hailed
| it as the end of manufacturer-specific closed systems, and
| so did some of the developers like the ones from Home
| Assistant.
| arghwhat wrote:
| Matter doesn't need internet access, it's an entirely local
| protocol even when you integrate to other vendor ecosystems.
|
| Now, something like Google Home might decide to go online to
| talk to a Google Home Hub device, which is where Google wants
| to initiate all Matter communication from, but that's a
| Google thing, not a Matter thing.
| Volundr wrote:
| Technically Matter itself doesn't require Internet access,
| but you'll come across many devices that won't operate (or
| even join) without a functioning border router. What's in
| the spec and the lived experience are sort of different
| here.
| tommysve wrote:
| What a shit load of disinformation you are spreading. Read up
| on Matter and Thread, please.
| echelon wrote:
| Can I make a Matter device for myself?
| olalonde wrote:
| Yes. https://developers.home.google.com/codelabs/matter-
| device
| snickerdoodle12 wrote:
| Can I sell it without paying a gazillion fees?
|
| Spoiler alert: No. There's a whole bunch of bullshit: htt
| ps://developers.home.google.com/matter/integration/pair#p
| ...
|
| You can sort of run your own device if you're fine with
| giving google far too much information and they can block
| you at any time.
|
| Face it, bigtech has a hardon for closed ecosystems. If
| they could they'd make it so every computer that wants to
| send an ethernet packet has a private key blessed by some
| bigtech cabal which they can revoke, but luckily for us
| this standard predates this gross new fetish.
| olalonde wrote:
| Do you extend that criticism to USB, Bluetooth, WiFi,
| etc.? The alternative and current status quo is every
| vendor developing their own proprietary, incompatible and
| insecure protocols. Unless there's a better alternative I
| am unaware of, Matter is a step towards greater
| interoperability and openness.
| snickerdoodle12 wrote:
| I do, but it's especially grating here because Zigbee
| _didn 't_ have this restriction, and none of your
| examples actually enforce it technically. I have some
| Chinese USB devices that are very useful but use an
| incorrect VendorID. But I don't care, they work great.
|
| And besides, so far I've been able to use 100% of my
| Zigbee devices with Zigbee2MQTT and it's been wonderful.
| mardifoufs wrote:
| Isn't that true for ZigBee too? Can you sell ZigBee
| devices (and market them as such) without paying fees?
| snickerdoodle12 wrote:
| There are no technical limitations preventing this.
| vineyardmike wrote:
| No technically limitations, just legal ones. Which are
| famously irrelevant to international commerce?
| iamdelirium wrote:
| You cannot legally certify something as Zigbee with
| paying a fee. This is the same for Matter.
| markhahn wrote:
| branding is not closing.
|
| a closed ecosystem means hermetically sealed: nothing
| gets in or out. matter is just treating their brand with
| respect. not different from any other industry standard.
|
| if you're saying "I want all industry standards to become
| governmental ones", well, I happen to agree.
| Larrikin wrote:
| Matter has nothing to do with Google except they are
| supporting the standard. If you care so much about an
| open ecosystem Google Home shouldn't even matter, you
| would be worried about Home Assistant support.
| snickerdoodle12 wrote:
| Well, there appears to be some link. I'm not clear on
| what it is, but here are the Home Assistant docs for
| using a Matter dev board: https://www.home-
| assistant.io/integrations/matter/#experimen...
|
| > NOTE for Android users: You need to follow the
| instructions at the bottom of the page to add the test
| device to the Google developer console, otherwise
| commissioning will fail.
|
| Anyway, you absolutely should care about Google Home
| support if you want to _sell_ a device. It 'd be
| ridiculous to sell something that only works with Home
| Assistant even if I'd personally be perfectly happy with
| that.
| dieortin wrote:
| Are you seriously using some footnote about Android as
| proof that Google somehow has any control over Matter?
| luckydata wrote:
| I don't know why you're downvoted, it's the same reaction I
| had tbh.
| baobun wrote:
| Because it's insubstantial and doesn't further the
| conversation in a healthy direction.
| olalonde wrote:
| That's incorrect. Matter is an open standard.
|
| https://en.wikipedia.org/wiki/Matter_(standard)
| vorpalhex wrote:
| Matter is "open" in that it is published. It is not "open" in
| that you can make a matter device in your basement.
|
| Here is the Silabs explainer on the certification process:
| https://docs.silabs.com/matter/latest/matter-certification/
| CharlesW wrote:
| > _It is not "open" in that you can make a matter device in
| your basement._
|
| You can! You just can't ship it/sell it without
| certification.
|
| https://www.reddit.com/r/homeassistant/comments/1adh8ah/esp
| 3...
| olalonde wrote:
| > It is not "open" in that you can make a matter device in
| your basement.
|
| I did exactly that last week... Certification is required
| if you want to use the trademarked logo in your marketing
| materials (same as with Wi-Fi and Bluetooth afaik).
| devnullbrain wrote:
| >the ability to commission a finished product into a Matter
| network in the field mandates certification and membership
| fees,[15][16] entailing both one-time, recurring, and per-
| product costs.[17] This is enforced using a public key
| infrastructure (PKI) and so-called device attestation
| certificates.[15]
|
| Thank you for the clarification?
| arghwhat wrote:
| To be clear, this is the same organization that developed
| Zigbee, which requires paid certification - without, you're
| not allowed to say the product supports Zigbee or to use
| the Zigbee logo.
|
| You can connect devices without this, it just shows a
| warning during commissioning that the device is not
| certified. No impact whatsoever.
| pavon wrote:
| So by analogy, Zigbee is like USB in that it encourages
| certification through trademarks, while Matter is like
| HDCP or Blu-ray in that it enforces certification through
| technical means (cryptographic signatures)?
| FabHK wrote:
| > Matter is a closed ecosystem
|
| If "closed" means open to anyone that has their product
| certified to adhere to the rules, then I'm ok with that.
| OptionOfT wrote:
| I don't think that is entirely correct.
|
| Just like Apple HomeKit you can add devices that aren't
| certified. It shows a warning, but apart from that it functions
| like a normal device (for as far as I can tell).
|
| I have been using https://github.com/t0bst4r/home-assistant-
| matter-hub to expose my home assistant devices to Google Home
| without having to expose my Home Assistant to the cloud.
|
| Second, certification is what separates Z-Wave from Zigbee
| which in my (n=1) experience means less issues in terms of
| compatibility.
|
| Of course, with that GitHub package I shared all of that goes
| through the window, but who cares? I can clone the code and
| modify it.
| comandillos wrote:
| This isn't entirely true, isn't it? I mean, the whole internet
| runs on a PKI and we need such a mechanism to ensure secure
| communication across devices in the network. I understand home
| devices that contain all sort of sensors and actuators should
| be handled in a similar fashion, isn't it?
|
| I mean, that PKI doesn't exclude non-approved manufacturers
| from producing Matter devices, you can always trust their PAA
| (their CA) in your border router if it's not a well-known
| manufacturer. And also, I am pretty sure that if this is the
| case the Matter border router should warn you of this and
| ignore the fact that the PAA is not in the local store of root
| CAs (as we did in the times when we had https without Let's
| Encrypt and didn't want to pay Comodo to sign our certs)
| vineyardmike wrote:
| You're partially correct, but you've got enough details wrong
| details that you're misrepresenting reality.
|
| Matter has a _public blockchain_ with certificates added to
| enforce which products are considered certified. This is
| called the distributed compliance ledger (DCL). The hardware
| devices are expected to ship with certificates on them that
| match the public ones, and it's generally not possible to
| change the on-device certs.
|
| This is distinct from "normal" internet PKI certificate
| authority where you can just swap out a few files or grab a
| new cert from Let's Encrypt. Because this uses a dedicated
| blockchain with a history of signatures. Depending on how you
| want to control the device, you'd need to rebuild the whole
| chain of trust, including eg signatures from Google or Apple.
|
| Also, from a practical perspective, I'm not sure of any
| actual controllers that let you point to different
| certificate sources. You can create devices with a "test
| vendor ID" (0xFFFF) and the controllers are supposed to
| ignore certs. This has downsides, like OTA updates require
| signing, you can't encode proper identifiers in the device so
| info pages in apps are wrong, etc.
|
| Also, the "border router" isn't really the point of trust
| here, it'd be the actual controller device. A border router
| is just that, an IP router, like a WiFi router or a Ethernet
| router.
|
| https://webui.dcl.csa-iot.org/
| Larrikin wrote:
| I didn't believe any of the information in this post is
| correct.
| whitehexagon wrote:
| I only recently discovered and invested in the IKEA ZigBee
| hardware, about the only product their MBAs havent destroyed. The
| hardware is very well built, and sensibly priced. What I liked
| most of all was that the hub was optional, and thus no cloud
| account required.
|
| I ended up pairing mine with a 'ConBee II' and with a bit of Go
| code was able to receive sensor data with very little latency,
| and activate switches and lights very quickly.
|
| What a shame they discontinue such a great product line. But I
| already decided this is the last home automation technology I'll
| invest in. ZigBee seems perfectly suited for this role, and no
| idea why we need yet another new standard. Although I also said
| that switching away from x10, if anyone still remembers that.
| mongol wrote:
| My IKEA was missing a lot of Tradfri assortment when I visited
| this week. I started to have doubts if they had abandoned the
| home automation niche. Now when I am searching their site, much
| is gone. But I guess they are clearing the inventory for a
| Threads relaunch
| brabel wrote:
| That's such a shame. I bought quite a few IKEA devices as they
| were the cheapest in the market and were Zigbee-driven, which
| meant I could use it with my custom-made SmartHome software
| (which does what Home Assistant does but without a heavy
| runtime) and they connected with other manufacturer's devices
| (they form a mesh, so as long as you have a Zigbee device every
| few 10s of meters, the devices can communicate with the central
| hub even from very far away). I wonder if I will be able to
| connect to Thread devices at all now.
| kassner wrote:
| I'd not read much into that. My local IKEAs have stock issues
| since 2020. There is always a couple of products that are
| completely gone.
|
| They are also pretty good at labeling the products in their
| website, you can search by "last chance to buy" (or local
| language equivalent) to see the list.
| mongol wrote:
| What is the equivalent for zigbee2mqtt for Matter/Threads?
| jeroenhd wrote:
| I don't know if there's an MQTT bridge yet. Generally, you run
| some kind of border router and connect through that. While the
| work doesn't seem complete yet, there's a guide to turn a Home
| Assistant install into a Thread border router if you have the
| necessary hardware: https://www.home-
| assistant.io/integrations/thread/#turning-h...
|
| You can probably plumb Home Assistant into your MQTT server
| from there.
| madwolf wrote:
| You just need a Thread border router and Matter devices connect
| to your HA without problems. I use Apple TV as a border router.
| philjohn wrote:
| 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.
| bluGill wrote:
| 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)
| nagisa wrote:
| 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.
| bluGill wrote:
| 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)
| evadne wrote:
| This is horrible news. Zigbee has been trouble-free and Thread
| has been nothing but Trouble to the point I had to throw out
| everything based on Thread...
| victorbjorklund wrote:
| This really sucks. I have a smart home with home assistant and
| most of my things are Zigbee and Ikea stuff are great. They are
| affordable and they are high quality. So now I have to find
| another provider of especially light bulbs.
| madwolf wrote:
| What stops you from adding a Thread border router and adding
| new Matter devices to Home Assistant? It works.
| throwaway984393 wrote:
| "A software development kit (SDK) is provided royalty-
| free,[13][14] though the ability to commission a finished product
| into a Matter network in the field mandates certification and
| membership fees,[15][16] entailing both one-time, recurring, and
| per-product costs.[17] This is enforced using a public key
| infrastructure (PKI) and so-called device attestation
| certificates.[15]"
|
| So it's a closed ecosystem that makes money for a cabal of
| corporations
| CharlesW wrote:
| It's "closed" in the same way that all open wireless standards
| (Wi-Fi, Bluetooth, etc.) are closed. You can read the spec, use
| the open source SDK, and build devices without paying a cent.
|
| If you want to participate as more than a hobbyist, you'll need
| to join the CSA (a non-profit mutual-benefit corporation). This
| will cost a bit less than half of what it cost manufacturers to
| join the equivalent organization for Z-Wave -- a closed,
| single-vendor, non-IP-based solution that was state-of-the-art
| 25 years ago.
|
| Money paid by commercial vendors funds stuff like test labs,
| interop events, and compliance support systems.
| yjftsjthsd-h wrote:
| > It's "closed" in the same way that all open wireless
| standards (Wi-Fi, Bluetooth, etc.) are closed. You can read
| the spec, use the open source SDK, and build devices without
| paying a cent.
|
| My understanding - correct me if I'm wrong - is that it's not
| quite the same; I'm pretty sure you can make a wifi card on
| your own (maybe modulo FCC approval, but that's true of any
| radio) and you might not be allowed to put an official wifi
| logo on it without a license but it'll _work_ without needing
| to see an officially signed cert or the user having to touch
| developer settings.
| CharlesW wrote:
| Matter has a small but growing hobbyist community. A recent
| project I saw via https://www.reddit.com/r/MatterProtocol/:
|
| (1) https://tomasmcguinness.com/2025/06/27/matter-building-
| a-tin... (2) https://tomasmcguinness.com/2025/06/30/matter-
| tiny-dishwashe...
|
| You can definitely add uncertified accessories (using CSA
| test Vendor ID 0xFFF1) to HomeKit via an "Add Anyway"
| confirmation. Because Apple tends to be extremely
| conservative about this kind of stuff, I'd expect that all
| systems that support Matter would allow this.
| snickerdoodle12 wrote:
| RIP. The ikea zigbee stuff was close to being best in class.
| Matter is still an unusable mess.
| CharlesW wrote:
| In my experience, Matter already works better than Zigbee and
| Z-Wave ever did, and it gets better every year. I'm interested
| in what your unusable mess of a system consists of, if you
| don't mind elaborating.
| kstrauser wrote:
| That's been my experience. My older Zigbee/Z-Wave stuff
| seemed to work... up until it didn't, and then cue wailing
| and gnashing of teeth. My Matter gear was initially a little
| flaky but is now vastly more reliable than Zigbee ever was.
| snickerdoodle12 wrote:
| Just look at how long this page is:
|
| https://www.home-assistant.io/integrations/matter/
|
| Adding a device now requires a whole song & dance with
| bluetooth, a mobile phone and god knows what else.
|
| Meanwhile zigbee is:
|
| 1. Buy a zigbee stick, there are dozens, they all work great
|
| 2. Press the permit join button in home assistant
|
| 3. Press a button on the device for 10 seconds or 3 times or
| whatever
|
| 4. You're done and it works!
|
| Oh, and for some reason https://www.home-
| assistant.io/integrations/matter/#experimen... involves
| google cloud in the process of me testing a device I created
| locally on my own network
|
| The final nail in the coffin is:
|
| > It is recommended to run the Matter add-on on Home
| Assistant OS. This is currently the only supported option.
| Other installation types are without support and at your own
| risk.
|
| So I can't even officially use this stuff without uprooting
| my entire operating system.
| amanda99 wrote:
| Look, I agree with you and as someone with Home Assistant,
| I much prefer Zigbee.
|
| But if you imagine a typical consumer, not a tech nerd, I
| think "smartphone and bluetooth" is by far preferable to
| your 4-step process.
| snickerdoodle12 wrote:
| To be fair, step 4 isn't a real step, step 1 is just
| buying the "hub" or "border router" or whatever, and step
| 2 & 3 are the same for Zigbee and Matter, the button is
| just somewhere else.
|
| A typical consumer has bought a zigbee hub (like they
| need to buy a thread border router), then use their phone
| to press a button in the app and then they press a button
| on the device. Still dead simple and doesn't require
| flaky bluetooth from their phone, which in 2025 most
| androids still suffer from.
| Marsymars wrote:
| I have stuff that didn't support Matter on launch, that I
| updated to Matter, and it seems exactly the same in practice.
| yesimahuman wrote:
| Unfortunately, the writing's on the wall for mainstream adoption
| of Zigbee. For me, Leviton not making any more Zigbee smart
| switches was the last straw and I've prioritized Z-wave devices
| where possible. I also get much better performance out of Z-wave.
| Sad to see though, as the Zigbee devices I do have are working
| just fine. I don't really get the point of Matter or Thread when
| Z-wave works so well.
| CharlesW wrote:
| It's pretty straightforward: Z-Wave is a closed (one company
| owns and controls the tech and brand) hub-bound mesh, and
| really should've been displaced by an open solution long ago.
| Matter is an industry-standard IPv6-based application layer
| that works over Thread (the successor to ZigBee) _and_ Wi-Fi.
| mox1 wrote:
| Z-wave also uses 900mhz in the US, which penetrates walls
| better and has less competition with 2.4 (Zigbee). So while
| its closed, it usually more performant than Zigbee (in my
| experience...)
| philjohn wrote:
| Yes - but it does feel over-engineered in some places (for
| good reason, having device profiles that everyone adheres to
| makes supporting a new device of a given class a doddle for
| smart home platforms) and it is definitely more finicky at
| present to pair devices than with Zigbee.
|
| If I had to wipe and re-setup my smart home with 100 Zigbee
| devices and 18 Matter over Thread devices (Tado smart
| thermostat and TRV's) the Zigbee devices would take me about
| half an hour in total to have back up and running in
| HomeAssistant, the Matter over Thread devices would take me
| around 2-3 hours as you have to pair them one-at-a-time.
| CharlesW wrote:
| > _If I had to wipe and re-setup my smart home with 100
| Zigbee devices..._
|
| FWIW, this is purely an HA issue, not a Matter one. Once HA
| includes the Matter credential store in backups/restores,
| the experience will be the same.
|
| Out of curiosity, what is the reason you find yourself
| completely wiping and re-pairing all of your Z-Wave
| devices?
| luckydata wrote:
| So you dropped a dying ecosystem for a very dead and buried
| underground one?
|
| Bold move.
| yesimahuman wrote:
| Is there some reason you felt compelled to comment on this,
| using that tone? Because it was completely uncalled for
| pmarreck wrote:
| I use some sort of cobbled together solution with Philips Vue
| lights, a couple of LIFX lights, halfway set up HomeKit, the Vue
| app, some Alexa integration, some sort of gateway that I believe
| connects Zigbee to my LAN...
|
| .. but all I can remember from growing up is the X-10 POWERHOUSE
| elcapitan wrote:
| Apparently "smart home" means that it's now a knowledge worker
| job to operate a lightswitch.
| tzs wrote:
| Warning: a bit of a rant incoming...
|
| I've found Matter totally confusing. Given a device that supports
| Matter (e.g., a smart plug) and a set of devices I want to
| control that from (e.g., an Amazon Echo and an iPad) it is not
| clear to me what else I need.
|
| Apparently I need a "controller", which is not necessarily the
| thing that I as a user would think of the controller--as a user I
| think of the controller as the device I issue command from. A
| Matter controller is apparently a hub for connecting the thing
| I'm using to issue commands to the IOT device I want to control.
|
| And maybe I need a "Thread border router"?
|
| As far as the controller goes, apparently at some point Apple
| added the ability for iPads to be Matter controllers, so you
| could use a Matter device with just an iPad (if the Matter device
| used WiFi...if it used Thread then you would need a separate
| Matter controller and I'd guess one of those Thread border
| routers).
|
| I was able to briefly use a Matter smart plug with my iPad
| without having a separate hub, but it stopped working not too
| long after. I deleted the plug from the iPad and did a factory
| reset on the plug and tried setting up again, but now when the
| iPad searches for the device during setup it doesn't even see it.
|
| Apple still has instructions on their site for setting up devices
| for direct use from iPad, but several sites on the net report
| that they actually dropped that support from iPad.
|
| So lets say I go get an actual Matter hub. Do I need a separate
| hubs for using my Matter devices from my Apple devices and using
| my Matter devices from my Amazon devices? How about if I need a
| Thread border router--will I need one for Apple and one for
| Amazon? What if I add Home Assistant later--am I going to need a
| third hub?
|
| All I'm really trying to do for now is use this one TP-Link Tapo
| smart plug that supports Matter from Apple Shortcuts without
| having to use the Tapo app. The Tapo app does integrate with
| Shortcuts but you have to be logged in to your TP-Link account on
| the app for it to work. Every so often you have to re-login,
| breaking your shortcuts until you do.
|
| What I'm currently considering is installing Home Assistant
| somewhere, probably in a VM on my Mac for now but latter on a
| dedicated RPi if the experiments in a VM show that it will work,
| and setting it up to be my Matter controller for the smart plug.
| Shortcuts (or Siri) won't be able to directly use Matter to
| control the plug with that setup, but there is a Home Assistant
| app for iOS/iPadOS that can do so and that supports Shortcuts.
|
| It will basically be like I'm doing now with the Tapo app but
| instead with the Home Assistant app and no need to be logged in
| to TP-Link (or to even have internet access).
|
| PS: I wouldn't need any of this if Apple would just get around to
| implementing for iPadOS the same 80% charge limit option that
| they have had on iOS for ages. I'm using the smart plug and
| Shortcuts as a kludge while waiting for that. I charge through
| the smart plug and have a Shortcut automation to turn off the
| smart plug when the iPad's battery level rises above 80%.
| imp0cat wrote:
| Some Amazon devices (see a list here:
| https://www.amazon.com/b?ie=UTF8&node=37490568011 ) already
| support Matter devices, so you might already have everything
| that you need. The Tapo 110M (M for Matter) plug for example
| can easily be paired with them and work flawlessly (an also
| much faster than the non-Matter counterparts). And yes, they
| don't need internet access to work.
|
| You still need the TP-Link app for some more advanced functions
| like power metering though.
| Gi-hun wrote:
| Leggi tutto
| AlexandrB wrote:
| Matter has been very disappointing so far, with very unreliable
| connectivity and behavior (using Apple TV as a border gateway). I
| basically gave up on it and prefer to use non-Matter HomeKit
| hardware (usually WiFi) where I can. Don't know if Zigbee was
| better, but it can hardly be worse.
| the_mitsuhiko wrote:
| I'm pretty sure this is misreporting, and these devices actually
| support Matter as well as Zigbee.
| jauntywundrkind wrote:
| The lamp+speaker is interesting. Wish it had usb-c for power, and
| or wireless charging.
|
| A pity there's no home standards for audio streaming. Matter Cast
| is an abomination, unfortunately: from what I can tell it
| requires native apps for each device, and there's not really an
| app store system, and indeed seemingly many devices only can
| stream via the pre-installed software!!
|
| Really emphasizes the incredible power of Netflix's DIAL
| protocol, which tells a device to go to a URL & opens some
| command channels. Which is, if you squint, what Chromecast 's
| protocol was for a long long time (now I think there's also the
| ability to ship native apps to devices too?).
|
| Really glad to see Ikea on board here. This creates a lot of
| pressure for other devices makers to modernize & use the much
| improved Matter stack, with much better network performance &
| much more standardization for Apple Google & potentially other
| control fabrics to make viable home systems, something Z-wave and
| Zigbee weren't positioned to make great progress on.
| aerostable_slug wrote:
| We could have had ZigBee Smart Energy Profile 2.0 running all of
| this, with the glory and righteousness of IP networking
| everywhere. Oh well...
| maxglute wrote:
| First daim chocolate, now zigbee...
| riknos314 wrote:
| This could easily have as much to do with support costs as
| anything with the technical side of the protocols.
|
| A member of my family works in customer support for a company
| making devices using both zigbee and thread, and claims that
| support calls for debugging zigbee are often among the longest
| (and thus most expensive) calls they handle.
|
| Unsure what IKEA's tech support looks like, but I assume that
| most issues not solved by support turn into returns, which are
| also bad for the bottom line.
___________________________________________________________________
(page generated 2025-07-09 23:01 UTC)