The Connectivity Standard Alliance (CSA) has just announced the release of the Matter 1.3 specification and SDK with energy reporting, support for water and energy management devices, electric vehicle chargers, several new “major appliances”, namely various kitchen appliances and laundry dryers, and various other features.
As a reminder the Matter protocol was initially introduced several years ago under the name Project CHIP to improve the interoperability of Smart Home devices from various vendors, so for example, users could connect a Matter-compatible Philips Hue light bulb to a Samsung gateway, or a white-brand Matter sensor with Google Home, etc… Matter started to pick last year with several products launched, and Paisit notably reviewed the MINI Extreme Wi-Fi Smart Switch (MINIR4M), the first Matter device from SONOFF, last October. Matter 1.3 adds various new capabilities and devices.
Matter 1.3 highlights:
- Support for Water and Energy Management Devices
- Energy Management – Matter 1.3 adds support for new energy reporting capabilities. This enables any device to report actual and estimated measurements, including instantaneous power, voltage, current, and others, in real-time, as well as its energy consumption or generation over time.
- Electric Vehicle Charging – Matter 1.3 enables new energy-centric devices starting with “Electric Vehicle Supply Equipment” (EVSE). EV charging equipment manufacturers can now offer consumers a way to better control how and when they charge their vehicles. Users can manually start or stop charging, adjust the charging rate, or specify how many miles or kilometers of range to be added by a set departure time. The charging station would then optimize the charging to occur at the cheapest and lowest carbon times.
- Water Management – Support for leak and freeze detectors, rain sensors, and controllable water valves.
- The following Major Appliance Types are added
- Microwave Ovens – Users can control the cooking time, power level, and mode of operation and receive notifications, such as “end of cycle” or “food ready” when the microwave completes operation.
- Ovens – This enables the configuration of the operational mode (standard, convection bake, roast, steam, broil/grill, proofing) and temperature control, and users can receive notifications such as preheating and target temperature achieved.
- Cooktops — Similar to above.
- Extractor Hoods (Cooker Hoods, Vent Hoods) — Users can control the light and fan settings and receive notifications about the status/end-of-life of any filter material used such as HEPA filters.
- Laundry Dryers — Matter 1.2 added support for laundry machines, so it should come as no surprise that the new Matter 1.3 specification adds support for laundry dryers, enabling users to set the dryer mode and target temperature and remotely start and stop the dryer (depending on local safety regulations). Users may also appreciate notifications such as “end of cycle” and alarms on error states.
- Improvements to Matter Casting Media Players and TVs – Matter 1.3 adds push messages and dialog support for new ambient experiences, casting initialization enhancements, expanded interactivity options for TV apps, text and track support, and improved search functionality. Other Matter devices can now also send notifications to TVs or other devices with displays (for instance to notify that a robot vacuum is stuck, the laundry is done, and so on)
Matter 1.3 also implements various other user experience enhancements and new features for developers such as improved network commissioning through WiFi bands and Thread version/features reporting. You’ll find the full list of changes in the announcement.
At least four documents are part of the Matter 1.3 specification:
- Matter 1.3 Core Specification
- Matter 1.3 Application Cluster Specification
- Matter 1.3 Device Library Specification
- Matter 1.3 Standard Namespace Specification
These are available from the download page, but require your full name, company name, and email address. I’m not sure why they are doing this, as you’ll receive the email immediately without human moderation… The Matter 1.3 SDK can be found on GitHub in the usual “connectedhomeip” repository.
Thanks to TLS for the tip.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
While not strictly related to Matter, thread has some pretty restrictive licensing about implementing devices conforming to the thread specifications – https://overengineer.dev/blog/2024/05/10/thread/ and they use the same “register to download” mechanisms as Matter. I would be carefully studying the Matter EULA when downloading the specifications to ensure the same draconian measures are not in place there.
Yeah, that “No right to implementation of the Specification is granted” was bonkers. You can develop in-house, but you can’t implement? I had to verify myself in case there was some missing context. I’d say no to using that too. I wouldn’t want to have to need to say I’m perpetually testing. It seems to also apply to using openthread (even though the original link to the FAQ is 404 from google’s page.
But a quick look at Matter’s EULA to d/l the spec is really short and sweet, and it mainly looks to only point to the docs aren’t “open” (aka, don’t distribute them), but nothing about anything else like you implementing Matter.
*Maybe* somewhere else they require anyone selling to first certify, but I hadn’t seen it, and I only intend to dev/use for myself.
Matter is protected by a block chain. There is a test ID which is not blocked, but everyone has to use the same test ID to test with so it is impossible to distribute anything using the test ID. This works fine if you are by yourself or in a small group. Of course this breaks down when you try to combine with someone else who is using the test ID.
To distribute a product you have to pass certification and be issued a crypto certificate. When your device is commissioned the validity of that certificate is verified at a CSA server (like SSL certificates). If it is not valid, you can’t join the Matter network. You can only get this certificate by paying the per product annual fee. It is unknown what they will do if you stop paying that fee. Will they revoke the certificate and render all of that vendor’s product inoperable?
You can simply ignore Thread like I did when implementing Matter devices. Thread is painfully slow. All of my devices are wifi based. For sensors I use Bluetooth and then bridge them into Matter.
The biggest problem with Matter is that it is pay to play. You have to pay $20,000/yr to be involved with the group. That rule causes only corporations to be involved with Matter which in turn prevents a community from forming.
In general I find this 1.3 spec to be useless. What they need to do is get the products from 1.0, 1.1 and 1.2 more stable. Google, Apple and Amazon all need to get 1.0, 1.1 and 1.2 supported in their apps before adding more unsupported stuff.
Same with most of these things sadly. To certify a Z-Wave product you had to join the Z-Wave alliance which was a bunch of money, plus an expensive certification fee and they limited to buying Z-Wave modules for a higher price, unless you bought a 100k chips…
The Open Connectivity Foundation (OCF) seems to be the only affordable one to join, as it’s $0 if you just want to read the documentation and implement it into a product. There’s some kind of certification cost though. Sadly it never really took off, despite having a lot of members. They also like to bicker about who is the most right into how something should be implemented, as all the big companies are of course right… (yes, I have attended one of their meetups and it was hell).
Matter is disjoint on how they operate. The code is open source, but then it is pretty much impossible to communicate with anyone working on it (you have to pay $20K to be able to talk to them).
There is nothing wrong with charging $20K to vote on the spec and use their lab in Portland. My objection is to closing off the development process. I think the development process should work like the Linux kernel where it is done in the open and then the maintainers sort out the good stuff from the noise. The maintainers would be equivalent to the paying Matter members and they’d get to control the final stages of accepting or rejecting.
For example, when Matter converted the Zigbee thermostat model over to Matter they removed the Zigbee style error notifications (errors like cooling too long and temp is not falling). I think these should have been converted to Matter events, but instead they just disappeared. Now there is no standard way for a thermostat to indicate an error condition. Was this done on purpose, or is it a mistake? I have no mechanism to ask the question. I file issues and no one responds. The answer to this is behind the paywall.
And here I thought it was bad working Z-Wave. This sounds utterly insane.
I can only agree with you and I voiced similar concerns with the Z-Wave alliance back in the day. Great way of locking a lot of potential products out of an ecosystem.
As for the error notifications, that just seems like someone wanted to make things easier for themselves without understanding the implications of what they did.
I think from their perspective they looked at it fresh as an MVP that everyone could support easily. I definitely agree that this was a mistake, what seems to have happened is where matter has been implemented, they support the basic protocol, but the more complete features became proprietary messages for each manufacturer, sort of making a mockery of using Matter in the first place.
I also think Matter is too slow adding additional devices types, clusters and attributes that already exist in the ZCL.
If you already have a Zigbee or Z-Wave device design then you can not simply convert it to a Matter device since chace is that Matter does nor have the devices type, clusters and attributes that you want to use.
I take the opposite position. I would like to see the addition of new device types stopped until the existing ones are fully supported in the core Google, Apple, Amazon apps. Google is still missing support for some device types in the Matter 1.0 spec! Adding more device types right now will just make everyone frustrated that Google, Apple, Amazon are going to get around to support them for another five years.
Allowing vendors to developing device types without allowing public comment typically ends up with device types which are only useful to that particular vendor. That then leads to iterating through many versions of the device types. Which then ends up with no one supporting all of the various iterations.