UDMI/DTDL/Watson/matter/ZigBee all try to do "universal device management over a single API", matter is just the latest incarnation.
Matter is already 20gb and suffering from API sprawl before it's even released. I don't think it has much of a future as "that protocol" beyond whatever corporate life support its on.
That's a load of bullshit. With Z-Wave I have a pick of over 20-30 vendors. Z-Wave is just as open as Matter. It's just not controlled by Google and/or Apple.
You may have choice, but a vast proportion of the market aren’t even aware of it, and wouldn’t know where to buy it. They see, understand, and seek out the branding for the ecosystem that they use already.
This is unfortunate, as I like free and open as much as the next HN user, but it’s the nature of innovation and socio-technical ecosystems.
I suspect it's a combination of NIH and the big players wanting to control the certification process and chip supply.
Z-Wave has been working perfectly fine for years. There have been protocol upgrades, new hardware, a pretty large ecosystem, etc. Zigbee apparently suffers from interop problems.
In my limited understanding there are two levels to it.
At the network level, plain Wi-Fi doesn't really cut it. To get reliable connections with lightbulbs and stuff you need a mesh network where each thing connects to nearby things and they form a network among themselves. That requires a wireless transport designed for the purpose. Zigbee is one such transport, and Thread (awful name) is a new one. Both are open standards, but the main advantage of Thread is that it doesn't need a central hub. It just needs a "border router" to talk to other networks (if things need to). Thread is based on IPv6.
At the application level, you need a protocol for controlling IoT stuff, that knows about those kinds of devices and allows an application to, for example, tell a lighbulb what colour to be. This has been done with vendor-specific protocols to date, over UDP or HTTP or whatever. Matter (also an awful name) is a new open standard for it. It can work over any IP network, including Thread ones (or WiFi or ethernet or whatever).
So between them, Matter and Thread should provide standards based connectivity and control for IoT devices, and as a key design requirement they should allow it all to work locally, i.e. without the cloud connection so many vendors have forced on people. They seem like Good Things to me.
The above is just what I've picked up and may contain inaccuracies, which I would appreciate being corrected upon.
Matter came around after I left, but I believe it is the same as CHIP:
* IEEE 802.15.4 (2.4 GHz PHY/MAC)
* 6LowPAN (IPv6 for constrained devies)
* Thread (Mesh network layer)
* UDP or CoAP (CoAP is like http for connectionless networks)
You need a bridge to connect CHIP to the internet (e.g. Apple Home). It was cool to route IP packets directly to lightbulbs from aws, but we don't bridge the networks in practice and all incoming/outgoing traffic goes through the bridge application.
I went to the matter web site and followed the instructions to install the SDK on a raspberry pi. I didn’t measure how much space it took but it installed dozens (hundreds?) of packages; it is extreme bloatware.
Just as an FYI if you're like me and wanted a Raspberry Pi for something like PiHole but don't want to pay insane prices there are tons of clones out there like the Orange Pi (or just google "Raspberry Pi Alternatives")
(Context: Matter is an application layer protocol to control smart home devices, bring them into your Wifi or Thread network, and they ought to work with Homekit/Google Home/Alexa/Smartthings/Home Assistant etc. at the same time)
I'm currently working on a Matter device myself and the overengineering is unreal.
The idea is great (standardized messages over IP, no internet required, open source SDK on Github) but if they had just used MQTT with some standardized JSON messages and two or three fixed onboarding flows it would have solved the same problems with 1% of the effort.
But now the project is absolutely massive, almost 1k pages for the base spec, 1M+ lines of (mostly C++) code for the core SDK, no stable or even well defined API, almost no documentation. Progress is glacial, unsuprisingly. Bug fixes do not seem to be backported to older release branches but there is no source code compatibility either, so the security story will be interesting for sure...
Most discussions seem to happen on an internal Discord server and Wiki for paying members only, so the project is not that open either.
I really hope that the entire thing gets scrapped and a simpler approach will rise from the ashes...
Last time I cloned the repository it was already over 20 GB, holy ***.
Having read the spec up and down a few times I think it's sound, my main complain would be the device attestation and blockchain usage for OTA. Also Matter inherited the very same thing that sucked most for Zigbee: manufacturer specific "enhancements" are valid, what could possibly go wrong.
> Matter aims to build a universal IPv6-based communication protocol for smart home devices. The protocol defines the application layer that will be deployed on devices and the different link layers to help maintain interoperability. The following diagram illustrates the normal operational mode of the stack:
> [...] It is built with market-proven technologies using Internet Protocol (IP) and is compatible with Thread and Wi-Fi network transports.
> Matter was developed by a Working Group within the Connectivity Standards Alliance (Alliance). This Working Group develops and promotes the adoption of the Matter standard, a royalty-free connectivity standard to increase compatibility among smart home products, with security as a fundamental design tenet. The vision that led major industry players to come together to build Matter is that smart connectivity should be simple, reliable, and interoperable.
> [...] The code examples show simple interactions, and are supported on multiple transports -- Wi-Fi and Thread -- starting with resource-constrained (i.e., memory, processing) silicon platforms to help ensure Matter’s scalability.
Would it make sense to have an mqtt transport for matter? Or a bridge; like homeassistant or similar?
I was disappointed when I saw that Matter chose to go with Thread. It's pretty terrible, even for home usage. I managed a solution that was initially based on Thread but moved it over to a proprietary 802.15.4 protocol.
- Entire network runs on a single radio channel... not very resistant to interference. Good luck in congested environments. Other protocols channel hop.
- Only had 15ish channels you can operate on as opposed to other protocols that have up to 40.
- If you have a lot of devices on the network, it can take hours for the mesh to form / re-form.
- Horrible for battery powered devices. You get contention with a lot of and or chatty devices. There's no scheduling for transmitting so you have to "listen" with your receiver on until you "hear" nothing, then you transmit. Switching to a protocol that uses time slotting more than doubled our device's battery life.
35 comments
[ 4.9 ms ] story [ 89.9 ms ] threadUDMI/DTDL/Watson/matter/ZigBee all try to do "universal device management over a single API", matter is just the latest incarnation.
Matter is already 20gb and suffering from API sprawl before it's even released. I don't think it has much of a future as "that protocol" beyond whatever corporate life support its on.
It’s intended to be universal.
This is unfortunate, as I like free and open as much as the next HN user, but it’s the nature of innovation and socio-technical ecosystems.
Z-Wave has been working perfectly fine for years. There have been protocol upgrades, new hardware, a pretty large ecosystem, etc. Zigbee apparently suffers from interop problems.
At the network level, plain Wi-Fi doesn't really cut it. To get reliable connections with lightbulbs and stuff you need a mesh network where each thing connects to nearby things and they form a network among themselves. That requires a wireless transport designed for the purpose. Zigbee is one such transport, and Thread (awful name) is a new one. Both are open standards, but the main advantage of Thread is that it doesn't need a central hub. It just needs a "border router" to talk to other networks (if things need to). Thread is based on IPv6.
At the application level, you need a protocol for controlling IoT stuff, that knows about those kinds of devices and allows an application to, for example, tell a lighbulb what colour to be. This has been done with vendor-specific protocols to date, over UDP or HTTP or whatever. Matter (also an awful name) is a new open standard for it. It can work over any IP network, including Thread ones (or WiFi or ethernet or whatever).
So between them, Matter and Thread should provide standards based connectivity and control for IoT devices, and as a key design requirement they should allow it all to work locally, i.e. without the cloud connection so many vendors have forced on people. They seem like Good Things to me.
The above is just what I've picked up and may contain inaccuracies, which I would appreciate being corrected upon.
This apparently allows to have an RPi act like a lamp-type device in that protocol, with control over the GPIOs
You need a bridge to connect CHIP to the internet (e.g. Apple Home). It was cool to route IP packets directly to lightbulbs from aws, but we don't bridge the networks in practice and all incoming/outgoing traffic goes through the bridge application.
> switch an LED or another device via a relay
> requires around 8GB of disk space
Bit late for april fools'
All this does is toggle a pin on and off.
https://docs.espressif.com/projects/esp-matter/en/main/esp32...
I'm currently working on a Matter device myself and the overengineering is unreal.
The idea is great (standardized messages over IP, no internet required, open source SDK on Github) but if they had just used MQTT with some standardized JSON messages and two or three fixed onboarding flows it would have solved the same problems with 1% of the effort.
But now the project is absolutely massive, almost 1k pages for the base spec, 1M+ lines of (mostly C++) code for the core SDK, no stable or even well defined API, almost no documentation. Progress is glacial, unsuprisingly. Bug fixes do not seem to be backported to older release branches but there is no source code compatibility either, so the security story will be interesting for sure...
Most discussions seem to happen on an internal Discord server and Wiki for paying members only, so the project is not that open either.
I really hope that the entire thing gets scrapped and a simpler approach will rise from the ashes...
Having read the spec up and down a few times I think it's sound, my main complain would be the device attestation and blockchain usage for OTA. Also Matter inherited the very same thing that sucked most for Zigbee: manufacturer specific "enhancements" are valid, what could possibly go wrong.
Do we need a new thing? ZigBee and mqtt already exist. Maybe something a little nicer over IP networks?
From https://github.com/project-chip/connectedhomeip#architecture... :
> Matter aims to build a universal IPv6-based communication protocol for smart home devices. The protocol defines the application layer that will be deployed on devices and the different link layers to help maintain interoperability. The following diagram illustrates the normal operational mode of the stack:
> [...] It is built with market-proven technologies using Internet Protocol (IP) and is compatible with Thread and Wi-Fi network transports.
> Matter was developed by a Working Group within the Connectivity Standards Alliance (Alliance). This Working Group develops and promotes the adoption of the Matter standard, a royalty-free connectivity standard to increase compatibility among smart home products, with security as a fundamental design tenet. The vision that led major industry players to come together to build Matter is that smart connectivity should be simple, reliable, and interoperable.
> [...] The code examples show simple interactions, and are supported on multiple transports -- Wi-Fi and Thread -- starting with resource-constrained (i.e., memory, processing) silicon platforms to help ensure Matter’s scalability.
Would it make sense to have an mqtt transport for matter? Or a bridge; like homeassistant or similar?
https://github.com/home-assistant/core#featured-integrations lists mqtt
Is there already a good (security) comparison of e.g. http basic auth, x10, ZigBee, mqtt, matter?
- Entire network runs on a single radio channel... not very resistant to interference. Good luck in congested environments. Other protocols channel hop.
- Only had 15ish channels you can operate on as opposed to other protocols that have up to 40.
- If you have a lot of devices on the network, it can take hours for the mesh to form / re-form.
- Horrible for battery powered devices. You get contention with a lot of and or chatty devices. There's no scheduling for transmitting so you have to "listen" with your receiver on until you "hear" nothing, then you transmit. Switching to a protocol that uses time slotting more than doubled our device's battery life.
The documentation of OpenThread is amazing, so I was excited.
> a proprietary 802.15.4 protocol
A licensed existing solution or something custom?
> Switching to a protocol that uses time slotting more than doubled our device's battery life.
Do you think this applies to most use cases?