Matter Raspberry Pi GPIO Commander – Turn Your Pi into a Matter Lighting Device
github.com
github.com
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?
We went with something licensed.
>Do you think this applies to most use cases?
I should have included "time slotting AND channel hopping." Given how congested the 2.4GHz band is, I think it does apply to a lot of battery powered use cases (especially wearables). Some use cases see a far greater benefit than others. The deployment environment also plays a big part.
If you have a lot of traffic on a channel, the radio hops to another channel so there's reduced error rates (reduced transmission reattempts = saved energy).
If you have a quiet radio environment and a lot of devices that communicate infrequently or a very small number of devices on the mesh, you may not see a huge benefit.
One downside of a time slot channel hopping protocol is that you need a more expensive crystal in your hardware for accurate time keeping/scheduling. Upside is that you have a reduced total cost of ownership as you need to buy fewer replaceable batteries.
> 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...
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.
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.